Change Management Across CMMC, FedRAMP Rev5, and FedRAMP 20x

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]
    C --> IA[Impact Assessment]
    IA --> A[Approval]
    A --> I[Implementation]
    I --> V[Verification]
    V --> L[Logged Record]
    L --> 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. 3-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. 3-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.

With the Rev5 Balance Significant Change Notification (SCN) improvement, change management gains a notification layer. Every change now falls into one of four categories:

1. Routine Recurring: no notification required. Automated patching, scheduled maintenance, standard deployments that follow an approved pattern.
2. Adaptive: notify within 10 business days after completion. Changes that modify the system within existing parameters but are not routine.
3. Transformative: staged notifications with specific timelines. 30 business days before initial plans. 10 business days before final plans. 5 business days after completion. 5 business days after verification. Updated documentation within 30 business days after completion.
4. Impact Categorization: SCN cannot be used. Requires a new assessment entirely.

The key insight: no change type requires pre-approval from the government. SCN replaced the advance-approval model with a notification model. This is a significant shift from how FedRAMP previously handled significant changes.

Notification content is specified by SCN-CSO-INF: FedRAMP ID, assessor name, change type, description, reason, customer impact, plan and timeline, impact analysis, and approver. SCN-CSO-HRM requires notifications in both human-readable and machine-readable formats. SCN-CSO-HIS requires 12 months of historical notifications. SCN-CSO-MAR requires auditable records of how each change was evaluated and categorized.

What 3PAOs 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, and 30-day timelines for transformative changes are not suggestions. They are control parameters.

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-01 (Log and Monitor Changes): log and monitor all modifications to the Cloud Service Offering. Machine-based validation checks that configuration recording is active and comprehensive across the environment. This is the foundation: you cannot manage what you do not track.
• KSI-CMT-02 (Redeployment): execute changes by redeploying version-controlled immutable resources, not by modifying systems in place. Machine-based validation checks for long-running instances that violate the immutable infrastructure pattern and verifies that launch templates show active versioning.
• KSI-CMT-03 (Automated Testing and Validation): automate persistent testing and validation of changes throughout deployment. 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-04 (Change Management Procedures): review the effectiveness of documented change management procedures. Non-machine-based validation reviews the change management policy for completeness, accuracy, currency, and alignment with security requirements.
• KSI-AFR-05 (Significant Change Notifications): manage significant changes through the SCN process. This is the bridge between Rev5 and 20x. SCN is the default change process for 20x, and Rev5 providers can opt in now.

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-04 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?

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-01 runs machine-based validations checking that configuration change recording is active and covers the full environment. KSI-CMT-02 validates immutable infrastructure patterns by checking instance ages and launch template versioning. KSI-CMT-03 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 Rev5 Balance introduced the four-tier 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 3PAOs, and 20x KSI validators from the same data.

5. Structured intake. Every change request starts with required fields: type, affected components (linked to the system’s component inventory), business impact, risk assessment, and rollback plan. No free-text-only tickets. The data is structured at the point of entry because everything downstream depends on it.
6. SCN categorization at intake. The change type and impact assessment drive the SCN category. Routine Recurring, Adaptive, Transformative, or Impact Categorization is set during intake, not decided retroactively. The categorization record satisfies SCN-CSO-MAR.
7. 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.
8. 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.
9. 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.
10. Linked issues and POA&Ms. 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.
11. SCN notification generation. Qualifying changes auto-generate notifications with the fields SCN-CSO-INF requires. Human-readable and machine-readable versions are produced per SCN-CSO-HRM. The 12-month history required by SCN-CSO-HIS accumulates automatically.
12. SLA enforcement. Pending approvals that age out escalate automatically. Nothing sits in a queue indefinitely.

graph TD
    CT[Change Ticket] --> ISS[Linked Issues / POA&Ms]
    CT --> AP[Approval Record]
    CT --> SIA[Security Impact Analysis]
    CT --> COMP[Affected Components]
    CT --> SCN[SCN Notification]
    ISS --> POAM[POA&M Report]
    AP --> AUDIT[Audit Trail]
 
    style CT fill:#1a3d5c,stroke:#4ecdc4,color:#fff
    style ISS fill:#5c1a1a,stroke:#ff6b6b,color:#fff
    style AP fill:#1a5c3d,stroke:#51cf66,color:#fff
    style SIA fill:#5c4a1a,stroke:#ffc857,color:#fff
    style COMP fill:#2b5797,stroke:#5b9bd5,color:#fff
    style SCN fill:#5c1a3d,stroke:#ff6b9d,color:#fff
    style POAM fill:#4a1a5c,stroke:#c77dff,color:#fff
    style AUDIT fill:#1a3d1a,stroke:#a9dc76,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 3PAOs, and 20x KSI validators.

When a CMMC assessor asks for change request tickets with approvals and security impact analysis, the data is there. When a 3PAO asks for SCN categorization evidence and 12 months of notification history, the data is there. When a 20x validator checks KSI-CMT-04 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.]