How to Build a Security Policy Framework: Policies, Standards and Procedures That People Follow

Understand the Policy Hierarchy

A policy framework is a set of documents at different levels of detail. Mixing those levels is the most common cause of policies that are either too vague to act on or too detailed to keep current.

Choose the Core Policy Set

Start from your risks and obligations, not from a list of every policy a template library offers. ISO/IEC 27001 requires a top-level information security policy (clause 5.2) and Annex A control 5.1 expects topic-specific policies where the organisation needs them. A typical core set looks like this:

• Information security policy: scope, objectives, leadership commitment and how the rest of the framework fits together.
• Acceptable use: what staff may and may not do with company devices, accounts, data and AI tools.
• Access control and identity: joiners, movers and leavers, least privilege, MFA and privileged access.
• Data classification and handling: classification levels, handling rules per level, retention and secure disposal.
• Data protection and privacy: lawful processing of personal data, data subject rights and breach handling.
• Incident response: what counts as an incident, how to report it and who leads the response.
• Supplier security: due diligence, contract clauses and ongoing review of third parties.
• Business continuity and backup: recovery objectives, backup rules and testing.
• Secure development and change management: for teams that build or configure systems.
• Remote working and mobile devices: device security, home networks and travel.

Smaller organisations can merge several of these into one document. What matters is that each topic has clear rules and an owner, not the number of files.

Write Policies People Can Follow

A policy is only useful if the people it applies to can understand it in one reading. Write it for the busiest person in the organisation, not for the auditor.

• Use "must" for mandatory rules and "should" for recommendations, and define both at the top.
• Name roles, not people: "the system owner must review access every quarter".
• State scope clearly: which people, systems, locations and data the policy covers.
• Keep each policy short. Move detail into standards and procedures and link to them.
• Say what happens when the policy cannot be followed: point to the exceptions process.
• Check every rule against reality. A rule that nobody can meet trains people to ignore the whole document.

1. Purpose        - why this policy exists (one paragraph)
2. Scope          - people, systems, data and locations covered
3. Roles          - owner, approver, who must comply
4. Policy rules   - numbered "must" / "should" statements
5. Exceptions     - how to request one and who approves
6. Compliance     - how adherence is measured and enforced
7. Related docs   - standards, procedures, other policies
8. Document control
   Version | Date | Author | Approver | Summary of change
   Next review date: YYYY-MM-DD

Set Ownership, Approval and Version Control

Every document needs one accountable owner who keeps it accurate and one approver with the authority to make it binding. Top-level policies should be approved by senior leadership, because ISO 27001 clause 5 expects top management to establish the policy and show leadership commitment.

Keep a policy register: a single list of every policy, standard and procedure with its owner, approver, version, last review date and next review date. It is the first thing an auditor asks for, and it is how you spot documents that have drifted out of date.

Run an Exceptions Process

Some teams will not be able to meet a rule straight away. A legacy system may not support MFA, or a supplier may need temporary access. Without a formal route, these cases become silent, permanent non-compliance.

An exception request should record the rule affected, the business reason, the risk it creates, the compensating controls, the risk owner who accepts it and an expiry date. Feed every approved exception into the risk register so it is reviewed alongside other risks, and report open exceptions to management.

Drive Adoption and Prove It

Publishing a policy is the start of the work, not the end. Adoption means people know the rules, systems enforce them where possible and you can show evidence that they are followed.

• Collect acknowledgements from staff when they join and after significant changes.
• Build the key rules into onboarding and annual awareness training. See the security awareness program guide.
• Enforce rules technically wherever you can, for example MFA enforced in the identity provider rather than requested in a memo.
• Map each policy rule to the control that implements it and the evidence that proves it works.
• Track compliance per team and follow up until gaps are closed. The control ownership playbook shows how.

Review and Retire on a Schedule

Review each policy at least once a year and after any significant change: a new regulation, a major incident, a new business line or a change in technology. Record the review even when nothing changes, because "reviewed, no changes" is evidence of a working process.

Retire documents that are no longer needed. A smaller, accurate framework is stronger than a large one full of outdated rules. Once the framework is stable, the 10-step ISO 27001 implementation guide shows how it fits into a certifiable ISMS.