1Overview
Where 3.1.1 governs who may enter a system, AC.L2-3.1.2 governs what they may do once inside. It is the requirement that translates the principle of least privilege into the specific transactions and functions each authorized user is permitted to execute, and it carries the same maximum five-point weight and the same prohibition on remaining open at assessment.
This is the control that shared, all-powerful accounts quietly defeat. A great many small shops run on a handful of logins that can each do everything: read and write every share, install software, change configurations, administer the domain. Every one of those users is technically authorized to be on the system, satisfying 3.1.1, while none of their access is limited to what their role actually requires, failing 3.1.2. The distinction the assessor draws is between authenticated and authorized: 3.1.1 asks whether the person should be on the system at all, and 3.1.2 asks whether the person should be able to do the particular thing they just did.
Limit system access to the types of transactions and functions that authorized users are permitted to execute.
The requirement turns on the phrase "types of transactions and functions." A transaction is an action a user takes against the system: opening a controlled drawing, writing to the engineering share, running a report, installing an application, creating another user. Least privilege means each authorized user can execute the transactions their role requires and no others, and 3.1.2 asks you to have defined those permitted types and to enforce them.
2The Assessment Objectives
NIST SP 800-171A decomposes 3.1.2 into two objectives. The first is a definition task, the second an enforcement task, and they fail together when a shop has never written down what each role is allowed to do.
The types of transactions and functions that authorized users are permitted to execute are defined. A written statement, by role, of what each kind of user is allowed to do in the systems that handle CUI.
System access is limited to the defined types of transactions and functions. The definition from [a] is enforced by the system, so a user cannot execute a transaction outside their permitted set.
The two objectives are a pair: a defined matrix that is not enforced fails [b], and enforcement with no written definition fails [a], because the assessor cannot confirm that what the system does matches what the organization intended. Both must be present, and both must match.
3Failure Patterns
The failures here are patterns of excess privilege, and they are common precisely because broad access is convenient and narrow access takes deliberate design.
Everyone is a local administrator
The single most frequent finding against this control. Local administrator rights let a user install software, disable security tools, and reach resources their role never needed, which fails objective [b] across the board and undermines several other controls at the same time. The fix, standard user accounts with administration reserved to a small named group, is technically simple and organizationally disruptive, because it changes what people are used to being able to do.
The flat file share
One shared drive that everyone can read and write, holding job files, drawings, quotes, and CUI together. Every authorized user can execute every transaction against it, which is the definition of unlimited access. Objective [b] requires that the machinist who needs today's traveler cannot also open and alter the controlled engineering package, and a flat share makes that distinction impossible.
Roles that were never defined
Objective [a] is a documentation requirement, and many shops fail it outright because no one ever wrote down what each role should be able to do. Access grew by accretion: people accumulated permissions as they changed jobs, covered for absences, or asked for access to finish a task, and nobody ever took anything away. Without a definition of intended access, there is nothing for the assessor to check enforcement against.
Privilege that outlived the role
A user who moved from engineering to the front office still holds the engineering permissions, because access was granted at hire and adjusted at departure but never at the role change in between. Each of these is an authorized user executing transactions their current role does not require, which is the specific failure 3.1.2 describes.
4Ownership
This control divides cleanly between the people who know what each role should be able to do and the people who make the system enforce it. Neither can satisfy it alone, which is why the definition step so often stalls: IT cannot write the permission matrix without the business, and the business assumes IT will handle it.
| Role | Responsibility for this control |
|---|---|
| Department leads and process owners | Define what each role in their area is permitted to do, because only they know which transactions a job actually requires. This is the source material for objective [a]. |
| IT lead or system administrator | Translates the role definitions into groups, share permissions, and administrative rights, and removes standing local-administrator access. Owns the enforcement evidence. |
| Human resources | Signals role changes, not only hires and departures, so that permissions can be adjusted when a person's job changes, which is where privilege accretes. |
| Program lead | Owns the periodic access review that confirms the enforced permissions still match the defined matrix, and retains the review records. |
| Executive sponsor | Accountable for the result, and specifically for supporting the least-privilege decision when employees who have always had broad access object to losing it. |
5Tooling
Like 3.1.1, this control is built with the Microsoft tooling most contractors already hold. The work is less about acquiring software than about designing a role structure and enforcing it through group membership and rights.
| Objectives | Tooling | What it provides |
|---|---|---|
| [a] | Role-based access model, documented in the SSP or an access matrix | The written definition of permitted transactions by role. This is a design artifact rather than a product, but Active Directory security groups named by role give the definition a structure the system can then enforce. |
| [b], file and app access | AD security groups, NTFS and share permissions, SharePoint or file-server access | Group-based permissions enforce who can read versus write each share, replacing the flat drive with access that matches the matrix. Users are placed in role groups, and the groups carry the permissions. |
| [b], administrative functions | Standard user accounts, a restricted administrators group, Local Administrator Password Solution | Removing standing local-administrator rights is the highest-impact single change. LAPS manages local admin passwords where local access is genuinely needed, and privileged actions move to a small, named, audited group. |
| Evidence | Group membership exports, effective-permissions reports, access review records | Dated exports of who is in which role group, and the resulting effective permissions on the CUI shares, form the record that enforcement matches the definition. |
The recurring caveat applies with particular force here. The tooling to enforce least privilege exists in every Windows environment; what is usually missing is the decision about what each role should be able to do. A permission matrix that no one from the business helped write will not survive contact with how the shop actually works, and the assessor will find the mismatch by asking a machinist to open a file the matrix says they cannot.
6Evidence
The satisfied version of 3.1.2 shows both the intended design and its enforcement, and demonstrates that the two agree.
| Evidence | What it demonstrates |
|---|---|
| Role and permission matrix | Objective [a]. The written definition of which transactions and functions each role may execute, maintained and dated. |
| Group membership exports | Objective [b]. Who is assigned to each role group, showing that users hold the permissions of their role and no more. |
| Effective permissions on CUI resources | Objective [b]. The actual read and write access on the controlled shares, confirming the enforcement matches the matrix. |
| Administrator group membership | Objective [b]. The small, named set of accounts with administrative rights, and evidence that ordinary users are not local administrators. |
| Access review records | Dated records of periodic reviews confirming that enforced access still matches the defined roles, with changes made when it does not. |
The same two properties govern this evidence as govern the rest of the guide. It must describe the environment as it runs, because the assessor will test a live account against the matrix, and it must show operation over time, since a role matrix written the week before the assessment and never reviewed carries little weight. This control also compounds: the role groups built here become the enforcement mechanism for several later access requirements, so the design effort is spent once and reused.
Defining roles takes the business, not just IT
The reason 3.1.2 stalls is that the permission matrix has to come from the people who run the work, and getting that definition out of them and into an enforced structure is a facilitation problem as much as a technical one. That is part of the onsite readiness work this practice does, sitting with the department leads to map what each role actually needs before the groups get built.
Start CMMC Readiness or call 802-335-26627Sources
- NIST Special Publication 800-171 Rev 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, requirement 3.1.2. csrc.nist.gov
- NIST Special Publication 800-171A, Assessing Security Requirements for Controlled Unclassified Information, assessment objectives 3.1.2[a] and 3.1.2[b]. csrc.nist.gov
- 32 CFR 170.21, Plan of Action and Milestones Requirements, governing which requirements may remain open at a Level 2 assessment. ecfr.gov