How should organisations test Separation of Duties controls in Identity Governance and Administration?

Organisations should test Separation of Duties by mapping roles to critical processes, tracing who approves and who executes each step, and then comparing those duties against actual system entitlements. Walkthroughs, sample transaction testing, and recertification campaigns help confirm that no one person can complete a sensitive process end to end without oversight. Automated SoD checks should then monitor for toxic role combinations continuously.

What Separation of Duties testing is trying to prove

In identity governance and administration, Separation of Duties testing is not just a policy check. It is a verification exercise that proves critical work is split across distinct roles, approvals, and execution paths so a single identity cannot complete a sensitive process alone. That makes the test both a governance control and an entitlement control, because the real question is whether assigned access matches the intended business design.

Good testing starts by defining the sensitive process end to end, then identifying where approval, request, execution, review, and exception handling should be separated. This is where role design matters: if the workflow and entitlement model are vague, the control will look fine on paper but fail in practice. A control that cannot be traced to specific duties is usually too abstract to audit well.

Testing should also distinguish between “can do in theory” and “can do in the live system.” A role matrix may say duties are separated, but the system may still allow a privileged user to approve and execute the same transaction, or may permit indirect access through nested roles, shared accounts, or emergency access paths. That is why SoD testing must compare governance rules against actual entitlements and actual transaction behavior.

How to test SoD across roles, approvals, and entitlements

The most reliable approach is to test from process to person, not from person to process. Start with a list of critical business processes, the systems that support them, and the points where approval should be independent from execution. Then map those duties to roles and entitlements, and verify that the identity records, access assignments, and workflow logs all tell the same story.

Walk the process with the business owner and confirm the intended duty split.
Inspect role definitions and entitlement mappings for toxic combinations.
Sample real transactions and confirm who approved, who executed, and who reviewed.
Test exception paths, including emergency access, delegated authority, and temporary elevation.
Review recertification outcomes to see whether conflicts are being detected and removed.

Automated SoD engines are useful, but they only work if the rule set reflects the real process model. If rules are too broad, they create noise and mask real conflicts. If they are too narrow, they miss conflicts hidden in composite roles, inherited access, or application-specific permissions. The control is strongest when role mining, workflow evidence, and entitlement data are tested together rather than in separate silos.

For recurring testing, use a small but representative sample of transactions from each sensitive process, then vary the sample to include normal cases, exceptions, and recently changed access. That combination helps expose whether SoD is truly embedded in day-to-day administration or exists only in access review spreadsheets. Where an organisation uses role-based access models, the test should also confirm that the role design itself does not permit duty collapse under operational pressure.

What usually breaks Separation of Duties in practice

Most SoD failures are not dramatic policy violations, they are slow control erosion. Duties become concentrated because roles are expanded for convenience, temporary access becomes permanent, or one team accumulates approval and execution rights after repeated exceptions. Over time, the control can drift from “independent oversight” to “same person, different screen.”

The other common failure is poor visibility. If the organisation cannot reliably identify inherited entitlements, privileged group membership, service-style administrative access, or break-glass usage, SoD testing will miss the paths that matter most. In that situation, the organisation may be checking the policy design while remaining blind to the actual authority chain.

A further failure mode is weak evidence. If approvals are stored outside the identity platform, or transactions cannot be linked to the user who executed them, the test cannot prove separation. The result is a control that sounds strong in governance terms but is not defensible under audit or incident review.

Risk and Threat Considerations

Weak Separation of Duties increases the chance that a single compromised or overprivileged identity can approve, execute, and conceal a sensitive action. The same failure also makes fraud, unauthorized change, and policy bypass easier because the control no longer forces independent review before impact occurs.

Failure mechanism: Duties drift into composite roles, exception access, or shared administrative paths, and the organisation loses the ability to prove that approval and execution are actually separated in the live environment.

Impact: A successful abuse can produce unauthorized transactions, hidden privilege concentration, failed audits, and slower incident containment because there is no independent control point to interrupt the action chain.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-5 — Separation of Duties	Directly addresses separating incompatible duties in access governance.
	AC-6 — Least Privilege	SoD tests must confirm users do not retain unnecessary access enabling duty collapse.
	IA-5 — Authenticator Management	Credential and authenticator handling affects whether shared or elevated access undermines SoD.
Recommendation — Test and enforce conflicting duty splits across approval, execution, and review paths. Review entitlements for excess access that could bypass independent control points. Control credential lifecycle so privileged access cannot persist beyond need.
ISO/IEC 27001:2022	A.5.15 — Access control	SoD is an access control governance check over who may do what in critical workflows.
	A.8.2 — Privileged access rights	Privileged rights are where SoD failures most often concentrate and require testing.
Recommendation — Validate access rules against business duties and remove conflicting permissions. Test privileged paths for conflicts between approval, execution, and oversight.
CIS Controls v8	CIS-5 — Account Management	SoD depends on accurate account and role management to prevent conflicting access.
Recommendation — Audit accounts and role assignments for conflicting duties and stale privilege.

Practitioner Guidance

What to verify: Test the rule against the system, not just the policy document. The key evidence is whether the same identity can request, approve, and execute the same sensitive action through any direct or indirect path, including delegated and emergency access.

Decision rule: If a control only works when people behave ideally, it is not a strong SoD control. Treat any conflict that appears in production entitlements, workflow logs, or recertification results as a real control failure until the access path is removed or formally constrained.

Practitioner takeaway: Effective SoD testing is about proving that the process cannot collapse into one identity’s hands, even when roles are messy, exceptions exist, and access changes over time.