How do organisations implement separation of duties?

How separation of duties works in practice

Separation of duties is an operating control, not just an org chart principle. The practical goal is to make sure the same person cannot both initiate and finalise a sensitive action, especially where money, production systems, or privileged access are involved. That usually means splitting responsibility across people, enforcing workflow gates, and making approval evidence visible and reviewable.

The design choice is to separate tasks that would otherwise let one actor both create risk and conceal it. Common examples include request versus approval, build versus release, payment initiation versus payment release, and access grant versus access certification. In access governance, that same logic supports independent reviews of entitlements, toxic combinations, and exception handling through IAM and IGA Basics.

Well-implemented SoD does not rely on trust in a single approver. It is enforced through role design, workflow routing, system permissions, and periodic review so that the control survives staff changes and operational pressure. A useful mental model is that SoD should still hold when someone is absent, when a process is urgent, or when a privileged exception is requested.

Where separation of duties usually breaks down

Most failures come from exceptions that become normal. That includes emergency access with no expiry, shared accounts used to “move faster,” or approval chains where the same manager effectively controls both sides of the transaction. Over time, these shortcuts can defeat the control even when the process looks compliant on paper.

SoD also weakens when the organisation treats roles as static labels rather than actual combinations of permissions. A user can appear to be in different roles while still holding enough effective access to perform conflicting actions. That is why periodic access review and entitlement analysis matter as much as initial design. The control needs to be tested against real permissions, not just job titles.

Another common weakness is when software and automation are exempted from the same discipline applied to people. If bots, service accounts, or integration accounts can both trigger and approve a workflow, the SoD model is only partially implemented. Segregation of Duties (SoD) Guide addresses this wider ruleset view, including conflicting permissions and mitigations for non-human actors.

What good implementation looks like for auditors and operators

A strong SoD design starts with the highest-risk processes and maps each critical step to a distinct role, system, or control owner. The next step is to define what must be independently reviewed, what can be auto-routed, and which exceptions require time-bounded compensating controls. For many organisations, the hard part is not the policy statement, but keeping the permission model aligned with how work actually gets done.

Useful evidence includes approval logs, access review records, workflow history, and exception registers showing who can do what, who approved it, and whether the approval was truly independent. Where the process is automated, operators should verify that the approval path cannot be bypassed by API calls, privileged users, or back-end service paths. In cloud and platform environments, this often means checking the actual control implementation against the intended ISO/IEC 27002:2022 Information Security Controls.

Good practice is to treat SoD as a lifecycle control. That means reviewing role changes after reorganisations, deprovisioning dormant access, and revalidating exceptions before they become permanent. It also means measuring how many sensitive workflows still depend on manual override, because that is where control drift tends to accumulate.

Risk and Threat Considerations

When separation of duties is weak, a single account or role can both initiate and approve a high-impact action, which creates fraud, abuse, and concealment risk. The same pattern can also let an attacker with one foothold escalate into a completed transaction, a privileged change, or a hidden tampering event.

Failure mechanism: Conflicting permissions, standing exceptions, or shared credentials collapse the intended check-and-balance structure, allowing one actor to complete a sensitive action without meaningful independent review.

Impact: Organisations lose detection, accountability, and containment. The result can be unauthorised payments, privileged access abuse, unauthorised production changes, or difficult-to-attribute fraud and manipulation.

Practitioner Guidance

What to prioritise: Start with the small set of workflows where a single approval failure would create the largest loss, such as payments, production releases, privileged access, and master-data changes. Those are the places where SoD should be strictest and where exceptions should be rarest.

What to verify: Confirm that the control exists in the real workflow, not only in policy. The test is whether one person can still complete the sensitive action through delegation, emergency access, or back-end privilege even when the formal approval path says they cannot.

Common mistake: Treating role separation as sufficient when the same person still controls multiple privileged paths. If the approval, execution, and override paths are not independently constrained, the control is cosmetic rather than effective.

Practitioner takeaway: Separation of duties is only real when the organisation can show that conflicting actions are blocked by design, not merely discouraged by process.

Related resources from NHI Mgmt Group

• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?
• How can organisations reduce the blast radius of compromised agent identities?
• Should organisations prioritise external exposure or internal credential governance first?