NooBaa Blog

Who is liable?

In our previous post, Will your company survive a 2.7B fine, we discussed the fines companies are exposed to under the GDPR as well as the misconceptions of non European companies regarding their level of exposure. In this post, I would like to discuss some important considerations, especially in cloud and multi cloud environments, as the GDPR does not allow the transfer of liability from the controller, the entity that decides what data to collect,  to the processor, in this case, a cloud provider. The company's DPO and it's DevOps team should work together with its public cloud providers to understand each party responsibility, liability, and legal scrutiny exposure. 

Here are some basic considerations you should take into account when using the cloud for managing data that is enforced under the GDPR.

Privileged user access controls

Let's imagine there is an issue in a production environment and your developers access the production database with a "raw" access. Are they trained in the GDPR considerations? Are the fields that hold personal data encrypted? While copying data from production to test for development projects, are you taking measure to obfuscate or anonymize data? These are common challenges in the healthcare and finance industries.

Regardless of where and how you manage your data, after mapping the private data you should plan and enforce who can access it and how. Limiting access should be done across applications and "real" users.  This should also be enforced across environments in any migration and backup process.

Audit

• Does your cloud provider offer security logs that show authorized and unauthorized attempts to access data?
  Audit logs would help you demonstrate evidence that you are evaluating the effectiveness of technical and organizational measures for ensuring the security of the processing of personal data.
• Does your cloud provider offer security logs that show attempts to delete customer data?
  Succesful and failed attempts to access, change or delete personal data within the cloud environment is more challenging. 

Encryption 

There is a common misconception that in case the public cloud provider encrypts the data - the data controller is not exposed. Article 32 in the GDPR, requires that: "the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate: the pseudonymisation and encryption of personal data; ...".

Gaining access to the encryption keys as well as access the encrypted data is equivalent of gaining access to the data. If my last statement seems counter intuitive imagine that a nation state has hacked the biggest cloud provider at the lowest levels. What data would they have access to? To mitigate this, the controller needs to consider the data before sending it to the cloud and manage the encryption keys in a separate repository. I think it would be feasible to manage the encryption keys on one cloud provider and the encrypted data on another, but we'll need to wait for actual verdicts on this. Also, consider how data flows, its origin and distribution targets when planning the encrypted data read/write path.

Another benefit of managing the encryption keys by the controller is the relief granted to such controllers in case of a data breach. Article 34 in the GDPR, requires that organizations must notify affected data subjects about a personal data breach, but exempts such controllers in case the appropriate measures were taken, such as encryption. 

Storage

It is critical to understand how your cloud providers affect your compliance under the GDPR.
The question of "Where does your customer data reside?" needs to be considered across the board for every application:

• Your cloud providers (IAAS and PAAS)
• Your current service providers (SaaS)
• The location of archive/disaster recovery (DR) and backups.

The disaster recovery and backups are extremely important and covered under article 32 as discussed in our previous blog on this subject. It's also relevant for the SaaS providers as well, and in many cases, people ignore this point. 

Special considerations for companies serving customers across the world

If you are serving just US based customers - keep your operation in the states. If you serve only EU customers - keep it in the EU. If you serve both today or might consider penetrating the market at the other end of the pond in the future what should you do? It's complicated.
As you can find here the issue of citizens data protection is not in agreement between US and EU authorities. As that is the case you should maintain operations in both locations and/or consider how can you expand in case you don't have such operation. have the following information, available as evidence:

In addition, you should have the source location of each user, with a manner that can pass scrutiny, as well as the ability to route data to the right environment in a specific location.

Multi site operation is important to address early. If you set yourself for vendor lock-in with a specific cloud provider, you might be surprised that not only it's hard to move your application to a multi-cloud setup, but moreover, it's even hard to get into a multi region setup within the same cloud provider. Offerings differ between regions even within the same could provide and you'll need to add a lot of knowledge into the application on both the smart routing as well as the difference between environments. Some CTO's even preach maintaining two totally separate stacks with only routing done at the top.

How is NooBaa related to all this?

Whether your company is a controller, a processor or both, NooBaa's solutions can greatly simplify your journey to achieving compliance in a much shorter time and cost effective manner. We'd be happy to help.