Segregation of duties is the practice of splitting the steps of a sensitive process across different people so that no single person can start, approve, carry out, and hide an action on their own.
It is one of the oldest internal control ideas, borrowed from finance, and it applies directly to engineering and security work. The person who writes a code change should not be the only person who approves it. The person who requests elevated access should not be the person who grants it. The person who runs a control should not be the only person who reviews whether it worked.
In simple terms, segregation of duties answers:
- Which steps in this process are risky if one person controls all of them?
- Who is allowed to perform each step, and who checks it?
- When the same person must do more than one step, what extra check covers the gap?
Segregation of duties is often shortened to SoD. NIST and some other frameworks use the phrase separation of duties for the same idea.
Why Segregation of Duties Matters
Most damaging mistakes and most fraud need one person to control a full chain of steps without anyone else looking. Splitting the chain makes errors more likely to be caught and misuse harder to hide.
Segregation of duties matters because:
- A second person reviewing a change catches errors the author cannot see.
- Splitting request and approval makes it harder to grant yourself access you should not have.
- Separating operation of a control from review of that control keeps the review honest.
- Auditors look for it when they test change management, access management, and financial processes.
- It limits the damage a single compromised account can cause.
Common Examples in Engineering and Security
| Process | Duties to separate | Typical way teams separate them |
|---|---|---|
| Code changes | Author vs approver | Required pull request review by someone other than the author |
| Production deploys | Developer vs deployer | Deploys run through a pipeline after approval, not from a laptop |
| Access requests | Requester vs approver vs provisioner | Ticket approved by a manager or system owner, then provisioned by IT or an automated workflow |
| Access reviews | Account owner vs reviewer | Managers or system owners review accounts they do not personally use |
| Security exceptions | Requester vs risk approver | A security or business leader approves residual risk |
| Admin activity | Administrator vs log reviewer | Logs reviewed by someone without rights to edit them |
These are common patterns, not required designs. Each company decides which duties to separate based on its own risks and size.
Segregation of Duties in Small Teams
Small companies often cannot fully separate every duty. A five-person engineering team may have one person who can do almost everything in production.
When full separation is not practical, teams usually rely on compensating controls, such as:
- Required peer review on every change to protected branches, even if the reviewer is the only other engineer
- After-the-fact review of admin actions by a founder or manager
- Alerts on sensitive changes, such as new admin grants, sent to someone other than the actor
- Periodic review of deploy history against approved tickets
Document the gap, the substitute check, and who approved that decision. An undocumented gap looks like a missing control. A documented gap with a working substitute looks like a managed risk.
Segregation of Duties vs Related Terms
| Term | Primary job | How it relates |
|---|---|---|
| Segregation of duties | Split sensitive steps across people | Limits what any one person can do alone |
| Least privilege | Give each identity only the access it needs | Reduces how much any one account can do; SoD decides who does which step |
| Role-based access control | Grant access through roles | A common way to enforce SoD, by keeping conflicting permissions in separate roles |
| Workflow approval | Record who approved a step and when | Produces the evidence that a second person was involved |
| Change management | Control how changes reach production | One of the main processes where SoD is tested |
Evidence Themes Auditors May Expect
Auditors set their own procedures, but segregation of duties evidence commonly includes:
- A written description of which duties are separated in key processes, often in policies or the system description
- Configuration showing enforcement, such as branch protection settings that require approval from someone other than the author
- Samples of changes or access requests showing a different requester and approver
- Role definitions showing conflicting permissions are not combined without approval
- Documentation and execution records for any compensating controls where full separation is not possible
Framework Notes
SOC 2
The AICPA 2017 Trust Services Criteria, with revised points of focus published in 2022, list addressing segregation of duties as a point of focus under CC5.1, which covers selecting and developing control activities. SoD also shows up in practice when auditors test change management under CC8.1 and logical access under CC6. See What Are the Trust Services Criteria?.
NIST SP 800-53
NIST SP 800-53 Rev. 5 includes control AC-5, Separation of Duties, which calls for identifying duties that need separation and defining access authorizations to support it.
ISO 27001
ISO/IEC 27001:2022 Annex A includes control 5.3, Segregation of duties, which expects conflicting duties and areas of responsibility to be segregated.
Common Failures
- Authors able to approve and merge their own pull requests
- Admins who can bypass branch protection with no record or review
- One person who both requests and approves their own access
- Shared admin accounts, so nobody can tell who did what
- Small-team gaps with no documented compensating control
- Reviews performed by the same person who operates the control
How AuditFlo.co Helps
AuditFlo.co helps teams retain continuous evidence collection and audit-period history for operational artifacts when those records are stored or linked through connected systems and workflows your team already uses, such as GitHub and Jira.
For segregation of duties, that can mean dated history of pull request authors and approvers, ticket approvals, and access changes, so you can show a second person was involved without rebuilding it at audit time. Your code host, identity provider, and ticketing tools remain the systems of record. AuditFlo.co does not design your controls, does not issue SOC 2 reports, does not certify compliance, and does not replace auditors.
To see the workflow for your stack, request a demo.
Key Takeaway
Segregation of duties means no single person controls every step of a sensitive process. In engineering, that usually looks like separate authors and approvers for code, separate requesters and approvers for access, and separate operators and reviewers for controls. When a small team cannot separate a duty, document a compensating check and keep the records.