Ask a regulated organization about its segregation of duties program and an artifact usually appears: a spreadsheet of conflicting role combinations, or a rule catalog inside a GRC platform. The artifact is real. But it answers only one question — does the organization know which access combinations are dangerous? It says nothing about the question auditors actually ask: is anything being done about them?
The distinction is simple to state. An SoD rule names a toxic combination of access — two or more entitlements that, held by one person, would allow an error or fraud to be both committed and concealed. A segregation of duties control is the operating process built around those rules: it prevents the combination from being granted, detects it where it already exists, remediates or formally accepts it, and records evidence of every decision. A rule describes a risk. A control proves the risk was handled.
An SoD rule is the written definition of a dangerous access combination; an SoD control is the operating process that enforces that rule, detects violations, remediates them, and records the evidence.
The SoD rules vs controls distinction starts here. A rule is a definition. It states that no single person should be able to, for example, initiate a payment and approve that same payment, or create a supplier record and release funds to it. Rules are written once, reviewed periodically, and stored somewhere — a spreadsheet, a policy document, a GRC record.
A control is an operation. It is what the organization does, continuously, with the rule: enforce it when access is requested, scan for violations in existing access, drive each finding to an owner and a resolution, document the exceptions it chooses to live with, and record all of it.
The practical difference shows up in what each can tell you:
That last item is where the SoD rules vs controls debate stops being academic. Rules are evaluated by reading them. Controls are evaluated by testing them.
A rule list alone fails an audit because auditors test operating effectiveness — evidence that the rules actually prevented or remediated conflicts during the period — and a standalone list produces none of it.
Audit methodology draws a line between design and operating effectiveness. A well-constructed rule set may pass the design test: the risks are identified and the logic is sound. Operating effectiveness is a different examination. The auditor is not asking whether the rules exist, but for proof that they did something during the audit period.
That proof is specific. Show a request that would have created a conflict, and the decision that stopped it. Show the conflicts identified in existing access, the owner each was routed to, and the date each was closed. Show the exceptions — and for each, the documented rationale, the compensating control, and the scheduled review date. A standalone rule list can produce none of this — none of it was ever generated. There was no enforcement point, no remediation workflow, no decision record. The rule set has been describing risk, unattended, since the day it was written.
There is a sharper problem. A documented rule set with no operating control proves the organization knew. It wrote down which combinations were dangerous, and it cannot demonstrate that it acted on that knowledge. In an audit finding or a fraud post-mortem, documented awareness with absent enforcement is a worse position than it appears.
The same logic extends beyond SoD. A completed access review certification, signed and filed, faces the identical test — did it operate meaningfully, and where is the evidence?
A rule list becomes a control when three things operate together — preventive enforcement at the point of request, detection and remediation of existing conflicts, and documented exception handling — and the resulting evidence is exportable on demand.
Three elements separate a catalog of rules from an operating segregation of duties control. Each produces its own class of SoD audit evidence.
Preventive enforcement at the point of request. Access requests are evaluated against the rule set before approval. A request that would create a defined conflict is blocked, and the prevention decision is recorded. The strongest evidence a rule can generate is a conflict that never came to exist.
Detection and remediation for access that already exists. Preventive checks do not reach legacy entitlements, inherited access, or entitlements accumulated across role changes. Detection finds those conflicts; remediation is what makes the finding matter. Each violation needs a named owner, a tracked path to resolution, and a closure record with a timestamp. A finding that sits unowned in a report is not remediation — it is a future audit finding with a discovery date attached. SoD remediation evidence is precisely this trail: found, routed, resolved, recorded.
Evidence for every decision — including the exceptions. Not every conflict can or should be eliminated immediately. Small teams and transitional periods produce access risk that is accepted rather than removed. A compensating control for an SoD conflict is defensible only when it is documented: the owner, the rationale, the mitigating measure, the review date, and the expiry. An exception managed this way is SoD control evidence. An exception living in an email thread is a liability.
When these three elements run together and the record is exportable on demand — not assembled under audit pressure — the rule set has become what it was always meant to feed: a control.
SoD rule sets add real value as the essential input a control enforces against — but only when they are well-defined, business-readable, mapped to real entitlements, and ranked by risk.
None of this argues against rule sets. It argues against stopping at one. Without well-defined rules, preventive enforcement has nothing to evaluate against and detection has nothing to scan for.
Quality matters more than volume. A useful rule set describes each conflict in business language rather than raw entitlement codes, states why the combination is dangerous, maps cleanly to the entitlements that exist in target systems, and ranks conflicts by risk so remediation lands where exposure is highest. Rule sets built this way shorten the path from catalog to operating control. OpenIAM's SAP SoD Risk Reference is an example of the form: a structured, risk-ranked rule set designed to be enforced, not just filed.
The distinction to hold onto: the rule set defines what the control enforces. Are SoD rules enough? As an input, they are essential. As the program, they are a list.
No. A rule defines a toxic combination of access; a control is the operating process that prevents the combination, detects and remediates it where it exists, and records evidence of each decision. A list with no enforcement and no evidence documents intent, not operation.
An SoD rule is the definition of a dangerous access combination — for example, the ability to both initiate and approve the same payment. An SoD control is the process that operates on that definition: prevention at the point of request, detection across existing access, remediation tracked to closure, and documented exceptions. The rule is the input; the control is the operation and the evidence it produces.
An audit-ready SoD program can show that conflicts were prevented at the point of request or identified and reviewed, that every decision was recorded with an owner and a timestamp, and that remediation was tracked to completion. Exceptions are documented with rationale, compensating controls, and review dates. The full record is exportable without a manual reconstruction effort.
No. A spreadsheet documents which combinations the organization considers dangerous — it demonstrates intent, not operation. Auditors test operating effectiveness: whether conflicts were actually prevented or remediated during the period, with evidence of the decisions made.
No. Rules define which access combinations are dangerous, but they neither prevent those combinations nor evidence that anything was done about them. They become sufficient only as the input to an operating control: enforcement, remediation, and a recorded decision trail.
Yes. The rule set defines what the preventive control evaluates requests against; without it, there is nothing to enforce. The rules are the input, and the control is the operation built on top of them.