The structure of a security policy: what the document must contain

A security policy is not a free-form statement of intent: in SP 800-53 Revision 5 the policy for a control family is itself a requirement, and the catalogue says what the document must address. The content list is short — purpose, scope, roles, responsibilities, management commitment, coordination and compliance — and it is a requirement, not a template. Reproducing those headings meets part of the specification; the same control says that restating controls is not writing a policy.

What the control requires the document to say

PL-1 POLICY AND PROCEDURES states it for the Planning family: a planning policy that addresses “purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance”, consistent with applicable laws, directives, regulations, policies, standards and guidelines, written at one or more levels the organisation selects, and reviewed and updated at an organisation-defined frequency and following organisation-defined events. The control names the subjects to cover and leaves the wording and the layout to the organisation.

security policy — the components the control requires (SP 800-53r5 PL-1)
  purpose                 why the document exists and what it aims at
  scope                   which resources it covers, and what it excludes
  roles                   who acts under it
  responsibilities        who is accountable for what
  management commitment   the mandate behind the rules
  coordination            among the organisational entities involved
  compliance              what is required, and what follows from a breach

  designated official     the function that owns the document and keeps it alive
  review + update         a defined frequency, and a defined set of triggering events

Purpose and scope: what is covered, and what is not

SP 800-12 Revision 1 separates the two. Purpose carries the programme’s goals, specific to what is protected: a policy for mission-critical databases might stress “a reduction in errors, data loss, data corruption, and recovery”; one protecting confidential personal data, “stronger protection against unauthorized disclosure” (§5.2.1). Scope names the resources protected — “facilities, hardware and software, information, and personnel” — and may be narrower than the organisation: a policy for a high-impact system “will be much more stringent” than one for a low-impact system. A policy that does not say what it excludes leaves the reader guessing.

Roles, responsibilities and the designated official

The list names roles and responsibilities separately. SP 800-12 Revision 1 asks the programme policy to assign management of the programme to an office and to distinguish “between the responsibilities of information service providers and the managers of applications” (§5.2.1). SP 800-100 states the test: “Organizational policy should clearly define who is responsible for system security plan approval” (§8.4). SP 800-53 Revision 5 makes one role mandatory: a designated official manages the policy and the procedures that implement it.

Compliance, and what gives it force

SP 800-100 lists what an agency’s policy should address, among them security roles and responsibilities, a statement of the control baseline and the rules for exceeding it, and “Rules of behavior that agency users are expected to follow and minimum repercussions for noncompliance” (§2.2.5). The last gives the document its force: a rule with no stated consequence is advice, however firmly written. SP 800-12 Revision 1 splits compliance into general conformance and penalties and disciplinary actions, which a high-level policy authorises rather than details; legal counsel is “critical” when action against individuals is addressed.

One document or many: the level the policy is written at

The control lets the organisation select the level and prefers the organisation level. Read against those levels, SP 800-12 Revision 1 draws the ends of that range: the organisation-wide policy creates the programme and sets “the strategic direction for security and assign[s] resources for its implementation”; an issue-specific policy addresses an area of current concern — internet access, email privacy, social media — written so that it “will be clear to users” and reviewed regularly because technology changes (§5.3). Its components are an issue statement, the organisation’s position, applicability, roles and responsibilities, compliance, and points of contact (§5.3.2).

Review and update: a frequency and a set of events

PL-1 requires review and update at an organisation-defined frequency and following organisation-defined events; its examples of the events are “assessment or audit findings, security incidents or breaches, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines”. SP 800-100 gives the reason for the routine: policies and procedures “may become inadequate because of changes in agency mission and operational requirements, threats, environment … or business processes” (§2.2.6). CSF 2.0 pairs the two the same way: a policy for managing cybersecurity risks is established, communicated and enforced (GV.PO-01), then “reviewed, updated, communicated, and enforced” (GV.PO-02).

What a complete document does not prove

The list is necessary, not sufficient, and the catalogue says so at the end of the PL-1 discussion: “Simply restating controls does not constitute an organizational policy or procedure.” SP 800-12 Revision 1 records that the policy layer of SP 800-53 is expressed by the -1 controls for every family, which “establish policy and procedures for the effective implementation of the selected security control”; PL-1 is that control for Planning, and in Revision 5 the pattern holds for 19 of the 20 families. What makes implementation checkable belongs to the sibling sheet on control objectives and verification criteria; the standards and procedures under a policy are the sibling sheet on technical standards and operating procedures. A document is not conformant on the strength of its headings, and nothing here is a statement of compliance with any law.

Level and prerequisites

L2 — operational: read a policy against the required content list, place it on the right level, and say what each part must decide. Prerequisites: the L1 sheet on policy, standard, procedure and guideline, and the L1 sheet on roles and accountability. Drafting workshops and exception processes come later.

Where to go next

Knowledge — the index.
Cybersecurity Governance — the area this sheet belongs to.
Security governance foundations — this sheet’s node.

Sibling sheets are named in prose, never linked.

References

NIST — SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations — https://doi.org/10.6028/NIST.SP.800-53r5 — PL-1 POLICY AND PROCEDURES (the content list, consistency with laws and directives, the selectable levels, the designated official, review at a defined frequency and following defined events, and the “Simply restating controls” sentence) and the -1 POLICY AND PROCEDURES control of each family, with the PM-1 exception.
NIST — SP 800-12 Rev. 1, An Introduction to Information Security — https://doi.org/10.6028/NIST.SP.800-12r1 — §5 and §5.1 (the -1 controls as the policy layer); §5.2 Program Policy and §5.2.1 Basic Components of Program Policy (purpose, scope, responsibilities, compliance); §5.3 Issue-Specific Policy and §5.3.2 Basic Components of Issue-Specific Policy.
NIST — SP 800-100, Information Security Handbook: A Guide for Managers (October 2006) — https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-100.pdf — §2.2.5 Information Security Policy and Guidance (the fundamentals, the policy review and revision cycle), §2.2.6 Ongoing Monitoring, and §8.4 System Security Plan Approval.
NIST — The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29 (February 2024) — https://doi.org/10.6028/NIST.CSWP.29 — the Governance function’s Policy category GV.PO, subcategories GV.PO-01 and GV.PO-02.