The core concept

Change management is how you evaluate, approve, implement, and log every change to production. Every framework asks the same four questions: what changed, why, who approved it, and what happened when it ran.

This is not just an ITSM habit. In any regulated cloud environment, the change record is one of the first things an assessor pulls. They want to trace a vulnerability remediation back to the change ticket, the approval, and the implementation evidence. If the thread breaks at any point, that is a finding.

The discipline itself is simple. A change enters a pipeline: categorize it, assess the impact, route it for approval, implement it, verify the results, and log the outcome. What differs across CMMC, FedRAMP Rev5, and FedRAMP 20x is the evidence format, the notification requirements, and how much of the process has to be automated.

graph LR
    R[Change Request] --> C[Categorize] --> IA[Impact Assessment] --> A[Approval]
    A --> I[Implementation] --> V[Verification] --> L[Logged Record]
    C -.->|if significant change| SCN[SCN Notification]

    style R fill:#2b5797,stroke:#5b9bd5,color:#fff
    style C fill:#1a3d5c,stroke:#4ecdc4,color:#fff
    style IA fill:#5c4a1a,stroke:#ffc857,color:#fff
    style A fill:#1a5c3d,stroke:#51cf66,color:#fff
    style I fill:#5c1a1a,stroke:#ff6b6b,color:#fff
    style V fill:#4a1a5c,stroke:#c77dff,color:#fff
    style L fill:#1a3d1a,stroke:#a9dc76,color:#fff
    style SCN fill:#5c1a3d,stroke:#ff6b9d,color:#fff

What CMMC requires

CMMC addresses change management through Configuration Management practices in NIST SP 800-171 Rev 2. The framework does not prescribe how often you review changes or what notification format to use. It does require a documented, enforced process for any system handling Controlled Unclassified Information (CUI).

The relevant practices:

• CM.L2-3.4.3 (Level 2): Track, review, approve or disapprove, and log changes to organizational systems. 1-point, POA&M-eligible. This is the core change control practice. Assessors want to see change request tickets with approvals, implementation evidence, and audit logs.
• CM.L2-3.4.4 (Level 2): Analyze the security impact of changes prior to implementation. 1-point, POA&M-eligible. This means a Security Impact Analysis (SIA) exists for every change, captured before the change routes for approval. Not after. Not as a retroactive note.
• CM.L2-3.4.5 (Level 2): Define, document, approve, and enforce physical and logical access restrictions associated with changes. This practice is 5-point and not POA&M-eligible. You cannot defer it at assessment time. Both physical and logical access restrictions on who can implement changes have to be demonstrable.

What a C3PAO assessor looks for:

• Change request tickets with approvals on them
• Security impact analysis attached to each change
• Separation of duties between requestor, approver, and implementer
• Audit logs showing what changed, when, and by whom
• Baseline configurations to measure changes against
• Emergency change procedures with retroactive review evidence

The common gap: changes happen ad hoc. There is a policy document sitting on a SharePoint somewhere, but no enforced workflow. Emergency changes bypass every control and never get a retroactive review. The change ticket exists, but it has no linkage to what was actually changed or why.

The scoring matters here. CM.L2-3.4.5 is 5-point and not POA&M-eligible. That means you cannot plan your way around it. At assessment time, either you can demonstrate access restrictions on change implementation or you cannot. There is no “we will fix this in the next 180 days.” Organizations that rely on a shared admin account for deployments, or that allow developers to push directly to production without role separation, fail this practice outright.

Supporting practices add depth to what assessors expect. CM.L2-3.4.1 requires establishing and maintaining baseline configurations. CM.L2-3.4.2 requires establishing and enforcing security configuration settings. These feed into change management because every change is evaluated against a known-good baseline. Without a documented baseline, you cannot assess the impact of a change, and without enforced configuration settings, you cannot verify that a change did not introduce drift.

What FedRAMP Rev5 requires

FedRAMP treats change management as a core control with prescriptive requirements. The relevant controls:

• CM-3 (Configuration Change Control): documented change control process, approval by authorized individuals, retained decisions, and a communication mechanism for major changes (status page, bulletin board, etc.)
• CM-3(2): test, validate, and document changes before implementation. This is the pre-production validation requirement.
• CM-4 (Impact Analysis): security and privacy impact analysis on proposed changes. Similar to CMMC’s SIA requirement, but Rev5 ties it to the broader privacy and security analysis framework.

The Significant Change Notification (SCN) rules add a notification layer on top of change control. SCN started as a pilot improvement; under the FedRAMP Consolidated Rules for 2026 it is a final rule set that applies to both Rev5 and 20x. Every significant change falls into one of three categories:

• Routine Recurring: exempt from notification. Providers SHOULD NOT send formal SCNs for these (SCN-RTR-NNR). Automated patching, scheduled maintenance, standard deployments that follow an approved pattern.
• Adaptive: providers MUST notify within 10 business days after finishing the change (SCN-ADP-NTF). Changes that modify the system within existing parameters but do not routinely recur.
• Transformative: four staged notifications, each a MUST. Initial plans at least 30 business days before starting (SCN-TRF-NIP). Final plans at least 10 business days before starting (SCN-TRF-NFP). Within 5 business days after finishing (SCN-TRF-NAF). Within 5 business days after completing verification (SCN-TRF-NAV). Updated service documentation follows within 30 business days after finishing (SCN-TRF-UPD).

One thing SCN cannot cover: a Certification Class change. Per SCN-CSO-EVA, that requires a new assessment and cannot be done under the SCN rules.

The key insight: no change type requires advance approval from the government. SCN replaced the old advance-approval model with a notification model. Advance approval survives in exactly one place, as a penalty: FedRAMP MAY require providers to submit significant changes for approval in advance as a condition of a formal Corrective Action Plan (SCN-FRP-CAP). Emergency changes may proceed without advance notice, with all SCN materials provided retroactively (SCN-CSO-EMG).

Notification content is specified by SCN-CSO-INF: FedRAMP ID, assessor name, related vulnerability if applicable, change type with categorization rationale, description, reason, customer impact, plan and timeline, impact analysis, and approver. SCN-CSO-HRM requires notifications in both human-readable and JSON formats. SCN-CSO-HIS requires 12 months of historical notifications kept with your FedRAMP Certification Data. SCN-CSO-MAR requires auditable records of how each change was evaluated and categorized.

What independent assessors look for: categorization evidence for every change, impact assessments, approval workflows tied to roles, and an audit trail showing how each categorization decision was made. The 30, 10, 5, 5, and 30 business day windows for transformative changes are not suggestions. They are MUST requirements.

Common gap: organizations categorize changes retroactively instead of at intake. The SCN category is decided after the fact, if it is decided at all. Machine-readable notification formats do not exist. Historical notifications are not retained in a queryable format.

What FedRAMP 20x requires

FedRAMP 20x treats change management as a different problem than Rev5. Traditional change management assumes humans approve changes one at a time. 20x assumes changes ship through automated pipelines against immutable infrastructure, with validation running continuously.

The relevant KSIs:

• KSI-CMT-LMC (Logging Changes): modifications to the cloud service offering are logged and monitored. Machine-based validation checks that configuration recording is active and covers the environment. This is the foundation: you cannot manage what you do not track.
• KSI-CMT-RMV (Redeploying vs Modifying): changes to machine-based resources are executed through redeployment of version-controlled resources rather than direct modification wherever reasonable. Machine-based validation checks for long-running instances that violate the immutable infrastructure pattern and verifies that launch templates show active versioning.
• KSI-CMT-VTD (Validating Throughout Deployment): persistent testing and validation of changes throughout deployment is automated. Machine-based validation checks that deployment pipelines have sufficient stages (build, test, deploy at minimum) and that security review processes are in place.
• KSI-CMT-RVP (Reviewing Change Procedures): the effectiveness of documented change management procedures is persistently reviewed. Non-machine-based validation reviews the change management policy for completeness, accuracy, currency, and alignment with security requirements.

There is no separate KSI bridging SCN into 20x. The SCN rules apply to 20x directly: the same SCN-* requirements that govern Rev5 govern 20x, one rule set for both certification types.

The implications:

Immutable infrastructure is the assumed pattern; in-place edits to production are a 20x anti-pattern. Changes ship as new, version-controlled resources. If your deployment story requires someone to SSH into a server and edit a config file, that is not 20x-ready.

Validation is continuous, not periodic. Each deployment runs automated security and functional tests. Not just a pre-production smoke test once, but persistent validation throughout the deployment lifecycle.

Change procedures themselves are treated as something you measure. KSI-CMT-RVP expects you to track the effectiveness of your change process like any other metric: are changes failing? Are rollbacks happening? Is the process producing the outcomes it should?

Automation is not optional at the higher classes either: a Class C certification MUST have at least 2 automated validation methods for each KSI, and Class D at least 4 (FRC-CSX-VVK).

The gap on the path to 20x: manual deployment steps, no automated validation gates, in-place modifications to running systems, and change procedures that only get reviewed when an auditor asks.

We see this in our own 20x validation runs. KSI-CMT-LMC runs machine-based validations checking that configuration change recording is active and covers the full environment. KSI-CMT-RMV validates immutable infrastructure patterns by checking instance ages and launch template versioning. KSI-CMT-VTD validates pipeline stages and security controls. These checks run continuously, not once a quarter.

The pain we lived

Change management was one of the first places where our disconnected tools broke down.

We had change tickets. They were in a ticketing system. But they existed in isolation. A change ticket said “apply patches for January patch window.” It did not link to the six POA&M entries those patches were remediating. It did not link to the vulnerability scan results that identified the findings. It did not link to the assets being patched.

When we needed to prove to an assessor that a specific vulnerability had been remediated by a specific change, the trail went cold. We had the change ticket over here. We had the POA&M over there. We had the scan results in a third place. Connecting them required someone to manually cross-reference three systems, and the evidence was never clean.

Approvals were worse. Change approvals happened over email. The requestor would describe the change, send it to the approver, and wait for a reply. Sometimes the reply came quickly. Sometimes it took days. Three weeks later, when an assessor asked to see the approval for a specific change, nobody could find the email. It was buried in someone’s inbox, or it was in a thread that had been archived, or the approver had left the organization.

Emergency changes were the worst case. Something breaks in production at 2 AM. The engineer fixes it. Nobody files a retroactive change ticket. Or they file one three days later from memory, with no impact analysis and no formal approval. Now you have undocumented changes to a production system handling CUI. That is a finding.

We also had no way to categorize changes in terms that mapped to SCN requirements. When FedRAMP piloted the SCN categorization model, we had no structured field for it. Categorization happened in meeting notes, if it happened at all.

The scale made everything harder. One environment with spotty change management is manageable. You can chase down the approvals, reconstruct the evidence, and get through an assessment. Across 15+ environments, with different ticketing systems, different approval workflows, and different people responsible for each one, the problem is systemic. You cannot fix it by working harder. You have to fix the process.

The root cause was the same in every environment: the change ticket, the approval, the linked vulnerabilities, and the affected assets all lived in different places. The data existed, but the relationships did not.

How we automate it

Here is how we built change management in Stratus GRC-ITSM. The goal was one process that produces evidence for CMMC assessors, FedRAMP independent assessors, and 20x KSI validation from the same data.

1. Structured intake. Every change request starts as an approval-gated ticket with a defined change type (patch-window, transformative, or routine). Required fields: affected components (linked to the system’s component inventory), business impact, risk assessment, and plan, backout, and test documentation. No free-text-only tickets. The data is structured at the point of entry because everything downstream depends on it.
2. SCN categorization at intake. The change type and impact assessment drive the SCN category. Routine Recurring, Adaptive, or Transformative is set during intake, not decided retroactively; a change that would alter the Certification Class is flagged as out of SCN scope entirely. The categorization record satisfies SCN-CSO-MAR.
3. Security Impact Analysis as a workflow step. Not a checkbox. Not a free-text field someone skips. The SIA is captured as structured data tied to specific components and controls. This produces the evidence CM.L2-3.4.4 needs for CMMC and meets the CM-4 impact analysis requirement for Rev5.
4. Automated routing. Based on change type and impact, the workflow routes to the right approval path. Routine changes can auto-approve with full logging. Significant changes go through a documented approval workflow. Emergency changes implement first with retroactive approval captured right after. The approver chain is defined by role, not by individual. When people change roles, the chain updates in one place.
5. Single-click approvals on the ticket. No email threads. The approval, the approver’s identity, and the timestamp are captured on the change record. The audit trail writes itself.
6. Linked Issues. Every change request links to the Issue tickets it addresses. When a patch window remediates six vulnerabilities, those six Issues are linked to the change. The change record, the approval, the linked issues, and the affected assets are one connected dataset, and that dataset feeds the vulnerability reporting FedRAMP now requires.
7. SCN notification generation. Qualifying changes auto-generate notifications with the fields SCN-CSO-INF requires, and each notification window is tracked: the four transformative notifications, the 10-business-day adaptive window. Human-readable and machine-readable versions are produced per SCN-CSO-HRM. The 12-month history required by SCN-CSO-HIS accumulates automatically.
8. Framework attribution on every ticket. Every change ticket is automatically stamped with its FedRAMP controls, KSIs, FedRAMP Rules, and CMMC mappings, scoped to the baselines the system is actually certified against. When an assessor asks which changes touched CM-3, that is a query, not an archaeology project.
9. Change activity generates KSI validation evidence. Closing change requests correctly self-generates dated validation evidence for the change management KSIs. Operating the process produces the proof.
10. SLA enforcement. Pending approvals that age out escalate automatically. Nothing sits in a queue indefinitely.

graph TD
    CT[Change Ticket] --> AP[Approval Record] --> AUDIT[Audit Trail]
    CT --> SIA[Security Impact Analysis]
    CT --> COMP[Affected Components]
    CT --> ISS[Linked Issue Tickets] --> RPT[Vulnerability Reports]
    CT --> SCN[SCN Notification]

    style CT fill:#1a3d5c,stroke:#4ecdc4,color:#fff
    style AP fill:#1a5c3d,stroke:#51cf66,color:#fff
    style AUDIT fill:#1a3d1a,stroke:#a9dc76,color:#fff
    style SIA fill:#5c4a1a,stroke:#ffc857,color:#fff
    style COMP fill:#2b5797,stroke:#5b9bd5,color:#fff
    style ISS fill:#5c1a1a,stroke:#ff6b6b,color:#fff
    style RPT fill:#4a1a5c,stroke:#c77dff,color:#fff
    style SCN fill:#5c1a3d,stroke:#ff6b9d,color:#fff

The throughline: capture data once at intake. The workflow handles routing, notifications, approvals, documentation, and SCN compliance. One process serves CMMC assessors, FedRAMP independent assessors, and 20x KSI validation.

When a CMMC assessor asks for change request tickets with approvals and security impact analysis, the data is there. When a FedRAMP independent assessor asks for SCN categorization evidence and 12 months of notification history, the data is there. When a 20x validation check hits KSI-CMT-RVP for documented change procedures with effectiveness metrics, the data is there.

Compliance is a byproduct of operations, not a separate workstream.

FAQ

This article is part of a 15-part series on the operational disciplines that CMMC, FedRAMP Rev5, and FedRAMP 20x all test. [Read the series overview: Stop Building for Compliance. Build for Operations.]

Revised in July 2026 for the FedRAMP Consolidated Rules for 2026 (released June 24, 2026).