ISO 27001 Acceptable Use Policy: Complete 2026 Guide

An ISO 27001 acceptable use policy is one of the very few documents the standard’s Annex A asks for by name, and most organizations still ship half of it. Control A.5.10 does not just want rules about personal email and USB sticks. It wants rules for acceptable use and procedures for handling information, and it says both must be identified, documented and implemented. That single word — documented — puts A.5.10 in a different category from almost every other control in Annex A, and it is the reason an auditor can raise a nonconformity against you for a missing policy here when they cannot do the same for anti-malware or network security.

This guide covers what an ISO 27001 acceptable use policy actually requires under A.5.10, the handling-procedure limb that competitor templates leave out, the monitoring disclosure that protects you legally as well as technically, and the evidence a Stage 2 auditor will ask for. Figures and cadences are given as typical practice, clearly labelled, because the standard itself states no frequency anywhere in this control.

The One Word That Makes an ISO 27001 Acceptable Use Policy Mandatory

Readers of this blog will have seen a recurring line in our control-by-control guides: an Annex A control usually does not demand a policy. A.8.7 never says “documented”. Neither does A.8.6, A.8.20, A.8.22 or A.8.23. You can satisfy those controls with configuration and records and still have no policy document at all.

A.5.10 breaks that pattern. Its control text requires that the rules for acceptable use and the procedures for handling information and other associated assets be identified, documented and implemented. Its stated purpose is to ensure information and other associated assets are appropriately protected, used and handled. Three verbs, and the middle one is the one that bites: identification without a document is an opinion, and implementation without a document is a habit.

That makes A.5.10 a member of a short group of Annex A controls whose own wording calls for documentation rather than merely for a practice. The others worth knowing are A.5.31, which requires legal, statutory, regulatory and contractual requirements to be identified, documented and kept up to date; A.5.37, whose title is literally “Documented operating procedures”; and A.8.27, which requires principles for engineering secure systems to be established, documented, maintained and applied. If a control you are implementing is not on that list, a policy is a design choice. If it is on that list, a policy is the control.

One important qualifier. The AUP is not a clause-level mandatory document. Our ISO 27001 Mandatory Documents Checklist (2022) lists 7 documents and 6 record categories that clauses 4 through 10 demand regardless of your risk assessment. The AUP is not among them, because Annex A controls are applied through the Statement of Applicability under clause 6.1.3. In practice, though, nobody excludes A.5.10 — there is no credible justification for an organization that handles information deciding it needs no rules about how that information is used. So the ISO 27001 acceptable use policy is conditionally mandatory in theory and unconditionally expected in practice.

What A.5.10 Covers — and the Half Everyone Skips

A.5.10 is not a new 2022 invention. It is a merge of two controls from the 2013 edition, and the merge is the single most useful thing to understand about it, because the two ancestors answer different questions and almost every template on the market answers only the first.

Limb of A.5.10	2013 ancestor	Question it answers	Typical state of maturity
Rules for acceptable use	A.8.1.3 Acceptable use of assets	What may a person do with company information and equipment?	Usually present, often as an HR document
Procedures for handling information and other associated assets	A.8.2.3 Handling of assets	How must information at each classification level be accessed, copied, stored, labelled and destroyed?	Usually missing, or scattered across unrelated documents

Read your own ISO 27001 acceptable use policy against that table. If it tells people not to install unlicensed software and not to use work email for personal business, it answers A.8.1.3. If it says nothing about how a Confidential document must be stored, how copies of it must be marked, who is allowed to authorise its destruction and by what method, then the A.8.2.3 half of A.5.10 is unimplemented — and because the control text is one sentence covering both, an auditor sampling the handling limb is sampling A.5.10, not some optional extra.

This is the gap that produces most findings against this control. The ISO 27001 acceptable use policy exists, it has an approval date, staff have acknowledged it, and it still fails because the handling procedures it was supposed to carry do not exist anywhere.

What an ISO 27001 Acceptable Use Policy Must Say

ISO/IEC 27002:2022 gives three things the topic-specific policy behind an ISO 27001 acceptable use policy should address. They are short enough to memorise and specific enough to audit against.

27002 requirement	What to write	Evidence it is real
Expected and unacceptable behaviour of individuals, from an information security perspective	Positive duties (lock your screen, report suspected incidents, use the approved password manager) and prohibitions (no shared credentials, no shadow SaaS, no forwarding work mail to personal accounts)	The policy text, plus incident records showing the prohibitions get enforced rather than ignored
Permitted and prohibited use of information and other associated assets	Per asset class: endpoints, removable media, networks, email and messaging, cloud services, software installation, printing, personal use of company equipment, company use of personal equipment	Technical enforcement where it exists (application control, web filtering, DLP) and a documented exception route where it does not
Monitoring activities being performed by the organization	A plain statement of what is logged and inspected — endpoint telemetry, web traffic categories, email content scanning, DLP inspection, access logs — and for what purpose	The disclosure in the policy matched against the monitoring you actually run under A.8.15, A.8.16 and A.8.23

That third row is the one commercial templates almost never carry, and it is the one that does double duty. More on it below.

Note what is not in the list. The standard does not tell you to ban social media, set a personal-use percentage, or specify a password length. Those are your risk decisions. A good ISO 27001 acceptable use policy is specific because your risk assessment made it specific, not because a template filled in the blanks for you.

The Handling Procedures Your ISO 27001 Acceptable Use Policy Also Needs

The A.8.2.3 half of the control is where 27002 gets concrete, and it is the half your ISO 27001 acceptable use policy has to carry as well as the rules. Its guidance asks for procedures covering the whole life of the information, and they key off your classification scheme rather than off job titles. Paraphrased, the limbs are:

• Access restrictions that support the protection requirements of each classification level — so the scheme has to state protection requirements, not just names.
• Records of authorised users of the assets, which is the limb that connects A.5.10 to your access-review evidence.
• Protection of temporary and permanent copies at a level consistent with the original. An export to a spreadsheet does not get to be less protected than the system it came from.
• Storage in accordance with manufacturers’ specifications — the physical-media limb, easy to forget and easy to evidence.
• Clear marking of all copies of storage media for the attention of the authorised recipient, which ties straight to labelling under A.5.13.
• Authorisation of disposal, with deletion methods appropriate to the information. Who signs off, and what method, per level.

The practical way to deliver this is a one-page handling matrix appended to the policy, with a row per classification level and a column per lifecycle stage. Here is the shape of one — the values are an illustrative example for a four-level scheme, not a requirement of the standard:

Lifecycle stage	Public	Internal	Confidential	Restricted
Access	No restriction	All staff	Named role groups; access reviewed	Named individuals; owner approval per grant
Labelling	Optional	Footer marking	Footer marking on every page and on media	Footer marking, media marking, recipient named
Storage	Any approved system	Approved systems only	Approved systems; encryption at rest	Approved systems; encryption at rest; no local copies
Copies and extracts	Unrestricted	Permitted	Permitted to approved locations only	Owner approval; copy register entry
Transfer	Unrestricted	Corporate channels	Encrypted channels; recipient verified	Encrypted channels; agreement in place; delivery confirmed
Removable media	Permitted	Encrypted media only	Encrypted media, registered, owner approval	Prohibited unless owner approves in writing
Disposal	Delete	Delete	Secure deletion; record kept	Secure deletion or destruction; certificate retained

If you already have a classification scheme, this matrix is a two-hour job and it closes the biggest gap in the control. If you do not, start there — our guide to Data Classification: 6 Proven Steps for ISO 27001 covers how to build a scheme that handling procedures can actually key off, and how A.5.12 and A.5.13 divide the work between classifying and labelling.

The Monitoring Disclosure That Protects You Both Ways

The requirement to tell people, in the ISO 27001 acceptable use policy, about the monitoring you perform looks like a courtesy. It is not. It is the hinge between your technical controls and your lawful authority to run them.

Think about what you are actually doing on a managed endpoint: inspecting web traffic categories under A.8.23, collecting process and authentication telemetry under A.8.15, running anomaly detection under A.8.16, and inspecting content for data leakage under A.8.12. Every one of those reads information about an identifiable person. In most jurisdictions that is employee monitoring, and employee monitoring generally depends on transparency — you have to have told people, in advance, in terms they can understand. Our analysis of Employee Monitoring and Legitimate Interests 2026 works through how that balancing test is actually documented.

So the disclosure paragraph in your ISO 27001 acceptable use policy is doing three jobs at once. It satisfies the third limb of 27002’s policy guidance. It supplies the transparency your monitoring needs to stand up. And it makes the prohibitions enforceable, because a rule nobody was told about, policed by surveillance nobody was told about, is very hard to discipline anyone over.

Two failure modes to avoid in the ISO 27001 acceptable use policy. The first is the vague gesture — “the company may monitor use of its systems” — which tells nobody anything and will not survive a privacy review. The second is the opposite: a disclosure listing tools you no longer run, or omitting the DLP you deployed last quarter. Keep the disclosure synchronised with reality, and add “has the monitoring disclosure changed?” to your change process for any new inspection capability. If you are deploying content inspection, our guide to ISO 27001 Data Leakage Prevention: Complete 2026 Guide covers the A.8.12 side of that decision.

Scope: Who and What an ISO 27001 Acceptable Use Policy Reaches

27002 scopes 5.10 — and therefore the reach of your ISO 27001 acceptable use policy — to all members of the organization and to assets owned or operated by the organization. Both halves of that are wider than people assume.

“All members” includes non-employees. Contractors, temporary staff, interns and third-party engineers using your systems are in scope. The practical consequence is that the acknowledgement route for your ISO 27001 acceptable use policy cannot be the HR onboarding flow alone, because the HR flow does not touch a contractor engaged through procurement. Most organizations discover this when an auditor samples five people with system access and one of them has no acknowledgement record because they were never an employee.

“Owned or operated” includes the cloud. A SaaS tenancy you configure and administer is an asset you operate even though you own none of the hardware. So acceptable use rules have to cover behaviour inside third-party services — what may be uploaded to which tenancy, which external services are approved at all, and what happens to data in a service you stop using. Where the asset belongs to a provider, the enforcement path runs through the contract rather than through your own configuration, which is why A.5.10 and your supplier agreements have to say compatible things.

And it reaches personal equipment you permit. If staff use their own phones or laptops for work, the asset is not yours but the information is, so the handling procedures still apply. That is a different control set — see our BYOD Policy: The Essential 2026 Guide for ISO 27001 — but the AUP is where the two documents have to agree on what “work use” of a personal device means.

One accountability point that catches people out: delegating a handling duty does not move the accountability. An asset owner who hands day-to-day custody to a team is still the owner for A.5.9 purposes and still answerable for whether the handling procedures were followed.

Acknowledgement: ISO 27001 Does Not Require a Signature. NIST Does.

Here is a claim you will see repeated across the market: ISO 27001 requires signed acceptance of the ISO 27001 acceptable use policy. It does not. A.5.10 says identified, documented and implemented. It says nothing about signatures, acknowledgements, annual re-acceptance or completion rates. Neither does it state any review frequency — the annual cadence everybody runs is convention, and you should present it to an auditor as your decision rather than as the standard’s instruction.

Where the signature requirement genuinely lives, in ISO terms, is next door. A.6.2 puts information security responsibilities into the terms and conditions of employment, and A.6.6 covers confidentiality and non-disclosure agreements. Those are the controls that bind a person to the rules. A.5.10 writes the rules; A.6.2 makes them contractual; ISO 27001 Security Awareness Training: Complete 2026 Guide covers the A.6.3 and clause 7.2/7.3 machinery that makes sure people actually know them.

The explicit acknowledgement requirement comes from NIST. SP 800-53 Rev. 5 control PL-4 Rules of Behavior has four parts, and they are a better specification for the administrative side of an ISO 27001 acceptable use policy than anything in ISO:

• Establish and provide to individuals requiring access the rules describing their responsibilities and expected behaviour for information and system usage, security and privacy.
• Receive a documented acknowledgment that they have read, understand and agree to abide by the rules before authorising access.
• Review and update the rules at an organization-defined frequency.
• Require individuals who acknowledged a previous version to read and re-acknowledge at a defined frequency, or when the rules are revised.

NIST also notes that the documented acknowledgment can be satisfied through literacy and role-based training programs where those include the rules of behaviour, and that electronic signatures, agreement checkboxes and radio buttons all count as documented acknowledgements. That is a useful, citable answer to the “does an LMS tick-box count?” question.

PL-4 has exactly one enhancement in Rev. 5, and it is worth adopting: PL-4(1) Social Media and External Site/Application Usage Restrictions asks the rules to address social media and external sites and applications, the posting of organizational information on public sites, and — the item almost nobody writes down — the use of organization-provided identifiers such as work email addresses and organization-provided authentication secrets such as passwords to create accounts on external sites. If your acceptable use rules say nothing about staff registering for third-party services with their work address and a reused password, that is the gap to close this week.

How A.5.10 Maps to NIST and CIS

Three free, public control sets cover the same ground as an ISO 27001 acceptable use policy and give you defensible detail the standard deliberately leaves open.

A.5.10 limb	NIST SP 800-53 Rev. 5	CIS Controls v8.1	What the external set adds
Rules of acceptable use	PL-4 Rules of Behavior; PL-4(1) social media and external sites	14.1 Establish and Maintain a Security Awareness Program (Documentation, Govern, IG1)	The acknowledgement and re-acknowledgement mechanics ISO omits
Handling procedures	—	3.1 Establish and Maintain a Data Management Process (Data, Govern, IG1)	A named list of what the process must address: data sensitivity, data owner, handling of data, retention limits, disposal requirements
Classification-keyed protection	—	3.7 Establish and Maintain a Data Classification Scheme (Data, Identify, IG2)	Confirms the scheme itself is a later-maturity item than the process that uses it
Retention and disposal	—	3.4 Enforce Data Retention (IG1); 3.5 Securely Dispose of Data (IG1)	Retention needs minimum and maximum timelines; disposal method must be commensurate with sensitivity
Making handling stick	—	14.4 Train Workforce on Data Handling Best Practices (Users, Protect, IG1)	Names the behaviours to train: store, transfer, archive and destroy sensitive data, plus clear screen and desk

Two things fall out of that mapping. First, CIS puts the data management process at IG1 — the baseline tier — while the classification scheme that keys it sits at IG2. If you are a 20-person company arguing about proportionality, that is your answer: write the process now, refine the scheme later. Second, the handling half of A.5.10 has no NIST SP 800-53 analogue in the planning family at all; it lives in the media protection and data families. That is a hint about why the handling limb gets orphaned — it does not belong to the same team as the policy.

Both reference sets are free. The NIST SP 800-53 Rev. 5 catalog and the CIS Controls v8.1 Assessment Specification both publish full control text at no cost, and the ISO standard itself is described on iso.org/standard/27001, currently Edition 3, dated 2022-10, with Amendment 1:2024 available separately at no charge.

ISO 27001 Acceptable Use Policy Evidence Your Auditor Will Ask For

A Stage 2 auditor will not read your ISO 27001 acceptable use policy and move on. They will test whether it is identified, documented and implemented, which means sampling. Prepare these six items:

Evidence	What it proves	Common failure
Approved, dated, version-controlled policy	The “documented” verb	Draft status, or an approval date older than a major change to the estate
Handling matrix or equivalent procedures, keyed to the classification scheme	The A.8.2.3 half of the control	Absent entirely; or present but using classification labels the scheme does not define
Acknowledgement register covering employees and contractors	Communication and, with A.6.2, contractual force	Employees complete, contractors missing; no record for people who joined mid-cycle
Monitoring disclosure matched to deployed monitoring	The third 27002 policy limb, and your lawful basis	Disclosure describes last year’s tooling
Enforcement records — exceptions approved, breaches handled	“Implemented”, as opposed to published	No exception route, so undocumented workarounds are the real policy
Disposal authorisations and destruction records for a sampled asset	The last handling limb, end to end	Certificates exist for hardware but not for data in retired cloud tenancies

The fifth row is the one that separates a mature ISMS from a documented one. If your ISO 27001 acceptable use policy prohibits something that 40 people need to do, and there is no exception process, then those 40 people are non-compliant by design and your policy is evidence against you. An exception register with named approvers and expiry dates turns the same situation into a working control.

Five ISO 27001 Acceptable Use Policy Mistakes That Cost Findings

1. Writing only the rules half. The handling procedures are in the same control sentence. A policy with no handling matrix leaves A.5.10 partly unimplemented and gives the auditor an easy sample to fail.
2. Letting HR own it alone. An ISO 27001 acceptable use policy often lives in the staff handbook, which means the information security team never reviews them and the monitoring disclosure never gets updated when a new inspection tool is deployed. Keep it in the ISMS document set, cross-referenced from the handbook.
3. Prohibiting what you cannot enforce or detect. A ban on personal cloud storage with no application control, no web filtering category block and no DLP rule is a sentence, not a control. Either enforce it (see ISO 27001 Web Filtering: Complete A.8.23 Guide 2026), monitor it, or stop claiming it.
4. Treating classification labels as decoration. If the policy says Confidential information must be handled differently but the scheme never states what protection each level requires, the handling procedures have nothing to key off and the matrix cannot be written.
5. Claiming the standard requires annual signed acceptance. It does not, and an auditor who knows the text will notice you citing requirements that are not there. Present the cadence as your risk decision, then meet it.

Where the ISO 27001 Acceptable Use Policy Sits in Your Document Set

The ISO 27001 acceptable use policy is a hub document, which is why it is worth getting right early. The rules it carries depend on decisions made elsewhere, and other controls depend on the rules it states.

Related control	Relationship to the AUP
A.5.9 Inventory of information and other associated assets	Supplies the asset classes the rules apply to, and the owners accountable for them
A.5.11 Return of assets	The exit half of acceptable use; the AUP should state the return obligation
A.5.12 / A.5.13 Classification and labelling	Provides the levels and marking rules the handling matrix keys off
A.5.14 Information transfer	Takes over where “may I send this out?” becomes a channel and agreement question
A.6.2 Terms and conditions of employment	Makes the rules contractual; the AUP supplies the content
A.6.3 Awareness, education and training	Makes the rules known; CIS 14.4 names the handling behaviours to train
A.7.7 Clear desk and clear screen	The physical expression of several handling rules — see our Clean Desk Policy: 9 Essential Rules for 2026
A.8.1 User endpoint devices	Enforces endpoint-specific rules the AUP states
A.8.10 / A.8.12 Information deletion and data leakage prevention	Technical enforcement of the disposal and copy-protection handling limbs

For the full picture of how A.5.10 sits inside the 93 controls and 4 themes of the 2022 edition, start with ISO 27001 Annex A Controls Explained (2022), which walks the 37 organizational, 8 people, 14 physical and 34 technological controls and how the Statement of Applicability under clause 6.1.3 records your decision on each one.

ISO 27001 Acceptable Use Policy FAQ

Is an ISO 27001 acceptable use policy mandatory?

Effectively yes, with a technical caveat. It is not one of the clause-level mandatory documents, because Annex A controls are applied through the Statement of Applicability. But A.5.10’s own text requires the rules and handling procedures to be documented, so if the control is applicable — and for any organization that handles information, it is — a document is the control, not an optional extra.

How often must an ISO 27001 acceptable use policy be reviewed?

ISO 27001:2022 states no frequency in A.5.10, and ISO/IEC 27002 gives none for this control either. Annual review is the common convention and a reasonable default; the defensible answer is to review on a cadence you set and documented, plus on trigger events — a new monitoring capability, a new asset class, a merger, or a material incident. NIST PL-4 takes the same approach, leaving the frequency organization-defined but requiring re-acknowledgement when the rules change.

Does ISO 27001 require staff to sign the acceptable use policy?

No. A.5.10 says nothing about signatures. The contractual binding comes from A.6.2 terms and conditions of employment and A.6.6 confidentiality agreements. If you want an explicit acknowledgement requirement to point at, use NIST SP 800-53 Rev. 5 PL-4, which requires a documented acknowledgment before access is authorised and accepts electronic signatures, checkboxes or training completion records as that acknowledgement.

Can one ISO 27001 acceptable use policy cover employees and contractors?

Yes, and it usually should, because 27002 scopes the control to all members of the organization. What cannot be shared is the acknowledgement route: contractors rarely pass through the HR onboarding flow, so build a second path through procurement or your access-provisioning process and keep both registers in one place for sampling.

What is the difference between A.5.10 and an IT policy?

An IT policy typically describes what the IT function will do. A.5.10 describes what every person must and must not do with information, plus how information at each classification level must be handled through its life. The scopes overlap but the audiences differ, and merging them tends to bury the handling procedures inside operational detail nobody outside IT reads.

Skip months of drafting with an auditor-written toolkit

Writing an ISO 27001 acceptable use policy that carries both limbs — the rules and the classification-keyed handling procedures — is a week of work if you start from nothing, and most of that week goes on the matrix rather than the prose. The ISO 27001 Toolkit ships 165 comprehensive templates covering the ISMS end to end, aligned to ISO/IEC 27001:2022 including Amendment 1:2024, for $149 with 12 months of free updates. The acceptable use, classification, asset inventory and handling documents are already consistent with one another, which is the part that takes longest to get right when you write them separately.