Risk management for identity governance needs stronger SoD controls

At a glance

What this is: This is a risk-management analysis showing that segregation of duties and access governance must be handled as one control system, with the central lesson that authorised access can still create severe loss when risky function combinations are left intact.

Why it matters: It matters because IAM, IGA and PAM teams often treat access, approvals and audit evidence separately, even though the same identity pathway can create fraud, operational error or data exposure.

Context

Risk management in identity governance is about more than preventing direct compromise. The core problem is that a valid identity, with legitimate access, can still combine actions in ways that create fraud, data loss or operational damage if segregation of duties is weak.

In identity programmes, that means the control objective is not only who can sign in, but what combinations of functions, approvals and data actions a user can perform. When those combinations are not mapped and tested, risk remains hidden inside otherwise authorised workflows.

The article uses the Société Générale trading loss as a reminder that this is not a narrow finance issue. It is a recurring governance problem whenever access, approval and transaction controls are managed in silos.

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 does weak SoD increase business risk even without a breach?

A: Weak SoD lets authorised users create outcomes that no single function should control alone. The risk is causal, not hypothetical: one identity can move from request to approval to execution without interruption, which makes fraud, errors and hidden loss more likely in finance, admin and access workflows.

Q: How do security teams know if SoD controls are actually working?

A: SoD controls are working only if live access state matches the approved separation model across systems. Teams should verify that no identity can both initiate and validate the same sensitive transaction, and that exceptions are time-bound and independently reviewed. If certification reports look clean but operational workflows still allow self-approval, the control is failing.

Q: What should IAM and GRC teams do when access reviews and SoD rules disagree?

A: They should resolve the disagreement in favour of the more precise business-function conflict model, then update the role design and mitigation rules. An access review that ignores SoD can reapprove unsafe access, while an SoD rule that is out of date can block legitimate work. Governance has to reconcile both.

Technical breakdown

Why segregation of duties is a risk control, not just an audit rule

Segregation of duties, or SoD, is a control design that prevents one identity from completing incompatible actions in the same business process. In practice, it is meant to stop the same user from both creating and approving a purchase order, resetting and using a privileged credential, or combining access that produces unchecked financial or operational impact. Without that separation, the identity is still legitimate, but the workflow becomes unsafe. SoD works best when it is embedded in role design, request-time evaluation and periodic review, not treated as a post-hoc audit finding.

Practical implication: Model conflicting functions before granting access, so risky combinations are blocked rather than discovered after the fact.

How mapping and compilation expose hidden risk combinations

Risk mapping ties users, roles and entitlements to the business functions they can perform, while compilation turns that inventory into an evaluable risk picture. The article’s point is that risk is not a static label on a role. It emerges from the combination of permissions, inheritance paths and local functions, such as Azure admin actions versus SAP transaction functions. If the mapping is stale, the organisation may believe it has SoD coverage when the actual permissions graph has already drifted. Compilation keeps the control current by re-evaluating those combinations as roles and access change.

Practical implication: Keep function-to-entitlement mappings current so SoD analysis reflects live permissions, not last quarter’s role model.

Why preventative and detective controls both matter in identity risk

Preventative controls stop risky access combinations at request time, while detective controls identify violations that already exist in active accounts or inherited roles. Both are necessary because identity risk is not limited to new access grants. It also appears through role inheritance, legacy entitlements and periodic changes in business process. Transaction log reviews, access reports and digest alerts all help surface violations, but they only work if the underlying function model is accurate. The stronger design is to prevent obvious conflicts and then continuously check for any that slip through.

Practical implication: Use request-time SoD checks for new access and recurring review cycles for inherited or legacy violations.

Threat narrative

Attacker objective: The objective is to convert legitimate business access into unauthorised financial or operational gain without triggering an immediate control barrier.

1. Entry occurs through legitimate access to business systems, not through an external exploit, because the dangerous condition is already present in the entitlement set.
2. Escalation happens when one identity can perform incompatible functions such as creating and approving the same transaction or combining admin and business actions.
3. Impact follows when the unchecked combination produces fraud, unauthorised transactions, or other material business loss, as illustrated by the Société Générale case.

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 failure is a governance design problem, not a downstream audit problem. When access controls allow one identity to perform incompatible functions, the organisation has already accepted a fraud or error pathway. The issue is not the absence of evidence after the fact, but the absence of structural separation before the action occurs. Practitioners should treat SoD as a live control architecture, not an annual review artefact.

Risk management becomes materially stronger when technical, data and financial controls share the same function model. The article is right to connect Azure admin actions, SAP transaction paths and purchase-order workflows because risk often crosses system boundaries. If each team maps risk differently, the organisation gets fragmented visibility and inconsistent enforcement. The practitioner implication is to govern the business function, not just the system.

Recertification only works when it is informed by conflict analysis. Access review programmes often validate whether a user still needs access, but they do not always test whether that access creates an incompatible combination. That leaves governance blind to privilege sets that are individually permissible but collectively unsafe. The practical result is that recertification should surface SoD violations, not simply reapprove entitlements.

Identity risk management should prioritise the decision path, not just the entitlement list. The most important question is not merely who has access, but which sequence of actions that access permits across approvals, transactions and administrative functions. That shifts IAM and IGA design toward workflow-aware governance, where control strength is measured by the combinations it prevents. Practitioners should close the gap between access provisioning and business process safety.

Named concept: risk-function mapping. The article points to a control pattern where business functions, local system actions and mitigating rules are compiled into one evaluable model. That is the missing bridge between access governance and operational risk management. Practitioners should treat this as the basis for detecting incompatible access combinations before they become incidents.

What this signals

Risk-function mapping: identity governance becomes materially stronger when business functions, not just accounts, are the unit of analysis. That is the only way to see when apparently valid access combinations create fraud or operational exposure, and it aligns recertification with the actual work being done.

SoD should be evaluated as a control system that spans provisioning, workflow approval and periodic review. If any one of those stages is outside the conflict model, the organisation still has a path for unsafe combinations to survive.

For IAM and GRC teams, the programme signal is clear: if role inheritance and local system functions are not being compiled into one live risk picture, the organisation is relying on incomplete governance rather than true segregation of duties.

For practitioners

• Map incompatible business functions Inventory the combinations of create, approve, reset and post actions that cannot safely sit with one identity, then express them as explicit SoD rules.
• Compile live role-to-risk mappings Recalculate role inheritance and local permissions regularly so your risk model reflects current Azure, SAP and other system entitlements.
• Embed SoD checks in access requests Evaluate risky combinations before granting access so request-time controls can block conflicts instead of reporting them later.
• Surface SoD violations in recertification Use periodic access reviews to identify conflicts between held entitlements and business functions, not just to confirm access necessity.

Key takeaways

• SoD is a preventative identity control that limits what one user can do across a business process, not just an audit concept after the fact.
• The Société Générale loss shows how authorised access can still produce catastrophic business damage when conflicting functions are not separated.
• The most effective defence is to map risky function combinations, keep role risk data current and test those conflicts during access requests and recertification.

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.
• Risk Function: A risk function is a specific action or task that can create exposure when combined with another action. In identity governance, functions are the unit used to detect toxic combinations across roles, applications, and workflows.
• Access Recertification: Access recertification is the periodic review of user or account permissions to confirm that access is still justified. It is useful, but it is not enough on its own because it reacts after entitlements already exist, which is why lifecycle governance must reduce the volume of exceptions before review time.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.