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 how people behave, while other policies handle configuration. For a small business, it is also the single most useful document to write first. Almost every incident that starts with a person, whether a bad click, a risky download, or 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 that it changes behaviour instead of 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 usually uninformed rather than reckless, 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 part has practical weight. With an AUP in place and acknowledged, you have prevented most casual mistakes and set a fair basis for dealing with the few that remain. After an incident, "we never told anyone not to" is a weak position with an insurer, with a client, or with your own team. An AUP lets a small company set expectations once, in writing, instead of arguing them out again 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 going into the technical depth that other policies handle, and it points to those other rules where they apply. 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, not silently deleted.
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 devices left unattended and logged in.
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. The clauses worth including follow, 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 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. Say explicitly that it covers contractors, temporary staff, and anyone else with access to your systems as well as full-time employees, 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 on 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 not allowed, such as 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

Acceptable use policies usually fail on 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. 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. Everyone will break a ban on all personal use of work devices within a week, and that teaches your team 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. Aim for a policy your staff can live by: 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. Signatures collected two years ago on a different version are weak evidence that the current rules are in force.

Enforcement should be consistent and proportionate. The aim 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. When a team sees the policy applied fairly, it treats the policy as a standard instead of 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, and a rule that cannot be acted on cannot be broken or upheld either.

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, such as 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 do, and the last one matters as much as the rest. When people are thanked for reporting, your staff become the first to warn you that something is wrong.

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." A policy changes behaviour when every good intention in it has been turned into an instruction someone can follow and check.

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 that a new hire, an insurer, or a client can see at a glance that it is maintained.

Where the acceptable use policy fits

The acceptable use policy is 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 an existing 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. Either way, the work is in reading and adapting it until it matches how your team works.

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. Under that size rule, a ten-person company is usually not regulated by the directive at all. The requirements can still reach you, because one of them is supply chain security: organisations inside scope are expected to consider the security practices of their direct suppliers, and in practice that expectation arrives 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. A smaller business falls outside its direct scope unless a member state has specifically designated it or it sits 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. A small business that meets none of those tests is 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 with what you do now 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.