Design vs. Operating Effectiveness: Why SoD Programs Pass on Paper and Fail Under Testing

Author : Tushar Pansare | Published On : 25 Aug 2026

Segregation of duties programs rarely fail because the rules are wrong. They fail because nothing enforced them. In control-testing terms, the distinction is between design effectiveness — are the right conflicts defined, and would the control mitigate the risk if it operated? — and operating effectiveness: did the control actually operate throughout the period, and can the organization prove it? A well-researched rule catalog can pass the first test outright and contribute nothing to the second. That gap, between a control as described and a control as operated, is where most SoD findings originate. 

Key Takeaways 

Design effectiveness asks whether the rules are right; operating effectiveness asks whether they ran — and left a record. 

Most SoD findings are operating failures: sound rules with no enforcement point, no remediation path, and no evidence. 

Testers sample three evidence classes — prevention decisions, remediation closures, and documented exceptions. 

A documented rule set with no operating control proves awareness without action — a worse audit position than it appears. 

What is the difference between design and operating effectiveness in SoD? 

Design effectiveness is evaluated by inspection. A tester reads the rule set and asks whether the defined conflicts reflect real risk: does the catalog capture the combinations that would let one person both commit and conceal an error or fraud? Sound logic, sensible coverage, reasonable risk ranking — design passes. 

SoD operating effectiveness is evaluated by sampling. The tester selects transactions from the period and asks what the control did with each: an access request that would have created a conflict — was it evaluated and blocked, and where is the record? A violation identified in existing access — who owned it, and when was it closed? An accepted conflict — where is the rationale, the compensating control, the review date? Design is about the quality of the rules. Operation is about the existence of the record. 

Where paper programs collapse 

The typical failure sequence is consistent across industries. An organization invests in building the rule set — workshops, risk analysis, a reviewed and approved catalog — and then stores it. There is no enforcement point between the rules and the access request process, so requests are approved without ever being evaluated against the catalog. There is no scanning cadence, so conflicts in existing access accumulate silently. There is no remediation path, so the conflicts that do surface — usually during audit preparation — land in a report with no owner and no closure mechanism. 

When testing begins, the sequence produces a predictable result. The tester asks for the period's prevention decisions: none exist, because no request was ever evaluated. The tester asks for remediation records: a partial list exists in a spreadsheet, with no timestamps and no owner history. The tester asks for exception documentation: the exceptions were discussed in email. Each individual answer is a deficiency; together they establish that the control described in the design documentation did not operate. 

There is a second-order problem that makes this worse than having no program at all. The approved rule catalog is proof of awareness. The organization identified the dangerous combinations, documented them, and cannot demonstrate that it acted. In a regulatory examination or a fraud post-mortem, segregation of duties enforcement that exists on paper but not in operation converts the rule set from an asset into an exhibit. 

What testers sample — and what has to exist 

Operating effectiveness testing for SoD reduces to three evidence classes, each of which can only exist if the corresponding operation ran during the period: 

Prevention decisions. Records showing that access requests were evaluated against the rules at the point of request, with conflicting requests blocked and the outcome logged. These records cannot be created retroactively — either the enforcement point existed during the period or it did not. 

Remediation closures. For each identified conflict: the routing to a named owner, the action taken, and the closure timestamp. An identified conflict with no closure trail is an open finding, not evidence of a functioning control. 

Documented exceptions. For each accepted conflict: the owner, the rationale, the compensating control, and the scheduled review date. Well-documented exceptions strengthen the test result; undocumented ones fail it. 

Note what all three have in common: they are byproducts of a process, not documents anyone writes. An organization cannot draft its way to operating effectiveness in the weeks before an audit. The evidence either accumulated during the period or it is absent. 

Closing the gap 

The remedy is structural rather than documentary. The rule set — ideally a structured SoD rule set expressed in business language and mapped to real entitlements — becomes the input to a governed process: evaluation at the point of access request, detection across existing access, remediation routed and tracked to closure, exceptions captured with rationale and expiry, and every decision recorded in an exportable trail. The distinction between SoD rules vs controls is exactly this: the rules define what the control enforces, and the control generates the evidence that testing will later sample. In practice, that process runs on an access governance platform — because request-time evaluation, tracked remediation, and continuous evidence capture are workflow capabilities, not documentation exercises. 

The test most SoD programs face is not whether the rules are good. It is whether anything happened because of them. Design gets a program approved. Operation gets it through the audit.