Guide

Small Business Security Policy Guide

The written policies every small business needs, what each one must contain, and how to write, adopt, and maintain them without a legal team.

By SecureBusinessHub Editorial, International cybersecurity desk · · 15 min read

A security policy is a written record of the rules your business follows to protect its systems, its data, and the people who rely on it. It sets out how your team is expected to behave and what happens when something goes wrong, and it only works once it has been agreed and is applied the same way every time. For a large enterprise, that record fills a binder. For a ten-person company, it can be a handful of short documents. The purpose is the same at either size: something you can point to, hand to a new hire, and show to an auditor.

It is easy to put this off for years, and the reason is understandable: writing policy feels like paperwork for its own sake when you are busy running the company. But written policy has moved from "nice to have" to "show us or we walk away." Insurers ask for it before they will cover you. Larger clients ask for it before they will sign a contract. When an incident happens, your bank, your regulator, and your customers all start with the same question: did you have a plan, and did you follow it? This guide covers what an SMB security policy is, the core documents you need, what belongs in each one, and how to write and maintain them without hiring a consultant or a legal team.

Why written policies matter more than they used to

Ten years ago, a small business could reasonably treat security as an IT problem: install antivirus, keep backups, move on. Attackers now target small companies precisely because they expect the paperwork, and the discipline behind it, to be missing. A written policy sets a shared expectation, which no tool can do. When every member of staff knows that reusing passwords is against the rules, that customer data has a retention limit, and that a lost laptop must be reported the same day, there is far less ambiguity for an attacker to exploit. Policy lets a small team behave like a secure one without everyone having to be a security expert.

Cyber insurers have spent the last few years tightening what they require, and "do you have documented security policies?" is now a standard question on almost every application. A vague or missing answer raises your premium or gets you declined outright. If you ever file a claim, the insurer will also check whether you followed the policies you said you had. Our guide to why cyber insurance gets denied covers that in more detail. In short, the underwriter reads your policy as evidence that you manage risk deliberately.

Then there are your customers. Once you want to sell to a company larger than yours, you will meet the security questionnaire: a spreadsheet of questions about how you handle their data, who can access it, and what you do if it leaks. Almost every question maps to a policy. Do you enforce multi-factor authentication? That is your password and MFA policy. How long do you keep records? Data retention. Can staff use personal phones for work? Remote work and BYOD. Without written policies, you answer these questionnaires with guesses, and a buyer who is paying attention will notice. With them, you answer in a paragraph and attach the document.

  • Insurers read a written policy as evidence that you manage risk deliberately, which affects both whether you are covered and what you pay.
  • With clients, it can mean passing a security questionnaire in an afternoon instead of losing the deal to a competitor who can.
  • For regulators, it shows you took "appropriate" measures, the standard most data-protection laws hold you to.
  • For your own team, it turns individual good judgement into consistent behaviour from everyone.

The core policies every small business needs

You do not need a library of documents. Four written policies cover the ground that insurers, clients, and regulators ask a small business about. Start with these, get them adopted, and add more only when a specific need appears. Each one answers a different practical question about how your business operates, and each has a dedicated guide below that goes through the clauses one by one.

The first is an acceptable use policy. It defines what staff may and may not do with company systems, devices, email, and internet access: the everyday behaviour that either keeps you safe or slowly undermines you. It is the document that lets you say, with a clear conscience, "we told everyone not to do that." Our acceptable use policy guide breaks down every clause it should contain and how to adopt it without turning it into a wall of legalese nobody reads.

The second is a password and MFA policy. Weak and reused credentials remain the single most common way small businesses get breached, and this policy sets the rules that close that gap: how long passwords must be, that staff use a password manager, and that multi-factor authentication is switched on for anything that matters. The password and MFA policy guide covers what to require and what not to, because outdated rules like forced monthly rotation now do more harm than good.

The third is a data retention policy. Every business collects data it no longer needs, and every record you keep can be stolen, subpoenaed, or leaked. A retention policy decides in advance how long each type of information is kept and when it is deleted. That shrinks your risk and helps you answer the privacy questions clients and regulators ask. Our data retention policy guide explains how to build a simple retention schedule that fits a small business rather than a corporate legal department.

The fourth is a remote work and BYOD policy. If anyone on your team works from home, travels, or uses a personal phone or laptop for work, this policy sets the ground rules: device requirements, network expectations, and what happens when someone leaves. The BYOD and remote work policy guide covers how to protect company data on devices you do not own without micromanaging people's personal hardware.

Those four are the foundation. As the business grows, or when a client demands it, you may add an incident response plan, a vendor risk policy, or an access control policy.

What every good policy contains

Whatever the subject, a usable policy has the same skeleton. Once you know the parts, you can read any template critically and write your own. A policy that is missing them tends to fail in predictable ways: nobody knows if it applies to them, nobody owns it, and nobody can tell whether it is being followed.

  • Purpose: one or two sentences on why the policy exists and what risk it addresses. If you cannot state the purpose plainly, the policy is probably solving a problem you do not have.
  • Scope: who and what the policy covers, meaning which people (employees, contractors, temporary staff), which systems, and which devices. Vague scope is the most common reason a policy stops applying to the people who need it most.
  • The rules: the specific, testable requirements staff must follow, written as clearly as you can manage. "Use a strong password" is too vague to check. "Use a unique password of at least 14 characters, generated and stored in the company password manager" is a rule.
  • Roles and responsibilities: who owns the policy, who enforces it, and what individual staff are responsible for. A policy with no named owner will be out of date within a year.
  • Enforcement: what happens when the rules are broken, stated calmly and in proportion. The aim is consistency, so that a breach is handled the same way regardless of who caused it.
  • Review: how often the policy is reviewed and the date it was last updated. A visible review date is how you prove the document is maintained.

Most of these parts are about clarity and ownership. The hard part is usually writing each rule so plainly that a busy person understands it, and giving the policy to someone who will keep it current.

How to write a policy people will actually follow

The most common mistake small businesses make is copying a corporate template full of dense, defensive language into a company where nobody will ever read it. A policy that nobody understands is a policy that nobody follows, and an unfollowed policy is worse than none at all. It gives you a false sense of protection, and if you ever make a claim or face an audit, it exposes the gap between what you wrote and what you did.

Write in the second person, as if you were explaining the rule to a new hire on their first day. "You must not install software on your work laptop without asking IT first" beats "Employees are prohibited from the unauthorised installation of applications upon corporate endpoints." Keep each policy short enough to read in a few minutes. If it runs to ten pages, people will skim the first paragraph and sign the last one. A two-page policy that everyone reads protects you more than a twenty-page one that everyone ignores.

  • Lead with the rule, then give the reason. People follow rules they understand more readily than rules they are handed.
  • Prefer specific, checkable requirements over vague aspirations, so that anyone can tell whether the policy is being met.
  • Add a concrete example wherever a rule might be misread, because incidents happen in the gap between what you meant and what people assumed.
  • Leave out rules you cannot or will not enforce. A policy that is routinely ignored teaches your team that all your policies are optional.

Finally, write for the company you are now. If you are five people who all use the same three cloud apps, your acceptable use policy does not need a section on data centre access. Delete anything that does not apply. People can follow a policy tailored to how you work; a generic one full of irrelevant clauses trains everyone to treat the whole document as boilerplate.

Adopting and rolling out your policies

Writing the policy is only half the job. A document saved in a folder that nobody has read does not protect you, and it will not satisfy an insurer or a client. Adoption is the step that makes a policy real: someone with authority signs it off, every relevant person reads it, and there is a record that they did. That record, whether a signature, a checkbox, or an email acknowledgement, is what you point to later when you need to show the policy was in force.

Build policy acknowledgement into onboarding so that every new hire reads and accepts the relevant policies before they get access to systems. For existing staff, roll the policies out with a short explanation of why they exist rather than a terse "please sign this." People accept rules far more willingly when they understand the risk being managed, and a ten-minute conversation now prevents a lot of silent non-compliance later. Store the signed acknowledgements somewhere durable. If you ever face a claim or a dispute, being able to produce them is worth the small effort of collecting them.

  • Get formal sign-off from an owner or director, so the policy carries authority rather than reading as a suggestion.
  • Have every relevant person read and acknowledge each policy, and keep a dated record that they did.
  • Fold acknowledgement into onboarding, so new hires accept the rules before they receive access.
  • Re-circulate a policy whenever it changes materially, and capture fresh acknowledgements for the new version.

Keeping policies alive: review and maintenance

A security policy has to keep pace with how your business operates. Tools, staff, and regulations all change, and a policy written two years ago may now describe a company that no longer exists. The cheapest way to keep policies useful is to review them on a fixed schedule, at least once a year for every policy, and to write the review date on the document so anyone can see it is current.

Some changes should trigger a review straight away, without waiting for the annual cycle: adopting a major new tool, going through a merger or acquisition, suffering a security incident, or falling under a new regulation. An incident is especially useful, because it shows you exactly where your rules were unclear or unrealistic. Updating the policy while the lesson is fresh is how you stop the same thing happening twice.

Keep it simple to manage. Store the policies where the whole team can find them, track a version number and a last-reviewed date on each one, and give every policy a named owner who is responsible for the annual check. You do not need document-management software; a shared drive and a calendar reminder are usually enough. What matters is that one specific person is responsible for each policy.

Using templates without cutting corners

You do not have to write these documents from a blank page. A good template gives you the right sections, sensible default rules, and wording that has already been through the wringer, so you spend your time adapting rather than inventing. That is why we put together a set of ready-to-use policy templates covering acceptable use, passwords and MFA, remote work and BYOD, and data retention: the documents insurers and client questionnaires ask for, built to be edited.

Treat any template as a first draft. It cannot know how your business works, which tools you use, or which rules you will enforce. Read every clause, delete what does not apply, tighten what does, and run anything with legal or regulatory weight past someone qualified in your jurisdiction before you rely on it. A template you have adapted properly is worth ten times one you signed without reading, and the reading is where you learn what your own security looks like.

A sensible order to write them

You do not have to write all four policies at once, and trying to will usually stall the whole effort. Sequence them instead: start with the one that closes your biggest gap, and use what you learn from the first to make the next one easier. For a small business that is usually the password and MFA policy, because credential attacks are the most common way small businesses get breached and because much of the policy can be enforced immediately through configuration rather than trust. Getting one policy written, adopted, and followed also shows your team that the effort is serious, which makes the rest easier to land.

After passwords, the acceptable use policy is a natural second, because it is broad, references the others, and sets the general tone for how staff treat company technology. Data retention and the remote work and BYOD policy can then follow in whichever order matches your business. A company that is fully remote should prioritise BYOD, while one that handles a lot of customer records should start on retention. Whatever the order, count a policy as finished only once it has been adopted and acknowledged; a draft nobody has read is still work in progress.

Common mistakes small businesses make

The same handful of mistakes turns up again and again, and all of them are avoidable once you know to watch for them. Usually the policy has been treated as a document to produce instead of a behaviour to keep up, so it drifts out of use as soon as the writing is done. Keep these failures in mind as you write:

  • Copying a corporate template unchanged: you inherit pages of irrelevant, defensive language that teach everyone to treat the whole document as boilerplate they can safely ignore.
  • Writing rules you will not enforce: one rule that is routinely broken without consequence teaches your team that every rule is optional.
  • Leaving policies without an owner: with nobody responsible, the annual review never happens and the document slowly turns into fiction.
  • Never revisiting them: a policy written for last year's tools and team can describe a company that no longer exists, and an insurer or auditor will notice the gap.
  • Hiding them where nobody looks: a policy saved in a folder no one opens protects no one. Store them where the whole team can find them, and remind people they exist.
  • Confusing length with rigour: a short policy that everyone reads and follows beats a long one that everyone skims and signs.

None of these mistakes takes security expertise to fix. They come down to discipline and ownership, which is good news for a small business, because you do not need a specialist to get policy right. You need someone to own each document, plain language that people can follow, and a habit of reviewing what you wrote. The specific rules and the technical controls are easier to fix than those habits.

Frequently asked questions

What security policies does a small business need?

Four written policies cover the basics: an acceptable use policy, a password and MFA policy, a data retention policy, and a remote work or BYOD policy. Together they cover how staff use company systems, how accounts are protected, how long data is kept, and how work happens outside the office.

Is a written security policy a legal requirement?

It depends on your jurisdiction and industry, but a written information security policy is increasingly expected rather than strictly mandated. Data-protection laws such as GDPR require "appropriate" security measures, and cyber insurers and client security questionnaires routinely ask to see documented policies before they cover or contract with you.

What should a small business security policy include?

A usable policy states its purpose and scope, who it applies to, the specific rules staff must follow, who is responsible for enforcing it, and how often it is reviewed. Keep the wording simple and short enough that people will read it.

How often should security policies be reviewed?

Review each policy at least once a year, and sooner after any significant change, such as a new tool, a merger, a security incident, or a new regulation that affects you. Record the review date on the document so you can show the policy is being maintained.

Who is responsible for enforcing security policies in a small company?

Name an owner for each policy: usually the business owner, an office manager, or whoever handles IT. Enforcement means onboarding staff to the rules, applying them consistently, and handling breaches through a stated process rather than ad hoc. Without a named owner, policies drift out of date.

Do cyber insurers require written security policies?

Frequently, yes. Underwriters increasingly ask whether you have documented policies for access control, data handling, and incident response before they issue or renew cover, and a denied claim can hinge on whether you followed them. Having the paperwork ready speeds up the application and can lower your premium.

Start with one policy. Pick the gap that worries you most, usually passwords and MFA, write it, get your team to adopt it, and use what you learn to make the next one easier. Insurers, clients, and regulators ask for these four documents more often every year, and a small business that has written, adopted, and maintained them can answer when they do.

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.

Related reading