Home / Knowledge hub / Separation of duties
Knowledge hub
Separation of duties
Splitting a sensitive task so no single person can complete it alone.
What it means
Separation of duties means a sensitive task is split into parts handled by different people, so no single person can complete it alone. The person who requests a payment is not the person who approves it, and the person who writes code is not the one who releases it.
The point is not to distrust anyone. It means one mistake or one stolen account is not enough to cause a serious loss, because a second person has to agree. It is also called segregation of duties, and the idea is old, as it comes from accounting.
Why it matters
It limits both fraud and error. Without it, one insider, or one taken-over account, can create a vendor, approve an invoice and release the money. Auditors for SOC 2 and ISO 27001 ask for it, and so do banks. It is a standard ask in vendor reviews.
It is also a design question for your product. If a customer's finance team needs this control, your software has to enforce it, not just allow it. An approval step that the requester can skip, or approve for themselves, gives the customer no protection.
How it shows up
You meet it in approval flows, refunds, payouts, user and role administration, and in code release, where branch rules require a second reviewer. The flaws are business-logic flaws: an approve button that works on one's own request, or an API call that skips the approval state.
Check that the server enforces it, not just the screen. Try approving your own request, changing the amount after approval, and reaching the final step directly. Watch role changes too, because a person who can grant themselves both roles has undone the split.
Questions people ask
Separation of duties, answered
Is separation of duties the same as least privilege?
They work together but differ. Least privilege limits how much access any one account has. Separation of duties makes sure a risky task needs more than one person.
Do small teams need it?
The principle still applies, even if one person sometimes covers two roles. Where it is hard, use compensating controls such as review after the fact and tight logging.
Where does it appear in standards?
NIST SP 800-53 lists it as a control, and ISO 27001 Annex A includes segregation of duties. Both expect conflicting duties to be separated. Both ask for it in writing, and auditors will test whether the software actually enforces it.
How can software break it?
Through an approve action that accepts the requester, a state that can be skipped by calling a later step directly, or a role editor that lets someone give themselves both permissions.
How do we test it?
Try each step as the wrong person, try to approve your own request, and try to change details after approval. Each should be refused and should leave a record.
Sources
Where this comes from
Related
Terms that sit next to this one
Least privilege
Giving every person and service the minimum access the job requires.
Business logic flaw
Nothing is technically broken, but your own rules turn against you.
Workflow bypass
Skipping a required step, such as payment or approval, by calling a later one directly.
Role escalation
Changing your own role, or another's, through a flaw in how roles are assigned.
Audit log
A record of who did what and when, kept so you can answer later.
Can one account finish the job?
Approval flows are a common home for business-logic flaws, and we test them on the running app, proving whether one account can skip or self-approve a step. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.