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.
Editorial analysis by NHI Mgmt Group, based on content published by OpenIAM: “A List of SoD Rules Is Not a Control”.
Key questions
Q: What breaks when an SoD programme is only a rule list?
A: A rule list documents which access combinations are dangerous, but it does not prevent them, detect them in live access, or prove remediation.
Q: Why do auditors care more about SoD operating effectiveness than rule design?
A: Because rule design only shows that the organisation understands the risk.
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.
Practitioner guidance
- Convert SoD rules into enforced request checks Wire conflict logic into access request approval so toxic combinations are blocked before entitlement issuance, and retain the denial record as evidence.
- Build remediation workflows for existing conflicts Route every detected SoD violation to a named owner, assign a closure date, and preserve the full path from finding to resolution.
- Document exceptions as controlled decisions Capture the owner, rationale, compensating control, and review date for every accepted conflict so exceptions remain auditable.
Bottom line: A list of SoD rules identifies toxic combinations, but it does not prove that the organisation can stop, resolve, or justify them.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
30/07/2026 10:55 pm
SoD rule sets are governance inputs, not governance outcomes: The article is right to separate the definition of conflict from the operating process that handles it. A catalogue of toxic combinations can support design review, but it does not prove the organisation prevented, detected, or closed anything. Practitioners should treat the rule set as an input to control operation, not the control itself.
A question worth separating out:
Q: What should teams do when a SoD conflict cannot be removed immediately?
A: Use a documented mitigating control with a named owner, a defined frequency, and a clear link to the affected financial process. If those elements are missing, the exception exists without defensible governance and will be difficult to justify in SOX testing.
👉 Read our full editorial: SoD rules are not controls: what auditors actually test