Access visibility remains useful, but the organisation starts certifying entitlements instead of controlling outcomes. That leaves process conflicts, transaction risk, and SoD failures outside the control boundary, even when reviews and approvals look complete. The result is formal compliance without reliable business governance.
Why IGA Stops Working as Soon as It Becomes a General Governance Exercise
When IGA is pulled upward into enterprise governance, the operating question changes from “who should have this access?” to “was the policy process completed?” That shift sounds benign, but it weakens the link between identity decisions and the actual business controls they are meant to protect.
Access governance still has value, especially when it provides visibility into who can do what. The breakage starts when visibility is mistaken for control, because entitlement certification can look complete while the real business risks remain untouched. For the underlying mechanics of identity lifecycle, access reviews, and governance depth, IAM and IGA Basics is the clearest starting point.
The practical failure is that enterprise governance often absorbs IGA into broad approval structures, then assumes a signed-off review means the environment is safer. In reality, entitlements are only one layer. Process conflicts, toxic combinations, stale access paths, and segregation-of-duties exceptions still need explicit control design, which is why the Segregation of Duties (SoD) Guide matters for anyone trying to preserve business control rather than merely document review activity.
What Enterprise Governance Leaves Outside the Control Boundary
Enterprise governance frameworks are good at setting policy, ownership, and accountability lines, but they do not automatically govern transaction outcomes. If the review process asks whether an entitlement exists, instead of whether that entitlement can create an invalid payment, approve an incompatible trade, or enable conflicting duties, the organisation is measuring the wrong thing.
That is why lifecycle discipline matters. Access must be created, changed, and removed in step with the job or system role, otherwise the governance layer becomes a record-keeping function instead of a control function. The Joiner-Mover-Leaver (JML) Guide shows why access changes have to follow actual role changes, not quarterly committee cycles.
At scale, governance drift is usually visible first as exception sprawl: more temporary approvals, more role cleanup deferred to later, and more “reviewed but not removed” access. Once that pattern sets in, entitlements can appear fully governed while the organisation still carries accumulated exposure from old roles, unused privileges, and conflicting combinations.
Why Complete Reviews Can Still Produce Formal Compliance Without Real Control
The deepest problem is that enterprise governance rewards completion evidence. A review signed, a certification closed, or a committee note approved can all look like control success even when the control objective was never expressed in operational terms. That is how formal compliance diverges from actual governance.
For this reason, role design and review design need to be aligned. If roles are too broad, reviews become rubber stamps. If SoD rules are weak, the organisation can certify a user into a harmful combination and still record the process as successful. The Role Mining and Role Design Guide helps frame the role side of that problem, while the Access Reviews and Certification Guide addresses the review side.
For organisations that want IGA to govern outcomes rather than paperwork, the best signal is whether a control can answer a concrete business question: can this access create fraud, SoD conflict, or transaction failure, and will the process force a removal when the answer is yes? If not, the governance model is probably tracking entitlement state without controlling business risk.
Risk and Threat Considerations
When IGA is reduced to enterprise governance, the main risk is control illusion: access appears reviewed, but the review no longer blocks harmful combinations or stale privilege. That creates exposure to SoD failure, privilege accumulation, and transaction abuse even when the governance artefacts look complete.
Failure mechanism: The control boundary shifts from effective access and business conflict detection to administrative certification, so toxic entitlements survive because the process validates the record of review instead of the operational consequence of access.
Impact: Organisations can end up with formal compliance, weaker fraud resistance, and unresolved business-process exposure, especially where access decisions are dispersed across committees, systems, and owners.
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 sets 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 | Enterprise governance must limit access to what users need to perform duties. |
| AC-5 — Separation of Duties | The question centers on SoD failures surviving governance-focused IGA. | |
| AC-2 — Account Management | IGA depends on lifecycle provisioning, review, and removal of access. | |
| Recommendation — Enforce least privilege so certifications drive removal of excess access. Define conflicting duties and block combinations that create control failures. Review account lifecycle events to ensure entitlements change with role changes. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The issue is control of access outcomes, not just enterprise policy approval. |
| A.5.18 — Access rights | The page is about certifying and revoking rights, not merely documenting governance. | |
| Recommendation — Apply access control rules that tie approval to actual business restrictions. Recertify and remove access rights that no longer match business need. | ||
Practitioner Guidance
What to verify: Test whether each certification question is tied to a business conflict, transaction right, or role outcome, not just to the existence of an entitlement. If reviewers cannot explain why a permission is safe in operational terms, the review is too abstract to be relied on.
Decision rule: If the control only proves that someone approved access, treat it as a governance artifact and not as evidence of SoD protection or business control. If the control can force removal of conflicting access, it is doing real work.
Practitioner takeaway: IGA becomes weak when it governs approval flow more than it governs consequences; the fix is to anchor reviews, roles, and exceptions to actual business risk rather than to entitlement inventory alone.