What a change management policy should include

A change management policy states which changes need control, who reviews and approves them, how security impact is assessed, how approved changes are made and recorded, and who oversees the process. Keep it short and let procedures hold the detail.

Use the control as your outline

NIST SP 800-53 CM-3 (Configuration Change Control) is a ready outline. In paraphrase it asks you to:

1. Identify and document which types of changes are subject to control.
2. Review proposed changes and approve or disapprove them, explicitly considering security and privacy impact.
3. Document the decisions.
4. Implement approved changes.
5. Retain records of controlled changes for a defined period.
6. Monitor and review activity tied to those changes.
7. Coordinate oversight through a defined change control body that meets on a schedule or when needed.

Each item becomes a policy section.

Scope: which changes count

This is the section teams get wrong. Too broad and nobody follows it. Too narrow and risky changes slip through. Name the categories: production code, infrastructure and cloud configuration, identity and access settings, network rules, database schema, security tooling settings, and third-party integrations.

Say explicitly what is out of scope, such as copy edits on a marketing page, so people do not ask.

Approval and risk classes

Define a small number of change classes by risk. One common design has three: standard changes that are pre-approved and routine, normal changes that need review, and emergency changes that proceed first and are reviewed after. See standard, normal and emergency changes.

Impact analysis

State that someone checks security and privacy impact before approval. A short impact checklist keeps this from becoming a box tick.

Records and retention

Decide what a change record contains: what changed, why, who requested, who approved, when it was made, how it was tested, and how to roll back. Decide how long you keep them. CM-3 leaves the period to you. If you use pull requests and tickets, they are your records, so say so.

Oversight

CM-3 expects a change control body, often called a change advisory board. For a small team this can be two people who meet weekly, or a standing review in an engineering meeting. See whether small teams need a change advisory board.

Pitfalls

• A policy that requires a form your team never fills in.
• No path for emergencies, which guarantees people route around the policy.
• No check that unauthorised changes are detected. CM-3 supplemental guidance includes reviewing unauthorised changes, so compare production against what was approved at intervals.

Safeguard's policies, gates and guardrails can enforce checks on pull requests before merge, which supports the review step of a change process. Run a free scan at gold.safeguard.sh/scan.

Quick check

Sources

• CM-3 Configuration Change Control, NIST SP 800-53 Rev. 5

Last reviewed: 19 October 2026.