Segregation of Duties: 6 Proven Steps for SOX and ISO 27001

Segregation of duties is one term covering three different problems, and most control failures come from solving only one of them.

There is the transaction-level version an auditor tests, the entitlement-level version buried in your ERP, and the function-level version that regulators now impose on whole departments. They need different evidence.

The four functions that must not combine

Classical internal control doctrine separates four things over the same asset: authorisation, custody, recording and reconciliation. One person holding two of them can create a transaction and conceal it.

The pattern is why the well-known conflicts are conflicts. Whoever approves a supplier should not also create supplier records. Whoever runs the payment file should not also reconcile the bank account. Whoever writes the code should not also decide it goes to production.

Stated that way, segregation of duties is not a policy preference. It is the observation that fraud and error need a single unchecked actor, and removing that actor is cheaper than detecting them afterwards.

What SOX actually requires

Section 404 never uses the phrase. It requires management to state its responsibility for internal control over financial reporting and to assess its effectiveness — 404(a) — and requires the audit firm to attest to that assessment — 404(b).

Segregation of duties is where that assessment lands in practice, because a control whose preparer and approver are the same person does not operate effectively no matter how well it is documented.

The part worth knowing is 404(c): subsection (b) does not apply to an issuer that is neither a large accelerated filer nor an accelerated filer. Smaller issuers still assess; nobody external attests.

That changes the evidence bar, not the obligation. If you are exempt from 404(b), your segregation of duties analysis is never independently tested — which is precisely when a conflict matrix maintained by the people it constrains starts to drift.

The version hiding in your entitlements

Transaction-level design fails quietly at the system layer. A process that separates roles on paper is undone by one account holding both permissions, and nobody notices because the org chart still looks right.

The fix is a conflict matrix: named pairs of entitlements that may not be held together, checked at provisioning so a conflicting grant is blocked rather than discovered. The difference between checking at provisioning and reviewing at audit is the difference between a preventive and a detective control, and auditors price them differently.

Three things make that matrix work:

• It covers roles and direct grants. Most real conflicts arrive as an exception granted “temporarily” during a go-live.
• It is reviewed on a schedule with a named owner, because entitlements change faster than matrices.
• Exceptions are recorded and time-bound, with the compensating control written down at the moment of approval.

Segregation of duties at the level of whole functions

The newest form is organisational. DORA Article 6(4) requires financial entities other than microenterprises to assign responsibility for managing and overseeing ICT risk to a control function with an appropriate level of independence to avoid conflicts of interest, and to ensure appropriate segregation and independence of ICT risk management functions, control functions, and internal audit functions, according to the three lines of defence model.

This is not about who approves a payment. It is about whether the people running a control also assess it. A security team that writes the standard, implements it and then reports on its own compliance has a function-level conflict that no entitlement matrix will surface.

ISO 27001 carries the same idea in Annex A 5.3 Segregation of duties, sitting alongside 5.15 access control and 8.2 privileged access rights — and the management system’s own internal audit requirement is a segregation control in everything but name.

What to do when you cannot segregate

Small teams cannot separate four functions across three people, and pretending otherwise produces a policy nobody follows. The defensible answer has three parts.

Name the conflict explicitly. Write down which functions are combined and in whose hands. An auditor finding an undisclosed conflict is a different conversation from one reading your own analysis of it.

Add a detective control that a different person performs. An independent review of the payment run, a monthly reconciliation by someone outside the process, an alert on privileged actions reviewed by a manager. The compensating control must be operated by someone other than the person holding the combined duties, or it compensates for nothing.

Get the acceptance signed at the right level. A combined-duty arrangement is a residual risk decision, and the person accepting it should be senior enough to own the consequence.

Segregation of duties that is impossible and documented is a manageable finding. Segregation of duties that is claimed and absent is a material weakness.

The conflict almost everyone still has

Developer access to production is the most common unresolved segregation of duties conflict in organisations that otherwise pass their audits — usually justified by incident response, and usually implemented as standing access rather than break-glass.

The distinction matters. Standing production access held by whoever wrote the code combines authorisation, custody and recording. Time-bound, approved, logged and reviewed access invoked during an incident does not. The capability is the same; the control is entirely different.

How segregation of duties connects

Where to start

1. Map authorisation, custody, recording and reconciliation for your material processes before touching any system.
2. Build a conflict matrix and enforce it at provisioning rather than at review.
3. Check the function level too — who assesses the controls they operate.
4. List the conflicts you cannot remove, with named compensating controls performed by someone else.
5. Time-bound every exception, especially the ones granted during a go-live.
6. Fix developer production access, or convert it to break-glass with review.

This guide reflects 15 U.S.C. 7262, Regulation (EU) 2022/2554 and the Annex A structure of ISO/IEC 27001:2022, read at 16 August 2026. Filer status under Rule 12b-2 determines whether 404(b) applies to you — confirm yours.

The SOX Compliance Toolkit provides 45 editable ICFR templates covering the control matrices, the segregation of duties analysis and the testing evidence a 404 assessment produces — and the ISO 27001 Toolkit covers the access control side that enforces it.