Many security incidents don’t happen because controls don’t exist—they happen because too much power sits with one person or one role. Over my 30 years in governance, risk, and compliance, I have seen far too many small businesses, tech startups, and growing teams grant global administrative privileges to a single star developer or IT lead. When one person can initiate a system change, approve that change, deploy it directly into production, and modify or delete the audit logs to cover their tracks, your entire business operates at the mercy of single-point human failure, unmonitored fraud, or accidental widespread destruction. Annex A 5.3 is about introducing checks and balances to ensure no single individual holds unchecked power over your critical assets.
ISO 27001:2022 includes Annex A 5.3 to ensure your organisation identifies, documents, and segregates conflicting roles and responsibilities to prevent error, misuse, and fraud. This control updates former 2013 requirements (6.1.2) and serves as an essential governance pillar connecting access control policy (Annex A 5.15), privileged access management (Annex A 8.2), change management (Annex A 8.32), and secure code deployment (Annex A 8.28).
Quick Summary: What ISO 27001 Annex A 5.3 Requires
At a practical level, Annex A 5.3 is about preventing toxic combinations of duties that allow one person to execute, approve, and conceal a security breach or operational error. Crucially, the standard recognizes that small businesses and early-stage tech teams with under 10 people cannot maintain rigid corporate role separation; it explicitly allows for risk-proportionate compensating controls when full segregation is headcount-constrained. Here is what you need to do in plain English:
- Identify Toxic Role Combinations: Map critical business processes and pinpoint conflicting duties (e.g., developer + production deployer, access requestor + access approver, payment creator + payment releaser).
- Enforce Separation Across High-Risk Workflows: Split key execution, authorization, and review steps across different individuals where team size allows.
- Apply Technical Enforcement Barriers: Configure system permissions, CI/CD pipelines, and identity management rules to enforce dual-authorization and peer reviews automatically.
- Implement Pragmatic Compensating Controls for Small Teams: Where headcount constraints prevent physical role separation, apply independent management logging, automated alerting, and retrospective audit reviews (Annex A 8.15).
- Protect Audit Logs from Admin Manipulation: Ensure system administrators and developers cannot edit or purge central audit logs (Annex A 8.15).
- Review Segregation Rules During Role Changes: Re-assess segregation during internal employee transfers, promotions, or system re-architecting (Annex A 5.18).
Why Unchecked Role Power Is a Critical Hazard
When an organisation operates without segregation of duties, it relies entirely on implicit personal trust rather than defensible security controls. Trust is a vulnerability, not an information security control.
Ignoring segregation of duties controls exposes your business to severe hazards:
- Unmonitored Internal Fraud & Embezzlement: A finance manager or executive creating a fake vendor, approving the invoice, and releasing bank payments without dual-authorization (Annex A 5.20).
- Rogue Code Deployments & Production Corruption: A developer committing untested or malicious code directly into production branches without peer code review or release approval (Annex A 8.28 & Annex A 8.32).
- Self-Approved Privileged Escalation: IT staff requesting elevated system access, approving their own access ticket, and assigning themselves global admin rights indefinitely (Annex A 8.2).
- Un-investregatable Incidents via Log Deletion: System admins committing unauthorized changes and deleting or tampering with central SIEM logs to erase evidence (Annex A 8.15).
My 8 Step Plan to Implement Annex A 5.3 Fast
You do not need a 500-person enterprise hierarchy to satisfy an ISO 27001 auditor. Here is my pragmatic, 8-step plan to establish an audit-ready segregation of duties framework—even for small businesses and early-stage tech teams.
1. Document a Pragmatic Segregation of Duties Policy
Incorporate a concise Segregation of Duties Policy into your master ISMS documentation (Annex A 5.1):
- Define core principles: no single individual may initiate, authorize, execute, and review a high-risk transaction or system change.
- Identify specific high-risk business domains requiring segregation: Finance/Payroll, Software Engineering/Production Deployments, System/Access Administration, and Information Security Audit.
- Outline explicit rules for managing headcount constraints through documented compensating controls.
2. Map Toxic Duty Combinations Across Core Operations
Perform a quick risk assessment to map conflicting duties across your business functions:
| Operational Domain | Primary Duty (Execution) | Conflicting Duty (Authorization / Review) | Toxic Combination Risk |
|---|---|---|---|
| Access Management | Requesting system access | Approving access tickets | Self-granting unauthorized administrative privileges (Annex A 5.18). |
| Software Delivery | Writing application code | Merging & deploying to production | Pushing untested, bug-ridden, or malicious code to live users (Annex A 8.28). |
| Financial Operations | Creating vendor accounts/invoices | Approving & releasing payments | Embezzling funds via fraudulent vendor accounts (Annex A 5.20). |
| IT Administration | Executing system changes | Managing / Editing audit logs | Concealing unauthorized changes or malicious activities (Annex A 8.15). |
| Security Governance | Designing security controls | Auditing security compliance | Marking non-compliant controls as compliant to avoid remediation work (Annex A 5.36). |
3. Enforce Code & Deployment Segregation in CI/CD Pipelines
For tech startups and SaaS businesses, developer-to-production segregation is a major auditor focus (Annex A 8.28 & Annex A 8.32):
- Protect main/production code branches in GitHub, GitLab, or Bitbucket, preventing direct commits.
- Enforce mandatory “Pull Request (PR) Peer Reviews”: require at least one independent developer to review and approve code before merging.
- Separate development, staging, and production environments using distinct access permissions and service accounts (Annex A 8.31).
4. Enforce Segregation in Access Request Workflows
Eliminate self-approval in identity and access management (Annex A 5.18):
- Configure Helpdesk and Identity Provider (IdP) workflows to block users from approving their own access requests.
- Require explicit Information Asset Owner sign-off before IT Helpdesk staff can provision elevated access (Annex A 8.9).
- Separate standard user administration roles from Privileged Access Management (PAM) vault administration (Annex A 8.2).
5. Implement Dual-Authorization for Financial Transactions
Protect commercial assets by enforcing four-eyes principles across financial channels:
- Configure online banking portals to require dual-authorization (one person inputs the invoice/payment; a second independent lead approves and releases funds).
- Require explicit C-suite approval for bank account creation, payroll file modifications, or expenditure above agreed financial thresholds.
- Separate procurement vendor setup from payment approval workflows (Annex A 5.20).
6. Apply Pragmatic Compensating Controls for Small Teams (< 10 People)
If you have a small team where full segregation is physically impossible, apply auditor-approved compensating controls:
- Independent Retrospective Review: If a lead engineer must deploy code directly due to small team size, require a secondary lead or founder to conduct weekly retrospective log reviews of all production deployments.
- Automated Change Alerts: Configure automated Slack or email alerts to send real-time notifications to the CISO/Founder whenever administrative changes or production deployments occur.
- Read-Only Immutable Logging: Ship all system, cloud, and deployment logs instantly to a separate, read-only SIEM or log repository (e.g., AWS S3 Object Lock) that admins cannot edit or delete (Annex A 8.15).
- External Lead Auditor Verification: Engage an independent third-party auditor to conduct bi-annual reviews of administrative activity and change logs.
7. Protect Central Audit Logs from Administrative Tampering
The ultimate goal of segregation is preventing the concealment of actions (Annex A 8.15):
- Separate IT Administration roles from Log Administration roles.
- Enforce write-once-read-many (WORM) storage configurations for audit logs to prevent any user—including global administrators—from modifying or purging historical logs.
- Configure alerts for log disruption: trigger instant high-severity security alerts if log ingestion is disabled or modified.
8. Audit Segregation Controls During Access Reviews
Verify that segregation boundaries remain effective over time (Annex A 5.36):
- Include segregation-of-duties checks in bi-annual user access rights reviews (Annex A 5.18).
- Verify that internal job transfers or promotions (“movers”) have legacy conflicting access permissions stripped cleanly.
- Document all identified toxic role combinations, risk acceptances, and compensating controls inside your master ISMS Risk Register (Annex A 8.9) for auditor inspection.
Common Implementation Pitfalls and How to Fix Them
When preparing clients for ISO 27001 audits, I frequently spot the same segregation of duties mistakes. Here are the main traps and how to solve them:
- Problem: Claiming “We Are Too Small for Segregation” and Doing Nothing to Address Unchecked Power
Ninja Solution: Implement compensating controls—immutable logging, automated change notifications, dual-bank approvals, and weekly retrospective management reviews. - Problem: Allowing Developers to Deploy Directly to Production Without Peer Review or Approval
Ninja Solution: Lock master repository branches in GitHub/GitLab and mandate at least one independent Pull Request peer review before merging code. - Problem: Global Administrators Holding System Access to Edit and Purge Their Own Audit Logs
Ninja Solution: Stream logs off-host to a centralized, append-only SIEM or WORM storage bucket that restricts delete permissions globally. - Problem: Over-Engineering Segregation for Low-Risk Tasks, Creating Paralyzing Bureaucracy
Ninja Solution: Focus segregation strictly on high-impact areas: production deployments, financial payments, access approvals, and log management.
The ISO 27001 Ninja Bottom Line
ISO 27001 Annex A 5.3 is about introducing smart, risk-based checks and balances so no single person holds unchecked power over your critical assets. Segregation is not about creating unnecessary bureaucracy or slowing down small businesses—it is about preventing unmonitored fraud, catching accidental mistakes early, and protecting both your organisation and your staff from single-point human failure.
By publishing a clear Segregation Policy, mapping toxic duty combinations, enforcing peer reviews in CI/CD pipelines, locking down self-approval in access workflows, requiring dual-authorization for financial payments, applying robust compensating controls (immutable logging and retrospective reviews) for small teams, protecting audit logs from admin tampering, and auditing segregation rules routinely, you eliminate single-point operational vulnerabilities, build true governance resilience, and satisfy your ISO 27001 auditor with complete confidence.