Separation of Duties

What is separation of duties?

Separation of duties (SoD) — also called segregation of duties — is a control that divides a sensitive process across multiple people (or systems) so that no single individual can complete it alone. The classic example: the person who requests a payment should not be the same person who approves it, and ideally not the same who executes it — splitting the process means fraud or error requires collusion or is caught by the second party. It’s a foundational principle in both security and financial governance, rooted in the idea that concentrating complete control over a critical action in one person’s hands is dangerous, whether that person is malicious or simply mistaken.

Why it works — fraud prevention and error catching

Separation of duties defends against two distinct threats at once. Malicious action (fraud): if completing a harmful action requires two or more independent parties, a single bad actor can’t do it alone — they’d need to collude with others, which is harder, riskier, and more detectable. A developer who can write code and deploy it to production unilaterally could ship malicious code; requiring a separate reviewer/approver means they can’t act alone. An accountant who can both create a vendor and pay it could invent a fake vendor and pay themselves; splitting those duties blocks it. Honest error (mistakes): the same division catches accidental catastrophes — the second person is a check that catches the typo, the wrong account, the unintended production change, before it does damage. This dual benefit (deterring fraud and catching mistakes) is why SoD appears throughout security frameworks and is often a hard compliance requirement — SOX (financial controls), PCI-DSS, and many regulatory regimes mandate separation of duties for sensitive operations precisely because concentrated control is a well-understood risk. It’s closely tied to the principle of least privilege (no one should have more control than their role requires) and enforced through access-control models like RBAC/ABAC.

Where it applies, and the realities

SoD applies wherever a single actor completing a whole sensitive process is dangerous. Finance: request/approve/execute payments split across roles. Software/DevOps: code review and approval before merge (no self-approval of your own changes), separation between who writes code and who can deploy to production, and separating access to production data from development — a developer shouldn’t unilaterally push code and access customer data and control the audit logs. Security operations: the person who administers a system shouldn’t be the sole person who reviews its audit logs (or they could cover their tracks) — separating administration from log review/monitoring is a key SoD control. Cloud/IAM: using roles and approval workflows so privileged actions require a second party, and separating who grants access from who uses it. Implementation increasingly leans on automation — enforced approval workflows, GitOps requiring reviewed pull requests, multi-account boundaries, and just-in-time access with approvals — which enforces SoD consistently without relying on human diligence. The realities and tensions: SoD trades efficiency for safety (more people/steps involved means more friction, which teams resent and try to bypass under time pressure — the “just approve your own change to ship the hotfix” temptation that quietly dismantles the control); it’s genuinely hard in small teams where there aren’t enough people to separate every duty (mitigations include compensating controls — extra logging, after-the-fact review, external approval — rather than abandoning SoD entirely); and it can be undermined by concentrated access even when nominally separated (if one super-admin can do everything, the org-chart separation is fiction — so it must be enforced technically via access controls, not just policy). The recurring mistakes: allowing self-approval (letting the requester approve their own action defeats the whole point), giving individuals concentrated access that bypasses the intended separation, treating SoD as a paper policy rather than a technically-enforced control, and dropping it entirely in small teams instead of using compensating controls.

What people get wrong

• Allowing self-approval — letting the same person request and approve (or write and deploy) unilaterally defeats separation of duties entirely; the second party must be independent.
• Concentrated access that bypasses it: nominal role separation is fiction if one super-admin can do everything — SoD must be enforced technically through access controls, not just the org chart.
• Dropping it in small teams — when you can’t fully separate duties, use compensating controls (extra logging, external/after-the-fact review) rather than abandoning the principle and hoping.

Primary source: NIST SP 800-53: Separation of Duties (AC-5)