GDPR: What controller/processor guarantees must be agreed?
Co-operate compliantly and effectively
Proactively identifying your controller/processor relationships, and updating the terms under which these relationships operate, will be critical to processing personal data compliantly. No detailed guidance is offered by EU authorities on what particular steps to take in such relationships, yet a minimum set of controller/processor guarantees must nevertheless be agreed upon in terms of the General Data Protection Regulation (GDPR). In this article we explore how the controller and the processor can co-operate compliantly and effectively under the GDPR.
By Rodney Mhungu and Marloes Dankert
- Privacy email alert
- Exposure to privacy risks
- How to manage the relationship?
- More information?
Identifying your controller/processor relationships
Just because a vendor you are working with needs to process personal data in order to provide you or your customers with a service, it does not automatically make that vendor a processor. It is important to assess the specific context of your relationship with each vendor in order to determine this, because in the ever-complex world of business, governance, and computing, there is no one-size-fits-all relationship when it comes to data processing.
A controller decides on the means and purposes of processing personal data. If you assess the factual situation of a data processing relationship, not only the contractual terms, you can find a number of factors which indicate that an organisation is exercising controllership, including that the organisation
- determines which data are processed
- determines the purposes for processing such data
- decides how long (personal) data should be retained
- has complete control over data access, and
- decides whether data will be transferred to a third party or be transferred to a third country outside the European Economic Area
On the other hand, a processor processes personal data on behalf of the controller. One crucial indicator of this is that a processor’s core service is to process data on behalf of the controller. If the data processing is a mere result of other services provided, that is an indication that you are not dealing with a data processor. You may actually be dealing with a (joint) controller. For example, if one of your vendors is using your, say, web-shop performance data based on customer interaction to aggregate it against the vendor’s other customers, and provides you an analytics report on that basis, your vendor is processing “your data” for its own business analytics purposes. These business analytics reports may be useful to you, but your vendor would be a controller in this situation, not a processor. As a result, the vendor would need its own lawful basis/bases for processing your data, if it only relies on your lawful basis for processing, you may both be in jointly liable for infringing the GDPR.
Privacy email alert
Receive the latest Privacy insights.
Processors must process personal data on written instructions from the controller.
Exposure to privacy risks
For the GDPR’s provisions on processors to apply, the processor must process personal data on documented instructions from the controller. An overwhelmingly popular market trend to include processors under the umbrella of “third party” vendors in the vendor management process can lead to the misleading assumption that you can mitigate your GDPR risk with vendors by sending each (third party) vendor a data processing agreement geared towards establishing guarantees for a controller/processor relationship.
However, if you do not identify the relationship with your vendor correctly, you may end up exposing your organisation to privacy risks you did not take into account, such as
- privacy risks related to a joint controller relationship: if your vendor turns out to be a joint-controller, by deciding on (an aspect of) the means of processing personal data that you process together, that vendor may be subject to the same controller obligations as you are, which means your relationship is subject to a different set of (shared) risks and responsibilities than those in a controller/processor relationship.
- privacy risks related to a controller-to-controller relationship: if you are sharing personal data with a vendor after you have decided on the means and purposes of processing personal data, and that vendor determines how or why to process that personal data once you have shared it, perhaps you are transferring personal data to another controller. Firstly, you would need to have a lawful basis to transfer this data to your vendor. And secondly, this relationship of continuous data sharing may better be catered for in a data transfer or data sharing agreement rather than a data processing agreement.
Presuming you have correctly identified your vendor as a processor, how do you manage that relationship?
How to manage the controller/processor relationship?
Processors may be better equipped than their controllers to have expertise and technology to maintain state of the art security measures, recall information necessary to respond to data subject rights, and provide effective methods for identifying or categorizing high risk data processing. In this respect, the GDPR requires processors to help controllers deliver on their data-intensive compliance obligations.
Nonetheless, as a controller you still need to have complete control over what personal data your processor processes (i.e. what it gathers, stores, manipulates, and transmits) on your behalf. This control essentially means directing what your processors do, and why.
Your processor may have more sophisticated data processing capabilities than you do, and perhaps that is why you hired the firm in the first place, but you will not be able to manage your risk effectively if you ask your processor to process personal data in ways your organisation is not yet equipped to absorb, utilize or understand. For instance, machine learning can bring about tremendous efficiencies, but computers learn best from high quality datasets supported by value-driven analytics and clear business processes to support those analytical insights; if you are still working on the quality of your data sets, learning how to derive value from your analytics, or you are working on business processes to absorb this value, you should not yet be asking your processors to deliver machine learning capabilities to your organisation.
Asking for machine learning when your organisation is not yet mature in analytics may lead to data processing for purposes you did not request or even foresee. Asks such as these, if important for the goals of your organisation, may be better suited for business venture partnerships in the form of joint-controller or controller-to-controller relationships.
Provided you do indeed have control over the data processed by your processor, three key practices should be initiated, developed and updated regularly for you to manage your controller/processor relationship compliantly:
- ensure all your instructions for the processor are documented in writing;
- vet your processors for GDPR compliance and the use of sub-processors to process personal data on your behalf; and,
- in collaboration with your processor, design privacy-enhancing techniques and operations for all your processing operations.
First of all, as a controller, make sure that you have correctly identified the processors in your organization as compared to other types of vendors. Secondly, stay in control of how your personal data is processed by each processor; no matter how technologically capable your processor is, you can only maintain this control if you can effectively absorb the value and mitigate the risks of the data processing. And thirdly, continuously manage your relationship with your processors, in order to work together towards a risk-based and effective approach toward protecting personal data.
For more information about GDPR, please contact Annika Sponselee or Nicole Vreeman via the contact details below.