1Overview
AC.L2-3.1.4 asks the organization to divide sensitive responsibilities so that no single person can carry out and conceal a harmful action alone. It is a one-point requirement, but it is one of the harder controls for a small shop to satisfy honestly, because the whole difficulty of separation of duties is that a small company does not have many duties to separate.
The control descends from a principle older than information security: the person who writes the checks should not also reconcile the bank statement, and the person who requests access should not also approve it. Applied to a CUI environment, it means the sensitive functions, granting access, administering the systems, reviewing the logs that would reveal misuse, are distributed across more than one person, so that misuse requires collusion rather than a single actor. The assessment does not demand a large staff. It demands that the organization has identified its duties that need separating and has separated them as far as its size allows, with a documented, compensating approach where full separation is genuinely impossible.
Separate the duties of individuals to reduce the risk of malevolent activity without collusion.
The phrase that governs the control is "without collusion." The goal is not to make malfeasance impossible, which no control can, but to raise the bar so that a single individual acting alone cannot both commit a harmful act and erase the evidence of it. That is why the separation between performing a privileged action and reviewing the record of it matters as much as the separation between requesting and approving.
2The Assessment Objectives
NIST SP 800-171A decomposes 3.1.4 into three objectives: identify the duties that need separating, define the access authorizations that support the separation, and enforce it through the access controls.
The duties of individuals requiring separation are defined. The organization has identified which functions should not rest with a single person, such as requesting and approving access, or administering a system and reviewing its audit logs.
Responsibilities for duties that require separation are assigned to separate individuals. The identified duties are actually distributed among different people, not merely listed as separated.
Access privileges that enable individuals to exercise the duties that require separation are granted to separate individuals. The system access is arranged so the separated responsibilities are actually held by different people, each granted the distinct privileges their duties require, rather than everyone holding the same broad rights.
The three objectives build on one another: the duties are identified, the people are assigned, and the access is arranged to support the assignment. A shop can satisfy [a] and [b] on paper and still fail [c] if a shared administrator account gives everyone the same power, which is why this control depends heavily on the least-privilege work of 3.1.2.
3Failure Patterns
The failures cluster around the small organization, where one capable person has historically done everything, and where the honest response to the control is often the hardest to accept.
The one-person IT function
A single administrator, often an outside contractor, who grants access, administers every system, and is also the only one who ever looks at a log. Nothing they do is checked by anyone, which is the exact condition 3.1.4 exists to prevent. The remedy is rarely to hire a second administrator; it is to move one duty, usually the review of access and logs, to a different person who does not need technical depth to perform it.
Request and approval in the same hands
Access is requested and approved by the same person, or approved by no one at all, so anyone can grant themselves whatever they need. Separating these is one of the least expensive controls in the entire framework, requiring only that a second person sign off, yet it is missing in a great many shops because access has always been handled informally.
The administrator who reviews their own logs
The person who could misuse a system is the same person who reviews the record of its use, which means the audit trail protects nothing against the one actor most able to abuse it. This is the separation that matters most and is overlooked most, because log review is treated as a technical task and handed back to the technical person.
Separation on paper, shared account in practice
The policy names separated duties, but everyone works through a shared administrator login, so the separation exists only in the document. Objective [c] is where this collapses, because identical access defeats any assignment of responsibilities, and the assessor confirms it by asking who can actually do what rather than who is listed as doing what.
4Ownership
This control is decided by leadership more than by IT, because it is fundamentally about who is allowed to check whom, and that is an organizational choice rather than a technical one. The technical work of arranging access follows the decision.
| Role | Responsibility for this control |
|---|---|
| Executive sponsor or owner | Decides which duties must be separated and assigns the review responsibilities, since separation of duties is an accountability structure the leadership owns. In a small shop the owner often becomes the reviewer of the administrator's activity. |
| Business or office manager | Frequently holds the approval and review duties that separate the technical functions, because these tasks require judgment and standing rather than technical skill, and are best held outside IT. |
| IT lead or administrator | Arranges the access privileges so the separation is real: read-only log access for the reviewer, distinct approval functions, and no shared all-powerful account. Provides the evidence that access supports the assignment. |
| Program lead | Documents the separated duties, the assignments, and the compensating measures where full separation is not possible, and keeps that record current as roles change. |
5Tooling
Separation of duties is enforced less by specialized software than by how ordinary access is arranged, which is why the tooling here overlaps heavily with the access-control model already in place. The distinguishing work is designing distinct privileges and a review path.
| Objectives | Tooling | What it provides |
|---|---|---|
| [a] | A documented separation-of-duties matrix or policy statement | The written identification of which duties are separated and why. A design artifact rather than a product, and the reference the assignment and access are measured against. |
| [b], [c] access separation | Active Directory role groups, distinct privileged accounts, a restricted administrators group | Separate role groups give the approver, the administrator, and the reviewer distinct rights, and replacing a shared administrator login with individual privileged accounts is what makes the separation real rather than nominal. |
| [c] log review separation | Read-only access to logs or the SIEM, delegated log-reader roles | Granting the reviewer read access to audit data without the ability to alter it lets a non-administrator perform the review that checks the administrator, which is the separation that matters most. |
| [b] approval workflow | A simple access-request form or ticket requiring a separate approver | Even a paper or email approval step, retained as a record, separates requesting from approving without any new software. |
The caveat for this control is organizational rather than technical. The tooling to arrange distinct privileges exists in every environment; what is often missing is the willingness to take some access away from a trusted person who has always had all of it. The assessor tests objective [c] by asking whether the reviewer can alter the records they review and whether the administrator's actions are visible to anyone else, and a shared account answers both questions the wrong way regardless of what the policy says.
6Evidence
The satisfied version of 3.1.4 shows the separated duties, the people they are assigned to, and the access that supports the assignment, along with the compensating measures where separation is limited by size.
| Evidence | What it demonstrates |
|---|---|
| Separation-of-duties policy or matrix | Objective [a]. The identified duties requiring separation, maintained and dated. |
| Role assignments | Objective [b]. Who holds each separated responsibility, showing that the duties rest with different individuals. |
| Access privilege records | Objective [c]. Group memberships and rights showing the reviewer, approver, and administrator hold distinct access that supports the separation. |
| Access request and approval records | Objectives [b], [c]. Retained requests showing a separate approver, demonstrating requesting and approving are not the same hands. |
| Documented compensating measures | Where full separation is not possible, the written explanation of the residual risk and the measures that offset it, such as owner review of administrator activity. |
The evidence must reflect how the organization actually operates, because the assessor will ask a named reviewer what they can and cannot do, and it must be current, since a separation matrix that predates the last staffing change may assign a duty to someone who has left. Where a small shop cannot separate a duty completely, the documented compensating measure is itself the evidence, and a candid record of a limitation with an offsetting control is stronger than a separation the staffing plainly cannot support.
Deciding who checks whom is a leadership conversation
The hard part of separation of duties in a small company is not the technology but the decision to move a duty away from a trusted person, and to have the owner review what the administrator does. Working through that honestly, and finding the compensating measures where full separation is not realistic, is part of the onsite readiness work this practice does.
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.4. csrc.nist.gov
- NIST Special Publication 800-171A, Assessing Security Requirements for Controlled Unclassified Information, assessment objectives 3.1.4[a] through 3.1.4[c]. 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