This is the first practice in the Access Control family and one of the most foundational controls in the entire assessment. It’s also one of the most commonly botched. The implementation isn’t hard. The problem is that small contractors rarely think about access in the structured way the assessor expects. Once you’ve established who gets in, AC.L2-3.1.2 controls what they can do, and AC.L2-3.1.5 ensures they have only the minimum permissions needed. Strong access control is also prerequisite to effective IA.L2-3.5.1 (user identification) and AU.L2-3.3.1 (audit logging), since you need to know who accessed what before you can log it or authenticate it.
What the assessor is actually evaluating
The NIST language says “limit information system access to authorized users, processes acting on behalf of authorized users, and devices (including other information systems).” In the assessment room, that translates to three things:
Do you know who has access? Not “we have Active Directory.” Can you produce a list of every person with access to systems that touch CUI, what level of access they have, and why? The assessor wants to see that you’ve thought about this, not that you have a tool that could theoretically answer the question.
Is access based on something deliberate? The assessor is checking whether people have access because someone decided they should, or because they got it when they were onboarded and nobody ever revisited it. In a 15-person company where the owner set up everyone’s accounts three years ago, this is a real question.
Do you review it? This is where most people trip. Access controls exist, sure. But who checks that the person who left six months ago doesn’t still have a mailbox? Who reviews whether the admin assistant still needs access to the engineering file share? The assessor will ask, and “we handle it as things come up” is not an answer.
What a realistic SSP definition looks like
Here’s an example of what this looks like in an SSP for a small contractor. Don’t copy-paste this. Read it, understand why each sentence is there, and write your own.
[Organization Name] limits access to information systems within the CUI boundary to authorized personnel, service accounts, and managed devices. Access is provisioned through [identity platform, e.g. Microsoft Entra ID / on-premises Active Directory] using role-based assignments tied to job function.
New user access is requested by the employee's manager and approved by the IT Director prior to provisioning. Access rights are reviewed at least quarterly by the IT Director against a current roster of active employees and their job functions. Terminated employees are disabled within 24 hours of separation per our offboarding checklist. Service accounts are documented in the system inventory and reviewed at least semiannually.
Device access is limited to organization-managed endpoints enrolled in [MDM solution]. Personal devices are not permitted to access CUI systems.
A few things worth noticing about that language:
It names who does the reviews. “The IT Director,” not “management” or “appropriate personnel.” The assessor wants to know there’s a real human responsible.
It defines the frequency with “at least.” “At least quarterly” and “at least semiannually,” not “periodically” or “regularly.” Vague frequency is the easiest thing for an assessor to push on. The “at least” matters: if your SSP says “quarterly” and you happen to do it five times in a year, you’re technically non-compliant with your own policy. “At least quarterly” means you can always do it more often without creating a finding.
It covers the edge cases. Terminated employees, service accounts, device restrictions. These are the follow-up questions that catch people off guard. If your SSP already addresses them, the assessor often won’t bother digging deeper.
How to present your evidence
- Current user access list with roles and access levels
- Access review records with dates and sign-offs
- Onboarding/offboarding checklist showing approval workflow
- Service account inventory with documented purposes
- Proof of periodic reviews (quarterly or semiannual)
When the assessor gets to AC.L2-3.1.1, have these ready:
A current user access list. Every account with access to systems in your CUI boundary, their role, and their access level. Pull this from your identity provider. Bonus points if it includes the date access was last reviewed.
Access review records. Evidence that someone actually looked at the list and confirmed it was still correct. This can be as simple as a dated email from the IT Director saying “reviewed user access list, no changes needed” or a signed spreadsheet. Fancy GRC tools are nice but not required.
Your onboarding/offboarding checklist. Shows the process for granting and revoking access. The assessor wants to see that it’s a defined process, not ad hoc.
Common failures
"We use Active Directory, so access is controlled." Having AD isn't the same as having an access control program. The assessor wants to see the process around it. Who approves access? Who reviews it? How often?
No evidence of access reviews. This is the single biggest gap I see. The access controls are fine. The reviews just don't happen, or they happen informally and nobody documents them. If you can't show a dated record of someone reviewing the access list, expect a finding.
Stale accounts. Nothing makes an assessor dig deeper faster than pulling up your user list and seeing accounts for people who left the company months ago. Doesn't matter how good your policy is. If the evidence contradicts it, you have a problem.
Vague SSP language. "Access is reviewed periodically by management." Which management? How periodically? The assessor will ask, and if the answer doesn't match what's written, it creates doubt about everything else in your SSP.
A specific person who owns the process and can talk about it. Dated evidence of reviews. Clean user lists with no stale accounts. An SSP that matches what you actually do. When all of that lines up, the assessor checks the box and moves on.
AC is typically assessed first and it's the hardest domain. A strong start here sets the tone for everything that follows. Assessors want to see the identity provider live. Pull up Azure or AD and show privileged users, non-privileged users, and service accounts side by side. Clear naming conventions help tremendously. Consistent prefixes (like "SVC." for service accounts or "ADM." for administrative accounts) make it immediately obvious what each account is for, and assessors appreciate the clarity.
If you use an MSP/MSSP
If your MSP manages your identity platform, the assessor will want to understand who actually controls access decisions.
The answer needs to be clear: your organization decides who gets access. The MSP provisions it. If your MSP is making access decisions without your approval, adding users, granting permissions, that’s a problem. The assessor will ask who authorized it and “our MSP just set it up” isn’t going to work.
Here’s what the split usually looks like:
What’s typically on you (the contractor):
- Deciding who needs access and at what level
- Approving new access requests
- Conducting or initiating access reviews
- Notifying the MSP when someone leaves or changes roles
What’s typically on the MSP:
- Provisioning and deprovisioning accounts per your instructions
- Maintaining the identity platform
- Providing user access reports for your reviews
- Enforcing technical controls (MFA, conditional access policies)
When the assessor asks about this, the worst answer is ambiguity. The best answer is a responsibility matrix, even a simple table, that shows who does what. If your MSP can provide one, ask for it. If they can’t, write one yourself and get them to sign off on it.
The best MSSPs I've worked alongside actually do the access review themselves and present it to the contractor for sign-off. They pull the list, flag anything unusual, and hand you a report that says "here's who has access, here's what changed since last quarter, here's what we recommend." If your MSP isn't doing something like this, ask for it. Or do the review yourself with their reports as input.
Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.
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.
Q&A: What the assessor asks
This page covers AC.L2-3.1.1 from NIST SP 800-171 Rev 2 (3.1.1). 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.