Annex A 5.3: Segregation of Duties

Segregation of duties (SoD) is one of the fastest ways auditors and customers gauge whether your ISMS prevents both fraud and high-impact mistakes. Annex a 5.3: segregation of duties requirement expects you to deliberately separate incompatible tasks and privileges so a single individual cannot quietly create, approve, and execute a risky action end-to-end (ISO/IEC 27001 overview; ISMS.online Annex A control index).

For a Compliance Officer, CCO, or GRC lead, the practical problem is rarely “do we agree with SoD?” It’s “where do we apply it, how do we enforce it in real systems, and what evidence will an auditor accept?” This page gives you a requirement-level playbook: scoping, a step-by-step implementation method, evidence bundles, and the audit questions that commonly stall teams.

If you run a service organization with production systems, customer data, payment flows, or regulated workloads, SoD touches engineering, IT, security operations, finance, HR, and any outsourced operations. You’ll also need a repeatable exception method for small teams and emergencies, because SoD breaks down precisely when pressure is highest.

Regulatory text

Provided excerpt: “ISO/IEC 27001:2022 Annex A control 5.3 implementation expectation (Segregation of Duties).” (ISO/IEC 27001 overview; ISMS.online Annex A control index)

Operator interpretation: You must implement separation of responsibilities and access rights to reduce the chance of unauthorized or unintentional modification, misuse, or concealment of actions. Practically, that means:

• Define which tasks must not be performed by the same person (for example: build vs deploy approvals; create vendor vs approve payment; grant access vs approve access).
• Configure systems and workflows so these separations are enforced, monitored, and reviewable.
• Where separation is not feasible, apply compensating controls (for example: independent reviews, post-activity monitoring, and heightened logging) and document the rationale (ISO/IEC 27001 overview; ISMS.online Annex A control index).

Plain-English requirement: what “segregation of duties” means in practice

SoD is a control design principle: split high-risk actions into at least two independent steps, owned by different roles, so a single person cannot both cause and conceal a bad outcome.

Think in “chains”:

1. request/initiate
2. approve
3. execute/implement
4. verify/reconcile

If the same identity can do steps 1–4 in the systems that matter, you do not have effective SoD. Auditors will treat “we have a policy” as non-responsive unless you can show technical and procedural enforcement plus operating evidence (ISO/IEC 27001 overview).

Who it applies to

Entities: Organizations implementing an ISO/IEC 27001:2022 ISMS, especially service organizations providing services to customers and processing customer data (ISO/IEC 27001 overview).

Operational contexts where Annex a 5.3: segregation of duties requirement shows up immediately:

• Identity and access administration: creating accounts, granting roles, approving privileged access.
• Production change management: code merges, CI/CD approvals, infrastructure changes, feature flag changes.
• Security operations: tuning alerts, closing incidents, modifying logging rules.
• Finance and procurement: vendor onboarding, invoice approval, payment release, refunds.
• Data governance: exporting data, deleting data, changing retention rules.

Third party angle (often missed): If third parties perform operational tasks (managed IT, outsourced DevOps, payroll processor administration), you still need SoD across the combined workflow. Your control can be partly contractual and partly technical, but the segregation must exist and be evidenced.

What you actually need to do (step-by-step)

1) Create a control card (runbook) for SoD

Write a one-page control card that includes:

• Objective: prevent single-actor end-to-end control over high-risk actions.
• Owner: named role (Security, GRC, IT, Engineering Ops).
• Scope: systems and processes in-scope (IdP, cloud, production, finance).
• Trigger events: onboarding, role changes, access requests, emergency changes, quarterly access review cadence.
• Exception rules: how SoD exceptions are requested, approved, time-bounded, and reviewed. This aligns with the “make it runnable” expectation auditors look for, not just policy statements (ISO/IEC 27001 overview).

2) Identify “toxic combinations” by process, not org chart

Build a matrix of incompatible duties. Start with a short list of high-risk workflows:

• Access admin: requester ≠ approver ≠ provisioner for privileged roles.
• Production changes: developer ≠ approver for merge; deployer ≠ approver for release (or require independent review).
• Cloud/IaC: person who changes IAM policies ≠ person who approves the change.
• Payments: vendor creator ≠ invoice approver ≠ payment releaser. Capture these as explicit “cannot be held by same role” statements.

3) Map roles to systems and enforce via RBAC + workflow

For each workflow, implement SoD in the systems that actually execute the action:

• Identity system: separate “User Admin,” “Privileged Role Admin,” and “Access Approver” groups; require approvals for privileged access.
• Ticketing/work management: enforce required approvers for change types; require separation between request and approval fields.
• Source control / CI: require peer review for protected branches; limit who can bypass checks; log approvals.
• Cloud platform: minimize number of global admins; require change tickets for IAM policy edits; use separate break-glass accounts.

Your goal is to make SoD the default path. If it depends on people “remembering,” it will fail under pressure.

4) Define compensating controls for small teams (documented and time-bounded)

Some orgs cannot fully separate duties due to headcount or on-call realities. Annex a 5.3 is still achievable if you implement compensating controls and treat them as first-class controls:

• Independent after-the-fact review by someone not involved in the action.
• Enhanced logging and alerting for the high-risk action.
• Time-boxed elevated access with automatic revocation.
• Management sign-off for each exception, with rationale and end date. Keep the exception rate visible to leadership; auditors interpret frequent exceptions as a design problem.

5) Operationalize: recurring health checks and remediation tracking

Run a recurring control health check that answers:

• Do any users currently hold conflicting roles?
• Were there any SoD exceptions? Were they approved and closed on time?
• Were emergency changes retrospectively reviewed? Track findings to closure with owners and due dates (ISO/IEC 27001 overview).

6) Make evidence retrieval easy (the “audit packet”)

Store SoD evidence in one place (GRC tool or a dedicated repository) with a consistent naming convention. Daydream can help by turning the control card, evidence bundle definition, and health checks into a repeatable workflow with assigned owners and reminders, so you’re not rebuilding the packet during every audit.

Required evidence and artifacts to retain

Auditors typically want proof of design and operation. Keep:

• SoD policy/standard that states the principle and where it applies.
• SoD control card/runbook (objective, owner, cadence, exceptions).
• Role and responsibility matrix (RACI) for key processes (change, access, payments).
• “Toxic combination” matrix mapping incompatible roles/permissions.
• System configurations/screenshots or exports showing RBAC groups, protected branch rules, approval rules, and privileged role assignments.
• Samples of workflow records: change tickets showing requester/approver separation; access requests with approvals; production deploy approvals.
• Access review outputs: reviewer sign-off, identified conflicts, remediation tickets.
• Exception register: who approved, why, duration, compensating controls, closure evidence.

Common exam/audit questions and hangups

• “Show me how you prevent one engineer from approving and deploying their own production change.”
• “Who can grant privileged access, and who approves it?”
• “How do you detect conflicting access if roles drift over time?”
• “What happens during an incident when you need emergency access?”
• “Show me evidence from the last period that the control operated.”

Hangup to expect: teams present a policy, but cannot produce system-level evidence (RBAC settings, approval logs, tickets). Close that gap early.

Frequent implementation mistakes (and how to avoid them)

1. Defining SoD only at the org-chart level.
   Fix: define it at the permission and workflow step level, per system.

2. Ignoring service accounts and shared admin credentials.
   Fix: inventory service accounts, restrict their scopes, and make ownership explicit.

3. “Break-glass” accounts with no review.
   Fix: require post-use review and keep logs in the evidence bundle.

4. Over-scoping SoD and creating workarounds.
   Fix: start with the highest-risk workflows; expand after the first operating cycle.

5. Exceptions without compensating controls.
   Fix: require independent review plus time-bounding for every exception.

Risk implications (why auditors care)

SoD reduces the likelihood that a single insider, compromised account, or simple mistake can cause irreversible damage without detection. In ISO 27001 terms, it supports integrity, accountability, and control reliability across your ISMS (ISO/IEC 27001 overview). In customer diligence, weak SoD often maps to concerns about unauthorized changes, privileged access abuse, and unreliable change control.

Practical 30/60/90-day execution plan

First 30 days (foundation and scope)

• Publish the SoD control card (owner, scope, triggers, exceptions).
• Identify your top workflows (access admin, production change, payments, data exports).
• Draft the toxic combination matrix for those workflows.
• Define the evidence bundle and where it will be stored (ISO/IEC 27001 overview).

Days 31–60 (enforcement and compensating controls)

• Implement RBAC separations in the IdP and critical platforms.
• Turn on or tighten approval workflows (tickets, code reviews, release approvals).
• Stand up the exception register and break-glass procedure with post-use review requirements.
• Pilot a control health check and fix the first set of conflicts.

Days 61–90 (operate, prove, and harden)

• Run the first full operating cycle: access review + conflict remediation to closure.
• Collect a clean audit packet with samples from real tickets and approvals.
• Tune the toxic combination matrix based on findings and near-misses.
• Add monitoring for privileged actions and report exceptions to leadership.

Frequently Asked Questions

How do we meet Annex a 5.3: segregation of duties requirement with a small team?

Define compensating controls and document them in an exception process: independent review, stronger logging, and time-bounded elevated access. Keep an exception register with approvals and closure evidence (ISO/IEC 27001 overview).

Does “peer review” count as segregation of duties for production changes?

It can, if the reviewer is independent and the system enforces the review before merge/deploy. Auditors will still want evidence: protected branch rules, approval logs, and change records tied to releases (ISO/IEC 27001 overview).

What systems should be in-scope first?

Start where one identity could cause high impact quickly: identity provider/admin console, cloud IAM, source control/CI, and any payment or refund system. Expand scope after you have one operating cycle of evidence (ISO/IEC 27001 overview).

Are third parties included in segregation of duties?

Yes, if a third party can request, approve, or execute sensitive actions in your environment. You need segregation across the end-to-end workflow, even if parts are contractual and parts are technical (ISO/IEC 27001 overview).

What evidence do auditors actually accept for SoD?

They typically accept a combination of documented role separation (matrices), configured enforcement (RBAC/workflow settings), and operating proof (tickets, approvals, access review results, and exception sign-offs) (ISO/IEC 27001 overview).

How do we handle emergencies without breaking SoD?

Use a break-glass process with explicit approval rules where feasible, automatic logging, and mandatory post-incident review by someone not involved in the emergency change. Keep the post-review record in your evidence bundle.