Most small businesses that have a cyber security policy have one for one of two reasons: their insurer required it, or they were working from a template someone found online. Both are better than nothing. Neither typically produces a document that reflects how the organisation actually works, that staff have read, or that would demonstrably help in the event of an incident or regulatory investigation.
This guide explains what a cyber security policy for a small business needs to cover, how to write one that is proportionate rather than performative, and how to ensure it remains useful rather than gathering dust in a folder nobody opens.
What a Cyber Security Policy Is For
A cyber security policy serves three distinct purposes, and understanding all three helps you write one that is genuinely fit for purpose rather than a compliance checkbox.
The first purpose is operational: it tells your staff, contractors, and IT providers what is expected of them when it comes to handling information and using technology. Clear expectations, documented, reduce the probability of incidents caused by human error or misunderstanding.
The second purpose is evidential: it demonstrates to regulators, auditors, clients, and insurers that you have thought about cyber risk and put documented controls in place. Under UK GDPR's accountability principle, being able to show that you have a policy — and that staff are aware of it — is a component of demonstrating compliance. The ICO looks for it. Cyber insurers ask for it. Procurement teams increasingly require it.
The third purpose is incident response: when something goes wrong, a well-written policy provides a reference point for what the organisation's agreed response procedures are. Without it, decisions under pressure are made inconsistently.
What a Small Business Policy Must Cover
The instinct when writing a policy is to include everything. The result is usually a document too long to be read, too generic to be actionable, and updated so infrequently it becomes inaccurate within months. A better approach is to cover the essential areas thoroughly and resist the temptation to add sections that don't reflect how your organisation actually operates.
Acceptable Use
What are staff permitted and not permitted to do with company systems, devices, and accounts? This section should be specific enough to be useful: can staff use company laptops for personal use? Are personal devices permitted to connect to the company network? Is work data permitted on personal cloud storage? These are the questions that create ambiguity in practice, and ambiguity creates risk.
Password and Account Management
Your policy should specify minimum password requirements, the requirement to use a password manager, the prohibition on sharing credentials, and the procedure for account creation and removal when staff join and leave. The most common credentials-related security failure in small organisations is the failure to revoke access when someone leaves — a policy that makes this a mandatory step in the offboarding process, and assigns responsibility for it, directly reduces that risk.
Device Security
Which devices are permitted to access company data? Are personal devices allowed, and if so under what conditions? What must be installed on a device before it can access company systems — antivirus, screen lock, encryption? What happens to company data on a device when an employee leaves? For organisations with hybrid or remote working, this section is particularly important.
Data Handling and Classification
Not all data requires the same level of care. Your policy should define categories of data — at minimum: confidential (client data, personal data, commercially sensitive information) and general — and specify how each category may be stored, transmitted, and shared. This doesn't need to be complex: "personal data must be encrypted when stored on portable devices and must not be sent via personal email" is a specific, actionable requirement that addresses a real risk.
Incident Reporting
Staff need to know what constitutes a security incident and — critically — that they should report it rather than deal with it quietly or ignore it. Fear of blame is the primary reason incidents go unreported, and unreported incidents become serious incidents. Your policy should make clear that you want to know about suspected incidents, that reporting promptly is the right thing to do, and who to contact. A named person, not a generic email address.
Remote Working
If staff work from home, client premises, or public locations, your policy needs to address this specifically. Public Wi-Fi, home networks, over-the-shoulder access to screens, printing sensitive documents at home — these are practical risks that a policy should address with practical guidance rather than generic warnings.
Third-Party and Supplier Access
If you use an external IT provider, cloud services, or contractors who have access to your systems or data, your policy should address how that access is governed. What access are they permitted? How is it reviewed? What security standards do you require of suppliers who handle your data? GDPR's processor requirements mean this section also has legal significance.
What to Leave Out
Leave out anything that doesn't apply to your organisation. A section on "secure software development lifecycle" is irrelevant if you don't develop software. A section on "physical data centre security" is irrelevant if you don't operate a data centre. Every section that doesn't apply dilutes the credibility of the sections that do.
Leave out aspirational statements that you cannot currently meet. A policy that says you perform quarterly penetration tests when you don't is worse than no policy — it's evidence that your stated controls are fictional.
Making the Policy Stick
A policy that staff haven't read is not a control. It's a document. The difference between the two is whether it has been communicated, understood, and — at least in relation to the most important requirements — tested.
Keep it short enough to read in one sitting. Use plain English throughout. Make staff acknowledge they have read it — a simple email or form provides the evidence you need. Review it annually and after any significant incident or organisational change. Assign ownership to a named individual, not a team or a role.
A four-page policy that staff have read and understand is worth more than a forty-page document that hasn't left the shared drive.
Further Reading
Policy Is the Foundation. Monitoring Is the Structure.
A cyber security policy tells your staff what to do. SOC in a Box watches to ensure that what's happening on your network is consistent with what your policy says should be happening. Continuous monitoring and monthly analyst reports provide the evidential layer that sits above the policy — demonstrating to regulators and insurers that your controls are working, not just documented.
Book your scoping call