ISO 27001 Control 5.10 Acceptable Use of Information and Other Associated Assets

Alan Parker, ISO 27001 Consultant & Internal Auditor,
Helping UK SMEs hit ISO 27001 in 90 days.
B.Sc (Hons) Information Systems · Certified ISO 27001 Lead Auditor · CISMP · ITIL Expert · 30+ years in IT governance and security.
Read full bio →

ISO 27001 Control 5.10 Acceptable Use of Information and Other Associated Assets

Under control 5.10, ISO 27001 requires organisations to provide guidance to staff and other stakeholders on the use of information assets. Typically, this is addressed through an Acceptable Use Policy.

According to the UK Government’s Cyber Security Breaches Survey 2025/2026, 43% of UK businesses experienced a cyber breach or attack in the last 12 months. Of those, 69% cited phishing as the most disruptive incident type, and 38% specifically experienced phishing attacks. These are not technical breaches in any sophisticated sense; they occur because of how staff interact with information. The AUP is the document that most directly shapes that interaction.

Despite this, only 19% of UK businesses provided cybersecurity training to their staff in the past year. The combination matters: writing a good AUP is one thing; making sure staff have actually read it, understood it, and been trained to follow it is what closes the gap between policy and practice.

Purpose of the Control

Control 5.10 requires you to lay out the basic expectations regarding the use of information assets and what staff deem acceptable and unacceptable. The standard asks that you define a policy around it (often called the AUP / Acceptable Use Policy) and communicate those expectations to stakeholders.

Most of us think of acceptable use as work-issued laptops, phones, etc., but extend that thinking a little further to cloud services, data itself under certain classifications, and anything used to process information. The clue here is in the title “acceptable use of information and other associated assets”.

Having an Acceptable Use Policy won’t be seen by auditors as something you can opt out of. It’s going to be considered mandatory, so not having one is going to put you in a difficult position unless you are absolutely ready to defend your position of having it within other policies. I’d consider it mandatory.

Creating an Acceptable Use Policy

So, go to your list of assets captured under control 5.9, go through it and think “What do people need to know about handling these assets?”

There are three key aspects you need to consider;

1. Setting down the expectations around behaviours of individuals (e.g. treat laptops with care, don’t use them as a kitchen chopping board, don’t send ransom notes using your work smartphone, etc)
2. The uses that are permitted and prohibited (you can use it for this, but not that)
3. The business reserves the right to monitor usage to support the policy

Obviously, I’m joking about using a laptop as a chopping board, but you do need to consider the policy from the perspective of staff who will always look for what you didn’t say and use it as a loophole (like my children). This means that your policy needs to be quite explicit about the terms of usage of assets, and my suggestion is that you frame it as positive: “You may use your laptop for processing of data relating to GlobalHyperMegaCorp. Any other uses should be approved by your line manager.” By doing this, you are saying, “here’s what you can do – anything else, ask,” and now the staff member needs to ask, “can I install games for my kids?” or “can I run my own business from your server?” etc.

What Should be in an Acceptable Use Policy?

The sweet spot for an Acceptable Use Policy is probably around 6-10 pages, structured around clear behavioural expectations. Any longer than that, people won’t read it, will lose the will to live, and more importantly for you, won’t comply with it. It should never be legal speak if you want compliance. So, we want it clearly worded, simple to understand and readable.

AUP Considerations by Business Type

The 16-section structure above works for most SMEs, but the emphasis shifts depending on the kind of business you’re in. Three patterns I commonly see:

The underlying AUP structure stays the same across all three. What changes is the emphasis, the examples, and the specific rules within each section. Build for your sector, not for an abstract organisation.

The diagram above gives you the at-a-glance view; here’s the detail behind each section:

1. Purpose and Scope

As with any policy, start with a section on what the policy is for, who it applies to (employees, contractors, third parties, visitors), and what assets it covers (company systems, BYOD, cloud services, physical premises). Worth being explicit that the policy applies wherever company information is being handled, not just on company premises. Some of these policies might be sub-policies that you signpost to, so whether you have BYOD (Bring-Your-Own-Device) as a section or as a sub-policy is up to you.

2. Roles and Responsibilities

Who owns the policy, who enforces it, and who staff should contact with questions.

3. General Principles of Acceptable Use

Lay out the key behaviours. Things like using company assets for legitimate business purposes, not doing anything illegal, harmful, or against company values, protecting information appropriately for its classification, and following the policies that sit alongside this one.

4. Use of Company Systems and Devices

Explicitly calling out the operational aspects for laptops, desktops, mobile devices, and any company-issued hardware. This covers things like keeping software updated, not installing unauthorised software, not disabling security tools, locking screens when away, and promptly reporting loss or theft.

This is where the bulk of general practical “do” and “don’t” sits.

5. Email and Communications

Include a section specifically around email usage as it is the single highest-risk channel for most businesses, but I encourage you to do it through the lens of asking yourself what, exactly, the threats you are protecting your data from; phishing, fraud, etc.

Outline the appropriate use of company email, not using personal email for company business, awareness of phishing, not forwarding company information to personal accounts, and professional conduct in external communications.

I mentioned the need to include monitoring activities earlier, which comes later in the policy, but it is worth just mentioning that emails specifically are an area of monitoring, and it would do you well to set out in the policy things like ‘don’t include personal details’, etc., and that managers have the right to access mailboxes (or whatever your agreed terms).

6. Internet and Web Use

What’s acceptable browsing, what isn’t, awareness that activity may be monitored, prohibition on accessing illegal or inappropriate content, caution around uploading company information to web services. Again, this is another area where monitoring of behaviours is important to make clear to the user. It’s better to discourage them from doing something stupid before they do it than after.

7. Information Handling

Per control 5.12 Classification of Information, you should outline to the reader how to handle information according to its classification: where it can be stored, how it can be transferred, and how it should be disposed of. This links naturally to Controls 5.13 Labelling of Information, and 5.14 Transfer of Information as well.

8. Passwords and Authentication

Either cover it here, in a separate Access Control Policy or a Password Policy, depending on how you’ve structured your document set. For example, keep passwords secret, don’t share accounts, use MFA where available, report suspected account compromise, etc.

9. Working Outside the Office

Particularly important in today’s world, where people work wherever they can find a wi-fi signal. This should outline things like securing devices when remote, using approved networks, being aware of physical security in public spaces (overheard calls, screen privacy), and being careful with paper documents (if anyone is still doing that in 2026).

10. Personal Use

I think it important that there’s an honest acknowledgement that some personal use is acceptable on company devices. Unless there is a super high-level security reason not to, you should set the limits so people understand it’s okay to browse the BBC news in their lunch hour, so long as it’s occasional and reasonable, not excessive. Personal use should be set out clearly so that it’s not in ways that damage company assets or reputation, no expectation of privacy on company systems. I think businesses can often get this wrong by pretending personal use doesn’t happen, but who am I to judge?

11. Use of AI Tools

A 2026 essential. I recommend you address it either here or in its own policy, depending on the nature of your business. If, for example, you are a small business selling tents, cover it here. However, if you are a software development organisation or data analytics processor, then having your own AI policy is probably sensible.

If you choose to include it here, then outline what AI tools are approved, what information can and can’t be shared with them, awareness that prompts and outputs may be stored by the AI provider, and professional responsibility for AI-generated outputs.

12. Social Media

It’s important to clarify to people that they are representing the company appropriately, not disclosing confidential information, the line between personal opinions and company positions, and awareness that social media posts can be used for social engineering against the company.

We’ve all seen it: someone posts something on the socials that shocks and appals us, and the next thing you know, they are looking for a new job. If you aren’t specifying that expectation somewhere in policy, you are probably on a sticky wicket.

13. Bring Your Own Device (BYOD)

Another area where the line between personal and professional is increasingly merging. We need to acknowledge that many people work using their own devices and web access. Again, this is one of the areas where you might have either a section or an entire sub-policy. If you allow personal devices to access company information, this is where the conditions sit.

Sometimes you can set policies in Google or 365 to say that unless the connecting machine has specific security settings enabled (latest operating system, patches, etc.), it can’t connect. You might also outline that devices can be remotely wiped of company apps and data (this is common), and anything else the owner should really agree to and not find out as a surprise down the line.

14. Monitoring and Privacy

I’ve mentioned it a couple of times before now, but this is where honest disclosure that company systems may be monitored, what the limits of that monitoring are, and what data is retained. Usually a short section, but legally important to make sure you’re covered… If you are general about being able to monitor activities and communications over company services, tools and hardware, but don’t get detailed, then I think it’s best and allows you flexibility to implement tools and tracking without constantly adjusting the policy.

15. Reporting Issues

As with most policies, summarise briefly how and where to report suspected incidents, policy violations, or security concerns. Who to contact, what protections exist for those raising concerns in good faith.

16. Consequences of Non-Compliance

Another main clause of ISO 27001 is to be clear about what happens if you don’t comply with the ISMS policies and procedures. Be brief but clear. Clarify the key reasons (everyone’s safety), but reference the disciplinary process; don’t reproduce it.

The point is that breaches will be taken seriously, not to threaten people.

Other things you might choose to include or handle elsewhere

A brief mention of other aspects you may wish to include, but equally are picked up elsewhere. For example, in their own policies, or in the main infosec policy – you decide, but just so they don’t get forgotten;

• Incident reporting detail belongs in an Incident Management Policy. The AUP says “report incidents promptly”, the IRP says how.
• Clear desk and clear screen could be here or in a separate Clear Desk Policy. Either is fine; just don’t duplicate.
• Access control specifics belong in an Access Control Policy. The AUP says “follow access control rules,” and the Access Control Policy says what they are.
• Cryptography and encryption belong in a Cryptography Policy. The AUP says “use approved encryption”, the Crypto Policy specifies what.

Download My AUP Checklist Guide

Supporting Procedures for Acceptable Use

The wording of Control 5.10 specifically calls out both rules and procedures.

The AUP is the rules: what people should do. The procedures are the how: the step-by-step instructions someone follows when actually doing the task. Auditors should check both, and a policy that points to procedures that don’t exist is a gap they’ll quickly find.

For most small businesses, you don’t need a separate document for every procedure. You only need to create the procedure if there’s something complex about it, or steps that could go wrong (like any procedure under 27001) – you don’t need to document everything to the nth degree.

Procedures can sit as sections within one or two operational guides, or as short knowledge base articles that staff can find when they need them. What matters is that the practical steps are documented somewhere usable.

So, here are a few examples of the kind of supporting procedures you may wish to consider. They aren’t mandatory, but just provided as a list for you to reflect on:

• Data Transfer Procedure. How to send information securely depending on its classification: when to encrypt, when to password-protect, when to use approved file-sharing tools, and when sending externally is permitted. So, if you say “all attachments sent by email need to be encrypted to 256-bit encryption standards”, ask yourself, does a member of the accounts team know how to do that? If not, create a short guide showing them.
• Information Disposal Procedure. How to securely dispose of paper documents, wipe electronic media, decommission a device, and what evidence of disposal to retain.
• Lost or Stolen Device Procedure. What staff do in the first hour after losing a device: who to call, how to trigger a remote wipe, what to include in the incident report. We don’t want them hunting through lots of policies and pages for this information if it’s 2 am on a Saturday night and there’s no support available.
• Suspicious Email Reporting Procedure. What to do when a phishing or suspicious email arrives: don’t click, how to forward to the right inbox, and when to call IT directly. Could be part of the policy, or a separate procedure – it’s up to you.
• Requesting Access to a New Tool Procedure. The steps for getting a new SaaS service or piece of software approved before staff start using it. This is a good procedure to have as it helps support other controls.
• Asset Return Procedure. What’s collected back from a leaver, how it’s logged, how data is wiped or transferred, and who signs it off. Owned by HR and IT jointly.
• AI Tool Approval Procedure. The steps a member of staff follows before using a new AI tool with company information: who they ask, what checks are run, and how the decision is recorded.
• Exception Request Procedure. How staff request and obtain a documented exception to the AUP when they genuinely need to do something outside its rules.

Each of these should be short and instructional. A numbered set of steps that a member of staff can follow without ambiguity is what good looks like.

Again, it’s for you to determine what’s appropriate, helpful and necessary. Don’t go crazy, but do remove ambiguity where it exists. If a line in your policy is better, such as ‘report issues or request exceptions by contacting the helpdesk on…’, then do that. You don’t need a huge procedure showing people how to do that.

What Auditors Will Look For

Control 5.10 is one of those controls that auditors largely test through document review and a handful of targeted questions to staff, rather than through technical evidence.

They want to see that the acceptable use expectations are written down, communicated, and actually followed. So an ISO 27001 auditor will normally ask for:

• A current Acceptable Use Policy, with version control, dated approval, and a named owner. If it covers everything from email to AI to BYOD in one document, that’s fine. If it’s split across multiple topic-specific policies, the auditor will want to see those, and it might take them longer to piece it together.
• Evidence that staff have read and acknowledged the policy. This is the single piece of evidence auditors will first ask for. An LMS record showing completion, a signed acknowledgement in the HR system, or a tracked acceptance in your intranet are all good evidence. “It’s on SharePoint” isn’t great, because from the individual’s defensive position, it can sound like “you never told me!”
• Coverage of the asset categories the AUP applies to (company devices, BYOD if applicable, cloud services, physical premises). The auditor could check that the policy says what it covers, and that the coverage matches what the business actually uses.
• Links from the AUP to the topic-specific policies it depends on: access control, incident reporting, classification, and cryptography. The auditor will verify at least one of these references to ensure the linked policy actually exists and is current. They do like to do this.

Auditors could also test the AUP directly with staff. The typical questions are simple: “What would you do if you received a suspicious email?” “Can you use ChatGPT for company work?” “Where can company information be stored?” “What happens if you lose your laptop?” The point isn’t to catch staff out; it’s to check that the policy has actually translated into behavioural understanding.

If staff can answer broadly correctly, or at least say “I’m not sure, but I’d go and check the Acceptable Use Policy”, then your AUP is doing its job. If they look startled, a bit blank, and like a rabbit in the headlights, then the policy exists on paper but not in practice.

Common Issues I Find During Internal Audits

The AUP is only a potential weak point if it’s written down but not really reflective of reality, and having life breathed into it. Here’s what I’ve seen in my internal audits:

• The policy hasn’t been read and accepted.
  The AUP is in the policy library or on the intranet somewhere, formally approved, version-controlled, and well-written. But there is no evidence that it’s been read. I’ve spoken about that above, so ideally, make sure there’s a record somewhere of staff agreement/acceptance.
• The AUP doesn’t mention AI tools.
  This is 2026; there needs to be clear guidance in the policy or in a supporting AI policy; otherwise, I don’t think you are seriously considering the world as it is and are just using a document three years out of date, with refreshed approval dates.
• The policy hasn’t been approved or reviewed.
  It’s typical stuff when it comes to policies, but if there’s no record of the last review or sign-off, the policy isn’t under control (a requirement of ISO 27001) and would receive a noncompliance note.
• The policy only focuses on physical assets.
  Knowing how to use laptops, desktops, and other hardware is important, but it’s not the only thing the control is asking of you. Always go back to the control text and interpret it directly. In this case, it’s “Rules for the acceptable use and procedures for handling information and other associated assets shall be identified, documented and implemented.”

When I’ve audited organisations, the Acceptable Use Policy is always there. Nobody has ever skipped it, so it really becomes the list I’ve just outlined: minor noncompliances, not major issues.

A Recent Audit Example

One company I audited not too long ago had an absolutely huge AUP. It was drafted like you’d expect a legal document. It really wasn’t my place to judge, but I couldn’t see staff complying with it, which must be its reason for existence. For example, have you ever had one of those licence agreements flash up on your screen as you were signing up for online software, and have you ever gone through it word for word? Probably not, and it’s the same here. I spoke to them and offered a suggestion about the approach, and they said they would take it on board. It wasn’t that they were going to fail their audit; it was that I thought it would fail in its purpose of changing behaviour for the better.

How ISO 27001 Control 5.10 links to other clauses and controls

The AUP is a connector control: it references and is referenced by several other controls because acceptable use is fundamentally about how people interact with everything else in the ISMS.

Understanding the relationships helps you avoid documenting the same thing twice.

How Control 5.10 Fits With Other Compliance Frameworks

A brief summary on how the Acceptable Use Policy fits in with other frameworks you could be running or considering.

UK GDPR and the Data (Use and Access) Act 2025.

Article 32 of UK GDPR requires “appropriate technical and organisational measures” to protect personal data. The AUP is exactly the kind of organisational measure ICO inspectors expect to see, particularly in its sections on personal data handling, monitoring, and incident reporting.

Cyber Essentials and Cyber Essentials Plus.

Cyber Essentials doesn’t mandate an AUP by name, but the controls it requires (user access, malware protection, secure configuration, patch management, firewalls) all depend on staff following defined rules. An AUP is the document that operationalises those rules into staff-facing guidance. Most SMEs going through Cyber Essentials+ find that having a clear AUP makes the certification process noticeably easier.

NIS2 (where applicable).

NIS2 applies to essential and important entities across specific sectors (digital services, transport, energy, health, and others). For organisations in scope, NIS2 requires documented policies on the appropriate use of network and information systems, training on cyber hygiene, and clear escalation procedures. Your AUP satisfies several of these obligations directly, particularly the staff-behaviour and incident-reporting requirements.

SOC 2.

SOC 2’s Common Criteria framework includes CC1.4 (commitment to integrity and ethical values) and CC5.3 (deploying control activities through policies and procedures). An AUP under Control 5.10 satisfies these directly.

External Resources and Further Reading

For businesses implementing or reviewing their Acceptable Use Policy, the following authoritative sources are worth bookmarking:

UK Cyber Security Breaches Survey 2025/2026 (Department for Science, Innovation and Technology) – the official UK government statistics on cyber incidents, attack types, and organisational response. The most authoritative source on what UK SMEs are actually experiencing. https://www.gov.uk/government/statistics/cyber-security-breaches-survey-20252026

NCSC Guidance for Small and Medium-sized Organisations – the National Cyber Security Centre’s hub for SME-specific cyber guidance, including practical advice that directly supports AUP content. https://www.ncsc.gov.uk/section/information-for/small-medium-sized-organisations

ICO Monitoring Workers Guidance – the Information Commissioner’s Office’s guidance on workplace monitoring under UK GDPR. Particularly relevant for the Monitoring and Privacy section of your AUP. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/employment-information/monitoring-workers/

Cyber Essentials Overview – the UK government’s foundational cyber security framework. A natural complement to ISO 27001 for SMEs and worth linking your AUP’s technical sections to. https://www.ncsc.gov.uk/cyberessentials/overview

FAQs

Conclusion

Acceptable use is one of those controls that feels straightforward on the surface and gets more interesting the deeper you look. The rules-and-procedures distinction is what most SMEs miss, and it’s also what most auditors will check. Get the policy right, point it at the procedures that actually exist, make sure staff have acknowledged both, and you’ve satisfied the control properly.

For most SMEs, the AUP is also one of the documents that most directly shapes day-to-day behaviour. A clear, readable policy that acknowledges the realities of modern working (personal use, AI tools, remote working, BYOD) lands better than a legalistic document that nobody finishes reading. Keep it short, keep it honest, and keep it current.

If you’d like a ready-made Acceptable Use Policy template alongside the wider ISMS documents, the Iseo Blue ISO 27001 Toolkit includes both. Or if you’d rather talk through how to right-size the AUP for your specific business, the free 30-minute consultation is genuinely free and genuinely 30 minutes.

Author Background

This article was written by Alan Parker, an ISO 27001 consultant and founder of Iseo Blue Limited. He helps UK SMEs achieve certification in 90 days or less, often without a dedicated security team or a large budget.

With over 30 years in IT governance and information security, Alan works with software companies, IT service providers, managed service providers, and professional services firms across the UK, Europe, and internationally.

Qualifications: Certified ISO 27001 Lead Auditor (ANAB-accredited certification),
ITIL v3 Expert, ITIL v4 Bridge, PRINCE2 Practitioner. Named IT Project Expert of the Year (2024, UK). Alan writes in plain English for busy teams who need to get things done.

Connect on LinkedIn or Bluesky, or explore his free ISO 27001 tools and templates at iseoblue.com. B.Sc (Hons) Information Systems, CISMP certified.

Alan Parker