03.01.04: Separation of Duties

03.01.04: separation of duties requirement sits in the Access Control family in NIST SP 800-171 Rev. 3 and is a common “looks fine on paper, fails in operation” control. The requirement is simple: don’t allow one individual to both initiate and complete sensitive actions without an independent check. In a CUI context, the practical goal is to reduce the risk of insider threats, fraud, unapproved changes, and accidental outages by ensuring critical actions require at least two distinct roles or an equivalent compensating control.

Operationalizing this quickly requires decisions, not prose: which duties conflict in your environment; which systems enforce separation; which exceptions you tolerate; and what evidence proves the separation works. You also need the control to be assessable: tied to the System Security Plan (SSP) and backed by a plan of action and milestones (POA&M) when gaps exist, because assessors look for implementation detail and operating proof, not a generic SoD policy.

This page gives requirement-level implementation guidance you can implement as a CCO, Compliance Officer, or GRC lead with your IT and security owners.

Regulatory text

Requirement: “NIST SP 800-171 Rev. 3 requirement 03.01.04 (Separation of Duties).” (NIST SP 800-171 Rev. 3)

Operator interpretation: You must separate responsibilities for key system functions so one person cannot unilaterally execute conflicting activities that could cause unauthorized access, unauthorized changes, or concealment of activity. Separation can be implemented through:

• distinct roles (RBAC),
• workflow approvals (ticketing/change control),
• privileged access controls,
• and monitoring/detective controls as compensating measures where strict separation is not feasible.

Your SSP should state (1) which duties are separated, (2) how separation is enforced in each relevant system handling CUI, and (3) who owns ongoing operation and evidence. Any gaps belong in POA&M with defined remediation and closure validation. (NIST SP 800-171 Rev. 3)

Plain-English interpretation (what 03.01.04 requires)

You need to prevent “one-person control” over sensitive actions in your CUI environment. Practically, you are trying to stop scenarios like:

• A system administrator granting themselves access, using it, then deleting logs.
• A developer pushing unreviewed code directly to production.
• A finance or procurement user creating a third party record and approving payments without independent review (if those systems touch CUI processes or shared identity/ERP platforms).

Separation of duties is not always “two humans touch every task.” The requirement is satisfied when you can show that conflicting actions are split across people or controlled by strong technical safeguards plus independent review.

Who it applies to

Entities: Nonfederal organizations operating systems that handle Controlled Unclassified Information (CUI), including defense contractors and federal contractors with NIST SP 800-171 obligations. (NIST SP 800-171 Rev. 3)

Operational context (where auditors look):

• Identity and access management (IAM) and privileged access (admins, cloud admins, database admins).
• Change management for CUI systems (code, infrastructure-as-code, firewall rules, group policy, endpoint management).
• Security operations functions that can affect detection integrity (EDR policy changes, SIEM rule changes, log retention settings).
• Key business applications in the CUI boundary (ERP/MRP, ticketing, PLM, document repositories) when access rights can create, approve, and release CUI-bearing artifacts.

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

Step 1: Define “conflicting duties” for your CUI boundary

Create a short list of duty pairs that must not reside with one person for CUI systems. Start with these common conflict sets:

• Build vs approve vs deploy: developer cannot approve their own merge and deploy to production.
• Access provision vs approval: the person granting access is not the same as the approver for privileged roles.
• Admin vs audit: those who administer systems cannot modify or delete audit logs without independent oversight.
• Security tooling admin vs security monitoring: avoid having the same person both tune detection and control the evidence trail.

Deliverable: a one-page “SoD conflict set” statement that you can embed in your SSP control narrative. (NIST SP 800-171 Rev. 3)

Step 2: Build a role-to-system SoD matrix

Make SoD tangible with a matrix covering every in-scope system/component:

• Columns: system, privileged roles, sensitive actions, required approver, logging source, monitoring owner, break-glass process.
• Rows: roles (not individuals): SysAdmin, CloudAdmin, DBAdmin, DevOps, Security Engineer, App Owner, Helpdesk, Auditor/Compliance.

Keep it operational: list the actual platform roles/groups (e.g., “Azure Global Admin,” “AWS AdministratorAccess,” “GitHub repo admin,” “ServiceNow CAB approver”).

Deliverable: “CUI System SoD Matrix” with named control owners per system. This also supports “map the requirement to SSP control statements, responsible system components, and accountable control owners.” (NIST SP 800-171 Rev. 3)

Step 3: Enforce SoD with technical controls first

Policy is necessary, but assessors expect enforcement where feasible.

Access control patterns that work:

• RBAC with separate groups: separate “request,” “approve,” and “implement” groups.
• Privileged access management: time-bound elevation, approval gates, session logging for admin activity.
• Source control protections: branch protections, mandatory peer review, separation between repo admin and deployment approver.
• Change control workflows: tickets required for privileged changes; CAB approval distinct from implementer; emergency change with post-approval review.

Deliverable: configuration screenshots/exports and system settings that demonstrate separation is enforced.

Step 4: Define a controlled exception path (and treat it as risk)

Small teams often need exceptions. Make exceptions auditable:

• Define which roles can invoke break-glass or emergency changes.
• Require documented justification and an independent after-the-fact review.
• Restrict duration and scope (temporary membership, expiring access).

Deliverable: exception procedure plus a log of exceptions with reviewer sign-off and closure notes. Track gaps or structural constraints in POA&M with closure validation. (NIST SP 800-171 Rev. 3)

Step 5: Operationalize recurring reviews and evidence collection

Set recurring activities that produce consistent artifacts:

• Access reviews for privileged groups and SoD-sensitive roles.
• Change sampling to confirm approvals occurred and approver ≠ implementer.
• Log integrity checks for admin/audit separation (who can change retention, who can delete logs, who can disable agents).
• User lifecycle checks (joiner/mover/leaver) to ensure role changes do not create toxic combinations.

Deliverable: measurable implementation criteria and recurring operational evidence (logs, reviews, approvals, test outputs). (NIST SP 800-171 Rev. 3)

Required evidence and artifacts to retain

Assessors want proof that separation exists and operates. Keep these artifacts in a single evidence folder mapped to your SSP control statement:

1. SSP control narrative for 03.01.04: conflict sets, enforcement points, control owners, scope (in-scope systems). (NIST SP 800-171 Rev. 3)
2. SoD matrix: roles vs systems vs sensitive actions, including approver roles.
3. Access control evidence: group listings, role assignments, PAM configurations, screenshots/exports showing restrictions.
4. Workflow evidence: tickets showing request/approval/implementation separation; CAB minutes/approvals where applicable.
5. Access review records: review date, reviewer, findings, remediation actions, completion.
6. Logging/audit evidence: proof that log changes are restricted and auditable; sample admin activity logs.
7. POA&M items: any gaps (small team constraints, legacy apps), risk rating, target dates, closure validation artifacts. (NIST SP 800-171 Rev. 3)

Practical tip: If evidence is scattered across ITSM, IAM, Git platforms, and cloud consoles, Daydream can act as the system of record that maps 03.01.04 to SSP language, owners, and a standing evidence checklist so you stop rebuilding the same packet for every assessment.

Common exam/audit questions and hangups

Expect these questions, and pre-answer them in your SSP and evidence:

• “Show me where SoD is enforced technically for privileged roles.”
• “Who can grant themselves admin access? Prove they cannot without approval.”
• “Can a developer deploy to production without independent approval?”
• “Who can disable logging, change retention, or delete audit records?”
• “How do you handle emergencies? Show break-glass logs and independent review.”
• “Walk through a recent change: ticket, approval, implementation, validation, and logs.”

Hangup: teams present an SoD policy but cannot show real role boundaries in systems. Another hangup is a matrix that lists job titles but not the actual platform roles/groups that create or prevent toxic combinations.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: SoD only in policy documents.
   Fix: back it with RBAC/PAM/workflow controls and show configurations.

2. Mistake: Defining SoD too broadly.
   Fix: focus on a small set of conflict pairs tied to real risk in your CUI systems.

3. Mistake: Shared admin accounts and weak attribution.
   Fix: require unique admin identities, time-bound elevation, and audit trails.

4. Mistake: No exception governance for small teams.
   Fix: document break-glass, require after-action review, and log every use; track structural constraints in POA&M. (NIST SP 800-171 Rev. 3)

5. Mistake: Forgetting third parties.
   Fix: apply the same SoD expectations to managed service providers and other third parties with admin access to CUI systems; verify their role separation and approval workflows contractually and operationally.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat “enforcement” here as assessment and contractual risk rather than cited legal outcomes. The practical exposure is straightforward:

• Weak SoD increases the chance that a single compromised account can make unauthorized changes and erase evidence.
• In CUI environments, control failures can drive adverse assessment results, POA&M expansion, and program delays tied to contractual security requirements. (NIST SP 800-171 Rev. 3)

Practical 30/60/90-day execution plan

First 30 days: Define and map

• Assign a control owner for 03.01.04 and identify system owners for each in-scope CUI system.
• Draft your conflict set list and build the first SoD matrix for top-tier systems (IAM, cloud, endpoint management, source control, logging).
• Update SSP language for 03.01.04 to reflect real systems, roles, and enforcement points. (NIST SP 800-171 Rev. 3)

Days 31–60: Enforce and close obvious gaps

• Implement RBAC group splits and remove toxic combinations from privileged roles.
• Turn on or tighten workflow approvals (change management, branch protections, deployment gates).
• Stand up a break-glass process with logging and independent review; create initial POA&M items for any legacy constraints. (NIST SP 800-171 Rev. 3)

Days 61–90: Evidence and steady-state operations

• Run your first formal access review for privileged and SoD-sensitive groups; document remediation.
• Sample recent changes and compile an assessor-ready evidence packet (tickets, approvals, logs).
• Validate POA&M closure criteria for any completed remediation and keep artifacts that prove the control now operates. (NIST SP 800-171 Rev. 3)

Ongoing: treat SoD as a living control. Any new system added to the CUI boundary needs an SoD row in the matrix and a named owner.

Frequently Asked Questions

We’re a small team. Can one admin do everything if we “monitor them closely”?

You need separation or a compensating control that creates independent oversight you can prove. Use time-bound elevation, immutable logging where feasible, and documented independent reviews of privileged actions, then track residual gaps in your POA&M. (NIST SP 800-171 Rev. 3)

Does 03.01.04 require two people for every change?

No. Focus on conflicts that create material risk, such as approving your own access or deploying unreviewed changes. Use workflow gates and role design so independence exists at the highest-risk points.

What’s the minimum evidence an assessor will accept for separation of duties?

A defensible SSP statement, a role/system SoD matrix, and operating evidence from real activity: access approvals, change tickets, and logs showing different actors for request/approval/implementation. (NIST SP 800-171 Rev. 3)

How do we handle third parties with admin access (MSPs, cloud consultants)?

Treat them as privileged users inside your CUI environment. Require named accounts, role restrictions, approval workflows for high-risk actions, and provide evidence (tickets/logs) that their work follows your SoD rules.

Our CI/CD tool can’t enforce separate approver and deployer roles. What should we do?

Put the gap in POA&M, then add compensating controls such as branch protections with mandatory reviewers, restricted deployment credentials, and independent post-deployment review with logs. Keep configuration and review artifacts tied to the POA&M item. (NIST SP 800-171 Rev. 3)

How should this appear in the SSP?

The SSP should name your conflict sets, list the in-scope systems where SoD is enforced, identify role groups and approval steps, and assign operational owners and evidence sources. Keep it specific enough that an assessor can test it without guessing. (NIST SP 800-171 Rev. 3)