Separation of Duties

Separation of duties (SoD) is one of those controls that sounds like “IAM hygiene,” but FedRAMP assessors test it like a fraud-prevention and change-integrity requirement. Under NIST SP 800-53 Rev. 5 AC-5, you are expected to decide which duties in your environment are incompatible, document that decision, then build access authorizations that prevent one person from completing an end-to-end sensitive action without oversight. ¹

For a Cloud Service Provider (CSP) pursuing or maintaining FedRAMP Moderate, SoD is rarely satisfied by a generic policy statement. You need an operational model: roles, approvals, technical enforcement points, and a repeatable review cadence that catches drift (for example, engineers accumulating permissions across identity providers, cloud consoles, CI/CD, and ticketing tools).

This page gives requirement-level implementation guidance you can execute quickly: what to define, what to configure, what to collect as evidence, and what to expect from assessors during initial authorization and ongoing continuous monitoring. ¹

Separation of duties requirement (FedRAMP / NIST SP 800-53 AC-5)

Requirement statement you must implement: identify and document duties that require separation, then define system access authorizations that support that separation. ¹

Plain-English interpretation

You must decide where “one person can do the whole thing” creates unacceptable risk in your system, then prevent that outcome with access design.

In practice, SoD focuses on:

• Preventing self-approval (requesting and approving your own access, changes, or exceptions).
• Preventing unilateral high-impact change (one person pushing code, approving it, deploying it, and modifying logging to hide it).
• Preventing concealed misuse (one person both initiates and reconciles sensitive actions such as billing changes, key management, or security telemetry suppression).

NIST gives you flexibility (“organization-defined duties”), but that flexibility creates an audit burden: you must show your defined duties make sense for your system and you actually enforce them. ¹

Regulatory text

“Identify and document organization-defined duties of individuals requiring separation; and define system access authorizations to support separation of duties.” ¹

Operator translation:

1. Identify and document duties requiring separation: Produce a written SoD model that names the conflicting duties, the systems/tools where those duties occur, and the roles/groups that perform them.
2. Define access authorizations to support SoD: Configure RBAC/ABAC, privileged access pathways, approval workflows, and technical restrictions so a single identity cannot hold conflicting permissions (or can only do so under controlled, approved exceptions).

Who it applies to

Entities

• Cloud Service Providers (CSPs) operating a cloud service offering within a FedRAMP authorization boundary.
• Federal agencies to the extent they operate or manage roles within the authorized boundary or shared responsibility model. ¹

Operational context (where auditors will look)

• Identity stores and SSO (IdP), directory groups, MFA enforcement.
• Cloud control planes (IaaS/PaaS admin roles), SaaS admin consoles.
• CI/CD and source control (merge rights, release approvals, pipeline admin).
• Security tooling (SIEM admin, EDR admin, logging pipeline access).
• Key management and secrets (KMS admins, HSM operations, vault admins).
• Ticketing and change systems (change approvers, emergency change processes).

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

Step 1: Define your SoD scope and “sensitive functions”

Start by listing system functions where improper access creates material security impact. Keep it system-specific.

Common FedRAMP-relevant sensitive functions include:

• Account and access provisioning for privileged roles
• Security configuration changes (network policies, IAM policies, endpoint policies)
• Log configuration and log deletion permissions
• Key management operations (create/rotate/delete/export controls where applicable)
• Code merge and production deployment approvals
• Vulnerability exception approvals
• Backup/restore operations and data export controls

Deliverable: a scoped inventory of sensitive functions mapped to tools/systems.

Step 2: Build a conflict matrix (incompatible duties)

Create a simple table that states “Role A cannot be combined with Role B” and why.

Example conflict matrix (adapt to your environment):

Duty / Role	Conflicts with	Why it must be separated	Enforced where
Access requester	Access approver	Prevent self-approval and collusion	Ticketing/ITSM workflow
IAM admin (IdP)	Audit/log admin	Prevent hiding identity changes	IdP + logging platform
Code committer	Code approver/merger	Reduce risk of unreviewed changes	Git platform
Release manager	Production deploy approver	Prevent unilateral production changes	CI/CD + change tool
Incident responder	Evidence custodian/log deletion	Preserve evidence integrity	SIEM + storage controls
KMS admin	Application admin	Prevent key misuse aligned with app changes	KMS + cloud IAM

Deliverable: SoD conflict matrix approved by security/CCO and system owner.

Step 3: Map conflicts to real access entitlements

Auditors do not test job titles; they test permissions. Translate each duty into:

• IAM roles (cloud roles)
• Directory/IdP groups
• Application roles
• “Break-glass” roles
• Repository permissions and branch protections
• CI/CD permissions
• Logging platform admin permissions

Deliverable: an entitlement map that ties SoD conflicts to specific groups/roles.

Step 4: Implement technical enforcement (prevent toxic combinations)

Use controls that stop conflicts from happening, not just detect them later.

Common enforcement patterns:

• RBAC with mutually exclusive groups: design groups so conflicting roles cannot be assigned together.
• Approval workflows: access requests require approval by a different person with appropriate authority.
• Just-in-time (JIT) privileged access: time-bound elevation for admin actions, with approval and logging.
• Branch protections / two-person review: require independent approval for merges to protected branches.
• Change control gates: production changes require a change record and approval separate from implementer.

Deliverable: configuration screenshots/exports and documented procedures showing how SoD is enforced.

Step 5: Define an exception process (and keep it rare)

Some orgs have small teams and need exceptions. FedRAMP assessors can accept exceptions if they are controlled and evidenced, but you must treat them as risk decisions.

Minimum elements for SoD exceptions:

• Business justification and scope (what conflict, what systems)
• Compensating controls (extra logging, added reviews, time limits, increased monitoring)
• Explicit approver (system owner + security, and compliance where required)
• Start/end date and removal trigger (role change, project end, staffing change)
• Post-activity review (verify actions taken)

Deliverable: SoD exception register with approvals and closure evidence.

Step 6: Review access against the conflict matrix on a defined cadence

SoD fails over time due to permission sprawl. Your review should:

• Compare current entitlements to the conflict matrix
• Identify toxic combinations
• Document remediation (removal, role redesign, or approved exception)

Deliverable: periodic access review records that explicitly test SoD conflicts (not generic “manager attests access”).

Step 7: Prove it continuously (FedRAMP operations)

During continuous monitoring, you need to show the control still operates:

• New joiners, movers, leavers handled correctly
• Privileged access grants tracked and removed
• Exceptions reviewed and closed

Deliverable: ongoing evidence packet ready for assessors.

Required evidence and artifacts to retain

Keep artifacts in an auditor-ready folder aligned to AC-5.

Design evidence

• Separation of Duties policy/standard referencing AC-5 ¹
• SoD conflict matrix (version-controlled, dated, approved)
• Role/entitlement mapping (roles to groups to permissions)
• System Security Plan (SSP) statements describing SoD implementation approach (FedRAMP assessors will look for consistency with your SSP) ²

Operational evidence

• Access requests and approvals (show requestor ≠ approver)
• Provisioning records (IdP logs, IAM change logs)
• Access review outputs tied to SoD conflicts
• Deprovisioning evidence (termination, role changes)
• Exception requests, approvals, compensating controls, and closure
• Evidence of technical controls (branch protection settings, JIT configs, PAM records, workflow configs)

Common exam/audit questions and hangups

Expect assessors to ask for specifics and test samples.

Common questions

• “Show us your documented incompatible duties for this system.” ¹
• “How do you prevent one person from requesting and approving privileged access?”
• “Who can modify audit logs, and how do you ensure they cannot also administer identity or security controls?”
• “Demonstrate how code changes are independently reviewed and how production releases are authorized.”
• “Show evidence from a recent period that you reviewed access against your SoD conflicts.”

Hangups that cause findings

• SoD described in policy but not mapped to permissions.
• “Two-person rule” claimed, but approvals happen in chat with no record.
• Access reviews exist, but they don’t check for toxic combinations.
• Break-glass accounts exist with shared credentials or weak controls.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Documenting SoD at the org chart level.
   Fix: document SoD at the entitlement level (groups, roles, permissions) and maintain a mapping.

2. Mistake: Relying on “management oversight” as the control.
   Fix: add technical guardrails (mutually exclusive roles, workflow approvals, branch protections) and keep oversight as a backstop.

3. Mistake: Ignoring non-production admin paths.
   Fix: include CI/CD admin, logging admin, and IdP admin in your SoD model. Those paths often bypass traditional change control.

4. Mistake: Exceptions without expiration.
   Fix: require end dates and removal triggers, and track exceptions in a register with periodic re-approval.

5. Mistake: No clear owner for SoD conflicts.
   Fix: assign ownership to the system owner and IAM/security leadership; compliance verifies evidence quality.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, but the operational risk is straightforward: weak SoD makes it easier for unauthorized changes, concealed misuse, and hard-to-explain privileged access to persist. In FedRAMP work, that turns into assessor findings, delayed authorization, and ongoing continuous monitoring friction because you cannot justify why specific privileged users had conflicting access. ¹

Practical 30/60/90-day execution plan

Use this as a sprint plan for a CSP team preparing for assessment or remediating a finding. Timeframes are guidance, not a regulatory deadline.

First 30 days (stabilize and define)

• Name an SoD owner (IAM/security) and an approver (system owner).
• Inventory sensitive functions and where they occur (IdP, cloud IAM, CI/CD, logging, KMS).
• Draft the conflict matrix and get formal approval.
• Identify current toxic combinations (quick entitlement review across privileged groups).
• Stand up an exception process and register; migrate any “informal exceptions” into it.

Days 31–60 (enforce and instrument)

• Implement mutually exclusive groups/roles where feasible.
• Add or tighten approval workflows for privileged access requests (requestor ≠ approver).
• Add technical change controls: branch protections, required reviews, deployment approvals.
• Create an evidence capture routine (ticket templates, export scripts, log retention pointers).
• Pilot a targeted SoD access review using the conflict matrix, then remediate findings.

Days 61–90 (operate and prepare for assessment)

• Run the SoD review on your defined cadence and document remediation outcomes.
• Validate offboarding and role-change triggers remove conflicting access promptly.
• Test break-glass access: ensure it is time-bound, logged, and reviewed.
• Update the SSP/control narratives to match how SoD actually works in production ²
• Build an “AC-5 evidence packet” with samples: requests, approvals, provisioning logs, reviews, and exception closures.

Where Daydream fits naturally: Daydream helps you maintain the SoD conflict matrix, tie it to entitlement evidence (tickets, logs, access reviews), and keep an assessor-ready record set as your environment changes, so AC-5 stays continuously defensible instead of becoming a quarterly scramble.

Frequently Asked Questions

What’s the minimum documentation an assessor will expect for separation of duties?

A written definition of incompatible duties for your system plus evidence that access authorizations enforce it. The fastest way is a conflict matrix mapped to roles/groups and a set of access review and approval records. ¹

Can a small team meet SoD if people wear multiple hats?

Yes, but you need controlled exceptions with compensating controls, explicit approvals, and a clear end condition. Treat each exception as a documented risk decision with traceable evidence. ¹

Does SoD only apply to production access?

No. Assessors often focus on identity administration, logging administration, CI/CD administration, and key management because those can bypass normal controls. Your conflict matrix should cover those pathways.

How do we prove “requestor ≠ approver” in practice?

Use an access request workflow that records the requester and approver identities and blocks self-approval. Retain the ticket and the provisioning/audit log that shows the change was applied.

Are periodic access reviews enough to satisfy AC-5?

Reviews help, but AC-5 also expects access authorizations designed to support SoD. Auditors commonly expect preventive design (role design, approvals, technical gates) plus review evidence. ¹

What evidence usually fails in FedRAMP assessments for SoD?

Generic policies without entitlement mapping, approvals captured outside auditable systems, and access reviews that don’t test toxic combinations. Keep everything tied to specific roles, systems, and sampleable records.

Footnotes

1. NIST Special Publication 800-53 Revision 5

2. FedRAMP documents and templates