Policy and Governance Writing
Parent: Writing and Documentation · Published reference · snapshot 2026-09-08 · skill career-and-formal-writing/references/policy-and-governance-writing.md
↓ Facts as markdownall context files
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
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#overview]
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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#1-rfc-2119-rfc-8174-normative-keywords-bcp-14]
- Required incantation: > 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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#1-rfc-2119-rfc-8174-normative-keywords-bcp-14]
2. The policy / standard / procedure / guideline hierarchy (NIST SP 800-12)
- Policy - what must be true, and why. Mandatory. Strategic. Changes rarely. [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#2-the-policy-standard-procedure-guideline-hierarchy-nist-sp-800-12]
- Standard - which specific implementation satisfies the policy (TLS 1.3, AES-256). Mandatory. Tactical. [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#2-the-policy-standard-procedure-guideline-hierarchy-nist-sp-800-12]
- Procedure - how to perform a specific task. Mandatory for the role performing the task. Operational. [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#2-the-policy-standard-procedure-guideline-hierarchy-nist-sp-800-12]
- Guideline - suggested approach when no mandatory standard applies. Advisory. [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#2-the-policy-standard-procedure-guideline-hierarchy-nist-sp-800-12]
3. Required components of an enforceable policy
- Title and identifier - unique policy ID, version number, effective date [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#3-required-components-of-an-enforceable-policy]
- Purpose - one-paragraph statement of why the policy exists [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#3-required-components-of-an-enforceable-policy]
- Scope - who, what, where the policy applies; explicit in-scope and out-of-scope lists [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#3-required-components-of-an-enforceable-policy]
- Definitions - every term of art, listed alphabetically [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#3-required-components-of-an-enforceable-policy]
- Policy statements - the normative rules, using BCP 14 keywords in ALL CAPS [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#3-required-components-of-an-enforceable-policy]
- Roles and responsibilities - named role titles (not individuals) mapped to obligations [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#3-required-components-of-an-enforceable-policy]
- Exceptions - how to request and approve a documented deviation [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#3-required-components-of-an-enforceable-policy]
- Enforcement - consequences of violation [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#3-required-components-of-an-enforceable-policy]
- Related documents - pointers to standards, procedures, and laws [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#3-required-components-of-an-enforceable-policy]
- Review schedule - review cadence, owner, next review date, change-history table [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#3-required-components-of-an-enforceable-policy]
4. The scope section as the contract boundary
- A defensible scope section answers: [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#4-the-scope-section-as-the-contract-boundary]
- People - which employees, contractors, vendors, partners, customers? [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#4-the-scope-section-as-the-contract-boundary]
- Assets - which systems, data classifications, networks, locations, devices? [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#4-the-scope-section-as-the-contract-boundary]
- Activities - which operations, transactions, or behaviors? [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#4-the-scope-section-as-the-contract-boundary]
- State each as an inclusion list AND an exclusion list. [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#4-the-scope-section-as-the-contract-boundary]
5. The exception clause
- A well-built exception clause has four elements: [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#5-the-exception-clause]
- Who can grant - the approval authority (named role, not person) [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#5-the-exception-clause]
- What must be documented - business justification, compensating controls, scope, duration [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#5-the-exception-clause]
- How long it lasts - maximum duration before re-review (typically 90 or 180 days) [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#5-the-exception-clause]
- How it is tracked - where the exception register lives [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#5-the-exception-clause]
6. Review schedule and change management
- ISO/IEC 27001 clause 7.5.3 requires that documents be reviewed and updated as necessary. [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#6-review-schedule-and-change-management]
- Review cadence - at least annual [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#6-review-schedule-and-change-management]
- Document owner - the role accountable for triggering review [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#6-review-schedule-and-change-management]
- Change-history table - a row per version showing version, date, author, change summary, approver [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#6-review-schedule-and-change-management]
Anti-Patterns
- The descriptive policy - lots of background, no rules. [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#anti-patterns]
- Lowercase normatives - using "should" and "must" in lowercase while believing they bind readers. [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#anti-patterns]
- The grab-bag scope - "This policy applies to everyone and everything." Unenforceable. [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#anti-patterns]
- Personal-name responsibilities - "Jane Smith MUST approve all exceptions." Jane leaves; policy breaks. [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#anti-patterns]
- No exception path - forces operators to violate or route around. [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#anti-patterns]
- Procedure leakage - step-by-step instructions inside a policy. [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#anti-patterns]
- The standard masquerading as policy - "All servers MUST run TLS 1.3." When TLS 1.4 ships, the policy is wrong. [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#anti-patterns]
References
- RFC 2119 - https://datatracker.ietf.org/doc/html/rfc2119 [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#references]
- RFC 8174 - https://www.rfc-editor.org/rfc/rfc8174.html [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#references]
- NIST SP 800-12 Rev. 1 - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-12r1.pdf [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#references]
- Plain Writing Act of 2010 - https://www.plainlanguage.gov/guidelines/ [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#references]
- ISO/IEC 27001:2022 - Information security management systems - Requirements. [archived source: https://llms-explorer.com/sources/mdb-context-hub/policy-and-governance-writing/#references]
Where this helps
- Writing an information-security or data-handling policy that needs to survive an ISO 27001 or SOC 2 audit, where auditors check for named roles, review dates, and enforceable language. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Distinguishing a policy from a standard or procedure when a draft keeps needing edits every time the underlying technology changes — a sign it was written at the wrong level of the hierarchy. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Reviewing a vendor-supplied or legacy policy document that reads as background prose with no actual normative rules, before it gets circulated for sign-off. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Building an exception-request process for a policy that currently has no documented deviation path, forcing teams to quietly violate or route around it. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
How to apply this
- Classify the document before drafting a word of it: ask whether it states what must be true (policy), which implementation satisfies that (standard), how to perform a task (procedure), or a suggested approach with no mandate (guideline), and write only that layer. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Use BCP 14 keywords in ALL CAPS for every normative statement, and include the RFC 2119/8174 incantation once near the top so the capitalization convention is unambiguous to readers. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Draft the scope section as paired inclusion and exclusion lists across people, assets, and activities, rather than a single sentence claiming universal coverage. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Assign every obligation to a named role, not a named person, so the policy survives personnel turnover without requiring an edit. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Common mistakes
- Writing a "descriptive policy" that explains background and context at length but never states an actual binding rule. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Using lowercase "should" and "must" while assuming they carry the same enforceable weight as the RFC 2119 ALL-CAPS keywords. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Assigning a responsibility to a named individual ("Jane Smith MUST approve all exceptions") instead of a role, so the policy breaks the moment that person changes jobs. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Embedding a specific implementation detail ("All servers MUST run TLS 1.3") directly in the policy layer instead of the standard layer, so the policy goes stale the moment the implementation is upgraded. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Known issues
- The RFC 2119 keyword convention only carries normative force within the document that includes the BCP 14 incantation — pasting MUST/SHOULD language into an unrelated document without that framing doesn't automatically bind anyone. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- A policy with no exception clause doesn't eliminate edge cases; it just forces operators to either silently violate the policy or route around it undocumented, which is worse for auditability than a documented exception path. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- ISO/IEC 27001 clause 7.5.3 requires review "as necessary" in addition to a fixed cadence, so an annual-only review schedule can still fail an audit if a material change occurred mid-cycle and wasn't captured. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Getting the policy/standard/procedure boundary right requires ongoing discipline — a well-written policy can still drift into standard or procedure territory over successive edits if each editor treats it as a place to add operational detail. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
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