Policy and Governance Writing
Parent: Writing and Documentation · researched 2026-05-29T18:32:53.619Z· 6 sources · 10 concepts · skill policy-and-governance-writing
Policies prescribe. They do not propose, persuade, or describe — they bind. A reader of a policy needs three things in the first 60 seconds: who is bound by it, what they must do, and what happens if
Overview
- Policies prescribe. They do not propose, persuade, or describe - they bind. A reader of a policy needs three things in the first 60 seconds: who is bound by it, what they must do, and what happens if they don't. [source]
1. RFC 2119 / RFC 8174 normative keywords (BCP 14)
- RFC 8174 clarification: The normative meaning attaches only when the keyword is in ALL CAPITALS. Lowercase "must", "should", and "may" carry their normal English meaning and have no normative weight. [source]
- Required incantation: [source]
- > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. [source]
2. The policy / standard / procedure / guideline hierarchy (NIST SP 800-12)
- Policy - what must be true, and why. Mandatory. Strategic. Changes rarely. [source]
- Standard - which specific implementation satisfies the policy (TLS 1.3, AES-256). Mandatory. Tactical. [source]
- Procedure - how to perform a specific task. Mandatory for the role performing the task. Operational. [source]
- Guideline - suggested approach when no mandatory standard applies. Advisory. [source]
- The hierarchy test: if you can answer "yes" to "would this need to change when we upgrade the firewall?", it is not a policy. It is a standard or procedure. [source]
3. Required components of an enforceable policy
- Title and identifier - unique policy ID, version number, effective date [source]
- Purpose - one-paragraph statement of why the policy exists [source]
- Scope - who, what, where the policy applies; explicit in-scope and out-of-scope lists [source]
- Definitions - every term of art, listed alphabetically [source]
- Policy statements - the normative rules, using BCP 14 keywords in ALL CAPS [source]
- Roles and responsibilities - named role titles (not individuals) mapped to obligations [source]
- Exceptions - how to request and approve a documented deviation [source]
- Enforcement - consequences of violation [source]
- Related documents - pointers to standards, procedures, and laws [source]
- Review schedule - review cadence, owner, next review date, change-history table [source]
4. The scope section as the contract boundary
- A defensible scope section answers: [source]
- People - which employees, contractors, vendors, partners, customers? [source]
- Assets - which systems, data classifications, networks, locations, devices? [source]
- Activities - which operations, transactions, or behaviors? [source]
- State each as an inclusion list AND an exclusion list. [source]
5. The exception clause
- A well-built exception clause has four elements: [source]
- Who can grant - the approval authority (named role, not person) [source]
- What must be documented - business justification, compensating controls, scope, duration [source]
- How long it lasts - maximum duration before re-review (typically 90 or 180 days) [source]
- How it is tracked - where the exception register lives [source]
6. Review schedule and change management
- ISO/IEC 27001 clause 7.5.3 requires that documents be reviewed and updated as necessary. [source]
- Review cadence - at least annual [source]
- Document owner - the role accountable for triggering review [source]
- Change-history table - a row per version showing version, date, author, change summary, approver [source]
Anti-Patterns
- The descriptive policy - lots of background, no rules. [source]
- Lowercase normatives - using "should" and "must" in lowercase while believing they bind readers. [source]
- The grab-bag scope - "This policy applies to everyone and everything." Unenforceable. [source]
- Personal-name responsibilities - "Jane Smith MUST approve all exceptions." Jane leaves; policy breaks. [source]
- No exception path - forces operators to violate or route around. [source]
- Procedure leakage - step-by-step instructions inside a policy. [source]
- The standard masquerading as policy - "All servers MUST run TLS 1.3." When TLS 1.4 ships, the policy is wrong. [source]
References
- RFC 2119 - https://datatracker.ietf.org/doc/html/rfc2119 [source]
- RFC 8174 - https://www.rfc-editor.org/rfc/rfc8174.html [source]
- NIST SP 800-12 Rev. 1 - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-12r1.pdf [source]
- Plain Writing Act of 2010 - https://www.plainlanguage.gov/guidelines/ [source]
- ISO/IEC 27001:2022 - Information security management systems - Requirements. [source]
Children
- RFC 2119 / RFC 8174 normative keywords (frontier)
- NIST SP 800-12 policy hierarchy (frontier)
- Policy components (scope, definitions, roles, exceptions, review) (frontier)
- ISO/IEC 27001 Annex A policy patterns (frontier)
- Plain Writing Act 2010 accessibility (frontier)
- Exception clauses (frontier)
- Change management and version control (frontier)
- Policy vs RFC vs ADR vs runbook distinction (frontier)
Frontier under this node: Change management and version control, Exception clauses, ISO/IEC 27001 Annex A policy patterns, NIST SP 800-12 policy hierarchy, Plain Writing Act 2010 accessibility, Policy components (scope, definitions, roles, exceptions, review), Policy vs RFC vs ADR vs runbook distinction, RFC 2119 / RFC 8174 normative keywords