What happens when organisations try to manage access without a defined IGA process?

Without a defined process, access decisions become guesswork. Teams struggle to onboard users correctly, terminate access when it is no longer needed, and adjust entitlements when roles change. That creates inconsistent governance, slower administration, weaker auditability, and a higher chance that people keep access they no longer need.

What breaks first when access is managed without IGA?

Without a defined IGA process, access becomes an exception-driven activity instead of a governed lifecycle. Onboarding, role changes, and removals are handled inconsistently, so entitlements drift away from actual job needs. That means the organisation is no longer managing access as a controlled process, it is reacting to requests, reminders, and tribal knowledge.

The first thing that breaks is decision quality. If there is no consistent source of truth for who should get what, teams cannot reliably distinguish birthright access from temporary access, inherited access, or stale access. Over time, that turns access administration into a patchwork of approvals, manual checks, and local workarounds.

It also weakens the operating model around identity lifecycle. Defined IAM and IGA Basics explain why provisioning, role changes, and access reviews must be part of one governed flow rather than separate tasks. When those steps are disconnected, access tends to persist longer than it should and nobody can clearly explain why a user still has a permission.

Where do the governance failures show up in day-to-day operations?

The failure is usually visible in three places. First, joiner processes become slow or incomplete, so new users do not receive the right access quickly or receive too much access as a shortcut. Second, mover events are missed, so people retain old-role entitlements after changing teams or duties. Third, leaver events are inconsistent, so access remains active after departure or contract end.

At that point, administration gets harder even when nothing is under attack. Teams spend more time reconciling access than governing it, and managers cannot confidently attest that permissions match current business need. The absence of a defined process also makes reviews weaker, because reviewers are asked to approve lists of entitlements without dependable context about ownership, role intent, or expiry.

That is why lifecycle discipline matters. The Joiner-Mover-Leaver (JML) Guide and the Access Reviews and Certification Guide are useful complements because they show how lifecycle events and recertification close the loop instead of leaving entitlement decisions half-finished.

Why does weak IGA create both audit and security exposure?

Weak IGA does more than slow administration. It reduces auditability, because there is no dependable trail from business need to approved entitlement to revocation. It also increases exposure, because old access, overbroad roles, and orphaned accounts are more likely to remain in place. In practice, that is how privilege creep becomes normal rather than exceptional.

From a security perspective, the main problem is blast radius. If access is not periodically revalidated and removed on time, a compromised or departed account may still retain access paths that no longer make business sense. Even without a breach, the organisation has less confidence that its access boundary is current, least-privilege, and enforceable.

The Role Mining and Role Design Guide and the Segregation of Duties (SoD) Guide help here because they address the structural causes of excessive access, not just the symptoms. If roles are poorly designed or conflicts are unmanaged, IGA will keep producing messy outcomes no matter how many tickets the team closes.

Risk and Threat Considerations

When IGA is undefined, the risk is not only administrative disorder, it is persistent over-entitlement. Stale access, delayed deprovisioning, and uncontrolled role drift create a larger pool of permissions that an attacker, insider, or careless user can abuse.

Failure mechanism: Access remains active after the business justification has changed, so permissions accumulate across onboarding, moves, and departures. That makes it easier for excess privilege to survive reviews, for toxic combinations to go unnoticed, and for compromised accounts to have more reach than they should.

Impact: The organisation faces higher exposure to unauthorized access, weaker audit evidence, and more difficult remediation when something is finally discovered. Recovery also slows down because teams first have to reconstruct who should have had access in the first place.

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-2 — Account Management	Defined IGA processes govern account creation, changes, and removal.
	AC-6 — Least Privilege	Unmanaged IGA commonly leaves users with excessive access beyond current need.
	AU-6 — Audit Review, Analysis, and Reporting	IGA failures reduce the audit trail needed to explain access decisions.
Recommendation — Define and operate account lifecycle controls for provisioning, review, and disabling. Limit permissions to the minimum required and remove excess access promptly. Review access activity and entitlement changes so governance evidence remains traceable.
ISO/IEC 27001:2022	A.5.18 — Access rights	Access rights must be provisioned, reviewed, and removed under formal control.
	A.5.15 — Access control	Undefined IGA weakens consistent access control enforcement across the organisation.
Recommendation — Implement a controlled access-rights lifecycle with periodic review and removal. Apply a consistent access-control policy across onboarding, changes, and offboarding.
CIS Controls v8	CIS-5 — Account Management	IGA is the operational mechanism for managing accounts and their access lifecycle.
	CIS-6 — Access Control Management	Defined IGA is needed to enforce entitlement review and least-privilege access.
Recommendation — Centralise account lifecycle management and remove access when it is no longer needed. Use access control management to review, approve, and revoke entitlements consistently.

Practitioner Guidance

What to prioritise: Start by defining ownership for joiner, mover, and leaver decisions, then make entitlement review and revocation part of the same operating process. If no one owns the decision end-to-end, the process will drift back to email approvals and manual exceptions.

What to verify: Confirm that every material access path has a current business owner, a review cadence, and a revocation trigger. The key check is whether the organisation can prove why an entitlement exists today, not just whether it was once approved.

Common mistake: Treating access requests as the process and ignoring lifecycle hygiene. That shortcut creates approvals, but it does not create governance, because governance depends on recertification, removal, and role maintenance as much as initial grant.

Practitioner takeaway: A defined IGA process is what turns access from a series of one-off decisions into a controllable lifecycle, and without that control, governance degrades faster than most teams expect.