Cloud Migration Security Checklist: Step-by-Step

Step 1: Classify Your Data and Assets Before You Move Anything

Your goal here is a complete, tagged inventory of every asset you plan to move, sorted by sensitivity and regulatory weight. You cannot pick the right controls for a workload you haven't characterized yet.

Start by pulling an inventory of all data stores, applications, and services in scope. For each one, answer four questions: What data does it hold? How sensitive is it? What compliance framework governs it (HIPAA, PCI DSS, SOC 2, GDPR)? And who owns it operationally?

Assign each asset a sensitivity tier. A common approach uses three levels: regulated (PII, PHI, cardholder data), internal (business logic, unreleased financials), and public. The tier drives every downstream control decision, from encryption key management to who can access the workload in transit.

Map dependencies before anything moves. An application that looks standalone often pulls from a shared database, calls an internal API, or writes to a file share that another team owns. If you migrate the app without the dependency map, you'll break those connections or, worse, leave sensitive data in an unprotected intermediate state during the cutover window.

Flag regulated workloads explicitly. Covered entities must identify and protect electronic protected health information (ePHI) wherever it lives, including during migration. That obligation doesn't pause because you're mid-move.

By the end of this step, you should have a tagged asset list with sensitivity tiers, compliance flags, dependency maps, and named owners. That document becomes the source of truth for every control decision in the steps that follow. If you're evaluating enterprise cloud migration services to support the move, hand them this inventory on day one , gaps here tend to become incidents after cutover.

Step 2: Lock Down Identity and Access Controls

Identity is where most cloud breaches start. Overprivileged roles, shared credentials, and orphaned accounts from your on-premises environment will follow you to the cloud if you don't address them before migration day.

The foundation is least privilege. Every human user and every service account should have exactly the permissions needed for its function, nothing more. In practice that means replacing broad roles like AdministratorAccess with scoped policies, and auditing every existing role before it gets replicated in the cloud.

Federate identity to a single authoritative source. Whether you use AWS IAM Identity Center, Azure Entra ID, or a comparable cloud IAM provider, the goal is one identity provider (IdP) that all cloud accounts trust via SAML or OIDC. That single control point lets you enforce MFA once, revoke access on termination instantly, and feed a unified audit trail into your SIEM. Running separate IAM silos per cloud is how stale credentials survive for months undetected.

Enforce MFA across the board, without exceptions for service accounts. For privileged roles, layer on just-in-time (JIT) access so standing admin permissions don't exist at all. Deterrent controls — such as privileged access banners, session recording, and mandatory justification fields in your privileged access management tooling — let users request elevation for a defined window with full accountability. That friction is the point.

Machine identities need the same discipline as human ones. Assign separate service accounts per workload. Avoid long-lived keys. Use native mechanisms for temporary credentials — such as workload identity federation or equivalent short-lived credential services — rather than static keys. Rotate secrets on a schedule and track all usage in audit logs.

If you're moving workloads across multiple providers, consider a unified identity fabric approach that federates all clouds through one corporate IdP. This is especially important in regulated industries where PCI DSS v4.0 and similar frameworks require consistent access controls and audit trails regardless of which cloud hosts the workload. Our multi-cloud security and compliance practice at Zylo Technologies is built around exactly this kind of unified identity enforcement.

By the end of this step, every account (human and machine) should have a defined owner, scoped permissions, MFA enabled, and a rotation or review date on record.

Step 3: Segment Your Network and Restrict External Exposure

The goal is containment. If an attacker compromises one workload, network segmentation limits how far they can move. Without it, a single misconfigured security group can expose your entire cloud environment to the internet.

Start with VPC or VNet segmentation. Group workloads by sensitivity tier and function, not just by application. Production payment processing belongs in a different subnet than development tooling, even if both are owned by the same team. Use separate security groups and network ACLs (NACLs) for each segment, and default to deny-all inbound rules unless a specific port and source are explicitly needed.

Eliminate public exposure wherever you can. Storage buckets, databases, and internal APIs should never have public endpoints. Use private endpoints and VPC service controls to keep traffic off the public internet entirely. For workloads that do need external access, put them behind a load balancer or API gateway with WAF rules enabled, not directly on a public IP.

Egress filtering gets overlooked. Most teams think about who can reach their workloads from outside. Fewer think about which workloads can reach external destinations. An unfiltered egress allows data exfiltration and command-and-control callbacks. Apply egress restrictions at the security group and firewall level, whitelisting only the destinations each workload legitimately needs.

For cloud security best practices on network architecture, the principle is the same across AWS, Azure, and GCP: traffic between tiers should be explicit and inspected, not implicit and open. Build that into your migration architecture before the first workload moves, because retrofitting network segmentation after go-live is painful and error-prone.

Document your network topology as part of the migration runbook. Every security group rule, every private endpoint, every firewall policy should be in version control so your team can audit drift and roll back changes with confidence.

Step 4: Apply Preventive and Detective Controls Across Your Workloads

Prevention blocks bad paths before they're taken. Detection catches what prevention missed. You need both, and you need them mapped to specific workloads, not just listed in a policy document.

Preventive Controls

Preventive controls are the settings and policies that say no before a risky change reaches production. , these typically live in AWS Organizations SCPs, Azure Policy, GCP Organization Policy, Kubernetes admission controllers, and CI/CD gate checks.

Concrete examples: block public bucket creation at the organization policy level so no individual engineer can override it. Reject Terraform plans that open SSH to 0.0.0.0/0. Deny workload deployment in unapproved regions. The best preventive control is boring , no ticket gets opened, no apology gets written, the unsafe path simply isn't available.

Detective Controls

Detection doesn't fix problems. It tells you where reality moved away from the design. GuardDuty and other native threat-detection services are the starting points. But a detective control that fires a generic "high severity" alert is noise. One that says "production payments bucket, public access enabled 14 minutes ago, owned by Commerce Platform team, PCI scope" is actionable.

Build ownership context into your detection layer from day one. Tag every resource with environment, team, app, and compliance scope. Without that metadata, your alerts land in a queue with no clear owner and remediation stalls.

Deterrent and Compensating Controls

Deterrent controls add friction at the moment someone is about to touch production or escalate access. A mandatory reason field before privileged access elevation, a session recording notice, or a privileged access banner changes behavior without blocking the action entirely. Don't underestimate these. They work.

Compensating controls cover gaps that the ideal control can't fill yet. A legacy app that can't support modern encryption might get network isolation, IP allowlist restrictions, and a monthly access review instead. That's not ideal. It's still governed. Every compensating control needs a named owner, a documented reason, a substitute safeguard, and an expiry date tied to a remediation plan.

The table below maps each control type to its cloud-native implementation and primary use case.

At Zylo Technologies, when we scope a cloud migration engagement, this control mapping happens in parallel with the workload inventory, not after. Teams that bolt it on post-migration spend weeks remediating findings that would have taken hours to prevent.

Step 5: Encrypt Data at Rest and in Transit

Encryption is the one control that protects data even when access controls fail. It should be on by default for every regulated and internal-tier asset, with no manual opt-in required from engineers.

For data in transit, enforce TLS 1.2 as a minimum and prefer TLS 1.3 for new workloads. This applies to API traffic, database connections, replication streams, and migration pipelines. During the migration itself, data migration tools can route data through unencrypted channels if you don't explicitly configure TLS — that gap is easy to miss under deadline pressure.

For data at rest, use customer-managed encryption keys (CMKs) wherever compliance requires it. CMKs give you control over key lifecycle, rotation schedules, and access policy. Enable automatic key rotation. Tie key policies to the same ownership tags you defined in Step 1 so key access aligns with workload ownership.

For database migrations specifically, confirm that backup files, snapshot exports, and migration staging areas are encrypted with the same key policy as the production workload. Unencrypted backups sitting in an S3 bucket are a common post-migration finding in HIPAA audits, and one that's embarrassing given how straightforward S3 default encryption is to enable.

Tokenization is worth considering for regulated data that needs to flow through multiple services. Instead of passing raw PII or cardholder data between workloads, you pass tokens that resolve only in a controlled vault. This limits the blast radius if any downstream service is compromised. It's additional architecture work, but for PCI DSS scope reduction it's often worth the investment.

If your architecture spans multiple clouds, verify that your key management approach works consistently across providers. The cloud architecture consulting process we follow at Zylo Technologies includes a key management audit early in design, before workloads are placed, because retrofitting encryption governance across a multi-cloud estate is significantly harder than designing it in from the start.

Step 6: Embed Security Into Your Infrastructure as Code

If your infrastructure is defined in code (and it should be), your security policies can be code too. Policy as Code (PaC) lets you intercept and block non-compliant infrastructure changes before they reach the cloud, not after a post-deployment audit flags them.

Two approaches dominate here. The first is a native policy engine tightly coupled to your IaC platform — using a readable domain-specific language with tiered enforcement: advisory (log and proceed), soft mandatory (block unless an authorized user overrides), and hard mandatory (no override, ever). If your team already runs a managed IaC platform, this kind of integrated policy engine requires no external infrastructure to manage. The grounded options here include OPA/Rego and Terraform Sentinel, both listed as recommended controls for Infrastructure-as-Code security.

The open-source path uses OPA/Rego — a declarative language with a steeper learning curve but far wider applicability. The same engine and Rego syntax can enforce infrastructure policies across Terraform, admission control in Kubernetes, and API authorization at the proxy layer. If your stack spans tools beyond a single vendor suite, standardizing on one policy language across all of them is worth the investment.

In practice, the choice depends on your toolchain. A tightly integrated native engine works best when you want policy writers who aren't software engineers to own the rules. OPA/Rego fits better when you run open-source Terraform, Kubernetes, or a multi-tool ecosystem where a single policy language covering everything justifies the learning curve.

Either way, the critical rules to enforce at the IaC level are consistent. Block public storage bucket creation. Require encryption on every resource that stores data. Enforce mandatory tagging (environment, owner, cost center, compliance scope) so resources without context can't be provisioned. Reject deployments to unapproved regions. These aren't exotic policies. They're the checks that prevent the most common migration security findings before they land in production.

Drift detection matters equally. Policy as Code catches changes at deploy time. Drift detection catches manual changes made outside the pipeline, the "temporary" fix someone pushed at 11 p.m. that became infrastructure history. Set up continuous drift detection and route violations to the workload's named owner, not a generic security queue. For a deeper look at how governance extends to AI workloads and compliance automation, the enterprise AI governance framework we've published covers similar principles applied to model-layer risk.

By the end of this step, no infrastructure change should be able to reach production without passing your security and tagging policies. That's the durable control plane that makes the rest of this checklist compound instead of decay.

FAQ

Conclusion

Security built before migration day is an order of magnitude cheaper than security retrofitted after incidents. Start with classification, lock down identity, segment your network, layer your controls, encrypt everything by default, and enforce it all in code. If your team needs a partner to architect and ship that security posture alongside the migration itself, Zylo Technologies builds durable cloud security systems for founders and enterprise operators who want to own the outcome, not rent compliance theater. Reach out to our team and we'll respond within 48 hours.