20 November 2020
The European Data Protection Board (EDPB) has published an opinion that has significant implications for data processing agreements (DPAs). It's crucial for all businesses covered by the EU General Data Protection Regulation (GDPR) to note this updated guidance.
Any transfer of personal data from a controller to a processor must be covered by a DPA. A DPA is a legally-binding agreement between the parties designed to ensure GDPR compliance.
The EDPB's opinion recommends a lot of additional details and obligations. You may need to update your existing DPAs to meet the EDPB's recommendations.
This article will guide you through the new recommendations and provide some examples of existing DPAs that meet them.
The GDPR requires processors to only process personal data subject to a DPA. Failure to have a DPA in place when working with a processor is a very serious GDPR violation.
The DPA serves to ensure that the processor only processes personal data for a specific purpose. The DPA also allows the controller, and ultimately data subjects, to retain autonomy over the personal data after transferring it to the processor.
The GDPR's requirements are already extensive in this area. Article 28 of the GDPR states that DPAs must set out details of the scope and purpose of the data processing, specify how personal data will be protected, and impose legal obligations on both parties.
The EDPB is the EU's independent data protection body, comprising representatives from each EU country's Data Protection Authorities.
The GDPR allows Data Protection Authorities to submit standard clauses for inclusion in DPAs. The EDPB's Opinion 14/2019, published July 2019, comes in response to a submission by the Danish Data Protection Authority (known as the Datatilsynet).
The EDPB's opinion critiques the Datatilsynet's proposed standard DPA clauses, recommending changes to bring them more in-line with the requirements and spirit of the GDPR. The opinion is not legally binding. But it tells us what the EDPB considers to be a "good" DPA.
Applying the EDPB's recommendations would significantly increase the level of detail present in most DPAs and impose several additional obligations on processors.
However, a DPA is only valid insofar as it complies with EU law. Therefore, it's in your interests to ensure your DPA is in-line with the EDPB's standards.
Before we look at what the EPDB recommends for your DPA, let's recap the basic requirements under Article 28 of the GDPR.
Here are the main obligations that a DPA must impose on a processor, set out at Article 28 (3) of the GDPR:
The Article 28 (3) requirements oblige a processor to:
Article 28 (3) also states that the processor must immediately inform the controller if it is instructed to process the personal data in an unlawful manner.
There is a further requirement under Article 28 (4) that should be included in a DPA:
Article 28 (4) requires processors to only engage sub-processors under an agreement that imposes equivalent protections as the original DPA. If a processor fails to do this, it will be liable for any GDPR violations caused by the subprocessor.
In analyzing the Datatilsynet's standard DPA clauses, the EPDB's opinion provides some helpful insights about DPAs, including the following:
The EPDB makes the following recommendations about engaging sub-processors:
The EPDB makes the following recommendations about audits and inspections:
We're now going to work through the GDPR's DPA requirements, supplemented by some of the recommendations present in the EPDB's opinion. We've provided some examples of DPAs which meet the EPDB's recommendations.
Most of your DPA will concern the obligations of the processor. But the first part of Article 28 (3) specifies some additional information that your DPA must include regarding the processing itself.
The DPA must specify:
Here's how marketing and analytics company Voluum DSP describes the purposes of its processing in its DPA:
And here's an example from aBitrix24 that lists the categories of personal data processed, subject to its DPA (at page 10 of the PDF):
Your DPA must contain a clause requiring that the processor "processes the personal data only on documented instructions from the controller..."
Here's how Chattermill does this:
Your DPA should include a clause requiring the processor to ensure that anyone with access to the personal data undertakes a commitment to confidentiality.
Here's how SuperOffice does this:
SuperOffice goes beyond merely stating that employees are bound by a duty of confidentiality. It explains what employees agree to, and for how long they must adhere to it.
This complies with the EPDB's recommendation that the DPA both identifies and explains the Article 28 obligations.
Your DPA must require the processor to comply with Article 32 of the GDPR, which sets out the GDPR's security standards.
Again, you must do more than merely assert that the processor must comply with Article 32. You should explain what steps the processor will take to meet its security obligations.
Here's an example from HubSpot:
This excerpt from Hubspot's DPA lists some of the technical measures it takes to comply with Article 32, including network security and penetration testing.
The DPA must contain a clause requiring the processor only to engage sub-processors subject to the controller's authorization, under an agreement between the processor and its sub-processors that provides at least equivalent protection over the personal data.
The EDPB's updated guidance also recommends including a list of all sub-processors approved by the controller when signing the DPA.
Because the controller has the right to approve further subprocessor appointments, the EDPB also recommends that the DPA contains a requirement on the processor to provide advance notice of any new subprocessors.
Here's an example from TimeTac:
Note that in addition to listing the relevant sub-processors, TimeTac agrees to provide advance notice of the engagement of further sub-processors. The controller then has an opportunity to object to the appointment.
The EPDB also makes recommendations about the data processors/subprocessor agreements. For example, the EPDB recommends requiring processors to assign the controller as a third-party beneficiary in the event of the sub-processor's bankruptcy.
Here's how Players 1st does this:
The EDPB also recommends clarifying that the processor's liability for its sub-processors does not affect data subjects' rights to pursue a complaint or legal claim against the controller or the processor.
Your DPA must require the processor to assist the controller in facilitating data subject rights, such as the right to access or delete personal data in the processor's possession.
The EDPB's opinion builds on this requirement, recommending that the DPA describes how the processor will facilitate data subject rights and sets a timescale for the processor to notify the controller if they receive a data subject rights request.
Here's an example from Amiqus that implements some of the new guidance:
Note that Amiqus explains the processor's commitments in practical terms, and also references the relevant provision of the GDPR.
DPAs must oblige processors to notify controllers in the event of a data breach and assist controllers with carrying out data protection impact assessments (DPIAs).
The EDPB's guidance suggests some ways in which DPAs can add further detail to these requirements.
Here's a section from Headminer's DPA:
Rather than making a generic commitment for the processor to assist the controller with any necessary DPIAs, Headminer enumerates four steps that the processor will take to assist the controller with its DPIAs.
Note that Headminer's DPA also refers to the "rights and freedoms of the data subject." This also aligns with the EDPB's recommendations.
Regarding data breach notification, the EPDB recommends using the GDPR's wording: the processor should give notification on "becoming aware" of a data breach (rather than "discovering").
Here's an example from Firefish:
Firefish's DPA aligns with the EDPB's guidance in several ways:
Under Article 28 (3) (g), a DPA must require the processor to delete or return any personal data in its possession once the controller no longer engages its services.
Here's how HubSpot does this:
The controller can choose whether the processor deletes or returns the personal data in its possession. The EPDB recommends that the controller be permitted to change its preference even after the DPA is agreed upon.
The EPDB also recommends that the DPA contains an annex listing any national or EU laws that require personal data to be retained for a certain period:
"[Optional] The following EU or Member states law applicable to the processor requires storage of the personal data after the termination of the processing services: ................ The processor commits to exclusively process the data for the purposes provided by this law and under the strict applicable conditions."
The processor must submit to audits by the controller or an authorized third party.
The EDPB recommends that the DPA should specify that the controller must have access to the processor's premises and should be allowed to make recommendations in light of the results of the audit.
Here's an example from Gateway API (at page 28 of the PDF):
The EDPB's opinion sheds new light on the GDPR's DPA requirements. You must ensure your DPA meets the requirements under Article 28, and you should also implement the EDPB's recommendations as far as possible.
Your DPA should cover:
The processor's obligations, including:
Only engaging sub-processors subject to:
This article is not a substitute for professional legal advice. This article does not create an attorney-client relationship, nor is it a solicitation to offer legal advice.