Securing a move into public cloud became a discipline of its own only after organisations began vacating colocation sites in volume and found that the controls protecting their workloads did not make the journey with them. A firewall rule drafted for a flat internal network means something different within a virtual private cloud. A patch cycle run by an internal team acquires a different responsible lead once the platform beneath it belongs to a provider. The interval between switching an old control off and proving its replacement works became a period of measurable exposure, and the guidance that now governs the work was established to close it.
Two documents frame that guidance. In June 2022 the Cybersecurity and Infrastructure Security Agency published a revised Cloud Security Technical Reference Architecture, co-authored with the United States Digital Service and FedRAMP, which defines and clarifies considerations for shared services, cloud migration and cloud security posture management; the CISA release notice reports that more than 300 public comments were adjudicated before publication, and that organisations using or moving to cloud environments should adopt its practices where they apply. The National Cyber Security Centre approached the same ground from the infrastructure side, warning that a lift and shift replicates an existing local system machine for machine and leaves it with the problems of the local system plus a few cloud-specific ones, and that the approach should be avoided where possible.
This page arranges both into an order of work. It is addressed to whoever approves that a workload is safe to move, and to the architect who has to supply the evidence behind that approval. Seven steps appear in the order a project performs them, and each one gives the action and the test that closes it. Assessment method, cost model, supplier shortlisting and the compliance layer each have separate treatment elsewhere on this site, because the job here is to fix the sequence rather than exhaust the subject.
Step 1. Establish control responsibility
The shared responsibility model is easy to say and widely misread in practice. The provider secures the physical infrastructure, the hypervisor and the managed service control plane; the customer secures data, identities, configuration and operating controls. Cloud Bridge, in the Secure by Design research it published on secure cloud migration for UK businesses, found that 77% of respondents believe their public cloud provider is responsible for securing all aspects of the environment, that only 12% manage cloud migration security entirely internally, that 83% have met security issues during or after a migration, and that the average cost of underestimating security requirements now runs above £625,000 for each organisation. Those findings point at the same gap from different sides, and the matrix below is how a project closes it.
Write one row for each control layer: identity and privilege, network ingress and segmentation, compute hardening, storage and key management, logging and retention, patching, backup and recovery, and the application itself. Each row gives the provider or the customer as responsible, plus a specific individual. This step closes when a security architect and a platform lead have both approved the matrix, and when every row marked shared contains a sentence explaining what each side does.
Step 2. Build the landing zone before any workload moves
Platform first is not a preference. The NCSC guidance says that a chosen cloud platform should be configured securely before any migration is performed, because a hole left in the platform affects every workload hosted on it. That work includes the account or subscription structure, identity services and their federation, a central logging target with a retention rule, encryption defaults for data at rest and in transit, network segmentation with private endpoints, and policy guardrails that block a team from creating a publicly readable storage bucket at three in the morning. A guardrail earns its place only when it denies the action rather than reporting it afterwards.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyPublicBucketAcl",
"Effect": "Deny",
"Action": "s3:PutBucketAcl",
"Resource": "*"
}
]
}
This step closes when the baseline exists as code, has been applied to the target accounts, and is backed by a report that gives the issue time and lists every guardrail, logging target and default, with evidence that one deliberate attempt to breach a guardrail was logged and blocked. A guardrail that only raises a complaint after the bucket is public is a monitoring rule, not a control, and it belongs in a different row of the matrix.
Step 3. Inventory every workload and its dependencies
Inventory is where most projects learn that the infrastructure is larger than the spreadsheet. Take the inventory and simplify it, as the NCSC advises: identify end of life and vulnerable products, confirm that the security boundaries around each application remain valid in the cloud design, and remove the exceptions that have accumulated in the permissions model. The same guidance warns against extreme granularity, because a permissions model too complex to be understood correctly leads to errors, and argues that usability has to be excellent while security only needs to be good enough.
Credentials belong in this pass as well. Wiz, in its cloud migration security guide, reports that 61% of organisations have secrets exposed in public repositories, and a secret that was harmless within a private network can become an entry point once the workload is reachable from the internet. TierPoint's guide adds the rest of the usual list: storage buckets left open, default settings left unchanged, APIs built without rate limiting or with broken authorisation, and third-party access that no individual has reviewed since it was granted.
This step closes when every workload has a responsible individual, a data class, a recovery time and recovery point objective, a dependency list, and a decision to migrate, replatform, refactor, replace, retire or retain, approved by that individual rather than by the project office. An export from a discovery tool is not an inventory until those fields are filled and someone has put their approval to them.
Step 4. Choose the move for each workload
Each choice leaves a different security position, so it has to be documented against the workload rather than made once for the whole infrastructure. TierPoint's cloud migration security guide gives the security challenge against each of the seven approaches, and Cloudaware makes the related point that the choice shapes both the upfront bill and the running cost, which is why the security question and the money question are the same conversation.
The rehost approach moves the workload machine for machine into infrastructure as a service. The NCSC reports that this places most of the management and security burden on the customer, so what the approach gives up is managed patching, provider-maintained identity integration and platform-native logging.
The replatform approach exchanges a component for a managed equivalent, such as a self-managed database for a managed one. What it delivers is automated patching and a provider-operated control plane; what it gives up is application-level design change, so insecure code paths stay where they are.
The refactor approach rebuilds the application around cloud-native services. What it delivers is the chance to remove a vulnerability class rather than move it, and what it gives up is time, because the rebuild has to be tested against the same security requirements as the original.
The repurchase approach replaces an application with a software-as-a-service product. What it delivers is a provider that maintains the application security work, and what it gives up is direct control over configuration, data handling and the provider's own supply chain.
The retire approach removes an application that no longer has a business justification. What it delivers is a smaller attack surface, and what it gives up is the data retention question, which has to be settled before the application is decommissioned.
The retain approach keeps an application where it is. What it delivers is continuity for a system that cannot be moved without unacceptable risk, and what it gives up is the simplified management that a cloud platform provides, because the on-premises controls remain in place.
The relocate approach moves infrastructure at the hypervisor level without rewriting the application. What it delivers is speed, and what it gives up is the chance to correct the security design, because the workload arrives with the same configuration it had before.
This step closes when every workload has one of those decisions, with the security position and the cost position documented beside it, and with the responsible individual's approval on the record.
Step 5. Move identity and access before data
Identity is the control that decides whether a moved workload is reachable. The NCSC guidance puts access control on the customer, not the provider, because only the customer knows who needs access to its data and who should be kept out. That makes identity federation, multi-factor authentication and a simplified permissions model prerequisites rather than later tasks. Wiz reports that identity and access management lapses during migration allow an attacker to use one entry point and then move laterally, and that temporary elevated permissions granted for the move often remain in place long after the cutover.
The practical action is to migrate the identity provider integration first, then the roles and groups, then the workload. This step closes when a test account with no business need is refused access to the target environment, when a privileged action is logged with the identity that performed it, and when the migration's temporary permissions have a documented expiry time.
Step 6. Encrypt data in transit and at rest, and control the keys
Encryption during migration has two directions and two phases. Data in transit moves over a channel that should use a current protocol, and data at rest should be encrypted under a key whose lifecycle is documented. TierPoint's guide lists the key options, and each one changes who can read the data if a storage control is misconfigured.
Provider-managed keys put the lifecycle with the provider, which reduces operational work but leaves the provider able to decrypt.
Customer-managed keys put the lifecycle with the customer, which increases control and operational work.
Bring-your-own-key models let the customer import key material, which retains control over the root of trust but adds rotation duties.
Hardware security modules keep key material in dedicated hardware, which gives the strongest separation at the highest cost.
This step closes when a sample of migrated data can be shown to be unreadable without the key, when key rotation has been tested on one non-production workload, and when the encryption phase of every storage service in scope has been checked against the baseline rather than assumed from a provider default.
Step 7. Watch the migration window and the first ninety days
The migration window is a period when identities, data and workloads exist in two places at the same time. Wiz explains that overlap as where most problems start, and it lists the risks that matter most: data compromise, identity lapses, environment sprawl, confusion over the shared responsibility model, new compliance requirements, and insider threats or skills gaps. Post-migration security is not a review that happens after the project closes; it is the period when misconfigurations introduced during the move surface.
The practical action is to centralise logging in a target that existed before the first workload moved, to run vulnerability scans on a schedule that matches the rate of change, and to define incident response for the cloud architecture before it is needed. This step closes at the ninety-day mark, when the project can show that every alert has a specific route to a responder, that temporary migration permissions have been removed, and that the guardrails from step two are still denying the actions they were built to deny.
The NCC Group cloud migration and security service, listed on the Digital Marketplace, includes post-migration support to manage security and reporting, and accounts for post-migration security when setting expectations of cost savings.
Sources
- CISA Releases Guidance for Secure Migration to the Cloud
- Cloud security guidance | Using cloud services securely | How to 'lift and shift' successfully
- Secure Cloud Migration: What UK Businesses Need to Get Right in 2026
- Cloud Migration Security Explained | Wiz
- Cloud Migration Security Guide: Challenges and Best Practices
- Cloud Migration Costs: Savings, Benefits & Enterprise Cost Guide
- Cloud Migration and Security - Digital Marketplace
