Hybrid IT makes SoD harder because ERP, SaaS, and legacy systems often encode roles differently, so the same access pattern can look safe in one place and risky in another. That inconsistency creates policy drift and weakens auditability. Continuous, centralised policy enforcement is needed to keep the control coherent across platforms.
Why hybrid IT breaks a single, clean SoD model
Segregation of duties depends on consistent meaning, not just consistent labels. In hybrid environments, ERP, SaaS, and legacy platforms often model roles, entitlements, and approval paths differently, so the same business function may be split in one system and combined in another. That makes SoD analysis harder because you are comparing control intent across control planes, not simply checking a role name.
Hybrid estates also create translation problems at the governance layer. A permission set in one platform can map to multiple entitlements elsewhere, or be hidden inside application-specific admin functions that never appear as a single obvious toxic combination. The control is still possible, but the organisation has to reconcile multiple access vocabularies before it can decide whether a conflict exists.
That is why SoD in hybrid IT is less about one-time role design and more about control coherence. When policy is defined centrally but enforced locally, drift appears as systems evolve at different speeds, and reviewers can no longer tell whether an access pattern is genuinely safe or only safe in one environment. A Segregation of Duties (SoD) Guide is useful here because it frames toxic combinations, mitigations, and access governance across ERP, service accounts, bots, and AI agents.
Where policy drift and audit gaps usually appear
The most common failure is not a dramatic breach, but inconsistent enforcement. One system may block a role combination while another allows the same effective capability through a different entitlement structure. Over time, local exceptions, temporary access, and vendor-specific admin models accumulate into policy drift, which is hard to spot if reviews look only at individual platforms instead of cross-system effect.
Auditability weakens for the same reason. Auditors and control owners need a reproducible explanation for why a person or process can initiate, approve, and execute a sensitive action. If access is assembled from several systems, the evidence trail often becomes fragmented, and the organisation cannot easily demonstrate that the same SoD rule is being applied everywhere. That is the practical gap between having access reviews and having a defensible control.
This is also where compensating controls become risky if they are not centrally governed. A mitigation that is acceptable in one application may not cover the full business process when the workflow spans SaaS, ERP, and a legacy back end. The environment can therefore look compliant at the system level while still permitting an unsafe end-to-end path.
How to keep SoD coherent across hybrid platforms
The control objective is to make SoD decisions at the business-process level, then enforce them consistently through connected policy and authoritative identity data. That usually means one central ruleset, clear ownership for exception handling, and a mapped view of equivalent privileges across platforms rather than relying on native role names to tell the whole story. Centralisation matters because the risk is cross-platform inconsistency, not merely overpermission in one application.
Practically, SoD works best when organisations treat role engineering, provisioning, and review as one lifecycle. Define the prohibited business actions, map them to each platform’s entitlements, and validate that the mapping still holds after application upgrades, migrations, or vendor configuration changes. Where the business cannot remove a conflict immediately, the compensating control should be explicit, time bound, and reviewable rather than informal.
Hybrid estates also benefit from continuous monitoring of effective access, not just periodic recertification. If the control is only checked during annual reviews, drift can persist for months. If the organisation instead monitors role changes, privileged exceptions, and workflow exceptions centrally, it can catch the point where a safe pattern in one system becomes a toxic combination across systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-5 — Separation of Duties | Directly addresses SoD enforcement and conflicting duties across hybrid systems. |
| AC-6 — Least Privilege | Hybrid SoD failures often expose excess effective access beyond needed duties. | |
| Recommendation — Define and enforce separation rules across all platforms and exceptions. Limit each role and account to the minimum access needed for its function. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Hybrid SoD depends on consistent access policy and enforcement across systems. |
| Recommendation — Document and enforce access rules consistently across all connected environments. | ||
| CIS Controls v8 | CIS-5 — Account Management | SoD drift often comes from inconsistent account and privilege handling across platforms. |
| Recommendation — Standardise account and privilege lifecycle controls across the hybrid estate. | ||
Practitioner Guidance
What to prioritise: Start with the business transactions that create the highest fraud, payment, or integrity exposure, then map those actions across every platform that can execute or approve them. That is usually more effective than trying to normalise every role in the estate at once.
What to verify: Verify that each SoD rule has a single business definition, a platform-specific entitlement mapping, and a clear exception owner. If any one of those is missing, the control may be documented but not actually enforceable.
Common mistake: Treating native application roles as if they were equivalent across systems. In hybrid environments, role names are often misleading, so the meaningful question is whether the effective permissions can combine into the same unsafe business outcome.
Practitioner takeaway: Hybrid SoD succeeds only when the organisation controls the business meaning of access centrally and proves that each platform implements that meaning consistently, even when the underlying roles look different.