SoD rules are not controls: what auditors actually test

At a glance

What this is: This is an analysis of why segregation of duties rules are not the same as segregation of duties controls, and the key finding is that auditors test operating effectiveness, not the existence of a rule list.

Why it matters: It matters because IAM, IGA, PAM, and compliance teams need evidence that access conflicts are prevented or remediated in operation, not merely defined in policy.

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.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read OpenIAM's analysis of why SoD rules are not the same as controls

Context

Segregation of duties fails when it is treated as a document rather than an operating control. In practice, many organisations can list toxic access combinations, but they cannot show that requests were blocked, legacy access was remediated, or exceptions were approved with evidence.

This distinction is central to IAM governance because SoD sits at the intersection of identity lifecycle, privilege management, and audit evidence. The same mistake appears in non-human identity programmes when teams maintain inventories or policy lists without enforcing them at the request layer or proving closure.

For teams trying to tighten governance across human, machine, and privileged access, the operational question is the same: does the control change outcomes, or only describe risk? That is why structured rule catalogues need to connect to enforcement workflows and reviewable evidence, not remain as static references.

Key questions

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: Why do SoD rule lists fail audit testing?

A: Because auditors test operating effectiveness, not policy existence. A rule list may prove the organisation identified risky combinations, but it does not prove that access was prevented, that violations were remediated, or that exceptions were formally accepted. Without evidence of decisions and closure, the list documents intent rather than control.

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. If any of those are missing, the exception becomes an unsupported access risk. The strongest programmes treat exceptions as controlled outcomes, not informal approvals hidden in email or chat threads.

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.

Technical breakdown

SoD rule sets vs operating controls

An SoD rule is a policy definition. It states that a single identity must not hold a combination of entitlements that enables both creation and concealment of an action, such as initiating and approving the same payment. A control is the process that acts on that rule continuously. It evaluates requests before access is granted, scans existing entitlements for violations, drives remediation, and preserves the decision trail. The rule describes the risk. The control proves the organisation managed it. In governance terms, the rule catalog is the control input, not the control itself.

Practical implication: map each SoD rule to a live enforcement, detection, and remediation workflow before calling the programme operational.

Why auditors test operating effectiveness

Audit testing separates design from operating effectiveness. Design asks whether the rule logic is sound and the risk has been identified. Operating effectiveness asks whether the control actually prevented conflicts, detected them in existing access, and recorded what happened during the review period. A spreadsheet or GRC list can satisfy design, but it cannot prove action. Evidence must show a request blocked at the decision point, a conflict routed to an owner, or an exception documented with rationale, compensating control, and review date. Without that trail, the organisation has awareness, not control.

Practical implication: retain timestamps, owners, closure records, and exception approvals as first-class audit evidence, not as after-the-fact reconstruction.

Preventive enforcement and exception handling

The strongest SoD evidence is preventive enforcement at the request layer, because a conflict that never existed is easier to defend than one that was cleaned up later. But prevention alone does not cover inherited access, role drift, or temporary business exceptions. Mature programmes pair prevention with detection and remediation for existing conflicts, then formalise any tolerated exceptions. A defensible exception includes the owner, rationale, compensating control, and review date. If those elements live only in email, the control is informal. If they are exportable on demand, the programme can survive scrutiny.

Practical implication: require every exception to carry an owner, rationale, compensating control, and expiry date in the same workflow as the rule decision.

Threat narrative

Attacker objective: The objective is to use toxic access combinations to commit and conceal actions while leaving the organisation without defensible evidence of control.

1. Entry occurs when a conflicting access combination is requested or inherited without an enforcement point to stop it.
2. Escalation happens when the identity can both execute and conceal the same business action because the conflict was never blocked or remediated.
3. Impact is audit failure, fraud exposure, or control breakdown because the organisation cannot prove what was prevented, accepted, or closed.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Preventive enforcement at the request layer is the clearest control boundary. When a conflict is stopped before it exists, the organisation gets the strongest possible evidence of SoD operation. But prevention must be paired with detection and remediation for inherited or legacy access, otherwise the programme only protects new requests. Practitioners should treat the rule set as an input to enforcement, not as a substitute for it.

Exception management is where many SoD programmes quietly fail. A conflict that is formally accepted can still be defensible, but only if the organisation records the owner, rationale, compensating control, and review date. Informal acceptance through email or ad hoc approvals creates the appearance of governance without the evidence trail. The implication is that exception handling must be part of the control, not a side channel.

Static SoD inventories create false confidence across identity programmes. The same pattern appears in NHI governance when teams maintain lists of risky service accounts, tokens, or roles without connecting them to lifecycle actions and proof of remediation. The named concept here is the control-to-evidence gap: a documented risk that has no operational trace. Practitioners should assume that any unexecuted rule set will fail the first serious audit.

Risk-ranked rule design matters because control capacity is finite. A useful SoD programme prioritises the combinations that create the highest fraud or abuse potential and maps them to real entitlements in target systems. That ranking makes enforcement and remediation tractable instead of theoretical. The practical conclusion is to reduce the rule set to business-readable conflicts that can actually be operated and evidenced.

From our research:

• 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.
• That same lifecycle gap is explored in NHI Lifecycle Management Guide, which helps practitioners move from inventory to enforceable governance.

What this signals

Control-to-evidence thinking should spread beyond SoD into NHI governance. If teams can list risky service accounts but cannot prove who owns them, how they are reviewed, or when they are revoked, they have reproduced the same failure mode in a different domain. The control only exists when lifecycle events create evidence, not just inventory.

With 96% of organisations storing secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, the governance lesson is clear: static artefacts do not equal operating control. For identity teams, that means tying reviews, enforcement, and evidence to the systems where access is actually requested and used.

Rule catalogues need a lifecycle path. That means integrating SoD conflict management with joiner-mover-leaver events, privileged access reviews, and exception expiry so decisions do not outlive the identity state that created them. Teams that cannot export that trail on demand should treat the programme as incomplete rather than compliant.

For practitioners

• 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.
• Tie SoD reviews to identity lifecycle events Re-evaluate SoD conflicts when users move roles, gain privileged access, or inherit entitlements so dormant combinations do not persist across joiner-mover-leaver changes.

Key takeaways

• A list of SoD rules describes risk, but only an operating control can prove that conflicts were prevented, detected, remediated, and evidenced.
• Auditors test operating effectiveness, so blocked requests, closure records, and exception approvals matter more than the presence of a policy catalog.
• The practical standard is a rule set tied to enforcement, lifecycle review, and exportable evidence, not a spreadsheet of toxic combinations.

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.
• Exception record: An exception record is the formal evidence that a known SoD conflict was temporarily accepted rather than eliminated. It should include the owner, rationale, mitigating measure, and review date. Without those fields, the exception becomes an unmanaged access exposure instead of a controlled decision.

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.

👉 OpenIAM's full post covers the audit evidence model, control operation, and SoD exception handling in more detail.

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 building or maturing an IAM programme, it is worth exploring.