ISO 27001 Annex A 5.10: acceptable use policy that survives audit

The due-diligence questionnaire asks for your policy on generative AI. Your acceptable use policy dates from 2019 and never mentions it, and the auditor is about to sample your recent joiners. This guide to ISO 27001 Annex A 5.10 shows how a 25–250 person UK regulated firm can run a short, legally sound policy that holds up at Stage 2.

It covers what the control requires and what the policy should say. It then deals with AI tools, SaaS and personal devices, monitoring under UK GDPR, sign-off before access, what auditors sample and the automation that keeps evidence current. It is written for information security managers, heads of compliance and fractional CISOs.

What is ISO 27001 Annex A 5.10 and what changed in the 2022 revision?

ISO 27001 A.5.10 requires written, acknowledged rules for how people use company information and other associated assets, and for handling that information through its life. The 2022 revision merged two 2013 controls, acceptable use and asset handling, into one, with a sharper focus on authorised disposal and secure deletion.

If your policy predates 2022, the handling half is the likely gap. The rules section below shows how to close it without making the policy longer.

The control is smaller than it looks. You need a short policy, handling rules borrowed from your classification scheme and an acknowledgement habit. Three things should exist first:

• A policy framework that gives the acceptable use policy a home and an approval route.
• An asset picture: the inventory of systems, services and data stores the rules apply to.
• Classification tiers, which supply the handling rules so the policy does not repeat them.

With those in place, drafting takes days rather than weeks. After that, the policy becomes a standing part of onboarding instead of a project.

What does A.5.10 acceptable use of information and other associated assets require?

A.5.10 acceptable use of information and other associated assets requires three things. The first is a topic-level acceptable use policy stating expected behaviour, prohibited behaviour and monitoring. The second is handling procedures that follow information through creation, storage, sharing, return and destruction. The third is a scope covering assets you do not own. Everyone with access must know the rules.

A topic-level policy sits beneath your top-level information security policy and deals with one subject in detail. Here the subject is behaviour. The control is preventive, because clear rules and the guardrails behind them stop misuse before it becomes an incident. All three security properties are in play:

• Confidentiality: misuse leaks data, such as customer records pasted into a free chatbot.
• Integrity: misuse corrupts data, such as unapproved tools editing or processing records.
• Availability: malware or resource abuse, such as crypto mining on company kit, takes systems down.

The scope is the part people miss. Public cloud services, collaboration platforms and personal devices used for work all carry your data, so the rules travel with it. Ownership of the asset is not the boundary. The presence of your information is.

The people scope is as wide as the asset scope. "Everyone with access" includes contractors and third parties as well as employees, so a supplier's engineer with a login is covered too.

Which acceptable use policy rules does ISO 27001 Annex A acceptable use of information and other associated assets need?

A good AUP runs to a few pages, in plain language, and covers three things: behaviour you expect, behaviour you prohibit and the monitoring you perform. Handling rules then borrow your classification tiers, so confidential material gets restrictive handling, and the lifecycle includes copies, media labelling and destruction.

Draft the acceptable use policy in three blocks. Each is something an auditor checks off:

• Expected behaviour: reasonable personal use, an approved AI tool used within its guardrails, prompt reporting of lost devices.
• Prohibited behaviour: pasting confidential data into public AI tools, unapproved SaaS sign-ups, pirated software, crypto mining on company kit.
• Monitoring position: what you watch and why, written to match what is actually running.

Saying what is allowed makes the prohibitions credible. A policy that only forbids reads as a list of ways to get into trouble.

Pointing to your classification tiers keeps the handling rules short. Confidential material gets tight rules on sharing, storage and transfer, while public material gets none. You define the tiers once in the classification scheme, and the policy refers to them.

Lifecycle amnesia is the gap to avoid. A policy that covers using systems but says nothing about copies, media labelling or destruction misses the handling half of the control. Ask where a confidential file goes when the project ends, then write down who deletes it and how the deletion is recorded.

A thirty-page AUP is a document nobody finished reading, whatever it says.

The auditor's interview question is simple: can your people state the rules they signed? That tests the policy's length and wording as much as your staff's memory.

How should an AUP cover generative AI, shadow SaaS and personal devices?

An AUP should name public AI tools, personal cloud storage, unapproved SaaS sign-ups and personal devices explicitly, because A.5.10 follows the data, not the hardware. Company information on a BYOD laptop or in a supplier's platform is still company information. Pair every prohibition with an approved route, such as an enterprise AI tool.

Staff pasting customer records into free AI chatbots is today's version of the USB stick in the car park. The NCSC advisory on the risks of shadow AI warns that employees who send sensitive information to consumer AI services are likely to reduce the organisation's visibility and control over it. Enterprise security questionnaires and audit interviews now ask for your position.

Give each risk a named rule and an approved route:

• Public AI tools: prohibit pasting confidential or client data, and provide an enterprise tool with data protections.
• Unapproved SaaS: make SSO the front door to approved apps, and send new tools through a light review: who the supplier is, where the data sits and whether the contract covers deletion at exit.
• Personal cloud storage: prohibit company files there, and provide a sanctioned sharing route.
• Personal devices: allow access under MDM device policy, with the rules applying in full.

The NCSC Bring Your Own Device (BYOD) guidance states the principle. The organisation owns the corporate data on a device even though the user owns the hardware. Supplier platforms work the same way, and the contract is where your handling expectations land.

The failure case is a 2019-vintage policy, silent on AI tools, SaaS sprawl and personal devices, read by a workforce that lives in all three. It is out of date on the day it ships. The annual review should ask what staff now use, not only what the policy now says.

How do workplace monitoring disclosures fit UK GDPR and ICO expectations?

Annex A 5.10 expects the AUP to state that monitoring happens, and UK GDPR makes that disclosure a legal duty. Employers must tell workers clearly what is monitored, why and to what extent. List what you actually watch, such as email filtering, web logs and device management, and have the wording checked against employment law.

The ICO guidance on workplace monitoring and worker data protection goes beyond disclosure alone. Workers have the right to be informed, in a way that is accessible and easy to understand. You must also identify a lawful basis, and monitor only in ways workers would reasonably expect.

A monitoring clause that stands up names four things:

• The tools actually running: email filtering, web logs and device management.
• The purpose of each, in terms a worker would recognise.
• Where workers read it: inside the AUP they accept at onboarding, not in a handbook appendix.
• A legal check: employment-law review of the wording before it ships.

Overstating is as risky as staying silent. A policy that claims a level of monitoring you do not run creates legal exposure of its own.

Undisclosed monitoring is a bigger liability than most of the misuse it catches.

A disciplinary case built on monitoring data the worker was never told about is a weak case. Disclosure makes the evidence usable as well as lawful.

How do you gate AUP acknowledgement for employees, contractors and third parties?

Collect acknowledgement before access: a signature or digital tick during onboarding, before accounts and kit are issued, with contractors and third parties included. Wire the HR joiner event to raise the acceptance task and make account provisioning wait on it, then re-run acceptance annually and on material policy change.

Build the gate, and its exit, as a sequence the systems enforce:

1. Raise the task from the joiner event. One trigger covers employees and contractors, so neither route skips it.
2. Hold provisioning. Account activation and kit dispatch wait until the acceptance is recorded.
3. Bring third parties in. Anyone external with access to your information accepts the rules or is bound to them by contract.
4. Reopen on schedule and on change. The annual cycle and any material revision issue a fresh task.
5. Keep a dated record. Each acknowledgement carries a timestamp that reconciles against the joiner list.
6. Close the loop at the leaver event. Offboarding recovers kit, licences and access, and records the return. The detail belongs to A.5.11, return of assets.

Contractors are the classic gap. They often arrive through procurement rather than HR, so the joiner event never fires. Contractor gaps are among the most common findings against this control. Routing their starts through the same record closes that side door.

A document checklist asks whether you hold acceptance records. A gate makes the record a by-product of onboarding, so the answer is always yes.

A publish-and-forget policy binds no one. HR cannot discipline misuse, and lawyers cannot defend the company's position, without a rule the person can be shown to have accepted.

What do auditors sample at Stage 2 and how are non-conformities graded?

Auditors trace recent joiners from start date to acknowledgement date, test enforcement claims against live configuration, and interview staff on the rules they signed. Certification bodies usually grade no AUP, an unaccepted AUP or a policy contradicted by practice as major. A missed acknowledgement or a review older than twelve months is minor, but a pattern becomes major.

The common pitfalls each show up as a specific finding:

• Publish-and-forget: an AUP nobody was asked to accept grades major.
• Rules with no guardrails: a policy contradicted by observed practice grades major, because the auditor wants the control, not the sentence.
• A policy silent on AI, SaaS and personal devices: staff interviews expose it when people cannot state rules that fit how they work.
• Silent or overstated monitoring: the request "show me where you tell them" has no answer.

Expect questions on who approved the rules, when they were last reviewed and how a contractor starting Monday learns them. Expect others on what technically stops the prohibited cases and what happens when someone breaks them.

Walk in with the evidence assembled:

• The current AUP, with its approval trail and a review inside twelve months.
• Acknowledgement records that reconcile against the joiner list, contractors included.
• Training content and completion logs.
• The access model, showing that access restrictions follow your classification tiers.
• Enforcement configuration: filtering rules, device policies, the SSO catalogue and DLP alerts where deployed.
• Offboarding and kit-return records, plus investigation records where violations occurred.

With that folder ready, the Stage 2 sample becomes a reconciliation exercise rather than a surprise.

How can GRC engineering automate acknowledgement tracking and guardrail drift detection?

Automation fixes the AUP's two weak points: acknowledgement decay and enforcement drift. Shadow-SaaS discovery from the IdP catalogue and expense data raises review tickets. Scheduled exports of filtering, MDM and DLP settings prove the guardrails match the policy text. Violation alerts go to a case queue that tracks outcomes.

Four automations carry the load:

• Acknowledgement campaigns. The annual re-acceptance runs as a campaign with completion tracked, building on the joiner gate described above. The auditor's reconciliation becomes an export.
• Shadow-SaaS discovery. The IdP application catalogue and expense data give a continuously updated picture of what is in use. A new unapproved app raises a review ticket, which turns the policy's hardest prohibition into a monitored control.
• Enforcement config as evidence. Filtering rules, device policies and DLP rules are exported on a schedule. Drift between an export and the policy text raises an alert.
• Violation workflow. Alerts reach a case queue with tracked outcomes, so "does the policy have teeth?" is answered with data rather than anecdote.

A policy that bans what your estate permits is a statement of intent, not a control.

The commercial upside arrives at the questionnaire. "What is your policy on generative AI?" gets an answer backed by an acknowledgement export and a filtering configuration, not a PDF.

Frequently asked questions