GDPR, Big Data & The Cloud: What It Means for Users’ Data Access, Security and Compliance

Featured article by Alex Bordei, Bigstep

GDPR: It’s Complicated!

The field the European Union (EU) is trying to regulate with GDPR is so complicated that I am afraid there is just no easy and clear-cut way to both protect “data subjects”, and allow businesses to function.

Citizens gain an updated and reinforced right of access to their data (art. 15), the right to be forgotten (art. 17), and the right to data portability (art. 20), while companies are obliged to build and architect with security and privacy in mind (art. 25 & 32), to report data breaches (art. 33 & 34), to perform data protection impact assessments (art. 35), and to appoint data protection officers (art. 37).

Roles Under GDPR

If you are a company that handles user data in any way, you are either a Data Processor or a Data Controller. Data Processors and Data Controllers have different obligations under GDPR so figuring out which one is you is critical.

There is a whole host of information out there describing GDPR in far more detail than I could ever get. However, working in an arena that is already GDPR-compliant has given me an overview on the issue, so I hope you will find value in my layperson’s approach to providing an easy to understand summary and suggestions.

If you “determine the purposes and means of the processing of personal data on the data subjects,” i.e. your end-users’ data, you are the Data Controller.

When working with companies, the cloud provider is usually the Data Processor, even if it stores only encrypted data and even if no actual “processing” takes place. The cloud provider becomes a Data Controller when it offers cloud services directly to the end-user.

If you are a data analytics SaaS company hosting data with a cloud provider, you are a Data Controller, but if you also provide your services to a third-party company that in turn provides services to the end-user, then you become a Data Processor as well.

Obligations of Cloud Providers to Data Controllers:

In broad terms, you as a cloud provider are required to process personal data using the controller’s instructions. This is a broad definition which in effect indirectly obliges you to many of the obligations that the controller has, albeit at his/her instruction.

The binding obligations on the processor (the cloud provider) must cover the duration, nature, and purpose of the processing, the types of data processed and the obligations and rights of the controller. The terms of use and conditions that you and the controller have signed (digitally or otherwise) must include provisions to govern this relationship.

1. Self-Managed Customers:

My suggestion is not to touch the controller’s data unless in an automated fashion, and only if the controller used the UI or API to instruct the cloud systems to interact with that data. In effect, all of the controller’s data is very much under their direct control.

2. Single Point of Contact Customers:

You may design a “solution” document at the start of your business relationship with the controller, typically during the proof of concept phase.

3. Data Breaches:

You need to notify the controller of a data breach that affected their servers. It is their decision how to handle that incident afterwards.

4. Subcontracting:

You need to get the controller’s consent if their data ever reaches a 3rd party.

Other Obligations of Cloud Providers:

1. The Privacy by Design Principle:

As a cloud provider, you need to make sure you architect your products from the get-go so that they are as safe as they can be with the current technologies.

I believe in isolating customers’ machines physically from one another. This way you are also the only ones that create L2 overlay networks on physical switches rather than L3 on virtual ones.

The solutions you build for your customers must be designed with security and privacy in mind, and you should voice your concerns if the controller chooses to go for a less secure route.

2. The Transfer of Data to Another Country:

Regardless of the specific instructions from the Data Controller, you still need to make sure the country to which the data is transferred is deemed safe.

In the unlikely event that the controller instructs you to transfer data to a third party in a country that you do not consider safe, consider refusing the request.

3. Demonstrating Compliance:

You need to be able to demonstrate that you are compliant at all times. This means you need to maintain a record of all categories of processing activities or details of transfers of data to other countries.

This is mandatory, as art. 24 clearly states: “The controller shall implement appropriate technical and organizational measures to ensure and to be able to demonstrate that processing is performed in accordance with the Regulation.”

4. Appointing a Data Protection Officer

The DPO is the person(s) that oversees your GDPR compliance and is responsible for making sure you respect our fellow citizens.

Conclusion

As a cloud company, your work touches the data of millions of people. Often, a secure system is a far less flexible system, but this sacrifice ultimately adds up to a safer, better society in this digital age, and I believe the effort is worth it.

About the Author: Alex Bordei is Director of Product and Development at Bigstep, a company that empowers organizations determined to make sense of their data, by providing a full-stack big data ecosystem running in a high-performance bare metal cloud. He can be reached at alex.bordei@bigstep.com, or follow on Twitter at @BigStepInc.