3.1.2 — What They Can Do

The One-Liner

If a finance clerk can modify firewall rules, you fail this requirement.

What It Says

Limit system access to the types of transactions and functions that authorized users are permitted to execute.

What It Actually Means

Define roles. Assign permissions to roles, not to people. Then assign people to roles.

A contract manager gets read access to CUI documents — not delete. An engineer gets write access to technical data — not financial records. A receptionist doesn’t get access to the engineering file share.

This is role-based access control (RBAC). Where 3.1.1 controls who gets in, this controls what they can do once inside. The system enforces it technically, not just through policy.

---

Pass or Fail

Your assessor needs a “yes” to every row:

#	Question	What “yes” looks like
1	Are permitted transactions and functions defined per role?	Documented role definitions with specific permissions
2	Does the system enforce those limits?	A user in one role can’t perform functions from another role — prove it

---

What to Have Ready on Assessment Day

Documents they’ll review: Access control policy, access enforcement procedures, system security plan, list of role-based authorizations, system configuration showing permissions, audit logs

People they’ll talk to: Access enforcement staff, sysadmins, information security lead, system developers

Live demos they’ll ask for: “Log in as a standard user and try to access an admin function — show me it’s blocked.”

---

The Assessor’s Playbook

These are the actual questions. Have answers ready.

• “Show me your role definitions — how do you determine what each role can do?”
• “Are access control lists used to limit access based on role?”
• “Can you demonstrate that a restricted user is actually blocked from unauthorized functions?”
• “How do you handle temporary elevated access?”

Real-World Example

A 40-person defense contractor uses Entra ID security groups to define four roles: CUI-ReadOnly, CUI-Editor, IT-Admin, and Finance. SharePoint libraries enforce permissions by group. An engineer in CUI-Editor can create and modify technical documents but can’t access the Finance folder. IT shows the assessor by logging in as a CUI-ReadOnly user and demonstrating they can view but not edit or delete.

---

Where Companies Trip Up

Everyone is an admin. Small companies give all users admin rights for convenience. This is the fastest way to fail.

Roles on paper but not in the system. Having a policy document that describes roles but not configuring the system to enforce them.

Privilege creep. Users accumulate permissions as they move between projects. Old permissions never get revoked. Run quarterly access reviews.

Over-permissioned service accounts. An automated process running as domain admin when it only needs read access to one database.

---

How to Talk About This

To a CEO or Board

Every person has a defined role with specific permissions. The system enforces it — not just a policy binder. We can demonstrate it live to any assessor.

To an Engineering Team

RBAC via Entra security groups, scoped to SharePoint, file shares, and applications. No direct user-level permissions. Quarterly access reviews flag drift.

---

Connected Requirements

Requirement	Why it matters here
3.1.1 — Who Gets In	Controls who gets in; this controls what they do
3.1.5 — Minimum Necessary	The principle behind this: least privilege
3.1.7 — Log the Admin Work	Specifically controls and logs privileged functions

---

Implementation

🔒

Step-by-step guides for Microsoft 365, AWS, Azure, and GCP are available to Ancitus clients.

Start a conversation →

---

CMMC Practice ID: AC.L2-3.1.2 | SPRS Weight: 5 points | POA&M Eligible: No