Information Security Policies: What to Write and Why

Share with

Contents

Information security policies are the written rules that say how your organisation protects information and what is expected of everyone who handles it. They sit above procedures and controls: the policy states the rule, the procedure explains the steps, and the control enforces it.

Two problems show up again and again. The first is length. A forty-page policy nobody reads protects nothing. The second is copying. Information security policies borrowed from a template describe an organisation that does not exist, and staff spot that immediately.

Good information security policies are short, specific to how your business actually works, and written so a new joiner understands what they must do. This page covers what belongs in the policy set, how to structure it, who approves and reviews each document, and how to tell whether the rules are being followed. It builds on the wider information security management system framework.

What an Information Security Policy Does

A policy has three jobs.

It states management intent. Leadership is saying, in writing, that protecting information matters and that resources will back it up. Without that signature, security is a suggestion.

It sets expectations. Staff, contractors, and suppliers need to know what is allowed, what is not, and what happens when rules are broken.

It creates accountability. When a policy names an owner and an approval date, someone is answerable for keeping it accurate.

A policy is not a procedure. Policies say what and why. Procedures say how. Mixing them produces documents that need rewriting every time a tool changes.

Structuring the Policy Set

Most organisations need one top-level policy plus a set of topic policies beneath it.

Structuring the Policy Set

The Top-Level Policy

This single document states the organisation's commitment, the scope of what is covered, the security objectives, the roles responsible, and the consequences of non-compliance. Two to four pages is usually enough. It is approved by top management and is the document auditors and customers ask for first.

Topic-Specific Policies

Beneath it sit the detailed rules. A practical set covers acceptable use, access control, password and authentication, data classification and handling, remote and mobile working, clear desk and screen, backup, change management, supplier security, incident reporting, and physical security.

Not every organisation needs all of these on day one. Write the ones that match your actual risks, then add as you grow. A set of six well-followed policies beats fifteen ignored ones.

Match the Structure to Your Risks

Let your risk assessment decide the list. If your threats and vulnerabilities work shows most exposure sits in remote access and supplier connections, those deserve their own policies. Writing a detailed physical security policy for a fully remote company is effort spent in the wrong place.

What Each Policy Should Contain

Keep the shape consistent so readers know where to look. Each document needs a purpose, a scope stating who and what it covers, the rules themselves, named roles and responsibilities, any exceptions process, references to related documents, and a version and approval block with review dates.

Write rules as instructions, not aspirations. "Staff must report a suspected security incident to the service desk within one hour" tells someone what to do. "The organisation is committed to timely incident reporting" does not.

The exceptions process is the part most often left out and the part that decides whether a policy survives contact with the business. When a rule cannot be met, people need a route to request an exception, get it approved, and have it recorded with a review date. Without one, staff quietly work around the rule and the policy becomes fiction.

Try Effivity for Free and see how policy documents stay linked to the controls and records that prove they work.

Free Trial →

Writing Policies People Will Follow

Adoption depends on writing, not enforcement.

Writing Policies People Will Follow

Use plain language. If a rule needs a security background to understand, it will be misread. Replace "utilise approved cryptographic mechanisms" with "encrypt files before sending them outside the company."

Keep each policy under about four pages. Long documents get skimmed, and skimmed rules get broken.

Say why briefly. A sentence explaining the reason behind a rule raises compliance more than a paragraph of warnings. People follow rules they understand.

Name the owner in the document, not in a separate register. Readers need to know who to ask when a situation is unclear.

Avoid naming specific products where possible. A policy that names a particular tool needs updating every time procurement changes vendors. Refer to the function instead.

Approval, Communication, and Acknowledgement

A policy takes effect when it is approved, communicated, and acknowledged. Missing any of the three makes it hard to rely on.

Top management approves the top-level policy. Topic policies can be approved at a lower level, provided the delegation is recorded.

Communication means more than uploading a file. New joiners should meet the relevant policies during induction, and changes should be pushed out rather than waiting to be found.

Acknowledgement gives you evidence. A record of who read and accepted which version, and when, is what turns a policy into something enforceable. Security awareness training and policy acknowledgement work best together, since one explains what the other requires. The same pairing shows up in wider cyber security compliance work.

Reviewing and Updating Policies

Policies drift out of date quietly. Review each one at least annually, and sooner when something material changes.

Trigger a review after a significant incident, a new system or supplier, a change in law or contract, an audit finding, or a reorganisation that moves responsibilities. Handled well, change management catches most of these before the policy becomes wrong.

Record the review even when nothing changes. An unchanged document with a current review date shows the check happened. The same document with a three-year-old date suggests nobody is looking.

Version control matters here. Staff must be able to tell which version is current, and you need to show which version applied when an incident occurred. Weak document control is a common source of audit findings on otherwise sound policy sets.

Common Mistakes Worth Avoiding

Downloading a template unchanged. Auditors recognise generic wording instantly, and staff cannot follow rules describing systems they do not have.

Writing procedures inside policies. Step-by-step detail belongs elsewhere, or the policy needs reapproval every time a screen changes.

No exceptions route. Rules that cannot be met and cannot be challenged simply get ignored.

One giant document. A single combined policy is hard to update and harder to read. Split by topic.

No acknowledgement record. Without proof of who accepted what, enforcement and disciplinary action both become difficult.

How Software Keeps Policies Current

Policies stored on a shared drive develop the usual problems: several versions in circulation, no proof of who read what, and review dates that pass unnoticed.

A structured platform holds each policy with its owner, version history, and approval record, routes new versions for acknowledgement, and prompts owners when reviews fall due. Effivity's information security management software links policies to the Annex A controls they support and to the training records that show staff have read them, so the evidence trail is already assembled when someone asks.

During an ISO 27001 audit, assessors check the policy, its approval, its communication, and whether people follow it. Having those four in one linked record shortens the conversation considerably.

Get a Free Personalized Demo to see how your existing policy set would sit inside a managed system.

Free Demo →

Frequently Asked Questions

They are written rules stating how an organisation protects its information and what is expected of everyone handling it. Procedures and controls sit beneath them.

A top-level information security policy approved by management is mandatory. Topic-specific policies are expected where your risk assessment and applicable Annex A controls call for them.

Under about four pages for topic policies, and two to four for the top-level one. Longer documents get skimmed rather than followed.

At least annually, plus reviews after incidents, new systems or suppliers, legal changes, or audit findings. Record the date even when nothing changes.

Top management approves the top-level policy. Topic policies may be approved at a lower level if that delegation is documented.

Share with