Segregation of duties in auditing is now an identity control problem

At a glance

What this is: This is an analysis of segregation of duties in auditing and why modern identity governance now determines whether SoD controls actually hold up.

Why it matters: It matters because IAM, IGA, and PAM teams now carry part of the audit burden for preventing conflicting access, excessive privilege, and weak approval separation.

Context

Segregation of duties is the practice of splitting sensitive tasks, approvals, and privileged actions so one person cannot complete an entire critical process alone. In identity security terms, that means governance has to control who can request, approve, provision, certify, and execute access across systems.

The article's central point is that SoD is no longer just an audit checklist. As cloud, SaaS, ERP, and hybrid identity estates expand, conflicting permissions can accumulate faster than periodic reviews can catch them.

That shifts the control problem into IAM and IGA. If access governance cannot continuously detect toxic combinations, self-approval paths, and privileged overlaps, audit evidence may exist while actual separation of duties does not.

Key questions

Q: What breaks when segregation of duties is not enforced in identity governance?

A: When segregation of duties is absent, a single identity can create, approve, and audit the same sensitive action. That removes independent oversight and makes fraud, unauthorized changes, and compliance failures much easier to hide. The most dangerous failures usually appear as conflicting permissions across finance, HR, IAM, and privileged access workflows.

Q: Why do weak SoD controls create compliance and audit risk?

A: Weak SoD controls allow conflicting permissions, self-approval paths, and excessive privilege to persist across systems. Auditors treat that as evidence that internal controls are not operating effectively, which can lead to findings under frameworks that expect demonstrable governance over sensitive transactions and access.

Q: What signs show that SoD governance is failing in practice?

A: Common signs include users who can both create and approve transactions, admins who review their own privileged activity, recurring access creep, and unresolved toxic entitlement combinations. If those patterns appear across ERP, cloud, or IAM systems, the control is probably being managed as a periodic review exercise rather than an enforced governance rule.

Q: What should security teams do when users accumulate conflicting access over time?

A: Security teams should recertify the combined permission set, not just the latest role change, and remove any incompatible entitlement pair before the next approval cycle. The goal is to restore separation across request, approval, administration, and execution paths so the same identity cannot complete the full sensitive process.

Technical breakdown

How SoD matrices translate into access rules

An SoD matrix is the formal mapping of incompatible actions, roles, and approval paths. In practice, it defines which permissions must never coexist in one identity, such as initiating and approving the same financial transaction or provisioning and certifying the same access. The technical issue is not the policy document itself, but whether identity governance systems can evaluate entitlements across multiple applications, roles, and workflows at once. In cloud and SaaS environments, that requires correlating role assignments, delegated admin rights, approval chains, and certifications against a single conflict model.

Practical implication: Build SoD logic into entitlement evaluation so conflicting access is blocked or flagged before it is granted.

Why access reviews alone miss toxic entitlement combinations

Access reviews are periodic snapshots, but SoD risk is often cumulative. Users can accumulate permissions through role changes, temporary projects, or delegated exceptions until a conflicting access pattern appears without any single obvious event causing it. That is why manual review cycles often detect problems late. The governance failure is temporal as much as structural: a review may confirm current access is valid while missing the way multiple valid-looking permissions combine into an invalid state. Continuous monitoring is therefore a control problem, not an administrative preference.

Practical implication: Treat recurring certification as evidence collection, not as the only control for conflicting access.

Why privileged access and approval separation matter in cloud and ERP systems

Privileged access creates the highest SoD exposure because the same identity can often provision access, alter records, and review its own activity if controls are weak. In ERP, finance, and cloud admin environments, that can collapse the separation between requester, approver, and executor. The technical risk is not just excessive privilege, but the ability to use administrative paths to bypass standard workflow controls. That is why independent approval, restricted admin scope, and logging must work together rather than as isolated controls.

Practical implication: Separate provisioning, approval, and privileged execution paths so no single admin can complete a sensitive workflow end to end.

Breaches seen in the wild

• Zacks breach claim 2025: A hacker leaked 12 million Zacks accounts in 2025, claiming domain admin access in 2024; HIBP verified the data, Zacks has not confirmed.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SoD is now an identity governance control, not just an audit test: the article shows that conflicting duties emerge from how access is issued, reviewed, and certified across modern systems. Once permissions live across cloud, SaaS, ERP, and PAM layers, the control depends on identity governance operating continuously, not at audit time. The practitioner conclusion is that SoD ownership now sits squarely with IAM and IGA teams as much as with auditors.

Access review cadences were designed for static privilege, and that assumption no longer holds: the article describes access creep, temporary assignments, and manual review limits that let toxic combinations persist. That assumption fails when identities move across roles faster than quarterly or annual reviews can reconcile them. The implication is that audit readiness now depends on continuous conflict detection, not on a review calendar alone.

Manual SoD governance creates false confidence in environments that change constantly: spreadsheets and point-in-time checks can document control intent without proving control enforcement. In cloud and hybrid estates, entitlement overlap can exist across systems that no single reviewer sees end to end. The practitioner conclusion is that evidence quality must be tied to live governance telemetry, not after-the-fact documentation.

Privilege is the highest-risk multiplier in SoD, not merely an access tier: once an administrative identity can both assign and approve, the separation model collapses into a single trust boundary. That is why privileged access management and SoD cannot be treated as separate operating concerns. The practitioner conclusion is to govern privileged workflows as part of the same control fabric that enforces audit segregation.

Least privilege is necessary but insufficient without conflict awareness: the article correctly frames minimum access as part of SoD, but minimum access alone does not prevent a user from holding two individually reasonable permissions that become incompatible together. The practitioner conclusion is to evaluate entitlements as combinations, not as isolated grants.

What this signals

Identity governance is now the enforcement layer for SoD: if conflicting duties are spread across SaaS, ERP, cloud, and privileged access tools, the control only works when entitlement data is unified enough to detect combinations. That means organisations should expect SoD failures to surface first as governance gaps, not as audit paperwork issues.

The most common failure mode is not a missing policy, but a policy that cannot keep pace with role changes, temporary assignments, and delegated approvals. Teams that rely on periodic reviews alone should assume conflicts will exist between review windows.

Audit-ready SoD depends on live evidence, not static attestations: if an organisation cannot show who approved access, who provisioned it, and whether the same identity later exercised the privilege, the control is incomplete. Continuous logging and entitlement correlation are now part of audit defensibility.

For practitioners

• Define an SoD matrix for critical workflows Document incompatible task pairs for financial, IAM, ERP, cloud, and privileged workflows so enforcement can be automated instead of interpreted case by case.
• Automate conflict detection across entitlement sources Correlate role assignments, admin rights, approval paths, and certifications across systems so toxic combinations are flagged before they become audit findings.
• Separate access request, approval, and provisioning duties Ensure no identity can self-approve access or complete both sides of a high-risk workflow, especially for privileged roles and production changes.
• Increase review frequency for privileged accounts Prioritise admin, ERP, cloud, and finance identities for more frequent certification because they are most likely to carry conflicting authority.
• Preserve remediation evidence for audit defensibility Track when conflicts were found, who approved exceptions, and how access was corrected so SoD decisions remain explainable during audit.

Key takeaways

• Segregation of duties fails when identity governance cannot prevent one person from combining request, approval, and execution power across critical systems.
• The article's main warning is that cloud, SaaS, ERP, and privileged environments make toxic entitlement combinations harder to spot with manual review alone.
• The control that matters most is continuous conflict detection backed by clear evidence that sensitive tasks, approvals, and admin rights remain separated.

Key terms

• Segregation of Duties: Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
• Toxic Entitlement Combination: A toxic entitlement combination is a set of permissions that becomes risky when held together, even if each permission seems acceptable on its own. Auditors look for combinations such as request and approve, create and certify, or administer and review, because they create self-reinforcing control failure.
• Access Certification: Access certification is the periodic review of whether an identity still needs its current entitlements. For NHIs, certification is only reliable when reviewers know the identity's owner, purpose, and expiry, otherwise stale machine access can persist long after the original use case has ended.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.