CMMC Level 2 Practice 3.1.4: Separate the duties of individuals to reduce the risk of malevolent activity without collusion

CMMC Level 2 Practice 3.1.4 requires you to implement separation of duties so one person cannot unilaterally perform high-risk actions that could enable fraud, sabotage, or data compromise without detection. Operationalize it by identifying “toxic combinations” (build + deploy, approve + pay, grant + audit) and enforcing split responsibilities through roles, workflows, logging, and periodic review. ¹

Key takeaways:

• Define and block specific “toxic combinations” for your CUI environment, not just generic IT admin statements. ²
• Enforce separation with technical controls (RBAC, PAM, change approvals) plus documented exceptions and compensating controls. ²
• Keep assessor-ready evidence: role matrices, workflow screenshots, access review records, and logs showing no single-actor paths for critical actions. ³

Separation of duties is an access control requirement, but assessors will treat it as an operational integrity test: can a single individual make a material security-impacting change, hide it, and move CUI without another person’s visibility? CMMC Level 2 Practice 3.1.4 (mapped to NIST SP 800-171 Rev. 2 control 3.1.4) expects you to design roles and processes that reduce the chance of malevolent activity succeeding unless there is collusion. ²

For most defense contractors, the hard part is scope and specificity. “IT has admin rights” is not a control; it’s a risk statement. You need a clear inventory of privileged actions in the CUI boundary (identity administration, endpoint management, configuration changes, code deployment, logging controls, backup restore, and security tooling administration) and then a practical split of who can request, approve, implement, and verify those actions. ²

This page is written for a Compliance Officer, CCO, or GRC lead who needs to turn the requirement into role design, workflow changes, and an evidence bundle that stands up in a CMMC Level 2 assessment. ⁴

Regulatory text

Requirement (provided excerpt): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.1.4 (Separate the duties of individuals to reduce the risk of malevolent activity without collusion).” ¹

What the operator must do: You must structure roles and processes so that high-risk actions affecting systems that process, store, or transmit CUI cannot be completed end-to-end by a single person acting alone. Separation can be implemented by splitting responsibilities (request vs approve vs implement vs review), limiting privileges, and requiring independent review for sensitive actions. The goal is risk reduction: if one person turns malicious, they should hit a second-person control before they can complete or conceal the activity. ²

Plain-English interpretation

You are preventing “one-person total control” over critical security and business pathways in the CUI environment. If the same individual can:

• create an account,
• grant it privileged access,
• disable logging,
• deploy code or change firewall rules,
• and approve their own change, you have not separated duties in any meaningful way.

Separation of duties is not limited to finance. In CMMC Level 2 environments, the most common duty conflicts are in identity, endpoint management, change management, CI/CD, and security tooling administration. ²

Who it applies to

Entities: Organizations seeking or maintaining CMMC Level 2 certification, typically defense contractors and other federal contractors that handle Controlled Unclassified Information (CUI). ⁵

Operational context (what’s in scope):

• People: IT admins, security engineers, DevOps, system owners, database admins, help desk, and any privileged contractor or managed service provider staff who can impact CUI systems. ²
• Systems: Identity providers, endpoints, servers, cloud platforms, CI/CD systems, logging/SIEM, backup systems, and network/security devices within the CUI boundary. ²

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

Step 1: Define the CUI boundary and “privileged action list”

Start with a scoped list of systems that process/store/transmit CUI and the administrative actions that matter. Your list should include actions that can change security posture or conceal activity, for example:

• Create/modify/delete identities and groups
• Assign privileged roles
• Change MFA policies
• Modify system configurations (GPO, MDM, baseline)
• Push software, scripts, or remote commands
• Change firewall rules / security group rules
• Disable or modify logging, alert rules, retention, or time sync
• Create/restore backups and access backup repositories
• Approve and deploy code to production workloads that handle CUI ²

Deliverable: a “privileged actions register” for the CUI environment.

Step 2: Identify “toxic combinations” (duty conflicts)

Create a matrix of actions that must not sit with the same person (or same standing role) without additional controls. Common toxic combinations in CUI environments:

• Identity admin + audit/log admin (can create access and erase traces)
• System admin + security tool admin (can weaken controls and suppress alerts)
• Developer + production deploy approval (can introduce unreviewed changes)
• Change implementer + change approver (self-approval defeats the gate)
• Backup admin + system admin (can exfiltrate or restore data outside oversight) ²

Deliverable: a separation-of-duties (SoD) matrix tied to named systems and actions.

Step 3: Map roles to people and enforce with RBAC/PAM

Turn the SoD matrix into actual access design:

• Define standard roles (e.g., Help Desk Operator, IAM Admin, Security Monitoring Admin, Endpoint Admin, Change Approver).
• Limit standing privileges and use privileged access management (PAM) or just-in-time elevation where feasible.
• Ensure logs exist for privileged actions, and that log administration is separated from the teams who generate the logs. ²

Deliverable: role-based access control (RBAC) definitions and current role assignments for in-scope systems.

Step 4: Add workflow gates for high-risk actions

Where pure RBAC cannot separate duties (common in small teams), implement workflow-based separation:

• Ticket required for privileged changes.
• Separate requester, approver, implementer, and reviewer fields.
• Mandatory peer review for code changes tied to CUI production environments.
• Independent review of changes to logging, alerting, or access control policies. ²

Deliverable: documented workflows with screenshots or exports showing approval steps and role restrictions.

Step 5: Define exceptions and compensating controls (small-team reality)

CMMC does not require you to staff like a large enterprise; it requires you to reduce risk “without collusion.” When you cannot fully separate duties due to staffing:

• Document the exception (system, action, why separation is impractical).
• Add compensating controls: heightened logging, independent periodic review by another manager, alerts on sensitive actions, or break-glass accounts with monitored use.
• Set an expiration/renewal for the exception and a plan to reduce reliance over time. ²

Deliverable: exception register with approvals and compensating control mapping.

Step 6: Operationalize and prove it works (control health checks)

Make the control sustainable:

• Run recurring checks that no user holds prohibited role combinations in key systems.
• Sample recent privileged changes and confirm the request/approve/implement/review split.
• Track findings to closure with owners and due dates. This is where teams often fail: they build the matrix once and never validate drift. ⁴

Deliverable: SoD review records and remediation tickets.

Required evidence and artifacts to retain

Keep evidence that shows design and operation:

Design evidence

• Separation of duties policy or standard (SoD expectations, scope = CUI boundary). ²
• Privileged actions register (system-by-system list of sensitive actions). ²
• SoD matrix (toxic combinations, required separations, compensating controls). ²
• Role definitions and access model documentation (RBAC/PAM approach). ²

Operational evidence

• Current role assignment exports (IdP, cloud IAM, endpoint tooling, CI/CD, SIEM). ²
• Workflow proof: ticket samples showing distinct requester/approver/implementer/reviewer for privileged changes. ²
• Access review results focused on toxic combinations, including remediation tracking. ³
• Exception register with approvals and proof of compensating controls (alerts, logs, independent review). ²

Make it assessor-friendly

• One “requirement control card” that states objective, owner, triggers, steps, exceptions, and evidence location, then points to the artifacts above. Daydream is a natural place to store the control card, attach evidence samples, and track drift remediation without losing context across teams. ³

Common exam/audit questions and hangups

Expect assessors (and serious customer diligence) to press on these points:

• “Show me the systems in your CUI boundary and who has admin rights in each.” ³
• “Can the same person create accounts and also administer logs or audit trails?” ²
• “How do you prevent self-approval of production changes?” ²
• “Walk me through a recent sensitive change and prove separation with evidence.” ³
• “How do you handle small-team exceptions?” If you answer “we trust our people,” you will struggle. Provide documented compensating controls. ²

Frequent implementation mistakes (and how to avoid them)

1. Policy-only SoD. A statement in an access control policy does not demonstrate separation. Fix: produce the SoD matrix and role assignments, then show workflow evidence. ²
2. Ignoring log administration. Teams separate deploy approvals but leave SIEM/admin rights with the same admins who can generate incidents. Fix: split log configuration rights from system administration, and require independent review for logging changes. ²
3. One shared admin account. Shared credentials erase accountability and separation. Fix: named accounts, controlled elevation, and auditable approvals for privileged access. ²
4. No exception discipline. Exceptions become permanent. Fix: approvals, compensating controls, and periodic re-approval with evidence of monitoring. ²
5. Not testing drift. Role sprawl breaks SoD over time. Fix: recurring checks and ticketed remediation to closure. ³

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat enforcement risk primarily as contractual and certification risk under the CMMC program framework. If you cannot show separation of duties, you risk assessment findings that can delay or prevent CMMC Level 2 certification, and you increase the likelihood that a single compromised admin account leads to undetected CUI compromise. ⁶

Practical 30/60/90-day execution plan

30 days (establish design + quick wins)

• Name an owner for the control and publish a one-page control card (objective, scope, roles, exceptions, evidence locations). ³
• Define the CUI boundary systems list and generate current privileged access exports for each in-scope platform. ²
• Draft the privileged actions register and first version of the SoD matrix (start with identity, logging, endpoint management, and production change paths). ²

60 days (enforce separation in the highest-risk paths)

• Implement or tighten RBAC so toxic combinations are removed from standing access. ²
• Update change workflows: require separate approval for privileged changes and define who performs independent review. ²
• Create the exception register and apply compensating controls where separation is not feasible. ²

90 days (prove operation + harden evidence)

• Run the first control health check: test for prohibited role combinations and sample completed changes for SoD proof. ³
• Close findings with ticketed remediation and retain before/after access evidence. ³
• Package an assessor-ready evidence bundle in a single repository. Daydream can track the control’s operating cadence, store evidence samples, and maintain an exception register that does not decay into tribal knowledge. ³

Frequently Asked Questions

We’re a small contractor. Can one person hold multiple admin roles?

Sometimes, but you must reduce risk without relying on trust. Document the exception and add compensating controls like independent review, heightened logging, and monitored break-glass access. ²

Does separation of duties mean we need a formal change advisory board?

No. You need clear separation between requesting, approving, implementing, and verifying sensitive actions for CUI systems. A lightweight ticket approval workflow can meet the intent if it is enforced and evidenced. ²

What’s the fastest way to show an assessor we meet 3.1.4?

Produce an SoD matrix for in-scope systems, export current privileged role assignments, and provide ticket samples showing separate approval and implementation for sensitive changes. Those three items usually expose gaps quickly. ⁷

Are developers allowed to deploy to production in a CUI environment?

They can, but you need controls that prevent unilateral deploys without oversight, such as required peer review and separate approval for production releases. Show the workflow and access restrictions that enforce it. ²

How do we handle managed service providers or third parties with admin access?

Treat third-party privileged users the same as employees for SoD: define allowed roles, block toxic combinations, and require auditable approvals for privileged actions. Keep evidence of role assignments and activity logs. ²

What evidence is most commonly missing during assessments?

Teams often have policies but lack proof of operation: role assignment exports, workflow records, and a documented exception register with compensating controls. Build the evidence bundle as you implement, not at the end. ³

Footnotes

1. NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance; 32 CFR Part 170

2. NIST SP 800-171 Rev. 2

3. DoD CMMC Program Guidance

4. DoD CMMC Program Guidance; 32 CFR Part 170

5. 32 CFR Part 170; DoD CMMC Program Guidance

6. 32 CFR Part 170; DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2

7. DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2