CM-5(2): Review System Changes

Compliance teams usually “have change management,” but CM-5(2) is narrower and sharper: it focuses on reviewing system changes so you can detect unauthorized modifications and confirm authorized changes were implemented as intended. For a CCO, Compliance Officer, or GRC lead, the fastest path is to translate CM-5(2) into two concrete expectations: (1) a defined review step in the change workflow, and (2) retained artifacts that prove the review happened and was meaningful.

This requirement matters most in environments where speed, automation, and privileged access intersect: cloud infrastructure, CI/CD pipelines, infrastructure-as-code, identity platforms, endpoint tooling, and network/security device configuration. In those contexts, “the change” might be a pull request merged to main, a Terraform plan applied, a firewall rule pushed, or a production feature flag flipped. CM-5(2) expects you to be able to reconstruct what changed, who approved it, who reviewed it, what testing occurred, and how you verified production was left in a secure state.

If you manage federal information systems or contractor systems handling federal data, CM-5(2) should be treated as requirement-level work: define ownership, embed the review into operations, and make evidence collection automatic where possible. ¹

Regulatory text

Control excerpt (as provided): “NIST SP 800-53 control CM-5.2.” ²

Operator interpretation: CM-5(2): Review System Changes requires a formal, repeatable practice to review system changes so you can confirm they are authorized and correctly implemented. You should be able to demonstrate:

• the change was requested and approved,
• the implemented change matches what was approved, and
• someone performed a review that is not self-attestation by the implementer.
  ¹

Plain-English interpretation (what CM-5(2) really expects)

A “review of system changes” is your check against two failure modes:

1. Unauthorized change: someone changed production without approval (maliciously or accidentally).
2. Authorized but wrong change: the ticket was approved, but the implementation deviated, was incomplete, or created security/availability risk.

Your review step must be operationally real:

• It happens consistently (not only for high-profile incidents).
• It is tied to the actual technical change (diff, configuration snapshot, deployment artifact).
• It has criteria (what the reviewer checks).
• It produces auditable output (recorded approval, comments, test results, and closure rationale).

Who it applies to (entity and operational context)

CM-5(2) is relevant for:

• Federal information systems implementing NIST SP 800-53 controls. ¹
• Contractor systems handling federal data where NIST SP 800-53 is a contractual or assessment baseline. ¹

Operationally, apply it anywhere a change can affect confidentiality, integrity, or availability, including:

• Production applications and APIs
• Cloud infrastructure (IAM, networking, Kubernetes, storage)
• Security tooling (EDR, SIEM configurations, DLP policies)
• Identity systems (SSO, MFA policies, privileged access)
• Network devices and firewall rules
• Databases and schema changes
• CI/CD pipelines and build/release definitions

What you actually need to do (step-by-step)

Use this as a minimum viable operating procedure that auditors can follow.

1) Define “system change” in scope

Create a short scope statement and include examples:

• Code changes to production
• Infrastructure-as-code changes
• Configuration changes on security/network devices
• Identity policy changes
• Emergency changes and break-glass actions

Practical tip: If your teams argue scope, start with “anything that can affect production security posture or availability” and refine by system criticality.

2) Assign clear control ownership and reviewers

Set:

• Control owner (often: Head of IT Ops, SRE, or Change Manager)
• Independent reviewers by domain (app, infra, security)
• Approvers (business/system owner for risk acceptance; security for sensitive changes)

Independence standard you can defend: the implementer cannot be the only reviewer. Peer review is acceptable if the reviewer is not the author/implementer.

3) Embed review gates into the change workflow

Pick the mechanism that matches your delivery model:

If you use ITSM tickets (ServiceNow/Jira):

• Require linked artifacts (PR link, CI run, Terraform plan, config diff).
• Add mandatory fields for reviewer identity, review checklist, and test/validation results.
• Prevent closure until review fields are completed.

If you use GitOps/CI/CD:

• Enforce branch protection: required reviewers, required checks, signed commits if applicable.
• Require a change record reference in PR template.
• Store build/deploy logs centrally and link them.

4) Set review criteria (a checklist reviewers must apply)

Keep it short and enforceable. Example checklist:

• Change matches the approved request/scope.
• Security impact considered (data access, authN/authZ, encryption, logging).
• Testing performed and results recorded (unit/integration/smoke as applicable).
• Rollback/backout plan exists for impactful changes.
• Post-change validation completed (service health, monitoring, security controls still active).
• No direct-to-prod changes outside the approved path (or emergency process invoked).

5) Handle emergency changes without losing control

Define an emergency path with:

• Allowed triggers (incident response, critical outage).
• Temporary approval authority (on-call manager + security on-call where relevant).
• Required post-change review within a defined operational window set by your policy.
• Evidence requirements identical to normal changes, plus incident reference.

6) Implement monitoring to detect “off-path” changes

CM-5(2) reviews are easier if you can detect drift:

• Alert on production configuration drift vs. approved baselines.
• Monitor privileged actions and correlate to tickets.
• Periodically sample changes and reconcile “what changed” to “what was approved.”

This is where Daydream typically becomes the natural operational glue: map CM-5(2) to an owner, a documented procedure, and recurring evidence artifacts so you can show consistent operation during assessment cycles. ²

7) Run a recurring quality check (control assurance)

On a schedule set by your governance process:

• Pull a sample of completed changes from in-scope systems.
• Verify each has complete traceability and a meaningful review.
• Record findings, remediation tickets, and any policy updates.

Required evidence and artifacts to retain

Auditors usually cannot “see” your intent; they only see artifacts. Retain:

Change-level artifacts ²

• Change request/ticket with unique ID and scope
• Approval record(s) and timestamps
• Identity of implementer and reviewer(s)
• Technical evidence of the change:
  • PR and diff, or
  • configuration diff/snapshot, or
  • infrastructure plan/apply output, or
  • deployment artifact version
• Testing evidence (CI results, test run outputs, or validation checklist)
• Post-change verification evidence (monitoring screenshot/export, smoke test output, service health confirmation)
• Closure notes, including exceptions and risk acceptance

Program-level artifacts

• Change management procedure including the “review” step
• Review checklist template and completion guidance
• Role assignments (RACI) for approver/reviewer/implementer
• Emergency change procedure and after-action review template
• Evidence retention policy (where stored, how long, access controls)

Common exam/audit questions and hangups

Expect these questions and pre-answer them with evidence:

• “Show me three recent production changes and the corresponding review.”
• “How do you prove the reviewer is not the implementer?”
• “How do you detect changes made outside the ticketing/PR process?”
• “How are emergency changes reviewed after the fact?”
• “What constitutes sufficient post-change validation?”

Hangups that trigger findings:

• Reviews recorded only in chat, not linked to the change record.
• “Approved” but no proof the implemented diff matches the approved scope.
• Gaps between CI/CD evidence and ITSM ticket evidence (no linkage).

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails CM-5(2)	Fix
Self-review (implementer marks their own change “reviewed”)	No meaningful independent check	Require peer/security review in workflow gates
Review exists but not tied to the technical change	You cannot prove what was reviewed	Force links to PR/diff, config snapshot, or deployment artifact
Emergency path becomes the normal path	Review is bypassed routinely	Limit triggers; require post-change review and management oversight
Ticket has approvals but no post-change validation	Correct change can still break controls	Add required post-change validation fields and monitoring evidence
Evidence scattered across tools	Audits become manual and error-prone	Standardize linkages; centralize evidence collection in a GRC system

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat enforcement risk here as assessment and contractual performance risk, not cite-specific penalty exposure. The operational risk is concrete: unauthorized or poorly reviewed changes are a common root cause for outages, control failures (logging disabled, IAM misconfigurations), and incident response gaps. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Name the CM-5(2) control owner and reviewer roles for in-scope platforms.
• Define “system change” scope and emergency change triggers.
• Add required review fields/checklist to the change record (ITSM or PR template).
• Identify where evidence will live (ticketing system, Git platform, CI logs, GRC repository).

By 60 days (embed into engineering operations)

• Implement workflow gates: required reviewers and required checks in CI/CD where applicable.
• Require ticket/PR linkage both ways (ticket references PR; PR references ticket).
• Create a post-change validation checklist for high-impact systems.
• Start drift detection for at least one critical configuration domain (IAM, firewall, Kubernetes, endpoint policy).

By 90 days (make it audit-ready)

• Run a control assurance sample: select recent changes, verify end-to-end evidence, log gaps, remediate.
• Document exceptions (tools that cannot enforce peer review, legacy platforms) and put compensating controls in place.
• Operationalize recurring evidence exports/reports so CM-5(2) is continuously provable.
• If you use Daydream, map CM-5(2) directly to the owner, procedure, and recurring artifacts so audits stop being a scramble. ²

Frequently Asked Questions

Does CM-5(2) require a formal change advisory board (CAB)?

CM-5(2) requires review of system changes with evidence; it does not inherently require a CAB. If your environment moves fast, peer review plus risk-based approvals can satisfy the intent if independence and traceability are strong.

Can peer review in Git count as the “review”?

Yes, if it is linked to the change request, performed by someone other than the implementer, and backed by artifacts like diffs and required checks. You still need post-change validation evidence for higher-risk changes.

What should we do about changes made directly in the cloud console?

Treat console changes as high-risk “off-path” changes: require an emergency change record, capture evidence (screenshots/exports where needed), and push teams toward infrastructure-as-code. Add monitoring to detect and reconcile console activity to approved tickets.

How do we prove the change implemented matches what was approved?

Link approvals to an immutable representation of the change (PR diff, commit hash, IaC plan, config diff) and require reviewers to attest to scope match in the record. Avoid approvals that only reference a vague description.

Are testing and post-change validation required by CM-5(2)?

The control excerpt provided is short, but operationally, review without validation is weak and hard to defend in an assessment. Build testing and post-change checks into the review criteria so the “review” demonstrates the change was implemented correctly. ¹

What’s the minimum evidence set an auditor will accept?

For each sampled change, expect to produce the ticket, approvals, reviewer identity, the technical diff/artifact, and closure notes with validation. If any one element is missing across samples, auditors often conclude the process is not consistently operating.

Footnotes

1. NIST SP 800-53 Rev. 5

2. NIST SP 800-53 Rev. 5 OSCAL JSON