CMMC 3.1.2 (Least Privilege): Evidence Examples & What Assessors Actually Check

Control: NIST SP 800-171 Rev. 2 §3.1.2 · CMMC Practice: AC.L2-3.1.2 · Updated June 2026

Plain-English answer

3.1.2 says: once a user is authorized, limit them to the transactions and functions they actually need. It's the least-privilege requirement — role-based access, no standing global admin, and no shared "everyone can do everything" buckets.

Who this applies to

Every organization seeking CMMC Level 2. Where 3.1.1 controls the front door, 3.1.2 controls the rooms inside it.

Why it matters

Most data exposure starts with someone having access they didn't need. 3.1.2 is the requirement that forces you to prove "need to use" — not just "approved at hire." It's a 5-point requirement under the DoD Assessment Methodology.

Control lineage

• CMMC Practice: AC.L2-3.1.2
• NIST 800-171 Rev. 2: §3.1.2 — limit system access to the types of transactions and functions that authorized users are permitted to execute.
• NIST 800-171A objectives: [a] types of transactions and functions authorized users are permitted to execute are defined; [b] system access is limited to the defined types of transactions and functions.

What the assessor will EXAMINE

• Role definitions / role-permission matrix mapping job roles to permitted functions.
• Privileged-account inventory: who holds admin, in which system, and why.
• Separation between standard and admin accounts (no daily-driver admin).
• Access-review records showing periodic recertification.
• SSP narrative for 3.1.2 referencing the matrix and review cadence.

What the assessor will INTERVIEW

• "Show me how a sales rep's permissions differ from an engineer's." — point to the role matrix and live group membership.
• "How do admins do day-to-day work?" — separate admin accounts, used only for admin tasks.
• "When did you last review who has elevated rights?" — name the cadence and produce the last review.

What the assessor will TEST

• Attempt a privileged function from a standard account — confirm it's denied.
• Sample privileged users against the role matrix for unjustified elevation.
• Inspect a recent access-review and verify revocations were actually applied.

Evidence examples (produce these)

• Role-to-permission matrix (current, dated within your freshness window).
• Privileged-account inventory with business justification per account.
• Standard vs. admin account naming convention + sample showing both.
• Quarterly access-review records with revocation evidence.
• SSP §3.1.2 referencing the matrix, the review cadence, and the enforcing system.

Platform-specific

• Google Workspace: Admin Roles (delegated admin), Groups for RBAC, and Admin audit log of role grants/revocations.
• Microsoft GCC High / Entra ID: PIM for just-in-time elevation, Entra role assignments, and Access Reviews tied to privileged groups.

Common failure patterns

• Everyone in a domain has the same group membership — no role differentiation.
• Admins use their privileged account for email and browsing — no separation.
• Role matrix exists in a slide deck but doesn't match what the directory actually enforces.
• Access reviews are run but revocations are never applied.

SPRS impact & POA&M

SPRS: not meeting 3.1.2 is a 5-point deduction. POA&M: POA&M eligibility for individual requirements is restricted under CMMC — confirm 3.1.2's eligibility against current rules before assuming it can be deferred.

Assessor-ready summary

You're good on 3.1.2 when there's a documented role-permission matrix, the directory enforces it, admin work uses separate accounts, and recent access reviews show real revocations — all reflected in the SSP.

Map your 3.1.2 evidence the way an assessor reads it. Get a least-privilege evidence map →

Related: 3.1.1 access control · 3.5.3 MFA evidence · Calculate your SPRS score

Athena prepares organizations for CMMC Level 2; certification rests with C3PAOs/DIBCAC. Verify all control facts against NIST SP 800-171 Rev. 2, NIST SP 800-171A, and current CMMC rules.