TL;DR
An acceptable use policy sets out what people may do with company systems and equipment. The version that works is two pages, written in plain language, with rules you could actually observe being broken. Most templates cover email and passwords well and say almost nothing about the laptop itself.
- Two pages for the document people read. Detail goes in supporting material.
- Every clause should pass one test: how would you know it was broken?
- Allow reasonable personal use, with clear exclusions.
- Add the device section: ownership, return, damage, loss.
- Name an owner who decides edge cases, not a committee.
- Record acknowledgement with a date, and store it where an investigator would look.
When you do not need one yet
Four stages, and the first genuinely needs nothing.
Very small and co-located. Six people in a room. Norms travel by conversation and a document adds nothing you are not already achieving.
Best tools for HR Operations
Growing, mostly remote. New starters cannot absorb norms by observation any more. A one-page statement is proportionate here, and writing twelve pages is not.
Something happened. Somebody installed a tool nobody vetted, or used a personal account for customer data. Now you need written expectations, because the conversation afterwards needs a reference point.
Somebody external asks. A customer questionnaire or an insurer wants to see the policy. At this stage the document needs to exist, be current, and have evidence that people saw it.
What an acceptable use policy should contain
Five sections. Anything else is usually a different document wearing this one’s name.
- Scope. Who it applies to and what counts as company equipment. Say whether contractors are included, because that ambiguity causes real problems later.
- Accounts and access. How credentials are handled, what sharing is prohibited, and what to do when something looks wrong. Keep the detail of password construction in a separate document.
- Data. Where company information may be stored and what must not leave approved systems. This is the section auditors read first.
- Devices. Ownership, acceptable personal use, damage, loss and return. Covered below, because it is the section most templates omit.
- Consequences and ownership. What happens if a rule is broken, and who decides. Without a named decision-maker, every edge case escalates.
If your organisation is working towards certification, the related control expectations sit under ISO/IEC 27001, which anticipates documented rules for acceptable use of information and associated assets. The standard does not dictate your wording, which is why borrowed templates so often read as generic.
One clause deserves more care than the rest, and it is the data one. If people handle personal information about colleagues or customers, the policy has to connect to whatever your organisation already says about data protection rather than inventing a parallel set of rules. Guidance published by national regulators is usually a better starting point than a template, and the National Institute of Standards and Technology publishes plain-language material that is useful even outside the United States.
The second thing worth doing is deciding, in advance, which clauses you would be prepared to dismiss somebody over. Most organisations have two or three. Writing them differently from the rest, in firmer language, tells people where the real boundaries are. A document in which every rule carries the same weight communicates that none of them does.
The device clause most templates skip
Search for a template and you will find thorough treatment of browsing, email and software installation. Then the laptop disappears from the document, which is strange, because the laptop is the most valuable thing you hand anybody.
Four things belong here and they take a paragraph each.
Ownership. State that the device remains company property throughout employment and afterwards. Obvious to you, genuinely unclear to some people, particularly where a stipend was involved.
Reasonable personal use. Say what is fine and name the few things that are not. Vagueness here produces inconsistent enforcement, which is worse than a permissive rule applied evenly.
Damage and loss. What to report, how quickly, and what happens about cost. Decide the deduction question before an incident rather than during one, because afterwards it looks punitive whatever you choose.
Return. That the device must be returned on request or at the end of employment, through the process the company specifies. This single sentence is what later makes a retrieval request routine rather than a negotiation, and it is the one most often missing.
Five tests for every clause
Could you tell if it was broken? If not, it is guidance. Move it or cut it.
Would you actually act? A consequence nobody would apply teaches people the document is theatre.
Is it specific enough to follow? “Use good judgement” is not a rule, it is a hope.
Does it survive remote work? Clauses assuming an office fail quietly for half your people.
Is it in the right document? Password construction, data retention and monitoring each deserve their own page.
Where teams get the document, and the trade-offs
A downloaded template. Best for speed and for having something. It struggles because it is written for nobody in particular, and the device section is usually thin or absent.
Your employment lawyer. Best for enforceability and local accuracy, which matters if you operate in several jurisdictions. It struggles on readability, since legally sound documents are rarely two pages and rarely read.
Your HR platform’s library. Best for distribution and acknowledgement tracking, which is half the problem solved. It struggles on specificity, because library content is generic by design.
Writing it yourself. Best fit to how you actually work, and the version people follow. It struggles on legal edge cases, so have someone check it rather than drafting from scratch with them.
Equipment and lifecycle vendors. Some supply policy language covering the device section specifically. Disclosure: RemoAsset is owned by the same people who publish this site. It handles procurement, delivery, retrieval and wiping across 80 or more countries, which matters to this document because a return clause is only as good as the process behind it. Where it struggles: it is a logistics service, not a policy or legal provider, so the wording remains yours to write. What it changes is whether the return clause is operationally real or aspirational.
The decision table
| Situation | Scale | Setup | Primary pain | Recommended starting point |
|---|---|---|---|---|
| Small and co-located | Under 15 | No HR function | None yet | One page, revisit at 25 people |
| Growing and remote | 15 to 80 | One HR owner | Norms do not travel | Two pages, acknowledged at onboarding |
| After an incident | Any | Any | No reference point | Rewrite the clause that failed |
| Customer questionnaires | 50 plus | Compliance owner | Must evidence it exists | Dated acknowledgements per person |
| Several countries | 100 plus | HR team | One wording fits nowhere | Core policy plus local annexes |
| Disputes over damaged kit | Any | Any | No agreed position | Write the damage clause first |
What an unenforceable policy costs
The cost of a bad acceptable use policy is rarely the incident itself. It is the discovery, mid-incident, that the document does not help you.
The common shape is a dispute about a device. Somebody has left and will not return a laptop, and the policy they acknowledged says nothing about return obligations. You are now negotiating from a position you could have written down for free two years earlier.
The second cost is uneven enforcement. Vague clauses get applied differently by different managers, which is unfair in practice and difficult to defend if anybody challenges it. A permissive rule applied consistently is safer than a strict one applied occasionally.
The third is credibility. A policy containing rules everybody breaks daily teaches people that the whole document is decoration, including the clauses that genuinely matter. That lesson is expensive and hard to reverse.
So the question is not whether you have a policy. It is whether the three clauses you would actually need in a dispute are specific enough to rely on.
When the policy needs operational support
A policy is a promise about how the organisation behaves. It stops being credible when the operations behind it cannot deliver.
The return clause is where this shows first. A document saying equipment must be returned on request means little if nobody can arrange a collection from another country, or if there is no record of who holds what. The clause is then an intention rather than a commitment.
Two supports make it real. An accurate record of which device sits with which person, and a working route to get equipment back from wherever your people are. Without those, the policy describes an outcome you cannot produce.
This is worth checking before rewriting the wording again. If the last three return requests were difficult, the problem is not the sentence. Seeing how a managed lifecycle service handles returns is a quicker way to find out whether the gap is drafting or logistics.
See how an equipment return clause works in practice
Read our guide to the device policy in your handbook
Related reading
- Putting device policy in the handbook
- Writing an employee equipment policy
- BYOD policy, practically
- What to do about unreturned equipment
- The employee equipment agreement
Frequently Asked Questions
What is an acceptable use policy?
A short document saying what people may and may not do with company systems and equipment. It covers devices, accounts, data and networks, and it exists so that expectations are written down before somebody breaks one. Its value is in being specific enough to act on.
How long should it be?
Two pages at most for the version people read. Anything longer gets skimmed and signed without being absorbed, which defeats the purpose. Detail that genuinely belongs somewhere can live in supporting documents the policy points at, rather than in the thing you ask everyone to agree to.
What do most templates miss?
The device itself. Templates cover passwords, email and browsing, then say nothing about who owns the laptop, what happens when someone leaves, or who pays if it is damaged. That gap is where most real disputes happen, and it is the easiest section to add.
Should personal use be banned?
Banning it outright is unrealistic and makes the whole document less credible. Reasonable personal use, stated plainly with a few clear exclusions, is more likely to be followed. A rule everybody breaks on day one teaches people the policy is decorative.
How do we make it enforceable?
Write rules you can observe and act on, name an owner for decisions, and record acknowledgement. A clause nobody can check is advice rather than policy. Before including a rule, ask how you would know it had been broken and what you would do next.
How often should it be reviewed?
Annually, and whenever something material changes such as a new tool class or a shift in working patterns. A policy referring to systems you no longer run signals that nobody is looking after it, which undermines every other clause in the document.
Does it need a signature?
Record an acknowledgement at onboarding and after material changes. A dated record that somebody was shown the policy is far more useful later than a wet signature filed somewhere nobody can find. Store it where the person investigating an incident will look.
