This practice bridges change management and access control. You have a change process (CM.L2-3.4.3) and you analyze risk (CM.L2-3.4.4). Now you need to ensure that only the right people can actually make the changes, and only after approval. It’s about closing the loop so the process can’t be circumvented. The approval and access restrictions here are fundamentally the same principle that AC.L2-3.1.1 and AC.L2-3.1.2 require for general access control: documented authorization and enforcement.
What the assessor is actually evaluating
The assessor is checking whether your change management process has teeth. Specifically:
Did you define who can approve changes? Not “managers” or “appropriate personnel.” The policy needs to name roles and explain the authority structure. Who approves configuration changes? Who approves security patches? Who can override approval in an emergency?
Did you restrict who can implement changes? Not everyone in IT should have the ability to make changes to CUI systems. In a small shop, you might have one system administrator with full access. But the policy should still define that role and limit access to that person or that role. The restriction doesn’t have to be complex. It just has to exist and be enforced.
Is there a separation between request, approval, and implementation? In the cleanest process, one person requests a change, a different person approves it, and it gets implemented either by a third person or following a documented process. In a small shop, the owner might request and approve, and the admin implements. The point is that the person implementing didn’t decide to implement it on their own.
Do you enforce it? The policy exists. But does it actually work? Can someone bypass it? The assessor will ask questions designed to find that weakness. If the answer is “yes, technically someone could,” you have a problem.
What a realistic SSP definition looks like
[Organization Name] restricts the ability to make changes to systems within the CUI boundary to authorized personnel. Changes to these systems require documented approval before implementation. The approval authority is defined by change type: routine patches and updates are approved by the Systems Administrator; configuration changes and security-related changes are approved by the IT Director; and emergency changes are approved by the IT Director or, if unavailable, the Organization Owner.
Access to systems for the purpose of making changes is restricted to the Systems Administrator and IT Director through role-based access controls, password protection, and multi-factor authentication where available. Physical access to systems is restricted to authorized personnel and documented in the facility access log. Implementation of approved changes is performed only by authorized personnel following the approved change request.
The organization reviews access permissions on a quarterly basis to ensure they remain appropriate to job function.
Key details:
It names the approval authorities. Not generic. The Systems Administrator for certain changes. The IT Director for others. Owner for emergencies. When the assessor asks who approved a specific change, the answer is traceable to the policy.
It describes how access is restricted. Role-based access controls, password protection, MFA. These are technical controls that actually prevent someone without authorization from making changes. The fact that they’re documented means the assessor can verify they exist.
It covers physical access if relevant. If changes require walking into a server room or physically interacting with hardware, you need a process for that too. Who has key card access? Who’s logged in the facility access log? This doesn’t have to be complex. It just has to be defined and enforced.
It includes a review schedule. The access list for who can make changes isn’t set and forgotten. You review it quarterly to make sure people still need that authority.
How to present your evidence
- Change management policy defining approval authorities by change type
- Access control list showing who has administrative rights to CUI systems
- System logs or ticket records showing changes were approved before implementation
- Role definitions and authorized personnel by role
- Physical access logs if physical access is required for changes
- Quarterly reviews of access permissions
When the assessor gets to CM.L2-3.4.5:
Your change management policy. It should explicitly define who approves what type of change. Pull it up and be able to walk through it. When the assessor asks “who approved this change,” you point to a section of your policy that says exactly who could have done it.
Access control list. Who has administrative access to CUI systems? Pull a list. It might come from your identity provider, your domain controller, your server console, or your MSP’s documentation. The point is that you have a documented list and can show it to the assessor.
Examples showing approvals were enforced. Pick a few changes from your log. Show that an authorized person approved them before they were implemented. The ticket system should show the approval step, or there should be an email chain, or a signed off form. Something that proves the process was followed.
Role definitions. If your policy says “the Systems Administrator,” who is that? A one-page document explaining roles is often enough. “Systems Administrator: John Smith, responsible for day-to-day infrastructure management” and so on.
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
Too many people with admin rights.** Everyone in IT can make changes. The approval process exists, but it's not enforced technically. An unauthorized person could implement a change and get caught only if someone reviews the logs later. The assessor will ask how you prevent unauthorized changes and won't be satisfied with "we trust people to follow the process."
No defined approval authorities.** The policy says "changes require approval" but doesn't say who approves. Is it the owner? The IT Director? Both? The assessor will ask "who approved this change" and get different answers for different changes.
Approval came after implementation.** The change was made, then someone approved it retroactively. That's not access restriction. That's just documentation.
Physical access not controlled.** If access to systems requires physical presence, there should be a process. Keycard logs, visitor logs, something showing who was in the server room. If not, the assessor will flag that changes could have been made by anyone with physical access.
Clear policy defining who approves what. A tight access control list limiting who can make changes. Tickets showing approval before implementation. Role definitions with named people. When the assessor can trace a change from request to approval to implementation and every step shows the right person did the right thing at the right time, 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 makes changes on your behalf, your access restriction policy needs to account for that. The MSP staff have administrative rights to your systems. That’s expected. But you need to define it.
A good approach is this:
Define the MSP’s authority. Your policy should say something like “the MSP’s Systems Administrator is authorized to implement approved changes to [specific systems or system categories].” Name the person or the MSP team role explicitly, if possible.
Require change requests. Even if the MSP proposes the change, it should go through your approval process. The MSP might have a ticketing system. You should have a process on your end that reviews their proposal and approves it before they implement.
Maintain your own access control list. You should document who at the MSP has access to your CUI systems. Ask them for a list. Include it in your evidence for the assessor.
Verify implementation. The MSP implements the change, but you or the MSP provides verification that it was completed as intended. That closes the loop.
The best MSPs have tiered access. Not everyone in the organization has full admin rights. A junior technician might have rights to patch a specific set of servers but not to change security settings. The access is narrowed to what's needed. If your MSP has that kind of structure documented, ask for it. It's worth including in your evidence because it shows they take access restriction seriously.
This page covers CM.L2-3.4.5 from NIST SP 800-171 Rev 2 (3.4.5). 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.