What are the signs that an IGA programme is too complex to sustain?

What makes an IGA programme too complex to sustain?

An iga programme becomes unsustainable when the operating model cannot keep pace with the amount of governance work it creates. That usually shows up as slow onboarding, review fatigue, endless exceptions, and a steady drift back to spreadsheets, manual queues, and ad hoc approvals. The core issue is not ambition, it is whether the controls can run reliably as a normal business capability.

Where complexity shows up first in the control model

The earliest signal is usually process friction, not a hard failure. If approvals multiply across systems, review campaigns need constant chasing, and role or entitlement logic keeps breaking under exceptions, the programme is becoming harder to operate than to govern. In practice, that often means the model is too dependent on individuals remembering special cases rather than on stable policy and repeatable identity governance basics.

Complexity also shows up when the scope of the programme expands faster than the organisation can standardise it. If every new application needs bespoke connectors, custom review rules, or unique role mappings, the programme stops scaling as a control plane and turns into a service desk for exceptions. That is especially visible in IGA platform selection and implementation when teams underestimate how much integration and process design work the governance model will require.

Another warning sign is role design becoming a source of operational debt. A healthy programme should reduce decision volume over time, not create permanent role explosion, overlapping entitlements, and repeated manual recertification. When the model needs continuous role surgery to stay usable, the governance structure is too fragile to support sustainable operations, which is why role mining and role design have to be treated as ongoing architecture work rather than a one-off cleanup.

Why unsustainable IGA programmes stall in day-to-day execution

The most reliable sign of overshoot is that the programme cannot complete its own control cycle without heavy human intervention. Reviews are opened, chased, escalated, and closed by hand; exceptions are handled in email; and owners rely on memory instead of system state. At that point, the programme is no longer governed by a durable mechanism. It is being held together by project behaviour.

That pattern usually creates a second-order problem: people stop trusting the process because it feels performative. If managers see the same stale access reappear after every review, or if approvals are duplicated across tools, they begin to treat the programme as ceremonial rather than risk-reducing. Sustained IGA depends on closed-loop remediation, not just more evidence that reviews happened, which is why access reviews and certification have to remove access, not merely document it.

Complexity becomes especially dangerous when joiner-mover-leaver handling is not absorbed into the operating model. If every termination, transfer, or contractor change needs manual exception handling, the governance burden rises faster than the business can absorb. When old access, orphaned accounts, and stale entitlements survive routine lifecycle events, the programme is not just complex, it is failing to encode the basic lifecycle decisions that make governance repeatable. A sustainable model needs joiner-mover-leaver discipline that removes work instead of accumulating it.

How to tell complexity has crossed from useful control to structural debt

Complexity has crossed the line when the programme requires constant project-style intervention to remain usable. That is the point where process owners, application teams, and auditors all depend on the same small set of specialists to compensate for weak design. The programme may still be producing artefacts, but it is not producing resilience. Sustainable governance should make the steady state easier, not require heroics to preserve it.

One practical clue is that the exceptions are becoming the real operating model. If every review cycle needs bespoke scope decisions, if ownership is unclear, or if SoD conflicts and entitlement exceptions are handled case by case, the control framework is too brittle. The problem is not simply volume. It is that the programme no longer has enough structure to absorb normal organisational change without rework, which is exactly where segregation of duties design either reduces effort or becomes another source of backlog.

A sustainable IGA programme should also leave an audit trail that is mostly a byproduct of operations, not a separate reconstruction exercise. If evidence has to be assembled manually after the fact, or if ownership, approval history, and entitlement state cannot be trusted in the system of record, the governance design is too complex for the controls to be durable. Lifecycle management works when the system can show what changed, who owns it, and why it remains valid without a human stitching that story together after each cycle.

Risk and Threat Considerations

When IGA becomes too complex to sustain, the immediate risk is control decay. Review fatigue, duplicated approvals, and manual exception handling create gaps that attackers and insider misuse can exploit, while the organisation becomes less able to prove that access was actually governed.

Failure mechanism: Excessive process complexity increases friction, so teams bypass the intended control path, leave access unresolved, or rely on stale approvals and unowned exceptions to keep work moving.

Impact: The organisation gets weaker assurance, slower response to access risk, and a larger blast radius if excess privilege, orphaned access, or approval drift is exploited.

Practitioner Guidance

What to prioritise: Treat recurring manual intervention as the primary warning signal. If the programme needs people to chase reviews, reconcile roles, or clean up exceptions every cycle, the design should be simplified before more controls are added.

What to verify: Check whether the system can complete a normal access lifecycle, from request to review to removal, without a project team intervening. If the answer is no, the operating model is not yet stable enough to scale.

Common mistake: Adding more approval layers to compensate for weak governance design. That often increases delay and inconsistency without improving assurance.

Practitioner takeaway: An IGA programme is sustainable when the control work becomes routine and mostly self-maintaining; if keeping it alive requires constant exception handling, the programme is too complex for its own governance model.

Related resources from NHI Mgmt Group

• What are the signs that a security automation program is too complex for a SOC to sustain?
• What happens when an IGA programme is too complex for an SMB to run effectively?
• What are the signs that an IGA modernisation programme is being over-customised or moving too quickly?
• What are the signs that security operations are too complex to sustain consistently?