This practice is the enforcement side of the access control story. AC.L2-3.1.1 establishes who has access. AC.L2-3.1.5 limits them to what they need. AC.L2-3.1.6 makes admins use separate accounts. AC.L2-3.1.7 ties a bow on all of it: only the right people can do admin things, and when they do, there’s a record. For most small contractors using cloud-based identity and modern endpoint management, the technical controls are already in place. The gap is usually in knowing how to show the assessor that they work. This practice also depends on AU.L2-3.3.1 (audit logging) to capture the evidence of privileged actions.
What the assessor is actually evaluating
Two things. First: are non-privileged users actually prevented from performing privileged functions? If a standard user sits down at their workstation and tries to install software, change a firewall rule, or modify a security policy, does the system stop them? The assessor isn’t asking whether your policy says they can’t. They’re asking whether the technology enforces it.
Second: when privileged functions are executed by authorized users, is there a log? Can you show who did what, when, and from where? This connects directly to the Audit and Accountability family (AU.L2-3.3.1 and AU.L2-3.3.2), but the assessor may ask about it here under AC as well.
In practical terms, the assessor will probably ask you to show them the role assignments in your identity provider. Who has admin roles? Then they’ll ask to see what happens when a standard user tries to do something administrative. And then they’ll ask to see the audit log for a recent privileged action. Three steps: who can, who can’t, and where’s the proof.
What a realistic SSP definition looks like
[Organization Name] restricts the execution of privileged functions to authorized personnel using designated privileged accounts. Standard user accounts are configured without administrative rights on endpoints and without elevated roles in cloud management portals.
Privileged functions include: account creation and deletion, security configuration changes, software installation, access permission modifications, audit log management, and firewall rule changes. These functions are restricted to accounts with assigned administrative roles in [identity platform] and local administrator rights where required.
All privileged function executions are captured in audit logs through [identity platform] sign-in and audit logs, endpoint event logs forwarded to [SIEM/log aggregator], and administrative portal activity logs. Logs are retained for at least [retention period] and reviewed [frequency] by [designated reviewer].
Key things in that language:
It defines what “privileged functions” means in your environment. The list of actions (account creation, config changes, software install, etc.) tells the assessor you’ve identified what matters. Without this list, “privileged functions” is just a phrase from NIST that you’ve echoed back.
It specifies how the restriction works. Standard accounts lack admin rights on endpoints and don’t have elevated roles in cloud portals. That’s a technical control, not a policy control. The assessor can verify it.
It connects to audit logging. The execution of privileged functions gets captured in specific log sources. The assessor can ask to see those logs and verify the capture is happening.
How to present your evidence
- Role assignments in identity provider showing who has admin roles
- Endpoint configuration showing standard users lack local admin rights
- Audit logs capturing a recent privileged action (account creation, config change, etc.)
- Policy or technical control preventing standard users from installing software
- Log retention and review evidence
Start with your identity provider role assignments. Show the assessor exactly who has admin roles and that standard users don’t. This is usually a quick screen share: pull up the role assignments page, point to the admin roles, show that standard users aren’t in them.
Then show the endpoint side. Pull up your endpoint management platform and show the policy that removes local admin rights from standard user workstations. If a standard user tries to install software, they get prompted for admin credentials they don’t have.
Finally, show a log. Pick a recent privileged action, something like an account creation or a configuration change, and show the assessor the audit log entry. It should show who performed the action, when, and from what account. If your MSSP reviews these logs, have them ready to explain the review process.
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
Standard users with local admin rights. This is the most common finding. The workstation was set up and the user was made a local admin "for convenience." Maybe they needed to install a printer driver once and nobody removed the rights afterward. The assessor will check.
No audit trail for privileged actions. Admin functions are properly restricted, but when an admin makes a change, it's not logged anywhere the organization can access or review. Having the restriction without the logging means you've only met half the practice.
Privileged functions not defined. The SSP says "privileged functions are restricted" but doesn't define what those functions are. The assessor will ask "what do you consider a privileged function?" If you can't answer specifically, that reveals a fundamental gap in your understanding of your own controls.
Clear role assignments showing who can and can't perform admin functions. Technical enforcement on endpoints (no local admin for standard users). Audit logs that capture privileged actions with enough detail to show who, what, and when. A defined list of what you consider privileged functions. When the restriction is technical and the logging is real, this practice is straightforward to pass.
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
Your MSP likely performs most of the privileged functions in your environment. Account creation, configuration changes, security policy updates. The assessor knows this and will want to understand two things: how the MSP’s access is scoped, and how their privileged actions are logged.
The MSP should be able to show that their personnel with admin access to your environment are limited to the people who need it. Not every help desk technician should have global admin. The engineers and security team have admin roles. Help desk has scoped access appropriate to their function. This ties back to AC.L2-3.1.5 and the user-admin matrix.
For logging, the MSP should be able to demonstrate that every administrative action they take in your environment is captured. Most cloud platforms do this automatically, but the MSP needs to know where those logs are and how to show them to the assessor.
The MSSP should be in the room for this practice. The assessor will likely ask the MSP engineer directly: “Show me a privileged action you performed recently and the log entry for it.” That’s a question the MSP should answer, not the contractor.
Assessors expect to see technical enforcement, not just written policies. Have your endpoint management policy ready showing standard users don't have local admin rights. Have your audit logs ready showing a privileged action with full context (who, what, when). The assessor will ask to see both the prevention side (how you stop unauthorized access) and the detection side (how you log what does happen). Both matter.
Your MSP should be able to produce, on the spot, audit log entries for their own administrative actions in your environment. If they can't pull up a log showing what their engineers changed, when they changed it, and which account they used, that's a visibility gap you need to address. The assessor will ask for this. The best MSSPs I've worked alongside have this ready before the question is even asked.
This page covers AC.L2-3.1.7 from NIST SP 800-171 Rev 2 (3.1.7). 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.