You’ve got authorized users in your systems. The question isn’t just whether they should be there. It’s what they’re allowed to do once they log in. AC.L2-3.1.2 is about limiting transactions and functions to match job requirements. An accountant shouldn’t delete user accounts. Where AC.L2-3.1.1 controls who gets in, this practice controls what they can do once they’re there. An HR coordinator shouldn’t modify salary records. A contractor shouldn’t have admin rights to your security appliance. This practice separates the “who” question (3.1.1) from the “what” question, and assessors care deeply about the difference.
What the assessor is actually evaluating
Role definitions tied to business functions. For most small contractors, the role structure is simple: admin and everyone else. You might have 1-2 people with Global Admin in Microsoft 365, department-level permissions on SharePoint sites, and standard user for everyone else. That’s fine. The assessor wants to see that you’ve thought about it and documented it, not that you have a complex RBAC hierarchy. A 15-person company doesn’t need “Accounts Payable Clerk Level 2.” It needs “these two people are admins, here’s why, everyone else has standard access.”
Permission assignments match what you documented. You define roles on paper (or in a spreadsheet), then the assessor checks whether Entra ID, Microsoft 365 admin center, and file share ACLs actually reflect those definitions. Ideally, your other business applications (ERP, CRM, accounting) are SSO’d through your identity platform so permissions flow through security groups rather than individual tool configurations. Drift here is a finding.
Least privilege is enforced, not aspirational. Users get the minimum permissions needed to do their job. The assessor will spot “everyone gets admin because we were in a hurry” immediately. They’ll also notice if contractors have the same rights as full-time staff.
Compensating controls exist when separation isn’t possible. In a small shop, sometimes the IT person also handles accounting, or the owner does everything. As long as it’s documented and the risk is acknowledged, this is generally acceptable. The assessor would rather see “we know this is a dual-role situation and here’s how we mitigate it” than pretend the overlap doesn’t exist. Documented risk acceptance with compensating controls (like audit logging on that person’s actions, or supervisor review of their work) is the path.
SSP language that works
The organization maintains a role-based access control matrix that maps job functions to specific system transactions and functions. Security Officer validates this matrix at least quarterly and updates it when roles change. User access in Active Directory, Microsoft 365, SharePoint, and application systems is provisioned to match approved roles only. For example, the Accounts Payable Coordinator role includes read access to expense reports and approval authority up to $25,000, but no access to general ledger, user administration, or system configuration. All user access assignments are documented in the user-role matrix and reviewed against actual directory settings during the annual access review.
How to present your evidence
Role matrix document. Bring a spreadsheet or table that shows each role, the business function it supports, and the permissions that role should have. For most small shops this is straightforward: admins, standard users, maybe a finance group with access to the accounting system. Include system names and permission scopes (read, write, approve, admin).
Security group memberships. Pull a report showing which users belong to which security groups and which resources each group can access. If you’re using Microsoft 365, show admin role assignments in the admin center. If your other business applications are SSO’d through your identity platform, the security group assignments cover those too. The assessor wants to verify that actual assignments match your role matrix.
Evidence of access reviews. Show that someone (name them specifically) reviewed user access at least annually and confirmed it still matches job functions. Include dates and sign-offs.
Compensating control documentation. If a system doesn’t support role-based permissions, document the alternative control (approval workflows, segregation of duties, audit trails). Explain why the control is appropriate.
Common failures
Flat permission model. Everyone has admin rights or broad permissions because granular role setup was seen as too complex. Assessor pulls a user access report and sees excessive privilege across the board.
Role matrix doesn't match reality. You have a nicely documented matrix that says "Finance user has AP module read-only access," but Active Directory shows that user is a member of a group with full AP admin rights. The documents and systems are out of sync.
No documented roles at all. You assign permissions reactively when someone asks. No role definitions, no matrix, no relationship between job function and access. The assessor can't trace the logic for why anyone has what they've got.
Contractors have same access as employees. You've never differentiated contractor scope from employee scope. If a contractor leaves, you can't cleanly revoke access because you didn't set boundaries in the first place.
You hand over a current role matrix tied to job functions. You show Active Directory groups, Azure subscriptions, and application permissions that match the matrix. You provide a signed access review from within the last 12 months confirming alignment. When the assessor spot-checks a specific user or role, the permissions make sense and stay within the stated bounds.
Q&A: What the assessor asks and what good answers sound like
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.
If you use an MSP/MSSP
Your managed service provider typically handles the technical side, like provisioning Active Directory groups, assigning Microsoft 365 admin roles, or applying application permissions. But the role definition and business logic stay with you. You own the role matrix. You decide what Finance-AP can do. You direct the MSP to implement those roles. You perform the access reviews. The MSP can help you pull reports to verify alignment, and that’s worth asking for.
Make sure your MSP contract specifies that they follow your role-based access control policy and that they’ll provide access reports on demand for your annual review. Don’t let them default all new users to high-privilege roles just to save setup time.
This page reflects NIST SP 800-171 Rev 2 requirements and typical CMMC Level 2 assessment practices as of March 2026. Your system security plan and specific control implementation must align with your organization’s security policy, system architecture, and regulatory obligations. Consult your CMMC C3PAO or security officer for guidance on your particular environment.