Security Policies: What You Actually Need and How to Write Them

The Policy Problem

Most organisations have one of two problems: either they have no policies at all, or they have dozens of policies that nobody reads, nobody follows, and nobody updates.

Neither is compliant. Neither is useful.

Good security policies are short, clear, and connected to real controls. They tell people what is expected of them — and the organisation has mechanisms to verify compliance.

Which Policies Do You Actually Need?

For ISO 27001 or SOC 2, you don’t need a 200-page policy library. You need a coherent set of documents that covers your risk landscape. For most organisations, that’s around 15–20 policies:

Core / Always Required:

• Information Security Policy (the top-level statement)
• Acceptable Use Policy
• Access Control Policy
• Incident Response Policy
• Business Continuity and Disaster Recovery Policy
• Risk Management Policy

Commonly Required:

• Asset Management Policy
• Cryptography Policy
• Physical Security Policy
• Supplier / Third-Party Security Policy
• Human Resources Security Policy (joiners, movers, leavers)
• Vulnerability Management Policy
• Change Management Policy

Situational:

• Remote Work and Mobile Device Policy
• Data Classification and Handling Policy
• Privacy Policy (separate from your public privacy notice)
• AI Usage Policy (increasingly relevant)

How to Structure a Policy

Every policy should answer the same questions in the same order:

Purpose — Why does this policy exist? What risk does it address?

Scope — Who does it apply to? (All staff? IT only? Contractors?)

Policy Statements — The actual requirements. Clear, specific, measurable where possible. Avoid vague language like “appropriate” or “reasonable” without defining what that means.

Roles and Responsibilities — Who owns compliance? Who enforces it?

Exceptions — How do people request an exception, and who approves it?

Review — When was it last reviewed? When is it next due?

Aim for 1–3 pages per policy. If it’s longer, it probably covers too much.

Making Policies Stick

A policy nobody reads is a liability, not a protection. Policies need to be:

Communicated — Staff need to be aware of policies relevant to their role. This means more than emailing a PDF once a year.

Acknowledged — Collect signed acknowledgements. This is an audit requirement and creates accountability.

Trained — For complex policies (incident response, data handling), training is more effective than documents alone.

Enforced — There need to be consequences for violations, proportionate to severity. A policy with no enforcement mechanism is a suggestion.

Reviewed — At minimum annually, and whenever there’s a significant change to the organisation, technology, or threat landscape.

Common Mistakes

Too long — Policies that try to cover every edge case become unreadable. Keep them high-level; use procedures for the detail.

Aspirational not actual — Policies should describe what you actually do, not what you wish you did. An auditor will test controls against your policy statements.

Set and forget — Policies that haven’t been reviewed in three years and still reference “the IT Manager” who left in 2021 will raise flags immediately.

No ownership — Every policy needs a named owner who is responsible for keeping it current and relevant.