IGA adoption is an operating model.

The gap between a platform and a programme.

Identity governance and administration (IGA) connects identity lifecycles, access entitlements and review decisions. An IGA platform can be live while much of the business still sits outside meaningful access governance. Application teams may not know what onboarding requires. Entitlement data may be incomplete. Owners may be missing, and a technically successful connection may reveal very little about whether access is appropriate.

That is why I see adoption as an operating-model challenge as much as an integration challenge. The useful question is not simply which connector to configure next. It is which application should come next, what control outcome it needs, and what must be ready before the team commits to delivery.

Start with risk-led intake.

A consistent intake gives the programme a common basis for prioritisation. Business criticality, data sensitivity, privileged exposure, lifecycle needs and application-team readiness should inform the decision together. A technically straightforward application is not automatically the most important one.

Make ownership explicit early. The business owner, application engineer and entitlement owner have different decisions to make. A questionnaire helps gather information, but someone still needs to validate it and resolve gaps.

• Confirm the business purpose, accountable owners and access model.
• Assess data classification, sensitivity and the consequences of inappropriate access.
• Identify account sources, entitlements, approval routes and lifecycle dependencies.
• Record readiness gaps, integration constraints and the next accountable decision.

Standardise the decisions. Adapt the integration.

REST APIs, databases and directory-backed applications have different integration constraints. An API pathway may depend on pagination, stable identifiers and provisioning operations. A database pathway may depend on connectivity and the quality of account and role data. Directory integrations need clarity about groups, nesting and where authorisation actually happens.

Reusable pathways should capture the decisions and artefacts that genuinely repeat: required inputs, connectivity assumptions, mapping rules, validation, exception handling and acceptance criteria. They should also make deviations visible. Standardisation loses its value if every application quietly becomes a bespoke exception.

Define what onboarded means.

Connectivity, account discovery and a fully governed lifecycle are different milestones. Agree the baseline before reporting progress. Depending on scope, it may include reconciled accounts and entitlements, named ownership, access requests and approvals, certification, and timely revocation when someone moves or leaves.

Later enhancements—such as role mining, birthright access or additional automation—should have their own acceptance criteria. Keeping that distinction clear protects the integrity of the delivery story. A programme should not imply that every connected application has every available control.

The Dark Reading survey commissioned by SailPoint in 2025 found that 24% of its 108 respondents were highly confident in managing entitlements and authorisation. That is useful context for the ownership and data-quality problem, not a measure of any particular client's environment.

Measure coverage, control quality and repeatability.

Track application coverage alongside control completeness, unresolved ownership, exception ageing and lifecycle outcomes. If time to onboard matters, define the start and finish points and distinguish active engineering time from delays caused by missing application inputs.

In the Maersk engagement, onboarded applications grew from 10 to more than 50. That supports a claim of more than fivefold application coverage. It does not establish fivefold faster delivery. The wider story is the staged method and integration pathways the team could carry forward.

The practical starting point is a small, agreed baseline and a visible next wave. Test the approach with representative applications, learn from the exceptions, and improve the model before scaling its use.

Practical questions.