They should resolve the disagreement in favour of the more precise business-function conflict model, then update the role design and mitigation rules. An access review that ignores SoD can reapprove unsafe access, while an SoD rule that is out of date can block legitimate work. Governance has to reconcile both.
How to reconcile access reviews with SoD without breaking governance
Access reviews and SoD checks answer different questions. A review asks whether a person should keep access; SoD asks whether a combination of access creates an unacceptable business-function conflict. When they disagree, treat the SoD model as the sharper signal for conflict analysis, then adjust the role or entitlement structure rather than forcing the review outcome to override it.
The practical issue is that access reviews are often person-centric and periodic, while SoD rules are control-centric and may be tied to transaction risk, financial workflow, or regulated duties. If the review logic is less precise than the conflict model, it can reapprove access that still creates a toxic combination. If the SoD rule is stale, it can flag harmless access patterns and create false blocks.
That means the right resolution is not to choose one control and discard the other. The better control relationship is: use the review to validate who needs access, use SoD to validate whether the access mix is safe, then reconcile the role design, exception handling, and mitigation rules so the two controls express the same business reality.
What usually causes the disagreement
Most conflicts come from a mismatch in control granularity. Access reviews usually operate at the user, role, or entitlement level, while SoD rules describe business activities such as creating vendors, approving payments, or posting journal entries. If roles are broad, the review can approve them for convenience even though the SoD model sees a conflict hidden inside the bundle. The reverse also happens when SoD rules are written too narrowly or retain obsolete business process assumptions.
Another common cause is change drift. Business processes, role catalogues, and application permissions evolve at different speeds. A new role may inherit permissions that were never reviewed for SoD impact, or an old mitigation may remain in place after the underlying workflow changed. In that situation, the disagreement is not a nuisance, it is a signal that governance data is out of sync.
Good practice is to investigate the specific conflict pattern, not just the control result. A reviewer may be correct that the person needs the work done, but wrong that the role packaging is safe. Or the SoD library may be correct in principle but wrong for the current process design. The real fix is usually in role engineering, entitlement cleanup, or mitigation redesign. Segregation of Duties (SoD) Guide and Role Mining and Role Design Guide both support that role-structure view.
How to make the two controls agree over time
Start by making the conflict model the authoritative reference for business-function incompatibility, then map access review decisions back to that structure. Reviews should confirm ownership, business need, and actual use, but they should not silently weaken SoD by reapproving a conflict because the reviewer lacks process context. Where the conflict is real, resolve it with a narrower role, an alternate workflow, or a documented mitigation.
Second, keep the SoD catalogue aligned to the current process and role model. If a rule is repeatedly disputed, decide whether the control is genuinely needed, whether the role design is too coarse, or whether the business process now contains compensating separation that the rule does not recognise. That decision should be recorded and versioned, because unresolved disagreement tends to reappear in the next certification cycle.
Third, track mitigation quality as part of governance, not as an afterthought. A mitigation is only useful if it is specific, owned, monitored, and durable. If a rule conflict is accepted because of a mitigation, that mitigation should be as reviewable as the access itself. Access Reviews and Certification Guide and IAM and IGA Basics are useful anchors for that operating model.
Risk and Threat Considerations
When access reviews and SoD rules disagree, the danger is either unsafe reapproval or unnecessary denial. Unsafe reapproval happens when a user keeps access that still creates a conflict path across transactions, approvals, or financial control points. Unnecessary denial happens when a stale SoD rule blocks legitimate work and pushes teams to create shadow access, temporary exceptions, or manual workarounds that are harder to govern.
Failure mechanism: The control with lower precision wins by default, either because the review over-trusts a broad role or because an outdated SoD rule encodes obsolete business logic. Over time that creates control drift, recurring exceptions, and hidden toxic combinations.
Impact: The organisation can approve access that undermines fraud prevention, auditability, or transaction integrity, or it can slow operations and encourage unmanaged exceptions. In both cases, governance loses credibility because the controls no longer describe the same reality.
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-6 — Least Privilege | Access reviews and SoD both aim to limit excessive access across duties. |
| AU-6 — Audit Record Review, Analysis, and Reporting | SoD disagreements should be investigated through evidence and exception review. | |
| AC-5 — Separation of Duties | The topic is directly about reconciling conflicting duties and access decisions. | |
| Recommendation — Limit access to the minimum set of duties the role actually requires. Review certification and exception evidence to resolve control conflicts. Define and enforce separation rules before approving conflicting access. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access reviews and role decisions are core access-control governance activities. |
| A.5.18 — Access rights | The question concerns whether rights should be retained, changed, or removed. | |
| A.5.3 — Segregation of duties | SoD is the primary control concept behind the disagreement. | |
| Recommendation — Align access decisions with documented access-control policy and role ownership. Revalidate access rights against current business need and remove conflicts. Maintain segregation rules and update them when business workflows change. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The issue is governance of access, roles, and exceptions. |
| CIS-5 — Account Management | Role and access review outcomes depend on accurate account and entitlement state. | |
| Recommendation — Tighten access approvals, recertification, and exception handling around role conflicts. Keep account and entitlement records current so reviews reflect real access. | ||
Practitioner Guidance
What to verify: Check whether the disagreement is about the person, the role, or the rule. If the same conflict appears across multiple users, the role or SoD definition is probably wrong; if it appears only for one user, the access review evidence or exception handling may be the issue.
Decision rule: If the SoD model reflects the current business process, keep the conflict and redesign access around it. If the SoD rule is stale, update the rule and its mitigation before treating the review outcome as authoritative.
What good looks like: Certification results, role design, and SoD exceptions all point to the same business-function model, with documented mitigations that are owned, time-bound, and reviewed when the process changes.
Practitioner takeaway: Treat disagreement as a governance defect to be reconciled, not a tie to be averaged; if the controls do not agree, the role model or SoD logic usually needs correction more than the individual access decision does.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org