Least privilege sounds simple. Give people what they need, nothing more. In practice it’s one of the most consistently messy controls in small organizations because permissions only ever expand. People accumulate access over time and nobody has a reason to clean it up until an assessor starts asking questions.
What the assessor is actually evaluating
The NIST language says “employ the principle of least privilege, including for specific security functions and privileged accounts.” In the assessment room, the assessor is checking three things:
Are people’s permissions scoped to their actual job? Not “does everyone have an account.” Does the person in shipping have access to the engineering file share? Does the marketing contractor have write access to the finance directory? In a 20-person company where the owner set up permissions five years ago, the honest answer is usually “we’re not sure anymore.” The assessor knows this. What they want to see is that you’ve gone through it, cleaned it up, and have a process to keep it that way.
Are privileged accounts separate from daily-use accounts? If your IT person logs into their email, browses the web, and manages Active Directory all from the same account, that’s a problem. The assessor wants to see that admin-level access lives in a separate account that only gets used when admin tasks are required. This applies to anyone with elevated permissions. IT staff, MSP technicians, anyone with global admin or domain admin rights.
Do you actively manage this, or did you set it and forget it? Permissions in a small company have a way of only ever growing. Someone needs access to a project folder, they get added, the project ends, and the access stays. Multiply that across every employee and every role change over several years and you end up with everyone having access to nearly everything. The assessor will check whether you have a process to catch and fix this.
What a realistic SSP definition looks like
Here’s an example of what this looks like in an SSP for a small contractor. Read it, understand the reasoning behind each sentence, and write your own version that matches what you actually do.
[Organization Name] implements least privilege through role-based access assignments in [identity platform, e.g. Microsoft Entra ID / Active Directory]. Access to systems and data within the CUI boundary is assigned based on job function using security groups that map to defined roles.
Privileged accounts (domain admin, global admin, and service-specific admin roles) are maintained as separate accounts from standard user accounts. Personnel requiring privileged access are issued a dedicated admin account used exclusively for administrative tasks. Standard accounts are used for daily operations including email, web browsing, and document work.
Access assignments are reviewed [frequency, e.g. quarterly] by the IT Director against current job functions. When personnel change roles, a ticket is submitted to IT documenting the role change, what access is no longer needed, and what new access is required. The IT Director adjusts permissions based on the role-to-permission matrix and documents the changes in the ticket. Access that is no longer required is removed at the time of the role change, not deferred to the next scheduled review.
Shared accounts are not permitted within the CUI boundary. All access to systems that store, process, or transmit CUI is performed through individually assigned accounts with unique credentials.
A few things to notice:
It addresses privileged accounts specifically. The assessor will absolutely ask about admin accounts. If your SSP already explains how they’re separated, you’ve preempted the question.
Role changes are tracked through tickets. Not an email. Not a conversation in the hallway. A ticket that documents what changed, what access was adjusted, and who did it. That’s your evidence. “Their manager notifies IT” doesn’t hold up if there’s no record of the notification or what was done about it.
Shared accounts don’t exist in the CUI boundary. Period. Not “we have a few but they’re documented and restricted.” Not “it’s just the conference room PC.” If an account touches anything in scope, it needs to be individually assigned. More on this below.
How to present your evidence
When the assessor gets to AC.L2-3.1.5, have these ready:
A user-admin matrix. This is the single strongest piece of evidence for this practice. Every account in the CUI boundary, including service accounts, listed with what that account has access to and why. Roles down the left, systems and permissions across the top. Keep it current. Define a review schedule (quarterly, monthly, whatever works for your organization) and actually follow it. Date the reviews. The matrix itself plus the dated review records together tell the assessor that someone owns this process and it runs on a schedule.
Separate admin account documentation. A list of who has privileged accounts, what those accounts can do, and evidence that they’re separate from daily-use accounts. If your IT person has jsmith for daily work and jsmith-admin for AD management, show that.
Role change tickets. When someone moved to a different position, there should be a ticket showing what was requested, what permissions were added, what permissions were removed, and who executed the change. If you don’t have these, start now. The assessor will ask what happens when someone changes roles, and “we handle it” isn’t an answer. A ticket trail is.
Access review records. Dated evidence that someone reviewed the matrix on the schedule you defined. What was reviewed, what was found, what was changed. Consistency matters here. If your SSP says quarterly and you missed a quarter, the assessor will notice.
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.
That last one is important. The assessor isn’t just checking a box with that question. They’re gauging how seriously you take access control as a whole. If you start explaining why you need a shared login for the conference room projector, you’re telling the assessor that convenience won sometimes. Even if you could technically justify it, it casts doubt on everything else you’ve presented. Do it right and the rest of the assessment gets easier. Cut corners here and the assessor will look harder at everything.
Common failures
"Everyone has admin because it's a small company." This is the most common version of this failure and the hardest to undo quickly. The reasoning is always the same: "It's just easier if everyone can install software and make changes." The assessor has heard it before. It's not a passing answer. You need to show that you've actually scoped permissions to job function, even if it meant some people lost access they were used to having.
Privilege creep with no review process. People accumulate permissions over years of role changes, project assignments, and one-off requests. Nobody ever removes anything because there's no process to catch it. The assessor will look at your user permissions and if the receptionist has write access to the engineering file share, they're going to ask why.
"But they need that access to do their job." Sometimes people genuinely believe they need admin rights or broad permissions because that's how they've always done things. Usually there's a better way. A specific security group, a delegated permission, a process that doesn't require them to have the keys to everything. "They said they need it" is not a justification the assessor will accept. You need to show that you've evaluated whether the access is actually required for their role, and if the answer is "there's a better way to accomplish what they need without giving them admin," then that's the answer.
IT staff using admin accounts for everything. Your sysadmin checking email, browsing the web, and managing Group Policy from the same domain admin account. This is a finding. Separate accounts are not optional.
Shared accounts in the CUI boundary. There is no acceptable reason for a shared account on any system that touches CUI. The conference room PC that everyone logs into with the same password. The generic "front desk" account. The parking validation computer with a sticky note. If it's in scope, every user gets their own account. If you can't make that work for a particular system, that system needs to be out of scope. Shared accounts undermine the entire concept of individual accountability, and that's what access control is built on.
Role changes handled informally. Someone changed positions six months ago. Their manager told IT about it in the break room. Maybe IT adjusted the permissions, maybe they didn't. There's no record either way. When the assessor asks how role changes are handled, "we just take care of it" isn't going to work. A ticket with a documented trail of what changed is what they want to see.
A user-admin matrix that covers every account in the CUI boundary, including service accounts, with documented review records on a defined schedule. Separate admin accounts for anyone with elevated access. Role change tickets showing the process actually works. No shared accounts anywhere in scope. When the matrix, the tickets, and the live environment all tell the same story, this practice closes fast.
If you use an MSP/MSSP
Least privilege gets interesting when your MSP has access to your environment. The assessor will want to know what level of access the MSP has and why.
Here’s the thing: not every MSP technician needs global admin to your tenant. Only one or two people on the MSP side should have global admin, typically the primary network administrators or security engineers who are responsible for your environment at that level. Everyone else gets scoped to their role. Help desk techs get help desk permissions. SOC analysts get security reader and response permissions. Whoever manages your backups gets backup admin. The same least privilege rules that apply to your own staff apply to your MSP’s staff. “All of our MSP’s techs have global admin” is a problem.
The assessor may ask specifically about MSP access. The answer should be clear: your MSP has documented access at defined levels, the access is scoped by role just like your internal accounts, and you have visibility into what permissions they hold. If your MSP can’t provide a list of what access their people have to your environment, that’s not just an assessment problem. That’s a problem, full stop. Whether you need CMMC or not, you should know who has the keys to your systems and why.
Here’s what the split usually looks like:
What’s typically on you (the contractor):
- Defining what roles in your organization need what access
- Approving access requests, including for MSP personnel
- Conducting or reviewing the access matrix on your defined schedule
- Reporting role changes to the MSP so access can be adjusted
What’s typically on the MSP:
- Provisioning access based on your role definitions
- Maintaining separate privileged accounts for their technicians
- Providing access reports for your review
- Implementing technical controls (conditional access, Privileged Identity Management, etc.)
The best MSSPs I've worked alongside use just-in-time access (PIM) for their access to client environments. Their technicians don't have standing admin rights to your tenant. They request elevated access when they need it, it's logged, and it expires automatically. On top of that, they maintain their own user-admin matrix for each customer environment, documenting exactly who on their side has what access and why. That's the kind of evidence that makes an assessor confident the MSP relationship is managed properly. If your MSP is running standing global admin accounts in your tenant around the clock, ask them about PIM. It matters for your assessment, and it matters for your security.
This page covers AC.L2-3.1.5 from NIST SP 800-171 Rev 2 (3.1.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.