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
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.
AuditThe above control also requires audit both by your company and the public cloud provider:
- 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.
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.
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
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,