Blog

How to Write a Cyber Security Policy

Image: fauxels via Pexels

A cyber security policy is one of those things every organisation knows it should have — but too many end up as a dense document that lives in a shared drive, never to be opened again. If your policy isn’t being read, understood, or followed, it isn’t actually protecting you. Here’s how to write one that does.

Start with purpose, not jargon

Before you type a single word, ask yourself: who is this for, and what do we want them to do differently? A good cyber security policy isn’t a technical manual — it’s a clear set of expectations for everyone in your organisation. Write it in plain language. If your receptionist or newest graduate can’t understand it, it needs to be simpler.

Cover the essentials without going overboard

You don’t need to document every conceivable threat scenario. Focus on the areas that carry the most risk for your organisation. Most policies should address at least:

• Password and account management (including multi-factor authentication)
• Acceptable use of devices, networks, and software
• How to handle sensitive or confidential information
• What to do when something goes wrong — your incident reporting process
• Remote working and bring-your-own-device expectations
• Software updates and patch management

The NCSC’s guidance for organisations is a great starting point for identifying the controls that matter most — and it’s written for a New Zealand context, which makes it directly relevant to your obligations and environment.

Make it specific to your organisation

Copied templates are better than nothing, but they’re rarely enough. A policy written for a law firm has different considerations than one written for a health provider or a community NGO. Think about the data you hold, the systems you rely on, and the ways your people actually work. Tailor your policy to reflect that reality — including named roles and responsibilities so there’s no ambiguity about who does what.

Keep it living, not laminated

A policy written once and never revisited quickly becomes irrelevant. Set a review date — annually is a sensible minimum — and treat it as a genuine checkpoint, not a formality. When your tools change, when you onboard new software, or when an incident occurs, update your policy to reflect what you’ve learned.

Get people on board

The best policy in the world fails if no one knows about it. Share it during onboarding, revisit it in team meetings, and make sure staff know where to find it. Consider a short acknowledgement process so there’s a record that people have read and understood it. And make reporting easy — if people feel safe flagging a potential problem, you’ll catch incidents far earlier.

Don’t let perfect be the enemy of good

A straightforward, practical policy that your team actually follows will serve you far better than an elaborate document gathering dust. Start with the basics, get them right, and build from there.

If you’d like a hand reviewing what you already have — or starting from scratch — our team is always happy to help.

Chris Drowley
General Manager, Resolve Technology
Outside the office, Chris runs a highly organised empire of model trains — where the schedules are always on time, unlike the real thing.