Topic starter
22/06/2026 3:43 pm
TL;DR: Weak segregation of duties can still let authorised access drive severe loss, as EmpowerID shows through the €4.9 billion Société Générale case. Identity governance fails when risky function combinations are left intact across requests and recertification.
Editorial analysis by NHI Mgmt Group, based on content published by EmpowerID: “Building Resilience: Risk Management in Hybrid Multi-Cloud Environments”.
Key questions
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Glossary terms: Segregation of Duties, Risk Function, Access Recertification
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 10 hours ago by NHI Mgmt Group
22/06/2026 3:48 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Risk management for identity governance needs stronger SoD controls