8. Description of Measures to Ensure Compliance by Processors and/or Joint Controllers
Summary: Personal data needs to be protected while it is processed by third parties, like other controllers and processors. Step 8 describes whether there are third parties involved, and if so, the implemented technical and organizational measures that ensure personal data is still properly protected even when processing takes place outside the direct control of the controller.
The aim here is to describe how the processing activity will ensure that working with others from outside the UU, like external collaborators and/or service providers, still complies with data protection regulations.
The first step is determining whether the processing involves working with third parties. In general terms, if a project involves working closely with other people or organisations outside the UU, for example, external researchers or other external collaborators, then these are considered to be third parties. Likewise, if the processing requires engaging with external service providers (like translators) or with software or tooling that depends or rely on server-side processing (i.e., needs to connect to external servers), and these providers or tools are not listed as safe to use in the UU Tooladvisor, then these are considered to be third parties.
Conversely, if the processing does not involve third parties, it can be stated in Step 8 that “There are no external controllers nor processors involved in the processing“.
The next step, is determining whether these third parties are controllers or processors.
As previously mentioned, A controller is an entity who “determines the purposes and means of the processing of personal data”. When a UU member (researcher, student, employee, etc.) processes personal data, the University is legally the controller.
Therefore, a third party involved in the process would be a controller when they also determine (independently or jointly with the UU) the purposes and means of the processing. In other words, if it has an influence in the decision of what data to process or why it is processed (purposes), or how to process it (means).
Most research collaborators and stakeholders are considered controllers. Even a funding entity like NWO can be considered as a controller, because even if it is not directly involved in the actual processing of personal data (it does determine the means of the processing), it does have influence on the purposes of the project, as it approves and funds projects according to their selection criteria (it determines the purposes of the processing). Likewise, research partners and other similar stakeholders are almost always considered to be controllers – as long as they determine, jointly or independently, the why and how personal data is processed.
What to do in this case?
Even if a third party is considered to be a controller, it does not mean that they are equally involved in the project, nor share the same level of responsibility. Controllers have joint responsibility for the privacy and security of personal data, but joint responsibility does not necessarily imply equal responsibility. Because of that, controllers must arrange between themselves their respective responsibilities for complying with GDPR obligations – basically, the obligations listed in the privacy scan, like transparency obligations (Step 5, who will be responsible for ensuring data subjects are properly informed?) and individuals’ rights (Step 6, who will be responsible for engaging data subject to respond to their data rights requests?), etc.
One way to arrange this, is to draft a joint controllers agreement with all stakeholders. To facilitate this process, this template can be used to start the discussion on the content of such agreement, where the template contents should be further modified until it suits the specific needs of the project. Once drafted, this document serves as a documentation that all parties involved (controllers) are indeed working together to ensure the protection of personal data.
Another way, is to include the respective GDPR-related responsibilities in other documents, like the consortium agreement, data sharing agreements, etc. As the goal is to ensure everyone involved is aware and responsible for their respective obligations regarding the processing, this can be achieved by embedding relevant texts into already existing documentation.
Lastly, for some less complex cases, it may be the case that all involved parties are already aware of their respective responsibilities, and therefore having a written agreement would not be necessary. For example, that would be the case when the processing involves a research project where just a couple of external researchers are involved, and where everyone is already aware of who is responsible for what within the project.
In short, the goal is to ensure that all parties (joint or independent controllers) understand that they are all responsible for ensuring compliance with the GDPR, and that all parties understand their respective obligations and responsibilities (what needs to be done) to achieve that compliance. This understanding can be achieved through a written agreement – unless the understanding is already present, and thus a written agreement is not required.
A processor is, by definition, a natural or legal person, public authority, agency or another body, which processes personal data on behalf of the controller. Two basic conditions for qualifying as a processor exist: that it is a separate entity in relation to the controller (so, it is not part of, or under direct supervision or control by the UU, so a UU student/employee can’t be a processor) and that it only processes personal data on the controller’s behalf, according to the controller’s instructions – so it only processes data for the controller’s purposes, and not for its own purposes.
Of note, the controller’s instructions may still leave a certain degree of discretion about how to best serve the controller’s interests, for example, to allow the processor to choose the most suitable technical and organisational means to comply with the controller’s instructions.
Most service providers are considered processors. Transcription/translation services, survey panel companies, event organisation, etc. Most tools that require, one way or another, a connection to an external server (“cloud”) are also considered as processors (for example, software that require internet connectivity to work) because data that is in the cloud is considered to be processed by a third party, outside the control of the UU.
Sometimes, a tool can require cloud connectivity for some features. For example, the tool NVivo has desktop and cloud features, but only when using the cloud features would this tool (or rather, the owner of the tool, that controls the cloud server) be considered as a processor. If the tool use is restricted only to its desktop features, then it is not considered as a processor.
What to do in this case?
To make sure processors handle personal data correctly, a Data Processing Agreement (DPA, a legally binding agreement) must be arranged. For many of the tools listed in the UU tool advisor a DPA has been in place to ensure the tool can be used safely. The DPA covers arrangements regarding privacy, such as the conditions for data processing, the security measures taken and the division of responsibility and liability – the UU-specific instructions that the processor must comply with.
If a DPA has not already been agreed with the service or tool provider, then one must be drafted before any data processing can take place. The UU has a UU-specific DPA template that must be used. This template is rigid and can only be deviated from in special circumstances, and the Privacy Officer and/or UU Legal Affairs must be involved for advice, review and approval.
Previous: Description of Lawful Basis for Processing | Next: Description of Planned Transfers of Personal Data to Other Countries Outside the EU
- Description of the Project’s Purpose
- Description of Data Subjects
- Description of the Categories and Purposes of Personal Data
- Description of the Processing of Personal Data
- Description of Information Provided to Data Subjects
- Description of How Data Subjects Can Exercise Their Data Subject Rights
- Description of Lawful Basis for Processing
- Description of Measures to Ensure Compliance By Processors and/or Joint Controllers
- Description of Planned Transfers of Personal Data to Other Countries Outside the EU
- Obtaining, Consulting, and Dealing with Data Subjects’ Views of the Processing
- Preliminary Risk Assessment