Separation of Duties (SOD) is part of an organization's access governance and organizational design, not a single technical control you switch on. Where Account Management (03.01.01) decides who gets an account and Access Enforcement (03.01.02) applies those authorizations, Separation of Duties (03.01.04) decides which combinations of duties are too risky to sit with one person and defines the access authorizations that keep them apart. It reduces the risk of one individual abusing authorized privileges to carry out malevolent activity without collusion. Note the dependency built into the requirement: per the NIST discussion, SOD is enforced by 03.01.02. That means 03.01.04 is where you identify and define the separations, and 03.01.02 is where they are actually applied. Unlike the material controls around it, SOD is also the classic case where compensating controls (e.g., management oversight, increased logging, and monitoring) come into play when full separation is not operationally feasible, so do not assume you can only satisfy it one way. SOD is easier for larger organizations with clearly distinct roles and responsibilities, but becomes far more subjective and administrative when one individual wears many hats within IT, cybersecurity or other functions.
A common difficulty with this requirement is treating it as a technical checkbox instead of a design exercise. The R3 requirement is short, and the two (2) parts read like something an identity provider handles for you. It does not. Before any tool can enforce anything, a person has to decide which duties conflict and write down the access authorizations that keep them separated. If you never documented which duty pairs must be split, you have nothing for an assessor to check and nothing for 03.01.02 to enforce.
Where things stand for companies facing the transition from NIST 800-171 R2 to R3:
The following is reproduced verbatim from NIST 800-171 R3, requirement 03.01.04 Separation of Duties. Only the formatting has been adjusted for readability. Unlike 03.01.02 and 03.01.03, this requirement has two (2) lettered parts:
The source control is AC-05 from NIST 800-53. The NIST discussion is specific about what separation looks like in practice: dividing mission functions and support functions among different individuals or roles, conducting system support functions with different individuals or roles (e.g., quality assurance, configuration management, network security, system management, assessments, and programming), and ensuring that personnel who administer access control functions do not also administer audit functions. It also notes that separation of duty violations can span systems and application domains, so you consider the entirety of your systems and system components, not one box. You can read the requirement directly at NIST 800-171 R3, 03.01.04 (p. 9).
None (0). Requirement 03.01.04 contains no bracketed assignment, so there is no organization-defined value to select and nothing for the DoD to specify. The requirement applies as written.
Your System Security Plan (SSP) narrative for 03.01.04 therefore records how the requirement is implemented rather than a parameter you chose.
NIST 800-171A R3 breaks 03.01.04 into two (2) determination statements, and it has no Organization-Defined Parameters (ODPs). These AOs are:
The two (2) AOs split the work into two distinct actions: identifying the conflicting duties (A.03.01.04.a) and defining the access authorizations that keep them apart (A.03.01.04.b). Identifying a conflict is not the same as defining the authorization that resolves it, so an assessor will look for evidence of both, and evidence for one does not cover the other. The full guidance on assessment methods and objects, is in NIST 800-171A R3, 03.01.04 (p. 10).
Examine: access control policy and procedures; procedures for the separation of duties and the division of responsibilities; system configuration settings; system audit records; system access authorizations; list of divisions of responsibility and separation of duties; system security plan.
Interview: personnel with responsibilities for defining the separation of duties and the division of responsibilities; personnel with information security responsibilities; system administrators.
Test: mechanisms for implementing the separation of duties policy.
03.01.04 maps from NIST 800-171 R2 requirement 3.1.4 (separate the duties of individuals to reduce the risk of malevolent activity without collusion):
Mapped against the two (2) AOs, one (1) is direct (minimal effort) and one (1) is indirect (moderate effort), with no net-new AOs and none with no mapping. This is one of the cleaner transitions in the family. The concept did not change, the intent did not change, and the underlying source control is still AC-05. What changed is consolidation: R2 spread separation of duties across defining the duties (3.1.4[a]), assigning responsibilities to separate individuals (3.1.4[b]), and granting the enabling access privileges to separate individuals (3.1.4[c]). R3 keeps the "identify the duties" objective as-is and folds the assignment and privilege-granting work into a single objective: define the system access authorizations that support separation. The effort you spent on 3.1.4 largely carries forward, but you should re-verify that your existing separation still holds under the R3 wording and across your full system scope.
Source Control in NIST 800-53 R5:
Secure Controls Framework (SCF) Crosswalk
Organizations running a single control set across multiple frameworks can satisfy 03.01.04 through the following SCF controls:
The crosswalks from NIST 800-171 R3 and NIST 800-171A R3 to the SCF are available at no cost through the SCF Set Theory Relationship Mapping (STRM): https://securecontrolsframework.com/start-here/set-theory-relationship-mapping-strm. The STRM also carries the relationship type for each mapping (Equal, Subset Of, Intersects With), which tells you whether an SCF control fully satisfies the requirement or only part of it. Mapping above taken from SCF 2026.3.
The following are issues teams may encounter rather than certainties. They are about the analysis R3 expects and the enforcement dependency it assumes, each of which needs documented evidence of due diligence and due care such as policies, standards, procedures, and configuration screenshots:
Reasonable objective evidence for an assessment is often subjective. The following examples of evidence to address NIST 800-171 R3 03.01.04 are sourced from the SCF Evidence Request List (ERL), available at https://securecontrolsframework.com/free-content/scf-download. These ERL artifacts are mapped to NIST 800-171 R3 03.01.04 through SCF controls. They establish a starting point for discussions on what an organization needs to have for evidence of due diligence and due care to withstand external scrutiny by an assessor or regulator.
Alongside these, keep the System Security Plan (SSP) narrative for 03.01.04.
With one AO mapping directly and one indirectly, and none net new, 03.01.04 is a lighter lift than requirements like 03.01.01. The risk is treating it as trivial and skipping the documentation the assessor expects. A realistic sequence:
How many assessment objectives does NIST 800-171 R3 03.01.04 have? NIST 800-171A R3 breaks 03.01.04 into two (2) assessment objectives. An assessor works through each one separately, so each needs its own evidence.
Which NIST 800-53 R5 control does NIST 800-171 R3 03.01.04 come from? AC-05.
How many Organization-Defined Parameters (ODPs) does NIST 800-171 R3 03.01.04 have? None (0). The requirement contains no bracketed assignment, so there is no organization-defined value and nothing for the DoD to specify.
Where does NIST 800-171 R3 03.01.04 sit in the NIST 800-171 R3 Kill Chain? Phase 6b, Identify Compliance Stakeholders. The Kill Chain is a phased model for sequencing R3 implementation, and it assigns this requirement to that phase.
03.01.04 Separation of Duties decides which combinations of duties are too risky to sit with one person, then defines the access authorizations that keep them apart. It carries one of the cleaner transition paths in the family from R2 3.1.4, with one assessment objective mapping directly and one indirectly, so there is no net-new work in the objectives themselves. The recurring problem is treating it as a technical toggle. Separation is a design decision you have to document, its enforcement happens through 03.01.02 rather than here, and small teams have to address the duty conflicts they cannot fully separate. Identify the conflicting duties first, define the authorizations that separate them, then prove enforcement through 03.01.02.
Authoritative sources:
Authoritative sources:
This guide reproduces U.S. Government text from NIST 800-171 R3 and NIST 800-171A R3. It is educational, not legal or assessment advice. Last reviewed: 2026-09-22.
