SoD rules are not controls: what auditors actually test

At a glance

What this is: This article separates SoD rules from SoD controls and concludes that auditors test operating effectiveness, not the existence of a conflict list.

Why it matters: IAM, IGA, and PAM teams need to treat SoD as an operating process with evidence, because rule catalogs alone do not prove prevention, remediation, or accountable exceptions.

Context

Segregation of duties is an identity governance control pattern, not just a policy artifact. The core mistake many programmes make is treating a list of conflicting access combinations as proof that the risk is managed.

The article argues that an SoD rule identifies what should not coexist, while a control is the operating process that blocks, detects, remediates, and documents those conflicts. For audit and compliance teams, that difference determines whether the programme can demonstrate operating effectiveness.

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. Without operating evidence, the programme can show intent but not effectiveness, which is exactly what auditors test. That gap turns a policy artifact into an audit risk rather than a control.

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. Operating effectiveness shows whether the control actually blocked conflicts, found existing violations, closed them, and documented exceptions during the review period. Auditors need proof of action, not just proof of awareness, because only action demonstrates that the control worked in practice.

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 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.

Technical breakdown

SoD rules define risk, not control operation

An SoD rule is a declarative statement about toxic access combinations, such as initiating and approving the same payment. It is written once, reviewed periodically, and stored in a policy, spreadsheet, or GRC catalogue. By itself, it says only that the organisation knows the risk exists. A control is different: it turns the rule into an operating mechanism that evaluates access requests, scans existing entitlements, routes findings to owners, and records decisions. In audit terms, the rule supports design; the control supports operating effectiveness.

Practical implication: map every SoD rule to an enforced workflow and evidence trail, not just a documented conflict list.

Why auditors test operating effectiveness of SoD

Auditors do not stop at whether conflicts are defined. They ask whether the control prevented a risky request, identified existing violations, drove remediation to closure, and captured approved exceptions with rationale and review dates. That is operating effectiveness: proof that the control actually worked during the review period. A static list cannot demonstrate any of those events because it generates no decision record. If the organisation cannot export timestamps, owners, closures, and exception approvals on demand, it has not shown that the control operated.

Practical implication: retain request denials, remediation closure records, and exception approvals as audit evidence, not just rule definitions.

Preventive enforcement creates the strongest SoD evidence

The strongest SoD evidence is a conflict that never existed because the request layer blocked it before approval. This requires the access workflow to evaluate the rule set at request time, not after the fact. Detection still matters for legacy access, inherited entitlements, and role drift, but it is weaker evidence than preventive enforcement because it deals with already-present exposure. Where organisations rely only on periodic reviews, they end up proving they can find problems, not that they can stop them from being granted in the first place.

Practical implication: place SoD checks in the request path first, then use detection and remediation for legacy conflicts.

NHI Mgmt Group analysis

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.

Auditable SoD depends on evidence of decisions, not policy existence: Auditors are testing whether the control operated during the period under review. That means denial records, remediation trails, exception approvals, compensating controls, and review dates matter more than the existence of a spreadsheet. The control boundary is the decision record, not the rule document.

Preventive request-layer enforcement should be the primary SoD posture: A conflict blocked at request time is stronger evidence than a conflict later discovered in a review cycle. The closer the check sits to entitlement issuance, the less the organisation relies on after-the-fact cleanup. That changes the governance model from documentation-led to operation-led.

Exception handling is part of the control, not a loophole around it: The article correctly frames exceptions as defensible only when they are owned, rationalised, mitigated, and time-bound. An exception without a review date is not a controlled risk. A mature SoD programme makes exception governance visible enough to survive audit scrutiny and internal challenge.

SoD rule design still matters because weak definitions create weak control outcomes: Business-readable rules mapped to real entitlements are the only way enforcement and detection can work reliably. Overly technical or incomplete conflict definitions create blind spots that look like control success until an audit or incident forces the gap into view. Good governance starts with accurate rules, but it ends with operating evidence.

What this signals

Audit-ready SoD is a decision trail, not a policy shelf: The programme signal to watch is whether every conflict has an owner, a timestamp, and a closure path. If those records cannot be produced on demand, the organisation is relying on documentation instead of control operation.

Access governance is strongest when prevention sits at the request layer and remediation is reserved for legacy exposure. That reduces the number of conflicts that ever become audit evidence and shifts the team from cleanup to control design.

For practitioners

• 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.
• Test exportable audit evidence on demand Verify that denial logs, exception approvals, and remediation closures can be exported without manual reconstruction when auditors ask for them.

Key takeaways

• A list of SoD rules identifies toxic combinations, but it does not prove that the organisation can stop, resolve, or justify them.
• Auditors test whether conflicts were prevented or remediated during the period, and whether each decision left a durable evidence trail.
• The control becomes audit-ready only when request-layer enforcement, remediation workflows, and documented exceptions operate together.

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.
• Operating Effectiveness: Operating effectiveness is the proof that a control works in real conditions, not just on paper. In DORA contexts, assessors look for logs, timestamps, approvals, and repeatable execution that show the control kept functioning over time.
• Compensating Control: A compensating control is a measure that reduces risk when the ideal fix, such as immediate patching or redesign, is not possible. In OT, compensating controls often include session recording, access restriction, and tighter monitoring. They do not eliminate the underlying issue, but they narrow exposure until safer remediation can happen.

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.