AC-5: Separation of Duties

AC-5: separation of duties requirement means you must identify which duties in your system are “incompatible” (too risky for one person or role to perform end-to-end), document them, and implement access controls and workflows so no single identity can complete those high-risk actions alone. Operationalize AC-5 by building an SoD matrix, mapping it to RBAC/ABAC roles, and collecting repeatable evidence.

Key takeaways:

• Define and document “incompatible duties” for your environment, then enforce them in IAM and workflows ¹.
• Make SoD testable: link each incompatible duty pair to systems, roles, approvals, and monitoring evidence.
• Audit readiness comes from artifacts: SoD matrix, role definitions, access reviews, exceptions, and sampled tickets showing enforcement.

AC-5 is an access control requirement that examiners treat as a practical control, not a policy statement. You are expected to name the specific duties that create unacceptable fraud, error, or unauthorized change risk when concentrated in one person or one role. Then you have to show the split is real in day-to-day operations: identities are provisioned into separated roles, approvals route to independent reviewers, and logs/tickets prove the separation is consistently enforced.

This requirement matters most where a single actor could both initiate and approve a transaction, both develop and deploy code, or both administer and audit the same system. Separation of duties (SoD) is also a common failure mode in smaller teams and fast-moving engineering orgs because “temporary” access becomes permanent and manual review steps get bypassed.

This page translates the ac-5: separation of duties requirement into a short set of decisions, an implementation sequence you can run, and an evidence plan you can maintain with minimal overhead. Where helpful, it also points to adjacent NIST control families you can cross-reference to make SoD durable (for example, access enforcement, account management, logging, and configuration management) ².

Regulatory text

NIST SP 800-53 Rev. 5 AC-5 (excerpt): “Identify and document {{ insert: param, ac-05_odp }} ; and” ¹.

Operator translation: the “{{ insert: param, ac-05_odp }}” placeholder in the OSCAL excerpt refers to organization-defined parameters. In practice, you must:

1. Decide what separation is required in your environment (the incompatible duties), and
2. Write it down in a control statement and supporting procedure, so it is assessable and repeatable ¹.

NIST leaves the exact list to you because incompatible duties differ by mission, system type, and risk. Auditors will still expect specificity: named duty pairs, named systems in scope, and named enforcement points.

Plain-English interpretation (what AC-5 is really asking)

AC-5 expects you to prevent a single identity from having enough privilege to:

• Create a risky change and push it into production without independent review.
• Create/modify a financial or high-impact record and approve/settle it.
• Administer security controls and override or tamper with the evidence (logs, alerts, approvals).

In operational terms, you’re building “two-person integrity” for a selected set of actions. The requirement is not “two people for everything.” It is “two separate roles (or people) for the actions that could cause high impact if abused or mistaken.”

Who it applies to (entity + operational context)

AC-5 applies wherever NIST SP 800-53 is your baseline or contract requirement, especially:

• Federal information systems ².
• Contractor systems handling federal data ².

Operationally, prioritize SoD for:

• IAM administration (identity creation, role assignment, privileged access).
• Production change pathways (code, infrastructure-as-code, CI/CD, database schema changes).
• Security tooling administration (SIEM, EDR, audit log stores, key management).
• Business workflows with approval/settlement (procurement, payments, refunds, credits).

If you are a smaller organization, AC-5 still applies. You may implement SoD through workflow approvals, time-bounded privileged access, and compensating monitoring, but you must document the design choice and keep the evidence.

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

Step 1: Define scope and “high-risk duties”

Create a short inventory of:

• Systems that process sensitive data or drive mission-critical outcomes.
• Privileged role families (cloud admin, DB admin, security admin, CI/CD admin).
• High-impact business workflows (if applicable).

Output: AC-5 scope statement (systems + workflows + privileged platforms).

Step 2: Build an SoD matrix (the core AC-5 artifact)

Create a table with incompatible duty pairs. Keep it concrete and system-mapped.

Example SoD matrix structure:

Process area	Duty A	Duty B (must be separate)	Systems	Enforcement method	Evidence source
Change management	Approve change	Deploy to prod	CI/CD, cloud	Branch protection + deployment permissions	PR records + deployment logs
IAM	Create user / assign roles	Approve privileged access	IdP, PAM	Access request workflow	Tickets + access review report
Logging	Admin SIEM config	Delete/alter logs	SIEM, log archive	Immutable storage + restricted delete	Storage policy + audit logs

Output: SoD matrix v1 owned by Security/GRC with technical owners per row.

Step 3: Map duties to roles (RBAC/ABAC) and people

For each duty pair:

• Define the roles/groups that perform Duty A and Duty B.
• Verify no role grants both.
• Identify service accounts and automation identities that may bypass human separation.

Output: Role design doc (or access control design) that references the SoD matrix.

Step 4: Implement enforcement points (make SoD real)

Pick enforcement mechanisms that are hard to bypass:

• IAM controls: separate admin roles; deny policies preventing dual assignment; privileged roles behind PAM.
• Workflow controls: ticketing approvals from an independent approver group; required peer review for code.
• Technical controls: branch protection, environment protections, change gates, separate cloud accounts/subscriptions for prod.

Output: Configuration evidence (policy exports, screenshots, config-as-code commits) tied to each SoD matrix row.

Step 5: Define exceptions and compensating controls (and time-box them)

You will have exceptions. Treat them as controlled risk:

• Require written exception justification, scope, and expiry.
• Add compensating controls (heightened logging review, after-the-fact independent review, time-bounded access).
• Track exceptions in a register.

Output: SoD exception register + approval records.

Step 6: Operationalize recurring checks

AC-5 fails most often at drift: people change teams, roles accumulate, contractors stay enabled.

• Run periodic access reviews for privileged roles.
• Monitor for dual-role assignment (alerts when an identity is in conflicting groups).
• Sample test SoD in audits: pick transactions/changes and show two separate identities performed required steps.

Output: Access review results, alert evidence, sample-based test package.

Step 7: Make it assessable in your control narrative

Write a control narrative that answers:

• Which duties are incompatible (by reference to matrix)?
• How do you enforce separation (systems, roles, workflows)?
• How do you detect and correct violations?
• What evidence is produced and where it is stored?

If you use Daydream, map AC-5 to a named control owner, the implementation procedure, and the recurring artifacts so the evidence set stays current across audits ¹.

Required evidence and artifacts to retain (audit-ready set)

Minimum evidence set that maps cleanly to AC-5:

• SoD matrix with version history and approvals.
• Role/group definitions (IdP exports, cloud IAM role policies, PAM role catalogs).
• Workflow configurations (ticketing approval rules, change gates, PR protections).
• Access request samples showing independent approvals for privileged access.
• Access review reports for privileged roles and remediation tickets.
• Exception register with expirations and compensating controls evidence.
• Violation monitoring evidence (alerts, detections, investigations) where implemented.

Tip: Store evidence by SoD matrix row so an auditor can trace requirement → duty pair → enforcement → proof.

Common exam/audit questions and hangups

Expect these:

• “Show me your list of incompatible duties and who approved it.”
• “Prove a developer cannot deploy to production without an independent approver.”
• “Do any admins have both the ability to grant privileges and approve their own access?”
• “How do you prevent service accounts from bypassing SoD?”
• “How do you manage exceptions, and are they time-bounded?”

Hangups:

• Policy-only SoD with no technical enforcement.
• Undefined parameters: you never decided what the “organization-defined” duties are ¹.
• Over-broad roles (“Admin” does everything), making separation impossible.

Frequent implementation mistakes (and how to avoid them)

1. Writing “we have SoD” without naming incompatible duties.
   Fix: publish an SoD matrix with duty pairs and in-scope systems.

2. Relying on manager approval as “independent” when the manager is also an operator.
   Fix: define independence criteria (different team, different role, no shared credentials).

3. Ignoring break-glass access.
   Fix: enforce time-bounded elevation, require post-event review, and log retention for those sessions.

4. Forgetting automation identities.
   Fix: inventory service accounts; restrict token scopes; separate build vs deploy permissions.

5. Exception sprawl.
   Fix: require expirations, periodic review, and measurable compensating controls (ticket samples, log review records).

Enforcement context and risk implications

No public enforcement cases were provided in the source material, so you should treat AC-5 as an assessment-driven requirement rather than a “case law” topic for this page. The risk is still straightforward: weak SoD increases the chance of unauthorized changes, fraud, and undetected security control tampering. For federal and federal-adjacent environments, it also increases the likelihood of audit findings and POA&M items tied to access control weaknesses ².

Practical execution plan (30/60/90-day)

30 days (foundation)

• Assign an AC-5 control owner and technical owners per system.
• Draft SoD matrix v1 for privileged access + production change paths.
• Document independence rules and a simple exception process.

60 days (enforcement + evidence)

• Implement IAM role separation and remove conflicting memberships.
• Turn on workflow gates (approvals, branch protections, environment protections) for in-scope systems.
• Start capturing evidence: exports, tickets, and a small sample set proving enforcement.

90 days (sustainment)

• Run the first privileged access review and remediate conflicts.
• Add monitoring/detection for conflicting role assignment.
• Operationalize exception expiry and re-approval, and package AC-5 evidence for audit reuse.

If you need to move fast, Daydream helps by keeping AC-5 mapped to owners, procedures, and recurring evidence artifacts so your SoD matrix and proof do not decay between audits ¹.

Frequently Asked Questions

Do we need two different people for every production change to meet AC-5?

No. AC-5 expects separation for defined incompatible duties. You choose which duties require separation, document them, and enforce them consistently ¹.

We’re a small team. How can we implement separation of duties without adding headcount?

Use workflow-based separation (independent approvals), time-bounded privileged access, and compensating monitoring. Document the exception model and keep evidence of approvals and reviews.

What’s the minimum artifact an auditor will ask for first?

An SoD matrix (or equivalent) that names incompatible duties and maps them to systems and enforcement points. Without it, you cannot show you “identified and documented” the organization-defined separation ¹.

Does AC-5 apply to service accounts and CI/CD robots?

Yes in practice, because automation can hold end-to-end privilege. Treat service accounts as identities: separate build, approve, and deploy permissions, and document the split in the SoD matrix.

How do we handle emergency “break-glass” access while maintaining SoD?

Require time-bounded elevation, restrict who can initiate break-glass vs who can approve it (where feasible), and mandate independent post-incident review with retained logs and tickets.

Can compensating controls replace SoD?

Sometimes, for specific constraints, but you should treat compensating controls as exceptions: documented rationale, explicit scope, defined monitoring/review, and an expiry or re-approval cycle.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5