Why do IGA programmes need to be treated as an ongoing effort rather than a one-time project?

Why IGA cannot stop after the initial rollout

IGA only works when it keeps pace with the organisation it governs. The operating model changes as people join and leave, roles shift, applications proliferate, contracts end, and business units reorganise. If the programme is treated as a finished project, access decisions, ownership, and review logic quickly drift away from reality.

That is why the real measure of success is not a go-live date, but whether the programme can absorb change without losing control. In practice, IGA has to stay aligned to joiner, mover, and leaver events, entitlement changes, role redesign, and periodic review cycles, because those are the moments when governance either holds or starts to decay.

Continuous operation also matters because the environment around IGA is never static. New SaaS platforms, acquired entities, shared services, outsourcing arrangements, and emergency access patterns all alter who should have what access and why. A one-time implementation may establish the control model, but only ongoing administration keeps the model accurate enough to be trusted.

What changes over time that breaks a one-off IGA programme

The biggest reason one-time programmes fail is that identity data is inherently dynamic. A person’s job family changes, a contractor extends their engagement, an application owner changes, or a new integration creates an access path that was not in scope during the original design. Governance depends on current context, so stale roles and stale entitlements are not just housekeeping issues, they are control failures.

Access review outcomes also age quickly. A campaign that was accurate at quarter end can be wrong weeks later if the underlying business structure changes. That is why access recertification, entitlement management, and lifecycle handling need to be embedded as operating processes, not as occasional project tasks. The IAM and IGA Basics guide explains why governance and administration must be sustained together rather than separated into a project phase and a maintenance phase.

In mature programmes, the control question becomes whether the organisation can discover and remove drift fast enough. A useful proxy is whether governance can keep up with role changes, offboarding, and application onboarding without accumulating exceptions. The Joiner-Mover-Leaver (JML) Guide and Access Reviews and Certification Guide both reflect this reality: lifecycle events and review campaigns have to close the loop, not merely document it.

For programmes that touch service accounts, bots, or other non-human actors, the same logic applies, but the cadence is often faster because credentials, scripts, deployments, and integrations can change outside human HR processes. The NHI Lifecycle Management Guide is useful here because it shows how lifecycle governance extends beyond human onboarding and offboarding into rotation, visibility, and decommissioning.

What ongoing governance looks like in practice

Continuous IGA is mostly about operating rhythm. You need authoritative sources for joiner, mover, and leaver events; a repeatable way to detect changes in roles, entitlements, and application ownership; and a review process that removes access instead of simply recording approval. That is why the strongest programmes treat governance as a control plane with recurring inputs, not a project deliverable that is archived after implementation.

Practically, this means the programme must be able to answer four questions at any time: who has access, why they have it, whether it is still needed, and what changed since the last review. If the answer to any of those depends on manual reconciliation or tribal knowledge, the programme is already drifting. The Role Mining and Role Design Guide supports this view by showing that roles require ongoing design, maintenance, and cleanup, not a single modelling exercise.

Governance also has to account for control exceptions and toxic combinations. As organisations grow, SoD issues, compensating controls, and privileged exceptions tend to accumulate, especially where applications are added faster than control design can be refreshed. The Segregation of Duties (SoD) Guide is a reminder that these controls need periodic reassessment because business processes and access paths change over time.

From an external control perspective, this is also where zero trust and identity control principles matter: access should be continuously validated, not presumed safe because it was once approved. The OWASP Non-Human Identity Top 10 and NIST guidance on access control both reinforce the broader point that governance must follow current entitlement state, not historical intent.

Practitioner Guidance

What to prioritise: Build IGA around recurring lifecycle events and review cycles first, then add role optimisation and exception handling. If the programme cannot reliably absorb joiner, mover, and leaver changes, every other control will be built on stale assumptions.

What to verify: Check whether access removal, role updates, and ownership changes are triggered from authoritative sources and whether exceptions are actually closed. A review process that produces tickets but not removals is governance theatre, not control.

Common mistake: Treating certification campaigns as the programme itself. Certification is only useful when it is linked to downstream remediation, continuous inventory, and ownership discipline.

Practitioner takeaway: IGA succeeds when it behaves like a living control system, with the organisation, applications, and entitlements treated as moving targets rather than fixed design assumptions.

Related resources from NHI Mgmt Group

• What breaks when cryptographic modernisation is treated as a one-time project instead of an ongoing capability?
• Why do data security and AI governance programmes need ongoing practitioner collaboration rather than one-time training?
• What happens when zero trust is treated as a one-time project instead of an ongoing programme?
• When do NHI access reviews create more value than a one-time cleanup?