Who should own governance when IGA depends on heavy services support?

The security and identity team still owns the risk, even if a vendor or integrator performs much of the setup. If governance only works while external specialists keep it running, the organisation has outsourced operating complexity, not transferred accountability. Ownership must remain internal even when delivery is shared.

Why This Matters for Security Teams

When IGA depends on heavy services support, the real question is not who clicked through the setup screens. It is who owns the risk, the operating model, and the evidence when access goes wrong. External specialists can accelerate deployment, but they cannot inherit accountability for business decisions, approval paths, or exceptions. That distinction matters because identity governance failures usually show up as audit gaps, privilege creep, and orphaned access, not as a clean implementation problem.

The control gap is especially visible when organisations treat IGA as a one-time product installation rather than a living governance process. Current guidance in the NIST Cybersecurity Framework 2.0 still points back to internal governance, continuous oversight, and defined ownership. NHIMG research on the Top 10 NHI Issues also shows how governance breaks down when identities are managed operationally but not owned strategically. In practice, many security teams discover this only after access reviews stall, integrations drift, or the services partner disengages and the control collapses.

How It Works in Practice

Ownership should stay with the security and identity function, while delivery can be shared across IAM engineering, business application owners, and external implementers. The internal owner defines policy, approves risk tolerance, and decides what “good” looks like. A vendor may configure connectors, workflows, and reports, but the organisation must retain control over approvals, recertification rules, SoD exceptions, and evidence retention.

A practical operating model usually separates governance from administration:

• Security sets policy, control objectives, and escalation paths.
• Identity teams run day-to-day platform operations and integration hygiene.
• Application and business owners validate access appropriateness.
• Services partners implement, tune, and document, but do not own risk acceptance.

This is where the Lifecycle Processes for Managing NHIs become useful even for IGA programmes, because governance only works when onboarding, review, rotation, and deprovisioning are explicit and repeatable. For audit and control design, the Regulatory and Audit Perspectives guidance reinforces that ownership must be traceable inside the organisation, not buried in a statement of work. External delivery should be measured against internal control outcomes, not effort spent.

That model works best when the organisation can name a service owner, a control owner, and an executive accountable for residual risk. It also works better when policy is documented in business language, not only in platform tickets and runbooks. These controls tend to break down in highly customised enterprise environments because fragmented applications, weak CMDB data, and unclear business ownership make recertification and exception handling slow and unreliable.

Common Variations and Edge Cases

Tighter governance often increases coordination overhead, so organisations must balance operational speed against the need for explicit accountability. That tradeoff becomes sharper in outsourced or co-managed IGA programmes, where the implementation partner may be doing most of the hands-on work.

There is no universal standard for this yet, but current guidance suggests a few practical rules. If a managed service provider runs the platform, the internal owner still approves policies, signs off exceptions, and owns audit response. If an integrator builds the workflows, the internal team should still maintain the control library and test cases so the programme does not depend on one contractor’s knowledge. If the organisation lacks in-house IAM maturity, best practice is evolving toward a named governance lead who can challenge the vendor and translate business risk into operating requirements.

One useful benchmark is whether the organisation can replace the services provider without losing control of access reviews, role models, and evidence production. If the answer is no, governance has been outsourced in practice even if the contract says otherwise.

Related resources from NHI Mgmt Group

• Who should own the governance of AI-enabled testing tools?
• What makes agentic AI an NHI governance issue?
• What is the difference between attack surface management and NHI governance?
• Why is it important to integrate identity and data governance?