CMMC Level 2 Practice 3.1.2: Limit system access to the types of transactions and functions that authorized users are

CMMC Level 2 Practice 3.1.2 requires you to restrict what each authorized user can do in your CUI environment by limiting access to specific transactions and functions based on their role and job needs (NIST SP 800-171 Rev. 2). Operationalize it by defining role-based access, enforcing it in systems (not just policy), and keeping auditable evidence of permissions, approvals, and periodic reviews.

Key takeaways:

• Define “who can do what” at the function/transaction level, not just “who can log in” (NIST SP 800-171 Rev. 2).
• Enforce least privilege through RBAC/ABAC, separation of duties, and privileged access controls in the CUI boundary (NIST SP 800-171 Rev. 2).
• Keep evidence that shows design and operation: role matrices, access changes, reviews, and exceptions with approvals (NIST SP 800-171 Rev. 2).

This practice is the difference between authentication and authorization. Many organizations can prove users authenticate with MFA and have accounts, but they struggle to prove users are constrained to the exact business functions they are supposed to perform. CMMC Level 2 Practice 3.1.2, mapped to NIST SP 800-171 Rev. 2 control 3.1.2, expects you to implement least privilege at the transaction/function layer: what actions a user can execute inside applications, databases, infrastructure consoles, and administrative tools (NIST SP 800-171 Rev. 2).

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat 3.1.2 as an “authorization control” with three moving parts: (1) a role/function model tied to job duties, (2) technical enforcement in the systems that store/process/transmit CUI, and (3) repeatable operations and evidence (joiner/mover/leaver, periodic access reviews, and exception handling).

This page gives you requirement-level implementation guidance you can hand to IT, IAM, and application owners and then audit internally the same way a CMMC assessor will. It also includes a practical execution plan and an evidence bundle you can standardize across systems.

Regulatory text

Requirement (excerpt): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.1.2 (Limit system access to the types of transactions and functions that authorized users are).” (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance; 32 CFR Part 170)

Operator interpretation: You must ensure that authenticated users can only perform the transactions and functions that match their authorization. “Authorized” is not a verbal assurance or an org chart. It must be implemented as enforced permissions (e.g., roles, entitlements, ACLs, administrative rights) inside the systems in your CUI boundary (NIST SP 800-171 Rev. 2).

---

Plain-English interpretation (what the assessor will look for)

What this means in practice:

• A user with a valid account should still be blocked from actions outside their job duties.
• “Transactions and functions” include: creating/deleting records, exporting data, changing security settings, creating new users, modifying logs, approving payments, pushing code to production, or administering backups.
• The control is met when you can show: defined authorization rules + technical enforcement + ongoing review and correction (NIST SP 800-171 Rev. 2).

Common boundary question: This applies to the CUI environment (the systems, networks, and services that store, process, or transmit CUI, including supporting components you rely on for security). CMMC’s program requirements live in the CMMC rule and program guidance (32 CFR Part 170; DoD CMMC Program Guidance).

---

Who it applies to (entity and operational context)

Entity types: Defense contractors and federal contractors handling CUI under CMMC Level 2 expectations (32 CFR Part 170; DoD CMMC Program Guidance).

Operational scope:

• Systems in the CUI boundary: identity provider, endpoints, file shares, collaboration tools, ticketing, ERP/MRP, engineering systems, code repositories, cloud consoles, SIEM/log platforms, backup systems.
• People: employees, contractors, and administrators with any access path into the CUI boundary.
• Third parties: managed service providers or SaaS providers can be in-scope if they administer or host parts of the CUI environment. You still need to ensure authorization is constrained (NIST SP 800-171 Rev. 2).

---

What you actually need to do (step-by-step)

Use this as a runbook your control owner can execute and evidence.

1) Define the “transaction/function” model for each in-scope system

Deliverable: a system-by-system authorization map.

• Identify the in-scope applications and platforms that handle CUI.
• For each system, list the high-risk functions. Start with: export/share, user admin, permission changes, security configuration, data deletion, bulk download, API token creation, disabling logs.
• Group functions into roles (RBAC) or attributes (ABAC) aligned to job duties.

Operator tip: If an application is too complex for a clean role model, define “baseline roles” (reader, contributor, approver, admin) and document exceptions with compensating controls.

2) Build a role-to-job mapping (least privilege + separation of duties)

Deliverable: Role Catalog + Role-to-Job Matrix.

• Create a short list of standard roles per system.
• Map each role to job titles/teams and define allowed functions.
• Implement separation of duties where a single role would create abuse risk (e.g., “can create users” and “can approve access” should not be the same person for high-privilege systems).

3) Implement enforcement in the identity and application layers

Deliverable: Technical configuration that matches the role model.

• Configure roles/groups in the IdP and/or within the application.
• Remove shared accounts and ad hoc permissions where feasible; move to groups.
• Restrict privileged actions through a dedicated admin role and, where possible, a separate admin account.

Minimum expectation: “Policy says least privilege” is not enough. Enforcement must exist in the systems (NIST SP 800-171 Rev. 2).

4) Operationalize joiner/mover/leaver (JML) with approvals

Deliverable: an access request and provisioning workflow.

• Require a ticket/work item for access grants and changes.
• Require manager and system owner approval for non-standard access.
• Implement time-bound access for elevated rights (where feasible), with documented expiration and removal.

5) Run recurring access reviews and remediate

Deliverable: periodic access review records + remediation tickets.

• Have system owners attest that user-to-role assignments remain appropriate.
• Review privileged roles separately and more rigorously.
• Track and close removals of excess access.

6) Define and control exceptions

Deliverable: exception register with expiration and compensating controls.

• Require a written rationale, explicit scope, and end date.
• Include compensating controls (e.g., increased logging/monitoring, dual approval for sensitive actions).

7) Create a control card and evidence bundle (make audits easy)

This is where teams fail: they “do the work” but cannot prove it later. Build a single-page control card and an evidence checklist aligned to 3.1.2 (32 CFR Part 170; DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2). Tools like Daydream help by standardizing control cards, evidence requests, and recurring health checks across systems without turning your program into a spreadsheet farm.

---

Required evidence and artifacts to retain

Keep evidence per system inside the CUI boundary. A strong bundle includes:

Core artifacts (design)

• Access Control Policy / Standard stating least privilege at transaction/function level (NIST SP 800-171 Rev. 2).
• System inventory and CUI boundary definition showing which systems are in-scope (DoD CMMC Program Guidance).
• Role Catalog (role names, purpose, allowed functions, risk tier).
• Role-to-Job Matrix (who gets what and why).
• Separation of Duties rules for sensitive functions.

Operational artifacts (operation)

• Access request tickets with approvals and timestamps.
• Provisioning/deprovisioning logs (IdP logs, directory changes, system audit logs).
• Access review reports with sign-off and remediation items.
• Exception register (approval, compensating controls, expiration, closure evidence).
• Privileged access list and proof of review/removal actions.

Testing/validation artifacts (assurance)

• Screenshots or exports showing role configurations.
• Samples demonstrating denied actions for non-authorized roles (test cases).
• Control health check results and remediation tracking.

---

Common exam/audit questions and hangups

Expect assessors to probe “show me” evidence:

1. “How do you decide what functions each role can perform?”
   They want a documented rationale tied to job duties, not informal tribal knowledge (NIST SP 800-171 Rev. 2).

2. “Show me your privileged roles and who has them.”
   Have an always-current list and an approval trail.

3. “Demonstrate enforcement.”
   Be ready to show configuration screens, group memberships, and an example of a blocked action.

4. “How do you handle exceptions?”
   If you cannot show expiration and closure, exceptions look like permanent over-permissioning.

5. “What about SaaS/cloud consoles?”
   If your CUI environment relies on cloud admin actions, console permissions are in-scope for transaction/function restriction (NIST SP 800-171 Rev. 2).

---

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails 3.1.2	How to fix it
Only controlling login (MFA)	Authentication ≠ authorization	Add RBAC/ABAC and restrict sensitive functions (NIST SP 800-171 Rev. 2).
“Everyone is an admin” in a key system	No least privilege at transaction/function level	Create standard roles, reserve admin for a small set, and review regularly.
Permissions granted directly to users	Hard to review and easy to miss removals	Assign permissions via groups/roles; keep direct grants as exceptions.
Access reviews are informal	No repeatable evidence	Use a defined review cadence, sign-offs, and remediation tickets.
No separation of duties	Increased fraud/misuse risk	Split duties for sensitive functions; document approvals and constraints.
Exceptions never expire	Permanent policy bypass	Require expirations and track closure evidence.

---

Enforcement context and risk implications

No specific public enforcement cases were provided in the source catalog for this requirement. Practically, failure on 3.1.2 increases risk of unauthorized disclosure or modification of CUI because overbroad permissions make insider misuse, account takeover impact, and accidental sharing more likely (NIST SP 800-171 Rev. 2). Under CMMC, weaknesses in access control practices can affect your ability to meet Level 2 expectations required by DoD customers (32 CFR Part 170; DoD CMMC Program Guidance).

---

A practical 30/60/90-day execution plan

Exact timelines depend on system count and complexity, but operators like phased execution. Use this structure and track progress per in-scope system (DoD CMMC Program Guidance).

First 30 days (stabilize and define)

• Name a control owner and system owners for each in-scope system.
• Confirm the CUI boundary system list.
• Create the control card: objective, scope, roles/responsibilities, trigger events (JML), and evidence locations (32 CFR Part 170).
• Draft role catalogs for top-risk systems (IdP, file storage, cloud console, key business app).

Days 31–60 (enforce and remove obvious excess)

• Implement RBAC groups and migrate ad hoc permissions into roles.
• Lock down privileged roles; require tickets and approvals for admin rights.
• Stand up the exception register with expirations and compensating controls.
• Produce your first access review pack for at least one high-risk system.

Days 61–90 (prove operation and scale)

• Expand role enforcement to remaining in-scope systems.
• Run access reviews across systems; drive remediation to closure.
• Add lightweight testing: sample users, validate denied functions, collect screenshots/log exports.
• Prepare an assessor-ready evidence bundle organized by system and by practice (NIST SP 800-171 Rev. 2).

Daydream note: this is where teams lose time. A platform workflow that assigns owners, schedules reviews, and bundles evidence by requirement reduces scramble and makes your 3.1.2 story consistent across systems.

Frequently Asked Questions

Do we need RBAC to satisfy CMMC Level 2 Practice 3.1.2?

RBAC is the most common way to implement it, but the requirement is about limiting transactions/functions, not mandating a specific model. ABAC or application-native permission sets can work if they clearly restrict actions and you can prove enforcement (NIST SP 800-171 Rev. 2).

Does 3.1.2 apply to administrators and IT staff?

Yes. Admins are authorized users too, and you must still limit them to the functions they need. Assessors will focus heavily on privileged roles because they can change permissions, disable logging, or access large volumes of CUI (NIST SP 800-171 Rev. 2).

What counts as a “transaction or function”?

Think actions inside a system: export data, delete records, change permissions, create users, modify security settings, approve workflows, or access audit logs. If the action affects confidentiality, integrity, or availability of CUI, treat it as in-scope for restriction (NIST SP 800-171 Rev. 2).

How do we handle small teams where people wear multiple hats?

Document the combined role and its justification, then add guardrails: approval-based elevation, separate admin accounts, or tighter logging/monitoring with managerial oversight. Keep the exception time-bound where possible and capture the approval trail (NIST SP 800-171 Rev. 2).

Are shared accounts automatically a failure of 3.1.2?

Shared accounts make it hard to prove that access is limited per authorized user because actions cannot be tied to an individual. If you have them, treat as a high-priority remediation item and document interim compensating controls until removal (NIST SP 800-171 Rev. 2).

What evidence is most persuasive to an assessor?

A role-to-job matrix plus system configuration exports, a sample of approved access tickets, and a completed access review with remediation closure. That combination shows design, enforcement, and ongoing operation (NIST SP 800-171 Rev. 2).