Acceptable Use Policy Template

The complete acceptable use policy, free to copy from this page or download as an editable Word document. No sign-up. Replace every [bracketed placeholder] with your own details, delete anything that does not apply, and have it approved before you rely on it. The guide below explains what each section has to contain and what an auditor checks.

15

sections

4

with real wording

7

auditor requests

7

failure modes

a day

to write it yourself

1. 1

   Purpose

   What it must contain

   Two or three sentences on why the rules exist and what they prevent - data loss, malware, legal liability, downtime - and a line placing this document beneath your information security policy.

   What the auditor checks

   Shows the policy is part of a system rather than a stray file someone wrote once. A purpose that cites no parent policy suggests there is no parent policy.

2. 2

   Scope

   What it must contain

   Who it binds and what it reaches: employees, contractors and third parties; company laptops, phones and network gear; personal devices used for work; every cloud service and account used for the business.

   What the auditor checks

   Scope gaps are where contractors and personal devices quietly fall outside the ISMS. If your scope statement covers a team the policy does not, that mismatch is the finding.

3. 3

   Permitted use

   What it must contain

   What the systems are actually for, that people use only the accounts issued to them, and the route to request access they do not have instead of borrowing a colleague's login.

   What the auditor checks

   Read against your access control policy. Shared logins are the classic contradiction: banned here, alive in the admin console.

4. 4

   Prohibited use

   What it must contain

   A short, specific list of things that are never acceptable. Password and MFA-code sharing, snooping, moving company data to personal accounts, harassment, disabling security controls, unapproved scanning tools, running a side business on company systems.

   What the auditor checks

   Checked for enforceability, not length. Any prohibition you cannot detect or will not act on weakens the ones you can.

5. 5

   Reasonable personal use

   What it must contain

   A plain answer to the question everyone has, with a limit a manager can apply, plus a warning that personal material on company systems can still be seen during support, backup or an investigation.

   What the auditor checks

   Mostly wants a decision on record. A tribunal or regulator wants it far more than the auditor does, which is why the warning sentence belongs here.

   Occasional personal use of email, the internet and company devices is allowed, as long as it is modest, does not interfere with your work and breaks no other rule here. Anything on company systems, including personal material, may be seen during support, backup or an investigation.

   It answers the question rather than dodging it, and the limit is one a manager can apply without a policy in hand. The second sentence is doing quiet work: it is the notice that makes the monitoring clause survive a challenge later. The usual failure here is a total ban that nobody intends to enforce, which teaches people that the rest of the document is optional too.

6. 6

   Accounts, passwords and multi-factor authentication

   What it must contain

   Unique passphrases stored in the password manager you actually license, no reuse on personal services, MFA turned on, deny any prompt you did not trigger and report it, lock the screen when you step away.

   What the auditor checks

   Reconciled against the real configuration: your tenant's MFA coverage, the password manager rollout, the screen-lock policy your endpoints enforce.

7. 7

   Devices, including personal devices (BYOD)

   What it must contain

   The settings company devices must keep - disk encryption, screen lock, automatic updates, endpoint protection - and the equivalent minimum for a personal device, including your right to remove company data from it. Same-day reporting for a lost or stolen device.

   What the auditor checks

   The natural home of A.8.1, user endpoint devices. Expect to be asked for the enrollment evidence and for the sentence where the employee agreed to the removal of company data.

   A personal phone or computer used for work needs a screen lock and current updates, work must stay inside the approved apps, and you must allow us to remove [Organization] data from it when you leave or if it is lost.

   Consent to remove company data is given in advance, in the document people sign, which is the only time it is easy to get. Note what it does not say: it removes company data, not the device. Promising a full wipe of a personal phone is a promise you will regret the first time you make good on it.

8. 8

   Software, cloud services and shadow IT

   What it must contain

   Only approved and licensed software and services, and the approval route to request a new one before any company or customer information goes into it - free tools and browser extensions included.

   What the auditor checks

   Sampled hard. Someone will pick a tool that is obviously in use and ask to see its approval, so name a role that really does the approving.

9. 9

   Removable media and printing

   What it must contain

   Whether USB drives and portable disks are allowed at all; if they are, that they must be issued by you, encrypted, approved, and erased or destroyed at the end of the task. Never plug in a drive you were given or found. How confidential paper is collected and destroyed.

   What the auditor checks

   Compared with the technical control. A written ban with open USB ports reads as a policy written to impress rather than to run.

10. 10

    Email, messaging and phishing

    What it must contain

    How to recognize a suspicious message, what not to click, how to verify through a channel you already trust, exactly where to report, and an explicit promise that reporting in good faith is never punished.

    What the auditor checks

    Read alongside your awareness training and your reporting numbers. Both are A.6.3 evidence, and both are checked more often than the policy text.

    Report suspected phishing to [report button or address] even if you already clicked: telling us early limits the damage, and nobody is disciplined for reporting in good faith.

    One sentence carries a named destination and an explicit amnesty. Without the amnesty, the person who clicked stays quiet until the finance team notices, and you lose the hours that mattered. It also protects your numbers: a policy that punishes reporters produces suspiciously clean reporting statistics, and experienced auditors know what those mean.

11. 11

    Social media and public comment

    What it must contain

    Who may speak for the organization and who may not, what must never be posted - customer information, internal documents, system screenshots, anything under a contract or NDA - and that nobody responds publicly to a security incident or a media question.

    What the auditor checks

    Cross-checked against the communications step in your incident response plan. Two documents naming different spokespeople is an easy finding.

12. 12

    Monitoring and what you can expect

    What it must contain

    What you log and monitor, the legitimate purposes, who can see the results, and what happens to the personal information monitoring inevitably captures.

    What the auditor checks

    The auditor checks that people were told. Where the law requires prior notice, so does a regulator, and after the fact is too late.

    [Organization] logs and monitors the use of its systems - accounts, email, internet access, devices and cloud services - to keep them secure and available, to investigate incidents and suspected breaches, and to meet legal obligations. Monitoring is proportionate, and the results are seen only by [role] and anyone investigating a specific matter.

    It names what is monitored, why, and who sees the output - and it does so before anyone is monitored rather than after something has gone wrong. This is the clause that gets picked apart when you rely on it in a disciplinary case, and several jurisdictions require you to give notice first. Rules on workplace monitoring differ by country and state, so check the local law before you finalize the wording.

13. 13

    Reporting problems

    What it must contain

    One named route and a timeframe, with concrete examples: a lost device, a link you should not have clicked, a password you may have exposed, a file sent to the wrong person. Say that people report their own mistakes as readily as attacks.

    What the auditor checks

    Matched against the incident register and the incident response plan. If the channel named here does not exist, or nothing ever arrives through it, the control is on paper only.

14. 14

    Breaches and consequences

    What it must contain

    The link into your disciplinary process, the contractual route for contractors and suppliers, referral to law enforcement for theft or fraud, and an exception route for rules that genuinely cannot be met.

    What the auditor checks

    Looks for the exception route to be real: risk-assessed, time-limited and recorded. Exceptions that are simply assumed are non-compliance with extra steps.

15. 15

    Acknowledgment, ownership and review

    What it must contain

    Everyone in scope confirms they have read and understood it when they join and at each annual refresher. Name the owner, the approver with their title, the approval date, the version, and the review cadence.

    What the auditor checks

    The clause tested hardest, because it is the one that generates evidence. Expect to be asked for the acknowledgment list and for a named recent joiner within it.

Get it written for your organization - your first document is free Card required; no charge today.

? Show me the current acceptable use policy.

Satisfies One version, with an owner, an approver named with their title, an approval date, a version number and a review date that has not passed.

Fails A header still reading Draft, or a review date from two years ago, fails before anyone reads a clause.

? Who has read it?

Satisfies An acknowledgment record covering everyone in scope with dates, including contractors and people who joined last month. This is the A.6.3 evidence, and it fails far more often than the document does.

? Take this person who joined in March.

Satisfies Their induction record: the policy issued, acknowledged, and the awareness training that went with it, all inside whatever timeframe you committed to in writing.

? Your policy says new software is approved by a named role. Show me the last approval.

Satisfies A real request and a dated decision, for a tool that is genuinely in use. Sampling a clause against reality is the standard move, so treat every rule you write as a rule you have agreed to evidence.

? You monitor email. Were people told, and when?

Satisfies The monitoring clause plus an acknowledgment that predates the monitoring, and a purpose a reasonable person would call proportionate.

Fails Notice issued after an investigation began is worse than no notice at all.

? What happens when someone breaks it?

Satisfies The link into your disciplinary process, and ideally one worked example: an exception that was risk-assessed, time-limited and recorded, or a breach that was actually handled the way the document says.

? How does this line up with your other documents?

Satisfies The password rule matching your access control policy, the reporting route matching your incident response plan, and the device rules matching what your device management actually enforces.

Fails Contradictions between documents are the cheapest finding an auditor will ever write.

The pattern is worth naming: every rule you write becomes a rule you have to evidence. That is an argument for a shorter policy that is true, not a longer one that is aspirational.

• ! Banning personal use you have no intention of policing.

  An unenforced rule is a lesson that the rules are decorative, and it spreads to the clauses you do care about. Write the rule you will actually apply, then apply it.

• ! Shipping it with the placeholders still in, or with somebody else's job titles.

  "[Approved password manager]" helps nobody, and neither does a Line Manager role you do not have. Name the real tool and the real role - "1Password, requested from the IT Manager" - then search the finished document for square brackets before anyone approves it.

• ! Twenty pages that nobody finishes.

  This is the one security document every employee reads, usually on their first day. Three pages read beat twenty scrolled past. Push the detail down into the specialist policies underneath and keep this one human.

• ! Writing rules that contradict your technical controls.

  If the policy bans USB drives while the ports are open, or requires MFA that half your systems do not offer, you have written your own audit finding. Match the words to the configuration, or change the configuration.

• ! Bolting on a monitoring clause after the investigation started.

  Notice comes first, and in several jurisdictions the law says so explicitly. Issue it, get it acknowledged, and only then rely on it.

• ! No exception route, so people quietly ignore the rule instead.

  Give them somewhere to ask. Exceptions that are risk-assessed, time-limited and recorded are a working control. Silent non-compliance is not, and you will not find out about it until the audit.

• ! Approving it and then never mentioning it again.

  A policy nobody has been told about satisfies nothing. Acknowledgment when people join, a refresher every year, and a record of both - that record is the part an auditor asks for first.

Follow the guide above and you get a good policy. The alternative is to answer questions about your business once and have it written: the same fifteen sections with the placeholders already resolved - the password manager you actually use, the approval route for new software, your real answer on personal use, a monitoring clause naming who reads the logs, and a closing block with the owner, approver and version. The hero above is the cover page of exactly that. Below is a page of the clauses themselves, generated for an example company and set in that company's branding.

Where the guide says [role] or [system], the document says yours; where PolicyMint cannot know a fact, it asks rather than guesses.

Guided review Actual product

The one fact this document could not know stays highlighted in the document and the export. The review explains what is needed and writes your answer in. Nothing is invented. Fictional demo data.

Both columns end with the same thing: one acceptable use policy you can issue on Monday. What changes is how much of it you write, and how much of it you have to keep true afterward.

Swipe the table sideways to read both columns.