1. Why This Practice Matters
AC.L1‑3.1.2 may look deceptively simple (“limit information‑system access to the types of transactions and functions that authorized users are permitted to execute”), but it is the cornerstone of least‑privilege at Level 2 (Its a Level 1 requirement) If you can’t prove that users can only do what they’re supposed to do, every other safeguard is built on sand. Department of Defense CIO
2. What the Assessor Must See
The CMMC Assessment Guide boils the requirement down to two assessment objectives:
| Objective | What the assessor looks for | Typical evidence |
|---|---|---|
| [a] Define the types of transactions/functions each authorized user (or role) may execute | A documented matrix mapping roles → permitted actions (e.g., “AR Clerk – read/enter invoices only”) | Access‑control policy, role‑based permission matrix, SSP excerpts, screenshots of RBAC configs |
| [b] Limit system access to those defined permissions | Technical enforcement that matches the matrix | ACLs, group memberships, AD/O365 role assignments, log samples showing denied actions |
3. Implementation Roadmap
-
Inventory Roles & Workflows
Interview department leads, map tasks, and group users into roles. -
Build a Permission Matrix
For each role, list CRUD (create‑read‑update‑delete) operations, modules, and administrative functions permitted. -
Configure Technical Controls
Use native RBAC in Windows, Entra ID, SharePoint, ERP, and SaaS platforms. Avoid one‑off “break‑glass” allowances. -
Document & Approve
Capture the matrix in your Access Control Policy; reference it in the SSP. -
Test & Monitor
Run least‑privilege tests: log in as each role and verify you can’t exceed your mandate. Enable auditing of failed access attempts. -
Maintain & Review
Tie role changes to your onboarding/off‑boarding checklist and conduct quarterly permission recertifications.
4. Objective Evidence Tips (from an Assessor’s Notebook)
-
Screenshots ≠ evidence on their own. Pair them with configuration exports or audit logs.
-
Change tickets showing approval of new permissions help satisfy both objectives in one stroke.
-
For cloud apps, CSV exports of role assignments are gold—tag them with the date pulled.
-
Narrative SOPs should reference the exact menu paths or PowerShell cmdlets used, proving the process is real, not theoretical.
5. Common Pitfalls
-
Granting “Company Administrator” to MSP technicians by default. Use just‑in‑time privileged access instead.
-
Relying on file‑share NTFS permissions alone; ignore SaaS & mobile‑app scopes at your peril.
-
Neglecting service accounts and API tokens—yes, they’re users in the assessor’s eyes.
6. Final Takeaways
Implementing AC.L1‑3.1.2 well is about discipline and evidence. Define, enforce, and prove—and you’ll sail through the assessment while strengthening your security posture. Need a sanity check? As a CMMC Certified Assessor and consultant, I’m happy to review your matrices or run a mock interview with your sysadmins.