Security Policy Framework Guide

Most security policy sets are written for the auditor, filed once and then ignored, while the real rules live in tickets, tool settings and tribal knowledge. A security policy framework fixes that by separating what the organisation requires (policy) from how it is measured (standards), how it is done (procedures) and how it is advised (guidelines), with named owners, a review cycle and a controlled way to grant exceptions. This guide covers the hierarchy, a core policy set, writing usable policies, ownership, review, exceptions, framework mapping, policy as code, adoption metrics, and two newer additions: AI usage and non-human identity (NHI) policy. It is written for CISOs, GRC leads and security architects, and for anyone who has inherited a policy library that nobody reads.

Key takeaways

• Keep the layers separate. NIST SP 800-12 Rev. 1 notes that "Because policy is written at a broad level, organizations also develop standards, guidelines, and procedures"; policies state intent and stay stable, standards carry the measurable values that change.
• Fewer, shorter policies work better. A core set of 12 to 16 topic-specific policies under one top-level policy, each mapped to controls, beats a library of 60 overlapping documents.
• Every policy needs an owner, an approver and a review date. ISO/IEC 27001:2022 Annex A 5.1, NIST CSF 2.0 GV.PO-02 and SP 800-53 AC-1 all expect periodic review and review after significant change.
• Exceptions are risk decisions, not favours. Record them in a register with a risk owner, compensating controls and an expiry date, and report the open count to the same forum that approves policy.
• Measure adoption, not existence. Track attestation, overdue reviews, open and expired exceptions, and the share of policy statements that are mapped to a control or enforced as code.

The policy hierarchy: policy, standard, procedure, guideline

NIST SP 800-12 Rev. 1 defines information security policy as "an aggregate of directives, regulations, rules, and practices". Its Chapter 5 separates program policy ("Program policies set the strategic direction for security and assign resources for its implementation"), issue-specific policy for a topic such as remote access, and system-specific policy for one system. ISO/IEC 27001:2022 uses a similar split: one information security policy (clause 5.2) plus topic-specific policies (Annex A 5.1).

• Why the split matters: a policy that names a cipher suite or product needs board re-approval whenever technology changes. Put values in standards, which change quickly, and keep policies stable.
• Requirement language: use "must" for mandatory statements and "should" for recommendations, in the spirit of RFC 2119, and define the convention once in the top-level policy. Avoid "where possible": it turns a requirement into a guideline.
• Do not restate the control catalogue: the SP 800-53 discussion for AC-1 makes the point that restating controls does not make an organisational policy.
• Size: a small organisation can merge everything into one policy with standards as appendices; a large or regulated one usually needs separate topic-specific policies owned by different forums. SP 800-53 allows either a single general policy or multiple policies reflecting an organisation's complexity.

A core policy set and what each covers

Use this as a starting catalogue and merge where your organisation is small. CIS publishes 13 free policy templates aligned to Controls v8 and v8.1 that "cater exclusively to IG1 Safeguards", and SANS, with the Cybersecurity Risk Foundation, publishes 36 free templates grouped as Governance, Application, Compute, Identity and Access, Network and Resilience. Adapt them; do not adopt them unchanged.

See the Data Classification Guide and the Business Continuity and Disaster Recovery Guide.

Writing policies people can follow

The NCSC's sixth cyber security culture principle asks organisations to "Provide well-maintained cyber security rules and guidelines, which are accessible and easy to understand". Its guidance says "The rules need to allow people the flexibility to work and solve problems within their local areas", recommends "inviting stakeholders from these groups to contribute to rule development", and expects organisations to "invite and use people's feedback to continue to refine and improve your security rules". In practice:

• Use one template: document ID, title, owner, approver, version, effective date, next review date; then purpose, scope, roles, numbered policy statements, exceptions, compliance and enforcement, related standards and procedures, definitions, and change history.
• Number every statement: "ACP-07: Privileged access must be granted just in time and expire within 8 hours." Numbered statements can be mapped to controls, tested, attested and cited in exceptions.
• Write testable statements: each "must" should be checkable by a person or a tool. If you cannot describe the evidence, the statement is aspiration and belongs in a guideline or an objective.
• Keep it short: two to five pages per topic-specific policy is enough when values sit in standards.
• Test with the people affected: walk drafts through with an engineering, a service desk and a business team, and name a contact in every policy, since the NCSC calls for "quick and easy access to experts" when rules are unclear.
• Publish in one place: a single searchable policy portal, with superseded versions archived. The NCSC advises to "make it clear when updates supersede any earlier content" and to ensure "out of date material is archived to avoid confusion".

Ownership, approval and governance

ISO/IEC 27001:2022 clause 5.2 places the information security policy on top management, and Annex A 5.1 expects topic-specific policies to be approved by management, published, communicated and acknowledged by relevant personnel. SP 800-53 AC-1 (and every other "-1" control) requires an organisation to designate an official to manage the development, documentation and dissemination of the policy and procedures.

Name owners as people, not teams. A GRC platform can hold the catalogue, approvals and attestation; see the GRC Platform Buyer's Guide.

Review cycle and change control

• Planned interval: review policies at least annually; standards when the technology or threat changes; procedures whenever the tool or team changes. NIST CSF 2.0 GV.PO-02 expects policy to be "reviewed, updated, communicated, and enforced to reflect changes in requirements, threats, technology, and organizational mission".
• Event triggers: the AC-1 discussion lists assessment or audit findings, security incidents or breaches, and changes in laws, regulations, policies and standards. Add mergers, new platforms, new regulation in scope (for example NIS2 or DORA) and recurring exceptions.
• "Reviewed, no change" counts: record the reviewer, decision and next review date.
• Version control: keep a change log and archive old versions. Owners approve minor edits; changes to a "must" statement go back to the approving forum.
• Transition periods: give new requirements a compliance deadline and track the gap as planned work, not blanket exceptions.

Exceptions and waivers

An exception is time-bound permission not to meet a specific policy statement, with the risk accepted by someone with the authority to accept it. Some organisations call a permanent documented alternative a "waiver" and a temporary gap an "exception"; define the terms once. ISO/IEC 27001:2022 clause 6.1.3 already requires risk owners to approve the risk treatment plan and accept residual risk; an exception is that decision applied to a single policy statement.

1. Request: cite the statement ID, affected assets, business reason and duration.
2. Assess: security rates the risk and proposes compensating controls (for example isolating an unpatchable system).
3. Approve at the right level: a delegation table sets who may approve which risk rating; high risks go to the steering committee or the accountable executive, never only to the requester's manager.
4. Record: log it in one register: ID, statement, owner, risk rating, compensating controls, approver and expiry.
5. Expire and review: set a maximum duration (12 months is common) and alert the owner before expiry. Renewal is a new decision, not an automatic extension.
6. Feed back: if many teams need the same exception, change the policy or fund the fix.

Link remediation work to the exception so it closes when the fix ships; organisations working to SP 800-53 track this as a plan of action and milestones (CA-5).

Mapping the framework to standards

Map each policy statement once to a common control set, then to every framework you report against, rather than writing one policy per framework. See the Control Mapping Guide.

See the ISO 27001 Certification Guide and the NIST SP 800-53 Guide for the wider control sets.

From policy to policy as code

For cloud, platform and pipeline controls, enforcement increasingly lives in code: Kubernetes admission rules, cloud organisation policies, infrastructure-as-code checks and API authorisation. Open Policy Agent, a graduated CNCF project, describes the model as one that "decouples policy decision-making from policy enforcement", with rules written in the declarative Rego language and evaluated against JSON input.

• Traceability: tag every code rule with the policy statement ID it enforces (for example a rule comment or metadata field "ACP-07"), so auditors can trace statement to rule to evidence and engineers see why a deployment was blocked.
• Same lifecycle: review, test and version rules like code. Run new rules in audit or warn mode, measure what they would have blocked, then enforce; roll back by reverting the rule version.
• Exceptions in code: express approved exceptions as scoped, expiring exclusions that reference the register ID. An exclusion with no expiry is an undocumented policy change.
• Machine-readable controls: NIST OSCAL holds control catalogues and system security plans as JSON, XML or YAML, so mappings are exportable.

Newer additions: AI usage and non-human identity policies

AI usage policy

The NIST AI RMF GOVERN function starts with policy: GOVERN 1.2 states "The characteristics of trustworthy AI are integrated into organizational policies, processes, procedures, and practices." ISO/IEC 42001:2023 also requires an AI policy for an AI management system. A practical AI usage policy covers approved tools and how to request new ones, which data classes may enter prompts or be connected to assistants, rules for agents acting with delegated permissions, human review of output for defined decisions, and incident reporting. The Samsung ChatGPT source code leak, where staff pasted code into a public AI tool, ended in a ban; an approved alternative is easier to follow than a prohibition. See the AI Governance Guide and the Agentic AI Security Policy Template.

Non-human identity policy

Service accounts, API keys, tokens, certificates, workload identities and AI agents usually outnumber people, yet most access policies describe only humans. The OWASP Non-Human Identities Top 10 names the gaps a policy should close, including NHI1:2025 Improper Offboarding, NHI7:2025 Long-Lived Secrets, NHI9:2025 NHI Reuse and NHI10:2025 Human Use of NHI. Policy statements should require a named human owner for every NHI, an inventory, a preference for short-lived or federated credentials over static secrets, maximum credential lifetimes set in a standard, no sharing of one NHI across applications or environments, no interactive human use of NHI credentials, and decommissioning when the owner leaves or the workload is retired. See the NHI Ownership Guide and the NHI Governance Maturity Model.

Building or rationalising the framework

1. Inventory: collect every policy, standard, procedure and guideline, including HR, legal and engineering wikis, with owner and last review date.
2. Rationalise: classify each document by layer, merge overlaps, retire orphans, and move technical values out of policies into standards.
3. Set the rules of the framework: approve the top-level policy with the template, numbering scheme, approval delegation, review intervals and exception process written into it.
4. Draft the core set: start with access control, acceptable use, incident response, data classification and supplier security, then fill the rest.
5. Pilot: publish two or three policies to one business unit, run attestation, gather questions, and fix wording before wider release. Keep previous versions in force until the new ones are approved, so you can roll back.
6. Map and enforce: map statements to the common control set and frameworks, and identify which statements can be enforced as code.
7. Publish and attest: release through the portal, run attestation and add policies to induction.
8. Operate: run the review calendar, the exception register and quarterly reporting to the steering committee.

Measuring adoption

Common failure patterns

• Policies that copy a framework: mirroring the control catalogue line by line, which staff cannot use.
• Technical values in policies: key lengths and product names in a board-approved document go stale.
• Exceptions without expiry: "temporary" exceptions that become the real policy for the most exposed systems.
• Owners that are teams: no named person, so reviews lapse.
• Prohibition without an alternative: bans on cloud storage or AI tools with no approved option push work into shadow tools, as the Samsung case shows.
• Human-only scope: access control policies that never mention service accounts, API keys or AI agents, leaving the most privileged identities governed by nothing.

Practitioner checklist

• Approve a top-level policy defining the hierarchy, template, approval delegation, review intervals and exception process.
• Keep topic-specific policies short and move measurable values into standards.
• Give every policy, standard and procedure a named owner, approver, version and next review date.
• Number every policy statement and map each "must" to a control and its evidence.
• Run one exception register with risk owner, compensating controls and expiry.
• Review policies at least annually and after audit findings, incidents, regulatory change or recurring exceptions.
• Tag policy-as-code rules with statement IDs and roll out new rules in audit mode first.
• Add an AI usage policy and NHI requirements (ownership, credential lifetime, offboarding) to the core set.
• Report overdue reviews, attestation, exceptions and statement coverage quarterly.

Standards and references

• ISO: ISO/IEC 27001:2022 Information security management systems, Requirements
• NIST: SP 800-12 Rev. 1, An Introduction to Information Security
• CSF Tools: NIST CSF 2.0 GV.PO Policy
• CSF Tools: NIST SP 800-53 Rev. 5 AC-1 Policy and Procedures
• NCSC: Cyber security culture principles, Principle 6
• CIS: Policy Templates for the CIS Controls
• NIST: AI Risk Management Framework Core
• SANS: Cybersecurity Policy Templates

Related NHI Mgmt Group resources: Control Mapping Guide · ISO 27001 Certification Guide · AI Governance Guide · NHI Ownership Guide · Agentic AI Security Policy Template