This is where configuration management stops being theoretical and becomes a real operational requirement. CM.L2-3.4.3 is about control. Not about tools. You need proof that changes to systems touching CUI don’t happen by accident, and that someone human reviewed them first. Related practices CM.L2-3.4.4 analyzes the security impact of changes, and CM.L2-3.4.5 controls who can make those changes. Change management also feeds into AC.L2-3.1.1, which requires that access decisions be documented and approved. Every change that affects access or configuration needs the same rigor.
What the assessor is actually evaluating
When the assessor asks about change management, they’re checking three things.
Did the change go through a defined process? Not “it was a small thing” or “I just did it on my own system.” The NIST language says track and review. In the assessment room, that means you have a process, and changes go through it. It doesn’t have to be complicated. A ticketing system works. An email approval chain works. A change log spreadsheet with sign-offs works. What doesn’t work is claiming a change was made and happening to know about it because you were the one who did it.
Was the change documented before it was implemented? The assessor wants to see that the change was described, reviewed, and approved before anything happened. After-the-fact documentation feels like covering your tracks. The timestamp matters.
Can you show what actually changed? This is where small contractors struggle. You can point to an approved change request. But can you prove that the change was actually implemented as described? Did the patch get installed? Did the configuration actually change? Did someone verify it? If you can’t show that the approved change made it into production, you haven’t closed the loop.
What a realistic SSP definition looks like
[Organization Name] implements a change management process for all systems within the CUI boundary. Changes include hardware updates, software patches, configuration modifications, and system upgrades. All changes are initiated through a ticketing system [or documented change log] that captures the change description, the business justification, the intended implementation date, and a unique identifier.
Prior to implementation, all changes are reviewed and approved by the Systems Administrator or IT Director for technical feasibility and risk. Changes are categorized as emergency or standard based on business impact. Standard changes require approval at least 24 hours prior to implementation. Emergency changes are approved immediately and documented retroactively within 24 hours.
After implementation, the change requestor or Systems Administrator verifies that the change was completed as intended and documents verification in the change record. All change records are retained for audit purposes.
A few things worth noticing:
The process names who approves changes. “Systems Administrator or IT Director,” not “management” or “the appropriate person.” The assessor wants to know there’s a real person responsible and identifiable.
It addresses both standard and emergency changes. Pure change control shops require pre-approval for everything. Realistic environments need to handle emergencies. Your SSP should define how emergencies are handled. If you say you can approve them retroactively, say so. Just make sure you actually do it.
It requires verification. The change is approved. Then it’s implemented. Then someone verifies that it actually happened and documents it. That third step is what separates a real process from a checklist.
How to present your evidence
- Change management process document or policy
- Change log or ticketing system records showing at least 5-10 recent changes
- Evidence of pre-implementation approval (signed change requests, ticket approvals, email chains)
- Implementation records showing changes were completed
- Verification records (test results, configuration confirmation, deployment logs)
Have these ready when the assessor gets to CM.L2-3.4.3.
Your change management process. One document. States what requires a change request, who approves them, timeline, emergency procedures, verification requirements. One to two pages max.
A populated change log. Real changes. Not made-up ones. The assessor will ask about specific entries, and if you have to make them up, you’re failing. Pull the last six months of actual changes from your ticketing system, your MSP records, or your change log.
Approval evidence. When the assessor picks a change from the log and asks who approved it, you need to show them. That’s an email, a ticket status change with a timestamp, a signature on a form. The point is to prove it wasn’t just you deciding to do something.
Implementation proof. For patching, this might be a deployment report or a screenshot from your patch management tool. For configuration changes, it might be a before-and-after screenshot. For hardware, it might be a photo and an invoice. The bar is not high. You just need to show that the change actually happened.
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
Common failures
No formal change process.** "We track changes informally" or "we just know what gets done." The assessor will ask for your change log. If it doesn't exist, that's a finding. If it does exist but it's unorganized email or Slack messages without timestamps, that's not sufficient.
Changes approved after implementation.** You made the change, then filled out the request. That's not review before implementation. It's documentation after the fact. The timestamp on the change request has to come before the timestamp of the implementation.
No verification step.** You have the request and approval. But nothing showing that the change actually happened or was verified. If you can't prove the implementation succeeded, the assessor assumes it either didn't happen or happened differently than planned.
No distinction between who requests, approves, and implements.** For larger orgs, separation of duties matters. For small shops, one person can do multiple roles. But the SSP needs to be clear about who did what. If you have only one IT person doing everything, say that. Just don't make the assessor guess.
A clear process. Real change records with timestamps. Approval before implementation. Verification that changes happened. When the assessor picks a random change from your log and can trace it from request to approval to implementation to verification, with all the dates making sense, they check the box and move on.
Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.
If you use an MSP/MSSP
If your MSP handles systems administration or patching, they’re probably making changes on your behalf. The key question is whether you’re controlling the process or just reacting to it.
The best setup is this. Your MSP proposes changes. You review and approve them. Then they implement. You verify. You own the change management process. The MSP executes it.
In practice, this often looks like a ticketing system where:
- You open a ticket for the change request or the MSP does and you approve it.
- The MSP documents what they’re going to do.
- You approve before the implementation date.
- The MSP implements and documents the result.
- You review the verification and close the ticket.
Some MSSPs have their own change management system. If they do, ask them to export your change log. You need to be able to show it to the assessor.
The most common recurring change is monthly patches. Your MSP probably patches on a schedule. Make sure you have a change record for each patch cycle, even if it's a summary entry like "monthly Windows patches applied to servers 01-05." The CMMC standard doesn't say every individual patch needs its own ticket, but you need evidence that patching is a tracked activity. A summary record with a monthly verification is sufficient.
This page covers CM.L2-3.4.3 from NIST SP 800-171 Rev 2 (3.4.3). The guidance here is based on experience in real CMMC assessments and is intended to help you prepare. It is not legal or compliance advice. Your organization’s situation is unique, and you should work with qualified professionals for formal assessment preparation.