They should treat access governance, change control, and audit evidence as one control system. That means the same policy logic should govern role design, request approval, sensitive configuration changes, and remediation tracking. If those functions live separately, toxic combinations and weak evidence will persist across the environment.
How to govern Segregation of Duties across applications and change management
Governing SoD well means treating application entitlements, workflow approvals, and change activity as a single control boundary. The practical goal is not just to stop one risky role from being created, but to prevent a user from combining access, approvals, and remediating changes in ways that defeat review. If the control is split across teams or tools, the conflict usually survives in the gaps.
What the SoD control system needs to cover
SoD governance should start with a ruleset that spans business roles, privileged roles, emergency access, and configuration authority. That ruleset needs to define toxic combinations at the level of real tasks, such as request, approve, create, deploy, and reconcile, not just at the level of job titles. The same logic should also cover temporary access and compensating controls, because exceptions are often where segregation breaks down.
It helps to build SoD rulesets and compensating controls around the actual activities that create conflict, rather than around a narrow application-by-application review. In practice, that means the control owner must be able to see whether one person can both initiate and approve the same sensitive path, or both change and validate the result.
change management belongs in the same model because many SoD failures happen after access review, when a production change or remediation path quietly grants the same effective power through a different route. If remediation tickets, code fixes, emergency patches, and configuration updates are outside the SoD policy, the organisation may technically have role separation while still allowing the same person to cause and approve the change.
How to keep SoD evidence reliable across systems
Reliable SoD governance depends on traceable evidence, not just policy statements. The organisation should be able to show who requested access, who approved it, what the role included, what change was made, who tested or validated it, and whether any exception was formally accepted. Without that chain, auditors and control owners cannot distinguish a clean separation from a temporarily convenient workaround.
Evidence quality also depends on making approval and remediation records joinable across systems. Access governance, ticketing, CI/CD, and configuration management tools often record different parts of the same event, so the control must reconcile them into one reviewable story. If one tool says a role was approved and another says the same user deployed the change, SoD analysis should surface that relationship automatically.
That is why many organisations map the process to broader control systems such as NIST Cybersecurity Framework 2.0, especially where governance, control integrity, and continuous oversight need to be tied together. The useful lesson is that SoD is not only a permission problem, it is an assurance problem.
Why SoD breaks in practice, and what to monitor
SoD usually fails when organisations optimise each workflow separately. Identity teams approve access, application owners approve roles, operations approve fixes, and change managers approve releases, but nobody checks whether those approvals together create a toxic combination. The most common breakdown is not a single bad decision, but accumulated consistency failures across multiple systems.
The risk rises when privileged access, emergency access, or production support paths are treated as exceptions without tight follow-up. Those paths are useful for business continuity, but they can quietly become standing workarounds if no one reviews how often they are used, whether they are revoked on time, and whether the same person keeps returning through the exception channel.
Failure mechanism: the organisation separates approvals by system or team, so a user can accumulate conflicting powers across access, change, and remediation workflows without any one approver seeing the full combination.
Impact: toxic combinations persist, audit evidence becomes incomplete, and a single actor may be able to create, approve, deploy, and reconcile a sensitive change with little resistance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | SoD governance is a control-risk problem spanning access and change workflows. |
| PR.AA-05 — Least Privilege | SoD depends on limiting users to non-conflicting access and actions. | |
| Recommendation — Define a cross-system SoD risk strategy and align exceptions, reviews, and evidence to it. Enforce least privilege so no role can both perform and approve conflicting actions. | ||
| NIST SP 800-53 Rev 5 | AC-5 — Separation of Duties | Directly governs conflicting duties across access and operational workflows. |
| AC-6 — Least Privilege | Reduces the chance that one account can accumulate conflicting powers. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | SoD across applications and changes requires evidence that can be reviewed end-to-end. | |
| Recommendation — Assign mutually exclusive duties and review any compensating controls for conflicts. Restrict permissions to the minimum needed for each role and change path. Correlate approvals, deployments, and remediation events in audit reviews. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | SoD is enforced through access design, approval, and review. |
| A.8.32 — Change management | Change control is a core part of SoD when sensitive fixes can bypass separation. | |
| A.5.28 — Collection of evidence | SoD governance needs traceable records for approvals, exceptions, and remediation. | |
| Recommendation — Document access rules that prevent conflicting duties across systems and processes. Require formal change approval and traceability for sensitive production changes. Retain evidence that shows who approved, executed, and validated each sensitive change. | ||
Practitioner Guidance
What to prioritise: define SoD at the process level first, then project it into applications and change workflows. If a control only exists inside one tool, assume it will be bypassed by an adjacent workflow until proven otherwise.
What to verify: for every critical role or change path, verify that approval, execution, and post-change validation are separated in practice, not just on paper. Check whether emergency access, compensating controls, and remediation tickets are reviewed with the same rigor as standard requests.
What to measure: track the number of toxic combinations found after approval, the number of exceptions that remain open past their expiry, and the number of changes whose evidence cannot be reconciled across systems. Those signals show whether SoD is functioning as a control system or merely as a policy document.
Practitioner takeaway: the strongest SoD programs treat access, change, and evidence as one governed lifecycle, because separation that is not continuously reconciled across workflows will erode into hidden privilege.
Related resources from NHI Mgmt Group
- How should organisations govern access consistently across ERP, cloud, and legacy applications as their environments become more heterogeneous?
- How should organisations implement identity and access management across multiple applications and user groups?
- How should healthcare organisations govern access to patient data across applications and privileged workflows?
- How should large organisations centralize identity management across cloud and on-premise applications?