What should teams do first when an IGA platform looks good on paper but may not fit the programme?

Start with the operating model, not the feature list. Define how joiner, mover, leaver events, access reviews, and audit evidence need to work across your real applications and identity sources. Then test whether the platform can support those workflows without manual repair, because that is where governance programmes usually break down.

Why the Operating Model Comes Before the Feature List

An IGA platform only works when it fits the way your organisation actually provisions access, approves exceptions, and proves control. A polished demo can hide a poor workflow fit, especially when identity sources are fragmented, reviews depend on manual cleanup, or audit evidence has to be assembled after the fact. The first question is whether the platform can support your operating model without creating new repair work.

The practical test is less about whether the tool can “do IGA” in the abstract and more about whether it can handle your joiner, mover, leaver pattern, your application sprawl, and your review cadence. A platform that looks complete on paper can still fail if it cannot express the real decision points, ownership boundaries, and exception paths your programme needs.

For a working definition of how these pieces fit together, IAM and IGA Basics is the best starting point because it separates governance design from access administration and shows why the programme model matters more than the feature checklist.

Which Workflow Gaps Usually Break a Good-Looking Platform?

The highest-risk gaps are usually in the joins between systems, not in the UI. Access requests may look straightforward until the platform has to reconcile authoritative sources, inherited roles, shared accounts, exception approvals, or non-standard applications that do not map cleanly to the vendor’s default connectors.

Joiner, mover, and leaver handling is where this becomes obvious. If the product cannot update entitlements quickly enough, remove stale access reliably, or preserve an auditable trail of who approved what, teams end up compensating with spreadsheets, tickets, and side processes. That is a sign the programme is adapting to the tool instead of the tool supporting the programme. A strong reference point for this workflow is Joiner-Mover-Leaver (JML) Guide, which focuses on the access lifecycle rather than the procurement narrative.

Access reviews are the same kind of test. The question is not whether the platform can launch a campaign, but whether reviewers can see enough context to make decisions, whether remediation closes the loop, and whether evidence remains usable when audit asks for it later. For that control layer, Access Reviews and Certification Guide is a useful companion because it addresses review quality, not just review volume.

How to Prove the Fit Before You Commit

The safest way to validate fit is to run a narrow proof of concept against your real workflows, not a vendor demo script. Use a few representative applications, a mix of straightforward and messy identities, and at least one review cycle that must produce audit-ready evidence. The goal is to see where humans still need to intervene, because every manual repair step is a signal that the platform is not yet aligned to your operating model.

For governance-heavy programmes, role structure and control boundaries matter as much as provisioning mechanics. If the platform cannot support sane role design, SoD checks, and clean ownership, the programme will drift into over-customisation or exception sprawl. That is why Role Mining and Role Design Guide and Segregation of Duties (SoD) Guide matter in platform selection, not just in later governance tuning.

Risk and Threat Considerations

When an IGA platform mismatches the operating model, the immediate risk is not a technical outage, it is governance decay. Teams start bypassing the platform for urgent access, exceptions multiply, and audit evidence becomes a reconstruction exercise instead of a by-product of the workflow.

Failure mechanism: The platform cannot accurately model source-of-truth identities, entitlement dependencies, or review/remediation paths, so administrators compensate with manual fixes, parallel spreadsheets, and exception handling outside the control plane.

Impact: Access drift, delayed deprovisioning, weak reviewer decisions, and poor evidence quality can all accumulate, which increases both compliance exposure and the chance that excessive access persists unnoticed.

Practitioner Guidance

What to prioritise: Test the operating model first, then score features against the specific workflows that matter most, especially joiner, mover, leaver handling, access reviews, and audit evidence production.

What to verify: Confirm that the platform can complete each workflow end to end across real applications without hidden manual repair, because that is the clearest sign of true fit.

Common mistake: Treating connector count or UI polish as proof of programme readiness; those are useful only if the workflow still works when the identity data is incomplete, inconsistent, or delayed.

Practitioner takeaway: If the platform cannot make your real governance process easier to operate and easier to evidence, it is too early to call it a fit.