---
title: "Acceptable use policy template"
canonical: https://www.grcmana.io/vault/templates/acceptable-use-policy
published: 2023-12-01
updated: 2026-10-17
author: "Harry West"
framework: "ISO 27001"
type: "Policy"
---

# Acceptable use policy template

## Key takeaways

An acceptable use policy tells everyone with access to your systems how they may use company information, devices and services. ISO 27001 control A.5.10 requires documented rules for acceptable use, which staff must know and accept. This Word template covers hybrid working, personal devices, messaging and AI tools for UK firms of 25 to 250 staff.

- **Required by** — ISO 27001:2022 control A.5.10. Cyber Essentials has no AUP requirement
- **Accepted by** — Everyone with access, contractors included, before access is issued
- **Review cycle** — At least annually, and when tools or rules change
- **Format** — Word, about 12 pages, with an approved tools register and acknowledgement form

A new joiner asks whether they can paste a client's spreadsheet into a free AI chatbot. A director forwards board papers to a personal email account to read at home. Neither has broken a rule, because nobody wrote one down. An acceptable use policy is where those rules live. This template gives a UK firm of 25 to 250 staff a ready-to-edit acceptable use policy in Word, mapped to ISO 27001 control A.5.10, with hybrid working, personal devices, messaging and generative AI already covered.

## What's in the template

One Word document, about 12 pages, version 1.0. It has four parts.

1. **The acceptable use policy.** Scope, the rules for company and personal devices, hybrid and remote working, email and messaging, internet and social media, generative AI tools, handling information, accounts and passwords, what's prohibited, monitoring, reporting, leaving the firm, and what happens if the policy is broken.
2. **Ready-to-use appendices.** An approved tools register (with a column for AI tools and the data each may receive), a staff acknowledgement form and a one-page "acceptable use on a page" summary for onboarding.
3. **A getting-started guide and next steps.** Which sections to tailor first, which options to choose between, and where the policy sits beneath your information security policy.
4. **A policy management checklist.** Approval, acknowledgement tracking, annual re-acceptance and review dates: the records an auditor asks to see alongside the policy.

Every placeholder is in square brackets, and where firms genuinely differ (personal use, personal devices, AI tools) the template offers two or three worded options to pick from. Choose, delete the rest, and the policy is ready for management approval.

## What is an acceptable use policy?

An acceptable use policy (AUP) is the document that tells everyone with access to your systems how they may use your information, devices and services: what's expected, what's prohibited and what you monitor. It's written for staff, not auditors, so it has to be short enough to read and plain enough to remember.

An information security policy sets direction from the top. The acceptable use policy is where that direction turns into everyday behaviour: locking a screen, choosing a messaging app, deciding what goes into an AI tool. It's also the policy staff sign, which makes it the one an auditor samples by talking to people.

Customers ask for it for the same reason. An enterprise security questionnaire that asks "what is your policy on generative AI?" or "do staff use personal devices?" is asking about your acceptable use policy, whether it says so or not.

### Which standards require one

ISO 27001 names acceptable use directly. Other frameworks and regulators don't ask for an "AUP" by name, but they expect the rules an AUP holds.

| Standard or source | What it asks for |
| --- | --- |
| ISO 27001:2022, control A.5.10 | Rules for the acceptable use of information and other associated assets, and procedures for handling them, must be identified, documented and implemented. |
| ISO 27001:2022, controls A.6.7 and A.8.1 | Security measures for people working remotely, and protection for information on user endpoint devices. Most small firms put these rules in the acceptable use policy rather than in separate documents. |
| ISO 27001:2022, control A.6.4 | A formal, communicated disciplinary process for policy violations. Your acceptable use policy should point to it. |
| Cyber Essentials | No policy document is required. Cyber Essentials is a technical scheme, so an AUP is a support, not a requirement: it tells staff the device and account rules the assessment tests. Personal devices that access company data or services are in scope, unless they are used only for calls, texts or multi-factor authentication apps. |
| UK GDPR (ICO guidance on monitoring workers) | Apart from very exceptional cases, you must tell workers about any monitoring, in a way that is accessible and easy to understand, and identify a lawful basis for it. |
| Customer due diligence | Security questionnaires commonly ask whether staff accept an acceptable use policy, and what it says about personal devices and AI tools. |

For the depth on the control itself (the 2022 merge with asset handling, monitoring disclosures, gating acknowledgement before access, and what auditors sample), see the [ISO 27001 A.5.10 guide](https://www.grcmana.io/vault/iso-27001/annex-a-5-10-acceptable-use-of-information-and-other-associated-assets). Remote working and devices have their own guides: [A.6.7 remote working](https://www.grcmana.io/vault/iso-27001/annex-a-6-7-remote-working) and [A.8.1 user endpoint devices](https://www.grcmana.io/vault/iso-27001/annex-a-8-1-user-endpoint-devices).

## How to create your acceptable use policy with this template

With the groundwork in place, this takes about half a day of drafting and one management meeting, then a week or two to collect acknowledgements. Without it, the policy will promise rules your systems can't support, so check the groundwork first.

### Before you start

An acceptable use policy borrows from the documents around it. Check you have:

- **An information security policy.** The AUP sits beneath it and should use the same scope and owner. No top-level policy yet? Start with the [information security policy template](https://www.grcmana.io/vault/templates/information-security-policy) and the [A.5.1 guide](https://www.grcmana.io/vault/iso-27001/annex-a-5-1-information-security-policy).
- **A classification scheme, even a simple one.** Three tiers (public, internal, confidential) are enough for most firms, and the AUP's handling and AI rules refer to them. No scheme yet? The [A.5.12 guide](https://www.grcmana.io/vault/iso-27001/annex-a-5-12-classification-of-information) shows how to set one.
- **A list of the tools people actually use.** Not the ones IT approved, the ones in use: your single sign-on catalogue and expense claims are the quickest way to find out. That list becomes the approved tools register.
- **An HR route.** A disciplinary procedure the policy can point to, and a way to record who has accepted it. The [A.6.4 guide](https://www.grcmana.io/vault/iso-27001/annex-a-6-4-disciplinary-process) covers the first. No way to record acceptance yet? A dated e-signature or tracked form will do, and the template's acknowledgement form gives you the wording.

If none of these exist yet, the job is bigger than one policy. That's the point where most firms bring in help.

**1. Decide who and what it covers** *(about 30 minutes)*

- **Do this:** list the people the policy binds (employees, contractors, temporary staff and third parties with a login) and the assets it follows: company devices, personal devices used for work, cloud services and your information wherever it sits.
- **The template:** has the scope written with [options] for each group, so you delete what doesn't apply rather than drafting from nothing.
- **Watch for:** contractors who arrive through procurement rather than HR. They miss onboarding, never see the policy, and are the first people an auditor samples.

**2. Build the approved tools register** *(1 to 2 hours)*

Next, fill in the register: the messaging, file-sharing, video and AI tools staff may use for work, and the highest class of data each may receive. The template's register has a column for exactly that. This is the step that makes the rules usable. "Use approved tools only" means nothing until someone can look up what's approved.

> **Where most firms get stuck:** prohibiting without providing. A policy that bans personal messaging apps and free AI tools, but offers no approved alternative, pushes the same work onto personal phones where you can't see it. Every "don't" needs a "use this instead".

**3. Write the rules for how your people actually work** *(about 2 hours)*

- **Do this:** work through the sections on hybrid working, personal devices, email and messaging, and generative AI. For each, pick the option that matches how your firm operates today, and adjust the wording to your tools.
- **The template:** offers worded options for the decisions that differ between firms: whether personal use is allowed, whether personal devices may access email, and which AI tools may receive which data.
- **Watch for:** rules written for a firm you aren't. "Company devices only" reads well, but if half the team checks email on personal phones, the policy is untrue on the day it's approved.

> **Where most firms get stuck:** rules the systems don't enforce. An auditor will ask what stops someone doing what the policy prohibits. If the answer is "nothing, we trust people", either add the guardrail (device management, web filtering, single sign-on) or soften the rule to what you actually do.

**4. Write the monitoring section, then check it** *(about 1 hour, plus a review)*

Then say what you monitor and why: email filtering, web logs, device management, and anything else that is actually running. The ICO expects workers to be told about monitoring in plain terms, and to be told about it before it happens. Overstating is as risky as staying silent, so describe what runs, not what you might run one day. Before approval, have HR and an employment lawyer read this section and the one on breaches, because they connect the policy to contracts and disciplinary action. The [A.5.10 guide](https://www.grcmana.io/vault/iso-27001/annex-a-5-10-acceptable-use-of-information-and-other-associated-assets) sets out what a monitoring disclosure that stands up contains.

**5. Approve, publish and collect acknowledgement** *(one management meeting, then 1 to 2 weeks)*

- **Do this:** take the policy to management for approval and set the next review date. Then ask everyone in scope to accept it, and make acceptance part of onboarding, before accounts are issued.
- **The template:** includes an acknowledgement form, a one-page summary for joiners, and a policy management checklist for approval, acceptance and review dates.
- **Watch for:** acceptance nobody can evidence, and joiners who started work before they accepted. Both are covered in [How to use it so it holds up at audit](#how-to-use-it-so-it-holds-up-at-audit).

A policy nobody was asked to accept binds no one.

### Do it yourself, or have us do it with you

|  | Do it yourself with the template | Do it with GRCMANA |
| --- | --- | --- |
| What you end up with | An approved acceptable use policy for your firm | This policy plus the classification scheme, approved tools register and the related ISO 27001 policies, consistent with each other, with acknowledgement built into onboarding |
| Your time | Half a day plus a meeting, if the groundwork is in place. Considerably more if it isn't | Agreed with you at the start, based on the groundwork you already have |
| Best if | You know which tools your people use and someone can make the personal-device and AI calls | Compliance landed on you alongside your day job, nobody knows which tools are in use, the audit date is fixed, or a client questionnaire is waiting on your AI position |

Prefer the second column? [Talk to us about ISO 27001 readiness](https://www.grcmana.io/contact).

## What does a good acceptable use policy look like?

Most acceptable use policies are lists of things staff must not do. The good ones read like instructions a sensible colleague would give: what to use, what to avoid, and what to do when something goes wrong. Here are examples you can adapt.

### Example clauses you can adapt

**Generative AI tools.** "You may use the AI tools listed in [approved tools register] for work. You may enter internal information into them, but never confidential or client information, personal data or credentials unless the register says that tool is approved for it. Don't use personal AI accounts for work. You remain responsible for checking anything an AI tool produces before you use or share it."

**Personal devices.** "You may access [email and collaboration tools] on a personal phone or tablet only if it is enrolled in [device management], runs a supported operating system and is protected by a PIN or biometric lock. [Company] can remove company data from the device, but not your personal data. Report a lost or stolen device to [channel] within [one hour] of noticing."

**Hybrid and remote working.** "When working away from the office, lock your screen whenever you step away, keep conversations about clients out of public places, and don't let family members or others use your work device. Use [VPN or secure access] on networks you don't control, such as public wifi."

**Email and messaging.** "Use [company email] and [approved chat tool] for work. Don't forward work emails or files to personal accounts, and don't use personal messaging apps for client matters. If a message asks for a payment change, credentials or an urgent transfer, check it by phone using a number you already hold, not one in the message."

**Monitoring.** "[Company] filters email and web traffic, and manages company devices, to protect our systems and clients. We check logs when we investigate a security incident or a suspected breach of this policy. We don't monitor the content of personal devices. Our [staff privacy notice] explains how we handle this information."

### Weak and strong, side by side

| Clause | Weak | Strong | Why the strong one works |
| --- | --- | --- | --- |
| Scope | "This policy applies to all employees." | "This policy applies to employees, contractors, temporary staff and anyone else given access to \[Company\] systems or information, on any device, wherever they work." | Contractors and personal devices are where the gaps are. Naming them closes them. |
| Personal use | "Personal use of IT is not permitted." | "Reasonable personal use is allowed outside working time, provided it doesn't interfere with your work, break the law or break this policy." | A blanket ban nobody follows makes the whole policy look unenforced. |
| Accounts | "Passwords must be kept secure." | "Never share your password or approve a sign-in you didn't start. Use \[password manager\] for work passwords, and multi-factor authentication wherever it is offered." | It names behaviours a person can follow and an auditor can check. |
| Reporting | "Report any security issues to IT." | "Report a suspected phishing email, a lost device or a mistake (such as an email sent to the wrong person) to \[channel\] straight away. You won't be disciplined for reporting an honest mistake." | Fast, blame-free reporting is what turns a mistake into a small incident instead of a breach. |
| Breaches | "Breaches may result in disciplinary action." | "Breaches are handled under the \[disciplinary procedure\], in proportion to intent and impact. Deliberate or serious breaches may lead to dismissal, and we may withdraw access while we investigate." | It points to a real process, which is what makes the policy enforceable. |

### What an auditor checks in the first five minutes

Before reading the detail, most auditors check that:

1. **It's current.** It has a version, an approval date and a review date that hasn't passed.
2. **Everyone accepted it.** Acknowledgement records exist for staff and contractors, and recent joiners accepted before their accounts went live.
3. **It covers how people work now.** Personal devices, remote working, messaging and AI tools are addressed, not just the office network.
4. **It matches the systems.** What it prohibits is backed by a guardrail, or at least not contradicted by what the auditor can see.
5. **Monitoring is disclosed.** What the firm monitors is stated, and matches what runs.
6. **People know it.** A staff member asked "can you use AI tools for client work?" gives the answer the policy gives.

If all six hold, the auditor moves on with confidence. If one fails, they tend to sample harder.

### What good looks like at 25 staff and at 250

| Feature | Around 25 staff | Around 250 staff |
| --- | --- | --- |
| Length | Four to six pages, plus a one-page summary | Six to ten pages, with separate standards for remote working or devices where needed |
| Personal devices | Allowed for email and chat on enrolled phones; company laptops for everything else | A defined BYOD scheme with device management and conditional access |
| AI tools | One approved tool, with a simple rule on what data may go in | An approved tools register with data limits per tool, owned by a named person |
| Acknowledgement | E-signature or a tracked form at onboarding, and annually | Built into the HR system and access provisioning, with annual re-acceptance campaigns |
| Training | A short briefing at onboarding | Onboarding module plus annual refresh, with completion tracked |
| Owner | A director, alongside their main role | A security or compliance lead, with HR as co-owner |

The common mistake at 25 staff is adopting an enterprise AUP of thirty pages that nobody reads and the firm can't enforce. The common mistake at 250 is the reverse, a policy written when the firm had 40 people, silent on the tools everyone now uses.

## How to use it so it holds up at audit

The policy is only half the evidence. An auditor tests whether it operates, and these are the records they usually ask for:

- **The approval record:** who approved this version, and when.
- **Acknowledgement records:** a dated acceptance for everyone in scope, contractors included, that reconciles against your joiner list.
- **The review history:** the last review date, what changed (new tools, new AI rules) and the next review date.
- **The approved tools register:** current, with an owner, and matching what your single sign-on and expense data show is in use.
- **Guardrail evidence:** device management, web filtering and email filtering settings that back the policy's rules.
- **Breach handling:** at least one example of a breach of the policy handled under the disciplinary or incident process, if one has occurred.

**The most common reasons this policy fails audit:**

- Staff or contractors can't be shown to have accepted it, or joiners accepted it weeks after starting.
- It's silent on personal devices or AI tools that staff plainly use.
- It prohibits things the firm's systems permit, and nobody has noticed.
- It claims monitoring that isn't running, or runs monitoring it doesn't mention.
- It was copied from a template and still names tools, roles or teams the firm doesn't have.

Each of these is cheaper to fix now than to explain in the audit room.

## Acceptable use policy questions

### What should an acceptable use policy include?

Who and what it covers, the rules for company and personal devices, remote working, email and messaging, internet use and AI tools, how information is handled and shared, account and password rules, what's prohibited, what's monitored, how to report problems, and what happens if the policy is broken. A short summary for joiners helps it get read.

### Is an acceptable use policy legally binding on employees?

An acceptable use policy is usually enforced through the employment relationship: the contract or handbook refers to it, staff accept it, and breaches go through the disciplinary procedure. How that works for your firm depends on your contracts, so have an employment lawyer check the wording.

### Should generative AI rules go in the acceptable use policy or a separate AI policy?

For most firms of 25 to 250 staff, the everyday rules (which tools, what data may go in, checking outputs) belong in the acceptable use policy, because that's the document staff read and sign. A separate AI policy makes sense when you build or deploy AI systems yourselves, rather than just use them.

### Does an acceptable use policy cover personal devices?

It should, whenever personal phones or laptops access work email, files or systems. The rules follow your information, not the device. The policy says what's allowed on a personal device, what conditions apply, and what the firm can and can't see or remove.

### How often should staff re-accept the acceptable use policy?

At onboarding, before access is issued, then annually and whenever the policy changes materially, for example when you approve a new AI tool or change the personal-device rules. Keep each acceptance as a dated record.

## Get the template

Start from a policy that already covers hybrid working, personal devices, messaging and AI tools, written for a firm your size. Download the Word template, choose your options, and build acceptance into your next joiner's first day.

*This template is a starting point to adapt to your organisation, not legal advice.*
