Who should own automated IGA outcomes across HR, IT, and security?

Why This Matters for Security Teams

Automated IGA sounds like a back-office workflow problem, but ownership determines whether identity decisions stay accurate, auditable, and defensible when systems drift. HR may originate the lifecycle event, IT may execute the connector logic, and security may set the control intent, yet none of those functions alone can reliably validate end-to-end outcomes. That is why the identity governance programme must own the result, not just the tooling. NIST Cybersecurity Framework 2.0 treats governance as an enterprise function, not a ticket queue, which is the right lens for this question.

NHIMG research shows how quickly weak identity oversight turns into exposure: only 20% of organisations have formal processes for offboarding and revoking API keys, and 91.6% of secrets remain valid five days after notification. Those gaps are exactly what happen when accountability is split across teams without one owner for closure. The Ultimate Guide to NHIs is clear that lifecycle control, revocation, and visibility have to be governed as one system, not as separate handoffs. In practice, many security teams encounter failed deprovisioning only after an access review, audit request, or incident has already exposed the gap.

How It Works in Practice

The practical operating model is a three-way split of responsibility with one accountable owner. HR remains the authoritative source for joiner, mover, leaver signals. IT owns the integrations, data quality, and workflow execution across IAM, ticketing, and target systems. Security defines policy thresholds, exception criteria, and risk acceptance rules. The identity governance programme sits above those functions and owns the outcome: the right account is created, changed, disabled, or flagged, and the result is verified.

In mature environments, that ownership means the governance team controls the policy model, reviews failures, and drives remediation when automation does not complete. Current guidance suggests mapping automated IGA to control objectives in NIST Cybersecurity Framework 2.0, especially around identity lifecycle, access control, and continuous monitoring. The governance owner should also maintain a clear exception path for cases like contractor extensions, rapid role changes, disputed termination dates, and system outages that interrupt provisioning or deprovisioning.

This model works best when the process includes:

• one accountable governance owner with authority to enforce closure
• source-of-truth validation for HR and authoritative data feeds
• policy-as-code or workflow rules that security approves centrally
• automated evidence capture for provisioning, recertification, and revocation
• exception handling that time-boxes manual overrides and requires review

The Ultimate Guide to NHIs is especially useful here because it frames lifecycle governance as a continuous control, not a one-time admin task. These controls tend to break down when HR, IT, and security each approve part of the workflow but nobody owns the final state of the identity.

Common Variations and Edge Cases

Tighter governance usually increases coordination overhead, so organisations have to balance speed against control assurance. That tradeoff becomes visible in mergers, shared service centres, outsourced IT, and complex contractor populations where one workflow spans multiple systems and legal entities.

There is no universal standard for this yet, but best practice is evolving toward a federated operating model. HR should remain the lifecycle trigger owner, IT should remain the systems integrator, and security should remain the policy authority, while identity governance owns the cross-functional decision record. For highly regulated environments, that owner may sit inside IAM, GRC, or a dedicated identity governance office, but the accountability should not be ambiguous.

Edge cases deserve explicit treatment. If automation depends on stale HR records, the governance team must quarantine the event rather than let downstream systems guess. If an emergency access exception is granted, it should expire automatically and require after-the-fact validation. If a system cannot support automated revocation, the gap should be tracked as a control defect, not accepted as normal operations. Organisations that treat ownership as a committee usually discover too late that committees can approve work, but they cannot be held accountable for outcomes.

Related resources from NHI Mgmt Group

• Who should own EHR access decisions across HR, credentialing, and clinical teams?
• How should security teams make NHI best practices usable across the business?
• Who should own identity lifecycle automation decisions across IT, security, and HR?
• How should security teams govern AI transformation across identity and access programmes?