A major healthcare provider's patient admission system went offline for six hours when their identity infrastructure failed during a routine update. Emergency room staff couldn't access patient records, surgery schedules were delayed, and the organization reported significant revenue loss while manually processing admissions.
While the specifics of this account reflect a composite of reported incidents rather than a single verified event, the pattern it describes is worth examining carefully — because the root cause matters. If the failed system was a directory or identity provider, the outage interrupted authentication and runtime access enforcement. If it was an identity governance and administration platform specifically, the operational impact would have been different in kind, though still significant.
That distinction is the subject of this article. Identity governance and administration (IGA) platforms — the systems that manage user provisioning, access entitlements, and access certification — carry real continuity risk, but it is not the same risk as an authentication or directory outage. The concern is that IGA platforms have become deeply embedded in business operations, yet their specific failure modes are rarely modeled accurately in continuity planning.
When identity governance breaks, provisioning stops, access requests queue without resolution, and governance workflows stall. That is a genuine operational problem — but it is a different problem than employees losing the ability to log in.
The problem
To understand IGA continuity risk accurately, the architectural boundary matters. In most conventional deployments, an IGA platform is not a runtime component of the access path. Employees authenticate against directories and identity providers. Applications enforce authorization against local entitlement stores or policy engines. The IGA platform manages changes to those entitlements — provisioning new access, removing it, certifying it periodically, and maintaining the governance record — but it typically does not sit in the path of every authentication or access decision.
This means an IGA outage would ordinarily interrupt the processes that alter access: onboarding new employees, fulfilling access requests, executing deprovisioning, running certification campaigns, and generating governance reports. Existing employees with established access can generally continue working. Existing customer and partner activity does not normally depend on the IGA platform remaining continuously available.
That said, organizations vary in how tightly they have coupled IGA workflows to runtime operations. Environments where access request approval is a prerequisite for time-sensitive operational tasks, or where automated provisioning feeds critical systems on short cycles, can experience faster operational impact than the conventional model suggests. Organizations should map their own dependencies rather than assuming either that IGA outages are harmless or that they immediately halt operations.
The risks that do materialize reliably during IGA outages deserve clarity. Provisioning backlogs accumulate immediately, creating delays for new hires, role changes, and partner onboarding. Access removal workflows halt, which creates regulatory and audit exposure — not because access controls stop enforcing, but because governance obligations require timely deprovisioning and the documentation that supports it. Manual workarounds introduced during recovery can themselves create risk if not properly controlled.
Organizations that treat identity governance as peripheral security tooling often discover during outages that their continuity plans do not accurately model these dependencies. NIST guidance on continuity and access management calls for risk and impact analysis to determine which systems warrant continuity controls — IGA platforms belong in that analysis, but their specific impact profile should be assessed against actual architecture rather than assumed to mirror authentication infrastructure.
Organizational impact
Identity governance outages produce three categories of operational impact, though their severity depends heavily on architecture and timing. Productivity accumulates as new employees and contractors cannot be provisioned, role changes queue without fulfillment, and IT teams are consumed by manual workarounds. Business process delays emerge when access request approvals are prerequisites for time-sensitive work and those approvals cannot be processed. Compliance and audit exposure develops when governance workflows are unavailable — not necessarily because application or authentication logs stop, which may continue normally, but because the governance record of access changes becomes incomplete and deprovisioning obligations go unmet during the recovery window.
On the question of audit trails specifically: application logs, directory logs, authentication logs, and SIEM feeds typically continue during an IGA outage. The compliance gap is more specific — it concerns the governance layer's record of who approved what access, when deprovisioning was initiated, and whether certification campaigns remained current. Organizations subject to access governance requirements should understand which logs their auditors require and whether those are maintained in systems independent of the IGA platform.
Manual procedures introduced during an outage carry their own risks. Bypassing governance workflows to provision access urgently can violate segregation-of-duties controls, create undocumented entitlements, and generate audit findings. Leading practice is not simply to allow manual workarounds but to maintain controlled break-glass procedures: defined approval authorities, mandatory logging of every manual action, explicit time limits, and a reconciliation process that reviews and remediates any out-of-band access granted during recovery.
What leading practice looks like
Some organizations have begun framing identity governance risk in terms of operational impact — mapping which business processes depend on IGA workflows, estimating the cost of provisioning delays beyond defined thresholds, and modeling recovery timelines against those dependencies. This approach, consistent with the risk and impact analysis principles in frameworks such as NIST SP 800-53 and broader operational resilience guidance from regulators including the UK's Financial Conduct Authority, supports clearer board-level visibility into what a governance platform failure would actually disrupt — and what it would not.
Accurate impact modeling matters here. Overstating IGA risk — treating it as equivalent to a directory outage — can produce misallocated investment and continuity plans that address the wrong failure scenarios. Understating it leads to the opposite problem. The goal is a realistic dependency map that reflects how provisioning, deprovisioning, certification, and access request workflows connect to business operations in a specific environment.
When process owners understand the operational cost of IGA failures — provisioning backlogs, delayed onboarding, unmet deprovisioning obligations — conversations about redundancy and recovery capability tend to shift from discretionary security investments to operational necessities. The conversation moves from security compliance to operational resilience, which tends to produce more durable investment and clearer accountability.
The decision
Three decisions require board-level attention. First, does your business continuity plan address identity governance platform failures with tested recovery procedures that accurately reflect what an IGA outage actually interrupts? Many plans either ignore IGA entirely or conflate it with authentication infrastructure, producing procedures that address the wrong failure scenario.
Second, do your break-glass procedures for IGA outages include mandatory controls — defined approval authority, logging of every manual action, time limits, and post-recovery reconciliation? Manual workarounds that bypass governance controls can trade one compliance problem for another if they are not themselves controlled and documented.
Third, has your organization mapped the business processes that depend on IGA workflows — provisioning, deprovisioning, access certification — with enough specificity to estimate the operational cost of delays at defined time thresholds? That mapping is the prerequisite for any meaningful continuity planning and for accurate board-level reporting on what this category of risk actually represents.
These decisions determine whether identity governance receives continuity investment calibrated to its actual operational role — neither overlooked nor overstated.
