Notifications
Clear all
Topic starter
30/07/2026 10:49 pm
TL;DR: An SoD rule set identifies toxic access combinations, but only an operating control that prevents, detects, remediates, and evidences violations will satisfy auditors, according to OpenIAM. Lists document intent; controls prove that conflicts were blocked, closed, or formally accepted with traceable decisions.
NHIMG editorial — based on content published by OpenIAM: A List of SoD Rules Is Not a Control
By the numbers:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
Questions worth separating out
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: Why do SoD rule lists fail audit testing?
A: Because auditors test operating effectiveness, not policy existence.
Q: What makes an SoD exception defensible?
A: A defensible exception has a named owner, a documented rationale, a compensating control, and a review date.
Practitioner guidance
- Map each SoD rule to an operating workflow Link every toxic access combination to preventive approval logic, detective scans, remediation ownership, and evidence retention so the rule can be tested as a live control.
- Require audit-ready exception records Capture the owner, rationale, compensating control, and review date for every accepted conflict in the same system that records the SoD decision.
- Test operating effectiveness, not policy existence Select sample conflicts and verify that at least one was blocked, one was remediated, and one exception has a complete decision trail with timestamps.
What's in the full article
OpenIAM's full post covers the operational detail this post intentionally leaves for the source:
- A risk-ranked SAP SoD reference model that shows how rule definitions map to business entitlements.
- The distinction between design evidence and operating effectiveness evidence for regulated audits.
- Practical examples of preventive enforcement, remediation tracking, and exception documentation.
- How OpenIAM positions its SAP SoD Risk Reference as a structured rule set for enforcement workflows.
👉 Read OpenIAM's analysis of why SoD rules are not the same as controls →
SoD rules vs controls: is your programme audit-ready?
Explore further
30/07/2026 10:55 pm
SoD is a governance process, not a catalogue. A rule list can describe dangerous combinations of access, but it does not prevent them, detect them in live entitlements, or produce evidence that a decision was made. That difference matters because auditors and regulators test operating effectiveness, not the existence of policy text. The implication is simple: if the programme cannot show action, it is not a control.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which shows how often governance stops at documentation.
A question worth separating out:
Q: How do SoD rules fit into identity governance programmes?
A: They act as the conflict definition layer inside broader IAM and IGA processes. The rule set tells the organisation which entitlement combinations are dangerous, while lifecycle and access review workflows ensure those conflicts are prevented, detected, or remediated over time. The rule is input, not the programme.
👉 Read our full editorial: SoD rules are not controls: what auditors actually test
