Guide

Acceptable Use Policy Template

How to write an acceptable use policy for a small business: the clauses it should contain, and how to adopt and enforce rules your team will follow.

By SecureBusinessHub Editorial, International cybersecurity desk — 2026-07-24 · 9 min read

An acceptable use policy, or AUP, is the document that tells everyone in your business what they may and may not do with company technology — laptops, phones, email, cloud accounts, and the internet connection they use all day. It is the most everyday of all security policies, because it governs behaviour rather than configuration: not what your firewall does, but what your people do. For a small business, it is also the single most useful document to write first, because almost every incident that starts with a person — a bad click, a risky download, a shared password — is one an acceptable use policy is meant to prevent.

This guide explains what an acceptable use policy is for, the clauses a small-business AUP should contain, and how to adopt and enforce it so it changes behaviour rather than gathering dust. It is one of the four foundation documents in our small business security policy guide, and it pairs naturally with a password and MFA policy, which covers the account-security rules an AUP references but does not spell out in full.

What an acceptable use policy is for

The purpose of an AUP is to remove ambiguity. Without one, every member of staff is left to guess where the line sits: can I install this browser extension, forward this file to my personal email, use the office wifi for my own devices, plug in a USB stick a client handed me? People are not reckless; they are usually just uninformed, and in the absence of a rule they default to whatever is convenient. An AUP replaces guesswork with a clear, shared standard, so that safe behaviour is the obvious behaviour and risky behaviour is something someone chose to do against a rule they had read.

That last point matters more than it sounds. When an AUP is in place and acknowledged, you have both prevented most casual mistakes and established a fair basis for dealing with the few that remain. "We never told anyone not to" is not a position you want to be in after an incident — with an insurer, with a client, or with your own team. An AUP is how a small company sets expectations once, in writing, instead of relitigating them every time a new situation comes up.

What an acceptable use policy covers

A good AUP is broad but shallow: it touches most of the ways staff interact with technology, without diving into the technical depth that other policies handle. Think of it as the map that points to your other rules. It typically covers the following areas, each in a short, plain paragraph rather than a legal essay.

Acceptable and unacceptable use of company devices and accounts — what work equipment is for, and the personal use, if any, that is tolerated.
Email and communication — how to treat attachments and links, and the expectation that suspicious messages are reported rather than deleted quietly.
Software and downloads — what staff may install themselves and what requires approval, because unmanaged software is a common way malware and licensing problems creep in.
Internet and network use — sensible limits on what company connections are used for, and rules for connecting personal devices.
Data handling — where company and customer data may and may not be stored, copied, or sent, at a level that a data retention policy then details.
Removable media and physical security — how to treat USB drives, printed documents, and unattended, unlocked devices.
Reporting — the simple expectation that anything odd, lost, or clicked-by-mistake is reported quickly and without blame.

The clauses your AUP should contain

Every AUP will be a little different, but a small-business version should contain a recognisable core. Below is the set of clauses worth including, described in the order they usually appear. You can lift these headings directly into your own document and fill each one with rules that match how your business actually works.

Start with purpose and scope. State in a sentence or two why the policy exists — to protect company and customer data and keep systems reliable — and who it applies to. Be explicit that it covers not just full-time employees but contractors, temporary staff, and anyone else with access to your systems, because those are exactly the people who are otherwise assumed to be someone else's responsibility.

Then set the general use rules: company devices and accounts are provided for business, staff are responsible for the security of what they are given, and a modest amount of personal use is either permitted within limits or not, depending on your culture. Follow with the specific behavioural rules — email caution, software approval, safe data handling, and the treatment of removable media — each phrased as a clear expectation rather than a vague hope.

Account security — reference your password and MFA policy so the AUP does not duplicate those rules but clearly requires them.
Prohibited activities — a short, honest list of things that are genuinely not allowed: sharing credentials, disabling security tools, installing unapproved software, or moving company data to personal accounts.
Monitoring and privacy — a plain statement of any monitoring you do and why, so staff are not surprised and you meet local privacy expectations.
Consequences — what happens when the rules are broken, stated calmly and applied consistently.
Acknowledgement — a line confirming the person has read and agreed to the policy, with a date.

Writing rules people will actually follow

The failure mode of acceptable use policies is length and tone. Because the subject is broad, it is tempting to write pages of defensive, catch-all language that reads like a legal contract. Nobody reads it, everyone signs it, and the policy protects no one. Resist that. Keep each rule to a plain sentence, write in the second person, and explain the reason where it helps — people follow "don't reuse your work password on other sites, because one breached site then exposes your work account" far more reliably than a bare prohibition.

Be realistic about personal use. A policy that bans all personal use of work devices is one that everyone violates within a week, which quietly teaches your team that the whole document is optional. It is usually better to permit reasonable personal use within clear limits than to write a rule you will not enforce. The goal is a policy your staff can genuinely live by, because a followed policy that is 90% strict beats a perfect one that is universally ignored.

Adopting and enforcing the policy

An AUP only works once people have read and accepted it. Roll it out with a short explanation rather than a silent request for signatures, fold acknowledgement into onboarding so every new hire accepts it before they get access, and keep a dated record of who has agreed to which version. When you update the policy, circulate the change and collect fresh acknowledgements — a policy people signed two years ago for a different version is weak evidence that the current rules are in force.

Enforcement should be consistent and proportionate. The point is not to punish; it is to apply the same standard to everyone, so that a breach is handled the same way regardless of who caused it. Most violations are honest mistakes and are best met with a reminder and, if a rule turned out to be unrealistic, a change to the rule. Reserve real consequences for deliberate or repeated disregard. A team that sees the policy applied fairly comes to treat it as a genuine standard rather than a threat that is never carried out.

A worked example: the email clause

It helps to see how a single clause moves from vague to usable, because the same method applies to every rule in the policy. Take email, the channel through which most attacks on small businesses arrive. A weak version reads: "Employees must exercise caution with email." It sounds responsible and means nothing — there is no behaviour to follow and nothing to check. Caution is a feeling, not an instruction, and a rule that cannot be acted on cannot be broken or upheld.

A usable version names the behaviour: "Do not open attachments or click links you were not expecting, even from a known contact. If a message asks you to log in, pay an invoice, or change payment details, verify it through a separate channel — a phone call or a fresh message — before acting. Report anything suspicious to whoever handles IT, and never feel you will be blamed for reporting something that turns out to be harmless." Every sentence describes something a person can actually do, and the last one matters as much as the rest: a reporting culture where people are thanked rather than blamed is what turns your staff from your weakest link into your earliest warning system.

Apply the same test to every clause. If a rule cannot be followed by a specific action or checked after the fact, rewrite it until it can. "Handle data responsibly" becomes "store customer data only in the approved systems listed below, and never copy it to personal email, personal cloud accounts, or USB drives." "Keep devices secure" becomes "lock your screen when you step away, and report a lost or stolen device the same day." The discipline of turning every good intention into a concrete, checkable instruction is what separates a policy that changes behaviour from one that merely expresses hope.

Keeping the policy current

An acceptable use policy dates faster than most, because it describes tools and habits that change. A rule about a chat app you no longer use, or the absence of any rule about the AI assistant your team adopted last quarter, is a sign the policy has drifted from reality. Review it at least once a year and whenever you adopt a significant new tool, and treat any incident as a prompt to check whether the relevant clause was clear and realistic. Record the review date on the document so anyone — a new hire, an insurer, a client — can see at a glance that it is maintained rather than forgotten. A living acceptable use policy is one of the clearest signals that your business takes everyday security seriously.

Where the acceptable use policy fits

The acceptable use policy is the front door to your security policies — the one most people encounter first and the one that references the others. It sits alongside your small business security policy framework and points to the password, data retention, and remote work rules that handle the detail. If you would rather adapt a professionally structured version than write one from scratch, our editable policy template pack includes an acceptable use policy built for small businesses, ready to fill in with your own tools, culture, and rules. Whichever route you take, the value is in the reading and the adapting: an AUP you have genuinely tailored to how your team works is one they can actually follow.

NIS2 requirements: the second regime to know about

Data protection law is not the only European regime a business gets asked about. The NIS2 directive sets baseline cybersecurity and incident-reporting obligations for organisations in a defined list of sectors, and it is the source of most of the security questions that now arrive attached to contracts. The two regimes cover different ground: data protection law governs personal data and what people can ask you to do with it, while the NIS2 requirements govern the security and resilience of network and information systems, whether or not personal data is involved. A single incident can engage both, on separate clocks, to separate authorities.

The directive applies to organisations in its listed sectors that are at least medium-sized, meaning broadly fifty or more employees or turnover and balance sheet above ten million euros. That size rule puts most small businesses outside its direct scope, and the honest answer for a ten-person company is usually that the directive does not regulate it. What the size rule does not do is keep the requirements away, because one of them is supply chain security: organisations inside scope are expected to consider the security practices of their direct suppliers, and the way that expectation shows up in the world is as a questionnaire in your inbox.

The measures the directive names are a reasonable checklist for any business, which is why they are worth knowing even when they do not apply to you directly. They cover risk analysis and written security policies, incident handling, business continuity and backups, supply chain security, secure development and vulnerability handling, basic cyber hygiene and training including for management, encryption and access control policies, and multi-factor authentication. Reporting is staged and fast for the organisations it covers: an early warning within twenty-four hours of becoming aware of a significant incident, a fuller notification within seventy-two hours, and a final report within one month.

Because the directive is national law in each member state rather than a single rulebook, the details of scope, thresholds and reporting differ by country. For a fuller explanation of the instrument itself, see our guide to what the NIS2 directive is, and for the supplier side of the supply chain obligation, our walkthrough of vendor risk assessment. The reporting clocks that run alongside data protection deadlines are covered in data breach notification requirements.

Frequently asked questions

Does NIS2 apply to a small business?

NIS2 generally applies to organisations in its listed sectors that are at least medium-sized, meaning broadly fifty or more employees or turnover and balance sheet total above ten million euros. Most smaller businesses fall outside its direct scope, unless a member state has specifically designated them or they sit in one of the size-independent categories such as DNS service providers or trust service providers. Being outside scope does not stop the directive reaching you through customers who are inside it.

What is the difference between GDPR and NIS2?

GDPR governs personal data: what you may collect, why you may hold it, and what rights people have over it. NIS2 governs the security and resilience of network and information systems in specific sectors, whether or not personal data is involved. One incident can engage both regimes at once, on separate reporting clocks and to separate authorities.

How long do you have to report a data breach?

Under the European model, a personal data breach is reported to the supervisory authority without undue delay and, where feasible, within seventy-two hours of becoming aware of it, and affected individuals are told without undue delay where the risk to them is high. Organisations in scope of NIS2 carry a separate obligation: an early warning within twenty-four hours, a fuller notification within seventy-two hours, and a final report within one month.

Does a small business need a data protection officer?

Under GDPR a data protection officer is required where the organisation is a public authority, where its core activities involve regular and systematic monitoring of people on a large scale, or where its core activities involve large-scale processing of special category or criminal offence data. Most small businesses meet none of those tests and are not required to appoint one, though naming someone internally as the contact for privacy questions is worth doing regardless.

What should a small business do when a client's security questionnaire asks about NIS2?

Answer what you actually do rather than what you think the client wants to hear. The questions usually cover written security policies, incident handling and how fast you would notify them, multi-factor authentication, access control when staff join and leave, backup and recovery arrangements, and which of your own subprocessors touch their data. Gaps are common, and disclosing one with a date for closing it lands far better than an answer that does not survive the follow-up question.

Do these rules reach a business based outside the EU?

They can. GDPR reaches organisations outside the EU that offer goods or services to people in the EU or monitor their behaviour, and other regions have their own regimes with their own triggers. NIS2 obligations follow the sectors and the member states that transpose it, but its supply chain expectations travel through contracts, which is how they reach suppliers anywhere in the world.