What should teams document before moving IGA into a regulated cloud tenant?

What should teams make explicit before the tenant move?

Before moving IGA into a regulated cloud tenant, the team needs a written boundary that says what is inside the tenant, what remains outside it, and who owns each control and decision. The point is not just to record architecture, but to preserve accountability when delivery, support, and audit evidence are split across cloud and enterprise teams.

That document should also capture the operating assumptions regulators care about: where data is stored and processed, which release train governs change, which team handles incidents and support, and what evidence will be available on demand. Without that, IGA can look technically deployed while the governance model becomes ambiguous in practice.

If the tenant will host identity governance functions for humans and non-humans, teams should also note which lifecycle actions stay centralized and which are delegated to the cloud platform. For a broader identity baseline, IAM and IGA Basics explains the governance boundary between provisioning, reviews, and entitlement control.

Why does regulated-cloud IGA documentation matter?

IGA is not only a tooling decision, it is an accountability decision. In a regulated tenant, the organisation must be able to show that its approval paths, review cadence, retention choices, and support model still satisfy the original governance intent, even though the service now runs in a different delivery environment.

That is why the evidence pack should be written as an operational record, not a slide deck. It should show who can change the tenant, who can approve access, how changes are reviewed, and how audit evidence can be produced without manual reconstruction after the fact. The strongest internal references on this point are IGA Buyer's Guide for platform and governance decisions, and Access Reviews and Certification Guide for review and certification evidence.

Regulated environments also force teams to be precise about regionality and evidence retention, because those choices can affect legal hold, supervisory review, and operational resilience. Where cloud delivery changes the control owner or the place where logs and approvals live, that change needs to be explicitly traceable in the governance record, not inferred from the vendor contract.

What belongs in the handoff record?

The useful minimum is a control map that ties each important IGA function to a named owner and a named evidence source. At a practical level, that means documenting the tenant boundary, data residency, release ownership, support responsibility, audit evidence location, and the approval path for exceptions.

Teams should also note how lifecycle events are handled when the tenant is managed as a shared platform. Offboarding, privilege removal, and access review need an owner and a timing expectation, especially if the tenant contains service identities or automation that can continue to act after the business no longer expects it. Joiner-Mover-Leaver (JML) Guide and Role Mining and Role Design Guide are useful when the tenant model changes how roles and lifecycle actions are governed.

Where the regulated cloud tenant introduces shared responsibility, the record should identify which controls the cloud provider supplies, which controls the organisation must still operate, and which controls require evidence from both sides. That prevents the common failure mode where everyone assumes someone else owns the proof.

Risk and Threat Considerations

Regulated-cloud IGA breaks down when the control boundary is assumed rather than written. The main exposure is not that the tenant is cloud based, but that ownership, residency, support, or evidence collection becomes ambiguous enough that auditability and accountability weaken at the exact point regulators expect clarity.

Failure mechanism: Teams migrate the platform first and try to reconstruct control ownership, logging, and evidence expectations afterward, which leaves gaps in incident response, retention, and supervisory proof.

Impact: The organisation can end up with functioning IGA workflows but incomplete audit evidence, disputed responsibilities, and a governance model that is harder to defend under regulatory review.

Practitioner Guidance

What to verify: Confirm that every control in scope has one accountable owner, one evidence source, and one retention rule before the tenant goes live. If a control cannot be traced to a named team and a retrievable artefact, treat it as not yet ready for a regulated environment.

Decision rule: If the tenant changes where approvals, logs, or entitlement data are stored, require a documented control-owner signoff and an audit test run before production use. If the cloud design only changes tooling but not evidence location or accountability, the documentation can be lighter, but it still needs to be explicit.

Practitioner takeaway: The safest migration path is to document accountability first and technology second, because regulated-cloud failures usually come from unclear ownership and missing evidence, not from the IGA function itself.

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities in cloud environments?
• What should identity teams verify before moving an insurer to cloud deployment?
• How should security teams align cloud governance with compliance requirements before moving workloads to the cloud?