Cyber Security Policies and Procedures: How to Write Them Correctly

Cyber security policies and procedures start with one short, top-level document approved by management, backed by shorter topic-specific policies and procedures underneath it. Most businesses get this backward, writing one long document that tries to do everything and satisfies no one, especially the auditor.

What is an information security policy, and how does it fit into ISO 27001?

An information security policy is the top-level document stating your organization’s commitment to protecting information, required under ISO 27001 Clause 5.2. It sets direction and objectives for your entire security program, while separate topic-specific policies and procedures handle the operational detail underneath it.

Clause 5.2 requires the policy to be appropriate to your organization, provide a framework for setting security objectives, and include two specific commitments: satisfying applicable legal and contractual requirements, and continual improvement of your management system. Without both commitments stated explicitly, the policy fails the clause regardless of how well-written it otherwise is.

Policy vs standard vs procedure: a distinction that saves you real trouble

A policy states what must happen and why, a standard defines the specific, measurable requirement, and a procedure explains exactly how to do it step by step. Mixing these three into one document is the most common structural mistake businesses make when writing cyber security policies and procedures for the first time.

Document Type	Answers	Example
Policy	What and why	“All systems must be configured securely”
Standard	Specific requirement	“Passwords must be 14+ characters, MFA required”
Procedure	Step-by-step how	“To reset a password: open the portal, click…”

The fix is simple but frequently missed: your policy should reference the standard rather than embed it. A well-written policy line reads something like “all production systems must be configured according to the standards approved by IT,” pointing to a separate standards document rather than listing specific numbers inside the policy itself. This keeps the policy stable, since standards change more often than the policy’s underlying intent, and a password length requirement shouldn’t force a full top-management re-approval every time it’s updated. Businesses that skip this separation end up with 40-page “policies” that are really policy, standard, and procedure stapled together, which fails both jobs at once: too long for general staff to read and understand, and too shallow to actually direct a specialist doing the implementation work. Split the three apart from day one, even if all three start as short documents, since retrofitting the separation later means rewriting everything anyway.

How long should this document be?

The confusion between “2 pages” and “12 pages” comes from two different things being measured. The standalone Clause 5.2 top-level policy should run 2 to 5 pages, covering scope, objectives, and commitments only. The wider figure of 6 to 12 pages usually refers to the policy plus its immediately linked framework elements, not the policy alone.

This distinction matters because businesses chasing a single “correct” page count often end up either padding a short policy with implementation detail it shouldn’t contain, or cramming their entire framework into what should be a short, stable document. Multiple audit-focused sources converge on the same guidance: a top-level information security policy belongs in the 2 to 5 page range, long enough to define scope, roles, and commitments, short enough that staff will actually read it. If your current policy runs past 10 pages, check whether it has quietly absorbed standard-level or procedure-level content that belongs in a separate, referenced document instead. A shorter, genuinely read policy protects you better in an audit than a longer one nobody has opened since it was signed.

Why your policy has to be approved by top management, not just IT

ISO 27001 Clause 5.2 explicitly requires the information security policy to be authorized by top management, not delegated to IT or a security team alone. Auditors expect to see it signed and dated by a named senior leader, treated as evidence of leadership commitment rather than a technical document quietly approved down the chain.

This requirement exists because the policy sets the tone and resource commitment for your entire security program, decisions that sit above IT’s authority to make alone. Auditors will check for approval evidence specifically: board or leadership meeting minutes, a signed copy, or a digital signature trail with a named approver. A policy technically written well but approved only by the IT manager, without documented senior leadership sign-off, is a common finding during Stage 1 review, since it signals the policy was never genuinely owned at the top of the organization.

One policy, many sections: the hierarchy that keeps this manageable

Your top-level information security policy stays short and stable, while topic-specific policies handle individual areas like access control, incident response, and acceptable use. This layered structure lets each document change at its own pace instead of forcing a full re-approval every time one operational detail shifts.

Common topic-specific policies sitting underneath your top-level policy include access control, cryptography and key management, information transfer, supplier security, incident management, and acceptable use, each owned at the appropriate management level for that topic. List or link this family within your top-level policy rather than merging everything into one document. This hierarchy is also what your Statement of Applicability references directly, since each Annex A control you mark as applicable typically maps to one of these topic-specific policies as its supporting evidence during audit.

Communicating it properly: why one email isn’t enough

Sending a policy by email satisfies the bare minimum of availability, but ISO 27001 auditors test genuine understanding, not just distribution. A common audit method involves stopping a random employee and asking where the information security policy is; “I don’t know” or “ask IT” is a documented major non-conformance against Clause 5.2.

This is the gap most businesses underestimate until it costs them a failed audit finding. Communicating a policy properly means publishing it somewhere staff actually check, like an intranet or handbook, building it into onboarding checklists, and keeping an acknowledgment log showing who’s confirmed they’ve read it. Awareness training records and periodic refreshers strengthen this further, since a policy acknowledged once during onboarding three years ago and never revisited again won’t hold up if an auditor asks a random employee what it covers. Treat communication as an ongoing responsibility with evidence attached, not a one-time send. If you can’t produce an acknowledgment log or point to where staff currently access the policy, budget time to fix that before your next audit, since it’s one of the easiest findings for an auditor to catch and one of the easiest gaps to close.

Do you need expensive GRC software to do this well?

No, not for a small policy set. A business managing a handful of policies typically needs a clear document structure, version control, and a review calendar first. GRC software earns its cost once you’re managing dozens of policies across multiple frameworks with recurring audit evidence requirements, not before.

Many first-time certification businesses get quoted GRC platforms before they’ve even finalized their document hierarchy, which is the wrong order. Start with a shared drive structure separating policies, standards, and procedures into clear folders, a simple version log noting date and approver for each document, and a calendar reminder for annual review. This covers Clause 5.2’s requirements adequately for a small organization. Revisit the GRC software question once you’re managing multiple frameworks simultaneously, like ISO 27001 alongside SOC 2 or GDPR documentation, where cross-referencing evidence manually becomes genuinely time-consuming rather than simply inconvenient.

A section-by-section template you can use

A working information security policy needs six sections: purpose and scope, management commitment, roles and responsibilities, policy statements, compliance and enforcement, and review cycle. Each section should be a few sentences to a short paragraph, keeping the whole document inside the 2 to 5 page range covered earlier.

Structure it in this order: state the purpose and who it applies to, declare management’s commitment including the two required Clause 5.2 commitments, name who owns enforcement, list your core policy statements in plain language, explain consequences for non-compliance, and close with a review date and named owner. Cyber Security Solutions Ltd builds this exact structure with first-time certification clients, and the businesses that follow this order consistently produce a policy that passes review on the first attempt, because every Clause 5.2 requirement has an obvious home in the structure rather than getting missed in a wall of unstructured text.

How does this connect to your UK GDPR accountability obligations?

UK GDPR’s Article 5(2) accountability principle requires you to demonstrate compliance, not just achieve it, and a documented, approved information security policy is one of the specific measures ICO lists as accountability evidence. The ICO’s first question in any investigation is consistently “show me your documentation.”

For UK businesses, this means your information security policy does double duty. It satisfies ISO 27001 Clause 5.2 and simultaneously contributes to your GDPR accountability evidence, alongside your record of processing activities, breach response procedure, and data protection impact assessments. An organization with a dated, approved, and communicated policy is materially better positioned in an ICO inquiry than one that can only describe its intentions verbally. If your business handles personal data and hasn’t connected these two obligations, treat your information security policy as GDPR evidence from the start, not a separate compliance project running in parallel.

Conclusion

Writing cyber security policies and procedures correctly comes down to keeping the top-level policy short and management-approved, splitting standards and procedures into their own referenced documents, and proving communication with real evidence, not just a sent email. Get that structure right once, and every audit after the first one gets easier, not harder. If you want help building or reviewing your policy framework, Cyber Security Solutions Ltd can walk through it with you at cybersecuritysolutionsltd.com.