Separation of duties means no single person can complete a risky action alone. On a small team you cannot split every role, so you pair the few actions that matter most, such as shipping code and moving money, and add logging and review where pairing is impossible.
What the control asks
NIST SP 800-53 AC-5 asks organisations to define which duties should be divided among different people, document them, and set access so that no single person can perform conflicting functions. The aim is to reduce the chance that one person could misuse authorised access without anyone else being involved.
It also notes that where one person holds several critical roles, compensating measures such as stronger screening and more auditing should be added. That sentence is the permission slip for small teams.
Pick the conflicts that matter
Do not try to separate everything. Start with these pairs:
- Request and approve: the person who writes a production change is not the only person who approves it.
- Create and pay: the person who adds a vendor does not release payment to that vendor.
- Grant and use: the person who grants admin access is not the only one who reviews its use.
- Develop and release: the author of code is not the sole approver of its merge.
Four rules cover most of the realistic fraud and error risk in a startup.
Use your tools to enforce it
Policy text is weak. Settings are strong.
- Require at least one approving review on pull requests to your main branch, and block self-approval.
- Protect the production deploy path so only a pipeline can release, not a laptop.
- Require two admins to confirm changes to billing details or payout accounts.
- Keep the owner or root credentials in a vault that needs a second person to open.
Two-party approval for changes to sensitive components appears in the same catalogue as CM-5(4). See also change management for small teams.
When you truly cannot split
With three people, someone will hold two roles. Compensate:
- Send a weekly report of the conflicting activity to someone outside the pair, such as the CEO or an advisor.
- Log the actions to a store the actor cannot alter.
- Review a sample of actions each month and record that you did.
- Rotate who holds the dual role.
Write down which conflicts you accepted, why, and what compensates. That record is what auditors and customers want to see.
Common mistakes
Approval theatre is the biggest. A reviewer who clicks approve in ten seconds adds nothing. Another is the shared admin login, which defeats attribution entirely. A third is exceptions that never expire.
Safeguard's policies, gates and guardrails can help enforce review requirements in the software delivery path, one piece of a wider duty-separation design.
Quick check
Do I need separation of duties for SOC 2?
Your auditor decides what evidence they need, so ask them early. Documented pairing or compensating controls for production changes and access administration are a sensible starting position.
Can the founder approve their own changes?
Technically yes if you accept it, but document it as an exception and add after-the-fact review by someone else.
Sources
- AC-5 Separation of Duties, NIST SP 800-53 Rev. 5
- CM-5 Access Restrictions for Change, NIST SP 800-53 Rev. 5
Last reviewed: 19 October 2026.
