Cloud migration security checklist: the decisions that are expensive to reverse

Cloud security failures are rarely exotic. They are almost always a migration-era decision nobody revisited - a flat account structure, over-permissive roles created to unblock a deadline, logging never centralised. This checklist front-loads the decisions that are cheap now and expensive to unwind later.

Before you move anything

• Read the shared responsibility model for each service class you will use. It differs sharply between infrastructure, platform and software services - the provider secures more of the stack as you move up, and the boundary is not intuitive. Write down what is yours per service.
• Classify what is moving. Data classification determines encryption, residency, access and logging requirements. Migrating first and classifying later means retrofitting controls to live systems.
• Confirm data residency and sovereignty obligations - regulatory, contractual and customer commitments. Region selection is effectively irreversible for stateful services, and support access from other regions is a detail worth checking explicitly.
• Check regulatory constraints on cloud use in your sector. Financial and public sector regimes in several jurisdictions impose notification, exit-planning or approval requirements before outsourcing.
• Review the provider's assurance - certifications and audit reports, with scope and period checked, not just the badge.
• Agree the target operating model. Who administers, who approves, who responds to incidents. Migrations frequently hand engineering full production control by default and never revisit it.

Landing zone: the structure everything inherits

• Multiple accounts or subscriptions separating production, non-production, security and shared services. A single account is the decision most regretted later - separation gives you a hard blast-radius boundary that permissions alone cannot.
• Organisation-level guardrails - policies preventing disabling of logging, public exposure of storage, or deployment into unapproved regions. Preventive beats detective, and these are set once.
• Network design with segmentation, private connectivity to data services, and deliberate egress control.
• Centralised logging into a separate account that workload administrators cannot alter. If an administrator can delete the evidence of their own actions, the audit trail is not evidence.
• Tagging standard covering owner, environment, data classification and cost centre - enforced at creation, because retrofitting tags across a live estate never completes.
• Infrastructure as code from the start. Click-configured environments cannot be reviewed, reproduced or evidenced.

Identity - where cloud breaches actually start

• Federate to your identity provider. Local cloud users outside your joiner-mover-leaver process are how orphaned access accumulates.
• MFA on every human account, phishing-resistant for administrators.
• No long-lived access keys. Use short-lived credentials and workload identity; static keys in code and CI systems are a leading breach cause.
• Least privilege, then verify. Migration-era roles are almost always over-permissive - review actual usage after a few months and cut back to what was used.
• Root and global administrator accounts secured, MFA-protected, unused day to day, and alerted on.
• Service-to-service permissions scoped, and reviewed like human access.

Data protection

• Encryption at rest and in transit, with a deliberate decision on provider-managed versus customer-managed keys - and if customer-managed, a key rotation, backup and recovery plan. A lost key is lost data.
• Storage exposure prevented at policy level, not just checked afterwards.
• Backups covering cloud-native data stores, held where a compromised production account cannot delete them.
• Non-production data masked or synthetic. Copying production data into a less-controlled environment is a routine and avoidable finding.

During and after

• Decommission the source. Migrations frequently leave the old environment running, unpatched and forgotten, with live data on it. Put decommissioning in the plan with an owner and a date.
• Update the asset inventory as workloads move, not at the end.
• Deploy posture management and fix the initial findings before the estate grows.
• Re-baseline monitoring - detection rules written for the on-premises estate will not fire on cloud control-plane activity, which is where cloud attacks are visible.
• Re-test recovery in the new environment; your previous restore evidence no longer applies.
• Review permissions against actual usage three to six months in.
• Write the exit plan. How data comes back or moves elsewhere, in what format, and at what cost - required by some regulators, and useful leverage at every renewal.

The two items skipped most often are decommissioning the source environment and re-baselining detection. Both leave you measurably worse off than before the migration, which is the opposite of the intended outcome.

Key takeaways

• Account structure, identity and centralised logging are set once and inherited by everything.
• Eliminate long-lived keys and federate identity - this is where cloud breaches start.
• Decommission the source environment; migrations routinely leave live data behind.
• Re-baseline detection for the control plane, and write the exit plan while you have leverage.