Segregation of duties breaks when controls stay static

At a glance

What this is: This is an analysis of why traditional segregation of duties programmes fail in modern hybrid environments and why static, detective controls no longer keep pace.

Why it matters: It matters because SoD now intersects with identity lifecycle, privileged access, and cross-system governance, so IAM, IGA, PAM, and control owners need enforcement that can follow change in real time.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.

👉 Read SafePaaS's analysis of why traditional segregation of duties falls short

Context

Segregation of duties is a control design problem, not a calendar exercise. In hybrid estates, access moves faster than policy refresh cycles, so static role matrices and spreadsheet reviews miss the toxic combinations that emerge when business processes, entitlements, and exceptions change across ERP, SaaS, and custom applications.

That gap is an identity governance issue as much as a finance or audit issue. When SoD is enforced late, organisations can detect conflict after a transaction has already been approved, posted, or concealed, which means IGA, PAM, and lifecycle controls have to operate as part of the control fabric rather than as after-the-fact evidence collection.

Key questions

Q: How should teams enforce segregation of duties in hybrid IT environments?

A: Teams should enforce SoD with centralised policy logic that evaluates actual business process risk across ERP, SaaS, and custom systems. Periodic role reviews are not enough when access changes constantly. The control has to follow entitlement changes, exception grants, and lifecycle events so toxic combinations are blocked or remediated before use.

Q: What breaks when segregation of duties relies on annual spreadsheet reviews?

A: Annual spreadsheet reviews fail because they see access too late and too abstractly. By the time a conflict is documented, the user may already have created, approved, or concealed a transaction. That makes SoD a reporting exercise rather than a preventive control, which is a governance failure.

Q: How do organisations know whether SoD controls are actually working?

A: SoD is working when conflict detection is tied to live identity and transaction events, not just audit reports. A useful signal is whether risky combinations are resolved before a transaction completes, whether exceptions are documented by process owners, and whether remediation happens inside the operational workflow.

Q: Who should own exceptions when toxic access cannot be removed immediately?

A: Business process owners should own exceptions because they understand the operational need and the risk trade-off. IT can enforce the mechanics, but only the business can justify why a conflicting combination exists, how it is compensated, and when it should be removed or re-reviewed.

Technical breakdown

Why static role models fail in hybrid environments

Traditional SoD depends on stable roles and predictable process boundaries. In practice, hybrid IT creates a moving target because entitlements are split across ERP, SaaS, and custom systems, while business units create exceptions to keep work moving. Role-based rules cannot express every toxic combination cleanly, especially when context such as legal entity, geography, or business unit changes the risk outcome. The failure is not the policy idea, but the assumption that role design alone can keep pace with operational change.

Practical implication: move SoD policy out of static role design and into centralised rules that evaluate context, not just job titles.

How toxic access combinations escape detective controls

Detective SoD finds conflicts after they exist, which is too late if the conflicting access has already been used. Toxic combinations often emerge through exceptions, temporary assignments, and accumulated privilege across multiple systems. Once a user can create, approve, and reconcile the same business event, the risk is no longer theoretical. Fine-grained entitlement analysis is required because generic role names hide the actual actions a user can perform, especially in systems where permissions are inherited or layered.

Practical implication: inspect transaction-level permissions and exception paths, not only annual role attestation reports.

Continuous monitoring and remediation as control mechanics

Continuous SoD works by collecting access changes, lifecycle events, and actual usage patterns as they happen, then comparing them against policy. That is different from audit logging alone. Logging records what happened; continuous control decides whether the current access state is still acceptable and whether compensating controls are needed. The architecture must connect identity changes to business process risk so that conflicts are remediated while they are still actionable, not after the fact.

Practical implication: connect SoD monitoring to access workflow, remediation, and business approval processes so conflict resolution is operational, not just evidentiary.

NHI Mgmt Group analysis

Static SoD is a control assumption that no longer holds in hybrid IT. The programme premise was that access could be reviewed on a cycle because roles and permissions were relatively stable between reviews. That assumption breaks when applications, exceptions, and business processes change continuously across ERP and SaaS estates. The implication is not a better spreadsheet, but a different control model that treats SoD as a live governance state.

Toxic access is usually created by accumulation, not one obvious policy failure. Users inherit access through role growth, temporary exceptions, and cross-system privilege overlap until a single person can complete incompatible steps in one process. This is why detective reporting often looks clean until a transaction is traced end to end. Practitioners need to see SoD as an entitlement accumulation problem, not merely a policy definition problem.

Continuous enforcement is now the difference between control evidence and control effectiveness. Many organisations can produce SoD reports for auditors, but that does not mean they can stop risky combinations before use. The field should treat policy engines, workflow approvals, and lifecycle events as one governance chain. That is the standard required for defensible internal control in dynamic environments.

Control drift at transaction level: the real failure mode here is that transaction rights outgrow role definitions faster than periodic reviews can compress them back into compliance. In practice, the business process becomes the unit of risk, not the user role. Practitioners should therefore evaluate whether controls are built around actual transaction paths rather than abstract job architecture.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Another finding from the Ultimate Guide to NHIs shows that 97% of NHIs carry excessive privileges, which helps explain why static controls miss risk.
• For practitioners, the forward step is to pair SoD policy with lifecycle enforcement through the NHI Lifecycle Management Guide, so exceptions do not outlive the access they were meant to constrain.

What this signals

Control drift at transaction level: SoD programmes should be judged by whether they can stop conflicting access before a transaction completes, not by how many conflicts appear in a quarterly report. That shift matters because static role reviews create a false sense of coverage in estates where entitlements mutate continuously.

The identity governance team should expect SoD to intersect more tightly with lifecycle events, approval workflows, and entitlement analytics. When access changes are the trigger for enforcement, the programme becomes materially more defensible for audit and much harder for toxic combinations to hide inside accumulated privilege.

For organisations that still separate identity administration from process risk ownership, the operating model is the problem. SoD only becomes durable when access, workflow, and control evidence are governed as one system, which is why mapping to the NIST Cybersecurity Framework 2.0 is useful for control ownership and continuous monitoring.

For practitioners

• Centralise SoD policy around business process risk Map toxic combinations to real process steps such as create, approve, post, and reconcile, then apply the same policy logic across ERP, SaaS, and custom applications.
• Move from annual review to continuous conflict detection Trigger SoD evaluation on access changes, exception grants, and identity lifecycle events so risky combinations are identified before they are used in a transaction.
• Inspect entitlement inventories at transaction level Review the actual permissions, menus, and privileges that enable action rather than relying on role names or job titles, which often hide layered access.
• Require documented business ownership for exceptions Route risky combinations to process owners for approval with a full justification trail, then tie the exception to a review date and remediation path.

Key takeaways

• Static segregation of duties programmes fail because hybrid IT changes faster than periodic review cycles can track.
• The scale of the visibility problem is already severe, with only 5.7% of organisations reporting full visibility into their service accounts.
• The practical fix is continuous, process-level enforcement that ties exception handling, lifecycle events, and remediation into one control chain.

Key terms

• Segregation of Duties: Segregation of duties is a control pattern that prevents one identity from completing incompatible steps in the same process. In practice, it limits fraud and concealment by separating creation, approval, execution, and reconciliation rights across people or systems.
• Toxic Access Combination: A toxic access combination is a set of permissions that becomes risky when held together, even if each entitlement looks acceptable on its own. The danger appears when the combined rights let an identity create, approve, alter, and hide the same business event.
• Compensating Control: A compensating control is an alternative safeguard used when the ideal SoD separation cannot be enforced immediately. It does not remove the conflict, but it reduces exposure through independent oversight, additional approval, or constrained execution until the access can be corrected.
• Continuous Monitoring: Continuous monitoring is the ongoing evaluation of identity changes, access use, and control drift as they happen. For SoD, it turns control from an annual check into an operational function that can flag and resolve risk before the business event completes.

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.

This post draws on content published by SafePaaS: segregation of duties in modern hybrid environments. Read the original.