How should IAM teams evaluate a service partner for IGA delivery?

What IAM teams should test in a service partner

For IGA delivery, the evaluation should start with whether the partner can operate the control model after go-live, not just configure the tooling. That means proving they can run access certification cycles, handle exceptions with audit trails, preserve evidence, and support operating procedures that survive staff turnover, not just a project team.

A useful test is whether the partner can describe the run-state in terms of ownership, cadence, escalation, and closure. If those answers stay vague, the delivery may still succeed technically while governance degrades quickly once the implementation team leaves.

Partners should also be able to explain how they handle identity lifecycle and entitlement hygiene across steady state. A credible IAM and IGA Basics discussion will cover reviews, provisioning, authorization models, and governance of both people and machines, which is the right baseline for judging whether a partner understands the operating model rather than only the tool.

What evidence separates a delivery partner from an operating partner

The strongest evidence is operational, not promotional. Ask for examples of access review execution, exception management workflows, evidence packs from regulated environments, and handover artifacts that show the partner has supported ongoing governance rather than a one-time deployment.

You also want to see how the partner manages closure. If review findings remain open, exceptions are granted informally, or evidence is scattered across emails and ticket comments, the programme may create the appearance of control without the durability of control.

Look for evidence that governance is designed into the process from the beginning. A partner aligned to Access Reviews and Certification Guide expectations should be able to reduce review fatigue, improve reviewer context, and close the loop on removals rather than treating certification as a ceremonial task.

It is also worth checking how the partner treats roles, SoD, and recurring entitlement drift. A partner that can explain role ownership, exception handling, and recertification cadence is better positioned to keep access decisions current after implementation stabilises. Role Mining and Role Design Guide is a useful reference point when judging whether the partner can sustain a manageable access model instead of creating role sprawl.

How to judge long-term governance capability, not just implementation speed

In practice, the right question is whether the partner can take responsibility for the control loop as well as the deployment. That includes operating handover, knowledge transfer, evidence retention, and the ability to keep access governance effective when integrations change or business owners become less responsive.

Partnership quality is also visible in how they handle operating exceptions. If a partner can only deliver the happy path, they may accelerate go-live but leave the client exposed when an application lacks clean entitlements, a review owner is absent, or remediation requires manual escalation.

A good evaluation should include the operating reality of exceptions, SoD conflicts, and audit pressure. The Segregation of Duties (SoD) Guide is relevant here because mature delivery partners should show how they identify conflicts, support mitigations, and maintain controls across recurring governance cycles.

For cloud-heavy or third-party-heavy programmes, partner capability should also extend to connected identity surfaces and evidence quality across systems. The CSA Cloud Controls Matrix is a useful external benchmark for assessing whether the partner’s operating model can support IAM, auditability, and vendor-assessment expectations in a cloud environment.

Practitioner Guidance

What to verify: Require the partner to walk through one full access review cycle, one exception path, and one handover scenario, with named owners and proof of retained evidence. If they can only show project milestones, they are not yet demonstrating run-state capability.

Decision rule: If the partner cannot explain how governance continues after implementation team exit, treat that as a delivery-risk issue, not a minor commercial gap. A faster go-live is not a successful IGA engagement if the operating model collapses immediately afterward.

What good looks like: The partner can show repeatable review execution, documented escalation, preserved audit evidence, and a support model that remains stable when business ownership, applications, or staffing change.

Practitioner takeaway: Select partners who can own durable governance outcomes, because IGA value comes from sustained control over access decisions, not from the speed of the initial deployment.

Related resources from NHI Mgmt Group

• How should security teams govern Active Directory service accounts?
• How should security teams evaluate self-service password reset in hybrid IAM environments?
• How should IAM teams evaluate an IGA platform for lifecycle governance?
• How should IAM teams evaluate converged IGA and PAM capabilities?