Why Data Protection During Cloud Migration Requires a Separate Plan
The global cloud migration services market reached USD 18.2 billion in 2026. Data protection during cloud migration is not simply a checklist item. It is a separate discipline that determines whether your business can complete the transition without data loss. In this COSMONOVA guide, we examine the risks, stages, and practical steps that distinguish a controlled migration from a security incident.
Most companies underestimate one important fact: moving systems requires a balance between deployment speed and data protection. Existing security controls often do not automatically cover cloud infrastructure without additional configuration, and this is where data leaks can occur.
Below, we explain how to build data protection into every stage, from readiness assessment to post-migration monitoring.
Security Risks When Moving Data to the Cloud
The main risks of moving data to the cloud fall into two categories: loss of perimeter control and technical configuration errors. Both categories are predictable and therefore manageable.
Information Leakage and Loss of Perimeter Control
When data leaves an on-premises server, the security perimeter becomes less defined. The company no longer controls physical access to storage media or network security at the level of its own server rack. This creates a risk of information leakage during a stage that is often treated as simple transportation.
Configuration Errors and Uncovered Security Controls
Incorrect configuration and insufficient data protection are among the main risks during migration. Security controls that worked in an on-premises environment do not always automatically cover cloud services.
Important: a common mistake is moving servers while keeping old access-control rules. In the cloud, this can expose databases to unauthorized access immediately after migration.
Data Encryption When Transferring Data to the Cloud: What to Protect at Every Stage
Data encryption during cloud migration is a basic requirement, not an optional feature. Three states of data must be protected: at rest, in transit, and in use, where applicable.
Three Data States and Their Corresponding Mechanisms
| Data state | What is protected | Mechanism | Who configures it |
|---|---|---|---|
| At rest | Disks, snapshots, backups, object storage | AES-256 (GCM/XTS), provider-side or client-side encryption | Client chooses the mode, provider executes |
| In transit | Replication channels, VPN, API, management console | TLS 1.2+ (preferably 1.3), IPsec/IKEv2 for site-to-site | Client and provider jointly |
| In use | Memory processing, confidential computing | Enclaves (SGX, SEV), homomorphic encryption, specialized scenarios | Client with provider support |
In practice, this means:
- Encrypting disks on the source side before transfer (LUKS, BitLocker with TPM).
- Using secure VPN tunnels or TLS 1.2+ for data transfer while disabling outdated ciphers such as RC4, 3DES, and SHA-1.
- Encrypting data in cloud storage with separate key management (BYOK/HYOK).
- Rotating keys according to a defined schedule and separating data encryption keys (DEK) from key encryption keys (KEK).
Key Management: KMS, BYOK, and HYOK
The weak point of many migrations is not the encryption algorithm itself but where the keys are stored. If keys are stored in the same cloud as the data and managed by the same provider, compromise of an administrator account can undermine the entire protection system.
Three models are commonly used:
- Provider KMS — the cloud generates and stores the keys.
- BYOK (Bring Your Own Key) — the client imports a key into the provider's KMS.
- HYOK (Hold Your Own Key) — keys remain in the client's infrastructure and the cloud receives only ciphertext.
The choice is a trade-off between control and functionality. BYOK can be considered for personal and payment data, while HYOK may be considered for particularly sensitive datasets, with an understanding of its service limitations.
Regulatory Requirements for Encryption
Important: a common mistake is leaving key management with the provider without contractually defining key rotation and destruction procedures.
Without multi-factor authentication at all access points, even strong encryption can lose its effectiveness. Encryption and MFA should therefore be treated as a single security layer.
ISO 27001 Data Center Security Standards and Pre-Migration Audit
ISO 27001 provides a framework for evaluating a cloud provider before signing an agreement. ISO 27001 certification indicates that the provider has established an information security management system and undergoes regular audits.
Pro Tip: request not only the provider's ISO 27001 certificate but also a report from the latest audit, including identified non-conformities.
Shared Responsibility Model in the Cloud: Who Is Responsible for What?
The cloud shared responsibility model defines the boundary between the provider's responsibilities and the client's responsibilities. The provider is responsible for physical data center security, the network, and the hypervisor. The client is responsible for data, access, application configuration, and encryption.
| Responsibility area | Provider | Client |
|---|---|---|
| Physical security | Yes | No |
| Network infrastructure | Yes | Partially |
| Data encryption | Partially | Yes |
| Access management | No | Yes |
| Application configuration | No | Yes |
| Backup | Partially | Yes |
Step-by-Step Data Protection Plan: From Readiness Assessment to Monitoring
A step-by-step data protection plan consists of several stages, each addressing a specific risk.
Infrastructure Readiness Assessment and Access Control
Cloud Readiness assessment shows which systems can be migrated immediately and which require additional preparation. At this stage, inventory your data, identify critical applications, and configure access control according to the principle of least privilege.
Backup, Disaster Recovery Planning, and Monitoring
Backups must exist before migration begins, not after. A Disaster Recovery Plan (DRP) defines recovery objectives and the required actions in case of failure. After migration, configure system monitoring so that resilience and data integrity are continuously checked.
- Inventory data and applications.
- Configure backups and test restoration.
- Create a disaster recovery plan with defined recovery objectives.
- Deploy monitoring and security auditing after migration.
Legal Aspects, Compliance, and Total Cost of Ownership After Migration
This section covers the requirements that apply to migrated data and how to calculate the actual cost of ownership after the transition.
Compliance: Which Requirements Apply?
The legal aspects of migration concern the storage of personal data, data protection requirements, and the provider's contractual obligations.
Key frameworks include:
- Law on Personal Data Protection (No. 2297-VI) — the basic framework for processing personal data.
- NBU cybersecurity requirements — mandatory security measures for banks and financial institutions.
- Industry standards — PCI DSS for payment data and ISO/IEC 27001 as an information security management framework.
- GDPR — applicable when data subjects include EU residents.
Provider Agreement: What Should Be Defined?
Compliance is not limited to technical controls. It is also contractual. The provider agreement should define:
- the types of data being processed and the purposes of processing;
- incident notification procedures and deadlines;
- procedures for returning and deleting data after termination;
- audit rights and access to non-conformity reports;
- liability for downtime and data loss.
Total Cost of Ownership (TCO) After Migration
The cost of ownership after migration is often higher than expected because additional expenses may appear beyond basic compute and storage.
Typical cost areas include:
- CSPM and security posture management.
- Backup and DRP.
- Monitoring and logging.
- Traffic between zones and regions.
- Employee training and reskilling.
Key takeaway: compliance and TCO are two sides of the same issue. An overlooked regulatory requirement can become an unplanned expense, while an overlooked expense can create pressure to reduce security controls.
Conclusion
Cloud migration without a dedicated data protection plan is a bet on luck rather than an engineering decision. Configuration risks, a blurred security perimeter, and unclear responsibility boundaries can undermine projects that looked flawless on paper.
Frequently Asked Questions
What security risks arise during cloud migration?
The main risks include information leakage caused by weak access controls, configuration errors when moving servers and databases, and loss of security control when existing security tools do not adequately cover cloud infrastructure.
How can ISO 27001 requirements be addressed during data migration?
The provider should be assessed before migration begins. Request current certificates and their scope, descriptions of access controls, backup procedures, and incident response processes.
What encryption methods should be used when transferring data to the cloud?
Data should be protected at the source, during transmission, and in cloud storage. TLS 1.2 or higher should be used for transport, while VPN tunnels can be used for connections between sites.
Who is responsible for data security in the cloud shared responsibility model?
The provider is responsible for physical data center security, resilience, network security, and the hypervisor. The customer is responsible for its own data, accounts, application configuration, and access rights. Responsibility boundaries should be clearly defined in the agreement and SLA.
