A.5.3
Segregation of duties
ISO 27001 · ISO/IEC 27001:2022 · Last verified July 2026
Objective
Separate conflicting duties and areas of responsibility so no single individual can authorize, execute, and conceal an unauthorized or unintentional action unchecked.
Points of focus
- Conflicting duties identified: code authorship vs. approval, deployment vs. change approval, payment initiation vs. authorization
- Branch protection and CI/CD gates enforce a second approver before merge and deploy
- Compensating controls documented where true separation is not feasible for a small team
- Finance and infrastructure admin access split from engineering where practical
Implementation notes
Enforce segregation with tooling, not policy language: branch protection requiring approval from someone other than the author, a separate CI/CD gate for production deploys, and IAM roles where the ability to approve access is not held by the same identity that grants it. In a small engineering team where one or two people hold broad access by necessity, write down the compensating control explicitly — for example, deploy notifications routed to a second engineer, or a monthly review of admin actions by someone outside the deploy path. Extend the same logic to finance: whoever approves a vendor contract or invoice should not also be the one who pays it. Revisit the segregation-of-duties matrix whenever the team is small enough that a single new hire changes who can act unilaterally.
Audit tip: Have an engineer open the repository settings live and show that the branch-protection rule actually applies to admin accounts, not just regular contributors — 'require review' toggles are commonly bypassed for the account that matters most.
Evidence auditors typically request:
- Branch protection rules requiring a review from someone other than the author, including for admin accounts
- CI/CD pipeline configuration showing a separate approval gate for production deploys
- IAM or role policy showing the ability to approve, merge, and deploy are not identical grants
- Documented compensating control, such as deploy notifications to a second reviewer, where a founder or sole admin can technically self-approve
Common gaps
- An admin or founder account can author, approve, and merge its own pull request because branch protection is bypassed for that account
- Deploy keys or CI service tokens are shared across the team instead of scoped per pipeline
- The same person can both approve a vendor invoice and issue payment from the corporate card
- A compensating control is assumed but never written down, so an auditor has nothing to sample
Cross-Framework Mapping
| Framework | Requirement | Implementation note |
|---|---|---|
| ISO 27001 | A.5.3 | This control |
| SOC 2 | CC8.1 | CC8.1 expects change authorization to be separate from execution — the same branch-protection evidence gathered for A.5.3 usually satisfies both. |
| GDPR | Article 32 | Article 32 lists integrity and access controls broadly; segregation of duties is one supporting control among several — do not present it as the complete Article 32 answer. |
Primary sources
- ISO/IEC 27001:2022 Annex A: ISO/IEC 27001:2022 Annex A (A.5.3)