The written policies every small business needs come to roughly eight documents, not forty. You need an information security policy, acceptable use, access control, data retention and deletion, incident response, vendor management, business continuity, and a code of conduct. Each one should be two to four pages, dated, signed off by a named person, and reviewed annually.
Length is not the measure of a good policy. A reviewer, insurer or customer is checking that the document says what you actually do, that someone owns it, and that it has been looked at recently.
Policy, standard, procedure: get the difference right
Most policy sets collapse because the three layers get mixed together, which makes the whole thing impossible to maintain.
A policy states intent and scope. It says what must be true and who is accountable. It changes rarely.
A standard sets the specific requirement. "Passwords must be at least fourteen characters and multi-factor authentication is required on all administrative accounts." Standards change when technology changes.
A procedure is the step-by-step. "To offboard a user: open the identity provider, revoke sessions, remove group membership, transfer file ownership, log the completion." Procedures change often and should live wherever your team actually works.
Keep policies free of tool names and screen-by-screen instructions. The moment you change tools, a policy written at procedure level becomes wrong, and a wrong policy is worse than a general one.
The eight policies to write first
Work through them in this order. The earlier ones are referenced by the later ones.
- Information Security Policy. The umbrella document. Scope, who is accountable, the high-level commitments, and a list of the other policies underneath it. Two pages is enough.
- Acceptable Use Policy. How company systems, devices, email and data may be used. Covers personal devices, removable media, software installation and what happens on suspected misuse. This is the one every employee signs.
- Access Control Policy. Who gets access to what, on what approval, with what authentication, and how access is removed. Include the joiner-mover-leaver flow and the rule for administrative accounts. This policy prevents the single most common source of real incidents.
- Data Retention and Deletion Policy. What categories of data you hold, where, for how long, and how it is destroyed. Also covers customer data at contract end. Privacy regimes including the GDPR require that personal data not be kept longer than necessary, which makes this policy load-bearing rather than cosmetic.
- Incident Response Policy. What counts as an incident, who declares one, who they call, and the notification obligations you have agreed to in contracts and are subject to by law. Keep the detailed runbook separate.
- Vendor and Third-Party Management Policy. How vendors are assessed, tiered, approved and reviewed. Points to your vendor inventory rather than containing it.
- Business Continuity and Backup Policy. What must stay running, the target recovery times, how backups are taken and where, and the requirement to test restores. State the test frequency, because an untested backup is the gap reviewers probe hardest.
- Code of Conduct. Behavior, conflicts of interest, confidentiality and reporting concerns. Employment counsel should see this one.
What to add when your situation calls for it
Add a privacy notice if you collect personal data from the public, which is almost everyone with a website. Add a remote work policy if staff work from anywhere other than your premises. Add a change management policy if you build or deploy software. Add an acceptable use addendum for contractors if you use them with system access.
Resist adding more than you need. Eight maintained documents beat twenty-five abandoned ones.
What belongs in every policy
Use the same seven-part shape for all of them, which makes the set look deliberate and makes review mechanical.
| Section | What goes in it |
|---|---|
| Purpose | One or two sentences on why the policy exists |
| Scope | Who and what it applies to, and anything explicitly excluded |
| Policy statements | The numbered requirements, written as "must" and "must not" |
| Roles and responsibilities | Named roles, and one named accountable owner |
| Exceptions | How an exception is requested, approved and recorded |
| Review | Frequency, the owner, and the next review date |
| Version history | Version, date, author, what changed |
Version history and a next review date are what separate a document in use from a template someone downloaded. Both are free to add.
The exceptions section matters more than it looks. Without a written exception route, people quietly work around the policy and the document stops describing reality.
How to write them without burning a month
Write from what you already do, not from a template you aspire to. Spend an hour per policy interviewing whoever does the work, write down the current practice, then mark the two or three places where current practice should change. Those marked places become your remediation list.
Draft at the level of "must" statements and stop. Ten clear requirements are better than three pages of prose. If you find yourself explaining a tool's interface, move that text to a procedure.
Have one person own the whole set so the voice and structure stay consistent. Then have someone who did not write them read two at random and ask whether they could follow them. Policies that cannot be followed get ignored, and an ignored policy is a liability in a review because it proves a control exists on paper only.
Get sign-off from one named person with authority, record the date, and distribute. Distribution with an acknowledgment record is part of the control, not an administrative afterthought.
Mistakes that make a policy set worthless
Copying a template without editing the scope. Policies referring to departments, data centers or roles you do not have are immediately recognisable and undermine everything else in the set.
Writing what you wish were true. If you claim quarterly access reviews and have never run one, you have documented a failure rather than a control. Write the practice you have, with a dated plan to improve it.
No dates anywhere. Undated documents cannot be assessed. A reviewer reads an undated policy as never reviewed.
One giant document. A forty-page combined policy cannot be distributed to the right audiences, cannot be versioned sensibly, and never gets read.
Naming specific products. Policies that name tools go out of date the week you switch vendors. Describe the requirement, not the product.
No owner. A policy with no named owner will not be reviewed, because nobody's calendar says to.
Keeping them alive
Put the review dates in one place and stagger them so you are not reviewing eight documents in the same week. A quarterly rhythm of two policies each quarter keeps the whole set current with modest effort.
Trigger an off-cycle review on four events: you adopt a materially different tool or platform, you take on a contractual obligation you cannot currently meet, you have an incident or near miss, or a law or regulation in your sector changes. The last one deserves a standing annual check, because compliance obligations shift and a policy written against an outdated requirement will not hold up.
Keep superseded versions rather than overwriting. The version history is the evidence that the process is real, and it is the first thing a careful reviewer looks at.
For a structured walk-through of which of these eight your business is missing and in what order to close them, start with the Compliance capability page on this site.