Data Sovereignty Is Complex: Ask These Five Questions Before Moving Your Data to the Cloud
By: Virginia Backaitis
Tags: Cloud Migration, Information Technology, Cloud Computing, Digital Transformation, Information Management

Guest Post by Rusty Chapin, Manager of DevOps, BitTitan

It’s not hard to see why more and more organizations are moving to the cloud. Given the shift to remote work during the pandemic, the benefits are clear — robust collaboration and engagement among remote employees, as well as the ease of sharing and securing data. But as organizations look to move workloads to the cloud, there is one often-overlooked issue they should be aware of: data sovereignty.

Put simply, data sovereignty is the idea that an organization’s data is subject to laws and other governance structures of the region or nation where it’s collected. When migrating data to the cloud, data sovereignty plays an important role in how and where the data is moved. Knowing what questions to ask potential vendors prior to migration is the key to data sovereignty compliance.

Before we jump into these questions, we should understand what makes data sovereignty so important. First, it’s a security issue with serious ramifications for noncompliance. Medical, financial, educational or governmental data have specific requirements about how and where the data is stored. In some instances, data can’t leave its country of origin. For instance, government agencies’ documents and emails cannot be processed on another country’s servers.

Noncompliance with data sovereignty initiatives can mean hefty fines, legal action against your organization, or even jail time in the cases of federal laws like HIPAA and FERPA. It’s vital to know exactly where your data goes and how it’s secured during migration. Asking these five questions before choosing a vendor can ensure the move complies with growing data sovereignty initiatives.

What happens to my data while it’s in transit?

Ideally, there are no intermediary stops for your data during migration. If the potential vendor tells you that your data will temporarily be stored in a private data center on its way to its destination, that should raise red flags. Such data centers are likely not as sound and secure as a public cloud offering.

These data centers might also be outside the region or country prescribed by data sovereignty regulations, which could result in noncompliance issues. It’s important that your vendor understand the different certifications and compliance issues they must adhere to with your data. Clearly communicating the various data sovereignty requirements with potential vendors is an important first step.

Does the vendor store my data during and after migration?

Additionally, the vendor shouldn’t store your data in any form. This includes writing it to a disk or keeping it in a database. Instead, they should be handling all your data in application memory. During the migration, any point where your data stops is a risk. It’s better to avoid those risks if possible.

How should I encrypt my data during migration?

Sometimes there are bottlenecks during migrations. For example, maybe the destination is a little slower than the source, and this creates an overflow of data. If this happens, it needs to be written to a disk. In this situation, it’s essential that the data be encrypted using strong encryption and then removed once the migration has been completed.

Data at rest (as opposed to data in transit) creates a window of opportunity for theft and other compliance issues. That’s why this window needs to be as short as possible. If your data comes to a rest during migration, it needs to be cleared immediately after it reaches its destination, shortening the window of resting time.

How does the vendor handle credential security?

Migration credentials are the keys to the kingdom. Whatever vendor has access to those credentials also has privileged access to the source and destination of a data migration. So the utmost care must be taken to secure these credentials.

The best practice is for the vendor to encrypt the credentials whenever storing them. Be sure to ask potential vendors about their own protocols. On the client side, you should always create accounts separate from normal administrator accounts for the vendor. That way, when the migration is complete, you can immediately disable the vendor accounts.

What happens to my data after migration?

Even after the migration is complete, there are still windows of opportunity for data insecurity. Knowing how a vendor handles your data post-migration is important. First, they should clear all data once the migration is successful. Deleting it isn’t good enough.

Any copies of your data should be destroyed, as should the operating environment in which that data was processed. Anything that leaves a memory footprint provides the opportunity for someone to bring your data back to life.

The cloud is a powerful tool, especially with the rise of remote working. But it’s important to do your due diligence before migrating to the cloud. Look at the vendor’s reputation in the industry. Ask to audit the migration logs to see exactly what was done, who was contacted during migration and what calls were made. That way you can see if anything out of the ordinary pops up. With issues of data sovereignty, it’s better to be proactive rather than reactive if issues arise.

Finally, look for vendors that are established and tested, not those who slid into the market after seeing an opportunity. When it comes to data sovereignty, you want to make sure that your organization and its data are in the hands of a vendor you can trust.

About the author

Rusty Chapin is the manager of DevOps at BitTitan, where he leads a team of engineers to deliver first-class cloud solutions to MSPs and IT professionals. His areas of expertise include database development, SQL server clustering, large-scale SQL server deployment, datacenter operations, IT management and executive mentoring, monitoring system design, and process analysis.