Most small teams don’t write a cyber security policy until something has already gone wrong. A laptop goes missing, someone clicks a dodgy link, or a client asks whether you actually have one in writing. By then you’re reacting under pressure instead of working from a plan everyone already understands.

This guide walks through a practical seven-step process for building a policy from scratch. You’ll see how to assess your risks, what sections the document needs, how to handle an incident when it happens, and how to keep staff on side so the policy gets used rather than filed away. None of it requires a security background.

Why a written policy beats a few good habits

Plenty of teams rely on unwritten rules. People sort of know not to share passwords, and someone usually remembers to lock their screen. The problem is that “sort of” and “usually” leave gaps, and those gaps are exactly where things slip through.

A written policy turns scattered habits into shared expectations. When the rules live in a document, a new starter can read them on day one, and nobody has to guess what counts as acceptable. It also gives you something to point to when a decision needs backing up, which matters more than people expect once a real problem lands on the desk.

Start by working out what you’re actually protecting

You can’t protect everything equally, so the first job is figuring out where your real exposure sits. Look at your threat surface: the devices people use, the networks they connect to, the cloud services you rely on, and the staff who touch sensitive information day to day. Each one is a way in.

From there, run a quick gap analysis. What security measures do you already have, and where are the obvious weak spots? Maybe everyone uses strong passwords but nobody updates their software. Or your client data is well protected, yet staff email it around without much thought.

Then pin down your critical assets: the technology, information, and financial details the business genuinely can’t afford to lose or expose. A small accountancy firm and a design studio will land in very different places here, and that’s the point. The assessment tells you where to spend your attention rather than spreading it thin. If working that out feels daunting, a cyber security provider can run the assessment with you and flag risks you’d otherwise miss.

What goes into the policy framework

Before writing any rules, set up the skeleton. A clear framework keeps the document usable and makes it far easier to review later. These are the core components worth including:

Purpose — why the policy exists and who it applies to
Scope — where and how the policy applies
Policy statement — the actual guidelines and rules
Roles and responsibilities — who implements and oversees it
Compliance measures — how you meet legal requirements such as GDPR
Review history — when and how it gets updated

The review history section gets overlooked far too often, and it’s the one that saves you headaches down the line. A dated record of changes means you always know which version is current and what prompted the last update.

Writing the sections that do the heavy lifting

This is the part staff will actually read, so keep each section direct and specific. Vague guidance (“be careful with data”) gives people nothing to act on.

Passwords and passphrases

Length matters more than fiddly complexity rules, so push people towards passphrases: three or four random words strung together are easy to remember and hard to crack. Each application should have its own unique password, because reusing one means a single breach unlocks everything. Skip the forced monthly resets. Current UK guidance has moved away from scheduled rotation, since it just nudges people into weak, predictable patterns like adding a “1” on the end. Change passwords when you actually suspect they’ve been exposed, and point staff at a reputable password manager, which beats a sticky note or a spreadsheet every time.

Email security

Email is where most trouble starts, so spell out the basics. When is it appropriate to share a work address? Staff should only open attachments from people they trust, and know how to spot a suspicious message: odd sender addresses, urgent demands, links that don’t quite match the company they claim to come from. Make reporting easy, because a quick flag to the right person stops one careless click turning into a real problem.

Handling sensitive data

People need to know what counts as sensitive before they can protect it. Define it plainly, then explain when staff may share it and when they may not. Physical files belong in locked drawers or rooms, and anything no longer needed should be destroyed properly rather than left lying around. Old data you don’t need is just risk you’re holding onto for no reason.

Device and technology rules

Cover where work devices can be used, and make screen-locking the default whenever someone steps away. Lost or stolen devices need reporting straight away, because the faster you know, the faster you can act. Lay out how system updates get handled and whether removable drives like USB sticks are allowed at all. Plenty of teams ban them outright, and honestly that’s a reasonable call for the hassle they cause.

Social media and internet use

Be clear about what business information can appear on social media, since a casual post can reveal more than intended. A short note on appropriate website use during work hours usually does the job here without turning into a lecture.

Building an incident response plan

Things will go wrong eventually, and a calm, written plan is what separates a contained problem from a spiralling one. The warning signs vary (missing files, a computer that keeps crashing, pop-up ads appearing out of nowhere), but the response follows a steady sequence.

Record what you’re seeing and report it to whoever’s responsible. Work out the cause quickly, then isolate anything affected by disconnecting it from the network so the problem can’t spread. Once contained, remove the threat, recover your systems, and get things running again.

Afterwards, update the plan based on what you learned. Every incident teaches you something about where the gaps were, and a plan that never changes is one that stopped being useful a while ago.

Quick checks before you sign it off

Run through these as a final sweep. Each one is worth a straight yes before the policy goes live.
Every section names a specific person or role responsible, not just “the team.”
Password rules are written clearly enough that a new starter could follow them without asking.
Staff know exactly who to contact when something looks wrong.
Sensitive data is defined in plain terms, with clear rules on sharing and disposal.
The incident response steps are short enough to follow under pressure.
There’s a dated review history so you always know which version is current.

Getting your team on board

A policy written in isolation tends to miss things and get ignored. Pull in input from IT, legal, HR, management, and the people doing the everyday work, because each group sees risks the others don’t. The folks on the ground often spot the practical snags before they become real problems.

When you roll it out, explain the why rather than just handing over a list of rules. Tell someone they can’t use a personal USB stick and they’ll grumble; show them how one infected drive took down a similar business, and the rule makes sense on its own.

Back that up with training that uses simulations and real scenarios, because a mock phishing email lands harder than a paragraph about phishing ever will. Keep the materials digestible and run refreshers now and then, since a single session at induction fades fast.

Staying compliant in the UK

If you’re operating in the UK, your policy needs to line up with GDPR and the relevant UK data protection rules. In practice that means being able to show how you protect personal data, who can access it, and what happens if it’s exposed. The mistake small teams make most is hoarding data they no longer need.

Every old customer record sitting in an inbox is something you’d have to account for if it leaked, so a clear line on deleting what’s past its use does more good than people realise. You don’t need to quote legislation chapter and verse, but the policy should reflect those obligations rather than ignoring them.

Where the legal side gets genuinely complex it’s worth speaking to a solicitor, but for the practical security side (how data is stored, who can reach it, how access is controlled) Absolute Consultancy Services works with SMEs across Manchester and the Northwest, and their IT consultancy team can sanity-check where your setup stands.

A policy that doesn’t go stale

A cyber security policy isn’t a write-once document. Threats shift, your tools change, and a policy that made sense two years ago can quietly fall out of step. Review it on a regular schedule, update it whenever you bring in new systems or working practices, and feed in the lessons from any real incident. That’s how it gets sharper over time instead of gathering dust.

What happens next

Once the policy is signed off and shared, the work shifts to keeping it active. Set a review date now, while you’re thinking about it, so it doesn’t drift. Make sure every current member of staff has read it and knows where to find it, and fold it into your onboarding so new starters get it without anyone having to remember.

If you don’t have a policy yet, start with the risk assessment this week. Even a rough one tells you where your biggest gaps are, and that’s enough to begin. You can refine the document as you go, and a working draft that people actually use beats a perfect one that never gets written.

If you’d rather not build it alone, Absolute Consultancy Services provides cyber security and IT support to small and medium businesses in Ashton-Under-Lyne and across the wider Manchester area. To talk through where your team stands, call 0161 850 0682