Who should own access governance during an insurer’s cloud migration?

Why access ownership shifts during cloud migration

Cloud migration changes who can create, change, and persist access. That means ownership cannot stay with infrastructure operations alone, because access governance is no longer just about servers and network paths. It becomes a business control issue, where entitlement decisions must reflect process ownership, approval authority, and revocation responsibilities in the target operating model.

In practice, the owner of access governance should be the function that can answer the question, “Should this role, entitlement, or exception exist at all?” The cloud team can implement the mechanics, but it should not be the final authority on business legitimacy. That distinction matters most when old on-premise approvals no longer map cleanly to cloud-native roles, shared services, and cross-environment permissions.

The cleanest operating model is shared accountability: business owners define acceptable access, identity governance teams codify and review it, and cloud/platform teams maintain the technical guardrails that enforce it. This keeps access decisions tied to the business process rather than the hosting model, which is the main source of confusion during migration.

What shared ownership has to cover

Shared ownership only works when each party has a clear decision boundary. Business stakeholders own the “why” of access, including who needs what for a process, application, or data set. Identity governance owns the “how” of review, certification, and removal. Cloud teams own implementation details such as IAM roles, cross-account trust, and platform patterns that make those decisions enforceable at scale.

Without that split, teams often confuse technical delegation with governance authority. A cloud team may be able to grant access faster, but speed does not equal legitimacy. That is why migration programmes should translate legacy entitlements into a role and entitlement model that can be reviewed, approved, and removed by the right owners, rather than simply copied into the cloud.

This is where lifecycle discipline matters. Access ownership is not just a migration design question, it is a continuing governance question that includes joiner-mover-leaver handling, periodic recertification, and offboarding of stale permissions. NHIMG’s IAM and IGA Basics is a useful reference for the division between authorization, provisioning, and review, while the Joiner-Mover-Leaver (JML) Guide reinforces why ownership has to track lifecycle changes, not just initial assignment.

How to prevent migration from turning into access sprawl

Cloud migrations often expose inherited over-permissioning, but they can also create new access sprawl if teams treat temporary migration access as permanent. The risk is not only excess privilege, but also unclear accountability for who approved it and who must remove it later. That is why ownership should include decision rights for exceptions, not just steady-state entitlements.

Practitioners should also pay attention to role quality. If the migration simply re-creates every legacy permission in the cloud, the result is usually a larger and less understandable entitlement model. Better ownership means insisting on business-readable roles, explicit review points, and a defined revocation path for every access path that survives the migration.

A practical pattern is to pair role design with access review. The role owner or business owner confirms the access need, while IGA validates whether the access is recertified or removed. NHIMG’s Role Mining and Role Design Guide is directly relevant here, and Access Reviews and Certification Guide shows how to close the loop instead of leaving reviews as paper exercises.

Risk and Threat Considerations

When access governance ownership is unclear during cloud migration, the most common failure mode is privilege persistence: old access survives the move because no one is clearly responsible for challenging it. That creates both governance risk and attack surface, especially where cloud roles, service permissions, and inherited exceptions are left in place after cutover.

Failure mechanism: Migration teams grant broad access to keep projects moving, but business owners do not review whether that access still matches the process, and governance teams cannot prove timely removal. Over time, permissions accumulate, exceptions become normalised, and privileged paths remain active long after the original business need has ended.

Impact: Excess access increases the blast radius of mistakes and compromises, weakens auditability, and makes revocation slower when staff, vendors, or systems change. In a regulated insurer, that can turn a simple migration shortcut into a persistent control failure.

Practitioner Guidance

What to prioritise: Establish a named access owner for every critical application, role family, and exception path before migration wave one. If no business owner can approve or reject the entitlement, treat that access as unresolved design debt, not a governance gap to be deferred.

What to verify: Confirm that every cloud role or entitlement has an accountable approver, a review cadence, and a revocation trigger. The control is not working if the team can grant access faster than it can explain who remains responsible for removing it.

Common mistake: Letting the cloud platform team become the de facto access owner because it is closest to implementation. That usually produces technically functional access that is weakly governed, which is exactly the wrong trade-off during migration.

Practitioner takeaway: In a cloud migration, access governance should follow business authority, not infrastructure ownership; the cloud team enforces the model, but business and IGA stakeholders must own the decisions that make the model defensible.

Related resources from NHI Mgmt Group

• Why do fragmented access governance and GRC processes create more risk during ERP modernisation and cloud migration?
• What is the difference between role-based access and API key governance for NHI security?
• Who should own access governance in cloud-native environments?
• How should organisations govern access during cloud migration?