Control Definition
Duties and areas of responsibility that conflict with each other must be identified and divided between different people, so that no single individual can take a sensitive action and also approve, verify, or conceal it.
Control Objective
To reduce the risk of fraud, error, and deliberate bypassing of information security controls by ensuring no one person controls a sensitive process from end to end.
What This Really Means
This is the oldest control in the book, borrowed straight from accounting: the person who writes the check should not be the person who reconciles the bank statement. Translated to information security, segregation of duties (SoD) asks one question of every sensitive process — can a single person initiate an action, approve it, and erase the evidence? If the answer is yes, you are relying entirely on that one person's integrity and accuracy, and the control exists because that bet eventually loses, through fraud or through an honest error nobody catches.
In practice, the control asks you to find your toxic combinations and break them up. The classic conflicts: requesting access and approving it; writing code and deploying it to production unreviewed; implementing a change and approving that same change; administering a system and auditing its logs; initiating a payment and releasing it; operating security controls and assessing whether they work. The standard working artifact is a conflict matrix — a short table of duties marked compatible or incompatible — mapped against who actually holds which rights today, usually pulled from your IAM platform or access review data.
ISO is realistic about small organizations. When a five-person engineering team cannot split every duty, the expectation is not magic headcount — it is compensating controls: independent monitoring of activity, audit trails reviewed by someone outside the process, dual authorization on the riskiest steps, closer management supervision. The failure mode is not having conflicts; it is having them unconsciously.
For auditors, the heart of A.5.3 is conscious design. They expect you to know which duty combinations in your organization are dangerous, to show where you separated them — in workflow tools, pipeline rules, and role definitions, not just on paper — and to show documented, monitored compensating controls where you could not. "We never analyzed it" is the answer that fails. "We have three known conflicts, here is the risk acceptance, and here is the monthly review that watches them" is the answer that passes.
Why It Matters
Nearly every large insider fraud and a striking share of catastrophic outages share one precondition: a single person held end-to-end control of a process, so a bad decision — malicious or mistaken — traveled from idea to production with no second pair of eyes. Segregation of duties is the structural defense against that concentration. It does not assume people are dishonest; it removes the need to find out.
SoD is also what makes the rest of your ISMS believable. Access reviews, change management, and logging all rest on the assumption that the person who acts is not the person who checks. When one identity can do both, audit trails stop proving anything and approval workflows become theater. Auditors treat weak segregation as a leading indicator: a finding here usually predicts findings in privileged access, environment separation, and change control.
Where conflicting duties are left combined, organizations face:
- •Undetected insider fraud – the person who can create a vendor, approve the invoice, and reconcile the account can steal indefinitely without tripping an alarm
- •Unreviewed errors reaching production – an engineer who can merge their own code and push it live turns every bad day into a potential outage or breach
- •Meaningless audit trails – an administrator who manages a system and also controls its logs can rewrite history, undermining investigations and the value of evidence
- •Total compromise from one account – duties concentrated in one identity mean a single phished credential hands an attacker the entire process
- •Cascading audit findings – an auditor who discovers self-approval in one workflow starts sampling every other workflow, and isolated gaps escalate into systemic nonconformities
Regional Compliance Context
In Indian financial services, segregation of duties is a supervisory expectation, not just an ISO one. RBI master directions push regulated entities toward structural separation — an information security function organizationally independent of IT operations, and maker-checker discipline as the default for changes that touch transaction systems — while SEBI's CSCRF carries comparable expectations for market intermediaries. If you operate in BFSI or sell into it, your SoD analysis will be read by more than your certification auditor; align the conflict matrix with what the sectoral regulator already demands so one piece of work serves both.
Implementation Guidance
Inventory Your Sensitive Processes and Duties
Start where fraud, error, or concealment would hurt most: access provisioning, software deployment, change approval, payment and vendor master-data processing, log administration, backup management, and security monitoring. For each process, list the distinct duties involved — request, approve, execute, verify, record. The CISO or risk owner should run this with the actual process owners, not from an org chart.
Build a Conflict Matrix of Incompatible Duties
Mark which duty pairs must never sit with one person. Four classic patterns cover most cases: authorization versus execution, execution versus verification or recording, asset custody versus reconciliation, and operations versus audit. Keep the matrix to genuinely toxic combinations in your top processes — a 200-row matrix nobody maintains is worth less than a 15-row one that gets reviewed.
Map Real People and Access Against the Matrix
Pull current entitlements from your IAM platform, ticketing tool, code repository, and finance systems, then compare them with the matrix. You are hunting live conflicts: the engineer who can merge, deploy, and delete logs; the manager who raises and approves their own access; the admin whose account spans production and its audit trail. Document every hit, even the awkward ones.
Separate Duties Where Headcount Allows
Redesign roles so conflicting duties land on different people: requesters never approve, developers never self-deploy to production, system administrators never administer the logging platform that watches them. Update role definitions and the access control policy so the separation survives staff changes instead of living in tribal knowledge.
Apply Documented Compensating Controls Where It Does Not
Small teams cannot split everything, and the standard anticipates that. For each accepted conflict, record a compensating control with an owner and a frequency: immutable or independently reviewed audit logs, alerts on direct production changes routed outside the team, dual authorization on the highest-risk step, or a monthly management review of privileged activity. Capture the residual risk in the risk register with formal sign-off.
Enforce Segregation in Systems, Not Just Policy
Configure tools to make violations hard: approval chains in the ticketing system that block self-approval, branch protection requiring a different reviewer before merge, deployment pipelines with a separate release approver, dual release in payment applications, and PAM workflows for privileged sessions. Technical enforcement is the evidence auditors trust most, because it works even on a bad day.
Re-Check Conflicts at Every Access Review and Org Change
Add an SoD column to quarterly access reviews so new conflicts surface as people move roles, and re-run the full analysis after restructures, acquisitions, or the arrival of a new core system. Movers are the main source of silent conflicts — their old rights plus their new rights often combine into exactly the pairing the matrix forbids.
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.5.3:
Documentation
- Segregation of duties analysis or conflict matrix listing incompatible duties and the roles that hold them
- Access control policy or role definitions showing how conflicting duties are separated by design
- Quarterly access review records that include SoD conflict checks and remediation of flagged conflicts
- Risk register entries with management sign-off for accepted conflicts and their compensating controls
- System configuration evidence: ticketing approval chains, branch protection rules, dual-authorization settings, PAM workflow approvals
Interviews
- CISO or risk owner on how conflicting duties were identified and how exceptions are decided and tracked
- DevOps or platform engineers on who can approve, merge, and deploy production changes — probing whether self-approval is technically possible
- Finance or HR process owners on dual control over payments, vendor master data, and payroll changes
Observations
- Live demonstration that a user cannot approve their own access request or change ticket in the workflow tool
- Inspection of repository and pipeline settings: required reviewers, blocked self-merge, separate deployment approvers
- A sample of recent production changes traced end to end to confirm requester, approver, and implementer are different people
Practitioner Insights
A pattern I see across audits: organizations answer a segregation question with an org chart. An org chart proves nothing — I want the last ten production changes with three columns: who requested, who approved, who deployed. When the same name fills all three columns week after week with no independent review, that is a finding regardless of what the policy says. Run that exact sampling on yourself a month before the audit; it is the fastest SoD self-test there is.
Small teams fail this control by pretending, not by being small. A five-engineer startup that writes "duties are segregated where practicable" and stops has nothing to show an auditor. The startup that writes "our platform lead can both deploy and administer logs — accepted risk, compensated by immutable log storage and a monthly founder review of admin activity" and keeps the review evidence passes. An honest one-page conflict list beats a beautiful matrix that does not match how the team actually works.
Common Challenges & Solutions
Challenge
A small engineering team writes, reviews, deploys, and operates everything, so full segregation is structurally impossible.
Solution
Take the segregation you can get and compensate for the rest. Require a different person to approve every pull request, gate production deploys behind pipeline approvals, and route alerts on direct production access to someone outside the team, such as the CTO or a founder. Document the residual conflicts as accepted risks and revisit the design at each hiring milestone.
Challenge
Administrators hold standing god-mode accounts that bypass every carefully designed approval workflow.
Solution
Separate daily-driver accounts from privileged accounts and move admin rights behind a PAM or just-in-time elevation flow, so privilege is granted per task and logged. Keep break-glass credentials sealed, with alerting and a mandatory post-use review. Revalidate the privileged access list quarterly — standing privilege is where segregation quietly dies.
Challenge
Nobody can say which duty combinations actually conflict, so the analysis stalls or produces an academic matrix.
Solution
Anchor on four patterns: authorization versus execution, execution versus verification, custody versus reconciliation, and operations versus audit. Apply them to your five most sensitive processes only — access, deployment, changes, payments, logging — and ignore the rest until those are solid. A matrix you can explain in two minutes is the right size.
Challenge
The person who administers the SIEM also administers the systems it monitors, and could erase their own traces.
Solution
Split log-platform administration from administration of the monitored systems, even if that means a part-time duty for someone in another team. Where headcount truly prevents it, make logs append-only or ship them to immutable storage with retention settings the admin cannot change, and have an independent person review log-platform admin activity on a fixed cadence.
Challenge
Role and entitlement creep over the years silently recreates conflicts the original design eliminated.
Solution
Treat movers as the highest-risk population: remove old entitlements within a defined SLA when someone changes roles instead of letting access accumulate. Add an SoD check to quarterly access reviews — IGA tools can flag conflicting entitlement pairs automatically, and a spreadsheet comparison works at smaller scale. Re-baseline roles against the conflict matrix annually.
