If you use
different cloud services in the same sequence of a business process, we speak of a multi-cloud-usage. There are good chances that the same data and cloud services will be used in several of your company’s business processes. Congratulations – you’ve internalized the cloud. And our condolences – you have reached the highest level of complexity for data protection.
In this trend blog we have primarily dealt with the topic of data residency and the associated encryption topic so far. Part V will shed light on the special challenge of data protection in the multi-cloud. We will equally show how to ensure effective data protection while at the same time fulfilling data residency regulations. To make a general statement, let’s assume the following scenario:
You are an European company with a local shop at your local telecom provider, you use an American CRM solution hosted in Ireland and you order products from a Chinese provider whose solution runs on AliCloud in China. Your customers are primarily located in Europe. Among them, there are citizen of the European Union as well as local residents from India, China, the USA and Canada.
The following challenges arise:
- Data of your customers from Europe, the USA and Canada should not be sent to the Chinese provider’s solution.
- Data of your customers from Europe, China and India should not be kept in the american CRM tool. For European customers, data storage on the system in Ireland is justified, as Ireland is subject to GDPR. For the Indian and Chinese citizens living in Europe, the situation is fuzzy at best.
These two plausible limitations alone highlight the problem of overlapping regulations. With unencrypted data, you run the constant risk of violating regulations from the USA, Canada, India, China and/or Europe.
With unencrypted data, you run the constant risk of violating one or more data residency regulations
What would this situation look like if you used multi-cloud encryption?
You enter a new customer in your CRM tool: it’s an Indian citizen, actually living in Germany. The BYOE-encryption recognizes the citizenschip and uses the indian key for the encrytion of PII (Personal Identifiable Information), which is compliant with Indian regulations. Let’s assume that this customer orders an item from China on your website. As a result, the shop solution triggers the order on the Chinese platform. The package is addressed in such a way that it is sent to your German distribution center. The QR code refers to your CRM solution for identifying the customer. In China, the code is scanned. The CRM recognizes the request, but does not authorize the Chinese supplier to access the Indian citizen’s PII. In the order confirmation, only the German distribution center is displayed. Once in Germany, German customs scans the package. The official nature of the request from local authorities is recognized by the CRM solution and the information of the real recipient is displayed to the customs officer. The cleared package is then sent to the distribution centre. Here, the QR code allows you to print the real delivery address on the package. After that, the delivery takes place.
If, on the other hand, the customer were a Chinese citizen and the request came from the Chinese export, then the CRM system would possibly decide differently and would have already displayed the real destination address.
The example is intended to show that different cloud instances, which operate with different keys, offer new possibilities to display or conceal data. Thus, country-specific encryption substantially increases data security while complying with different national data protection and data residency laws.
If you find yourself in a similar multi-cloud situation with customers from all over the world, talk to us. We are looking for customers like you with tomorrow’s challenges – in order to provide the data protection of the future.
This was the provisional conclusion of the trend blog series “Data Residency”. We hope to have brought in new perspectives and shown solutions for your challenges in the areas of data security and data residency. Was this blog too complex, too simple, too superficial, or just right? We welcome any kind of constructive feedback.