Mapped Requirement and Assessment Objective
Mapped to NIST 800-171 requirement 3.1.1 and CMMC Level 2 assessment objective AC.L2-3.1.1[b].
What AC.L2-3.1.1b Requires
This objective emphasizes transaction-level control. It is not enough to restrict who can access a system; you must also limit what authorized users can do once access is granted.
Examples include ensuring a finance user cannot modify firewall rules, limiting an intern from exporting large volumes of CUI, and granting administrative privileges only when needed and only for as long as needed.
Why Limiting Authorized Actions Matters
Many security incidents involve valid credentials being misused. Limiting users to only what they need reduces insider risk, prevents mistakes that can lead to data loss, and limits lateral movement during a compromise.
How to Implement Transaction-Level Access Controls
Use role-based access control (RBAC) to define and enforce permission sets, and document access requirements by job role or function. Implement technical controls in systems such as file permissions, group policies, and application access restrictions.
Regularly review roles and permissions (for example, quarterly) and avoid blanket administrative access. Document your approach as part of broader CMMC Level 2 access control scope and maintain clear rationale for privileged access aligned to NIST 800-171 control alignment.
Implementation Summary Table
| Control Activity | What to Do |
|---|---|
| Define Roles and Permissions | Establish role-based permission sets that restrict actions to approved job functions. |
| Apply Technical Restrictions | Enforce least privilege using system mechanisms such as file permissions, group policies, and application controls. |
| Limit Privileged Access | Grant administrative privileges only when required and restrict duration and scope. |
| Review Access Regularly | Perform recurring access reviews and adjust permissions when roles or responsibilities change. |
| Avoid Blanket Permissions | Prevent one-size-fits-all access patterns that grant unnecessary capabilities. |
Evidence Assessors Commonly Expect
Assessors commonly look for role definitions that include expected transactions or functions, system configurations showing access rights by user or group, and logs showing attempts to perform actions beyond assigned roles.
They may also expect documentation of your access review process and records showing access adjustments after role changes.
Common Gaps to Avoid
Common gaps include granting administrative access “just in case,” allowing shared drives without folder-level permissions, and lacking a documented access matrix by role.
FAQ
What does AC.L2-3.1.1[b] focus on?
It focuses on limiting what authorized users can do after access is granted by enforcing transaction-level restrictions based on role and job function.
What is transaction-level control?
Transaction-level control means restricting specific actions within a system, such as exporting data, changing configurations, or performing administrative functions.
What evidence can demonstrate compliance with AC.L2-3.1.1[b]?
Evidence can include role and permission definitions, system access configurations, access attempt logs, documented access reviews, and records of permission changes tied to role changes.