Vendor due diligence obligations under the GDPR
Lessons learned from new EDPB guidanceThe European Data Protection Board (EDPB) recently published new guidance on controllers’ accountability obligations in their relationship with (sub-) processors and on specific provisions in data processing agreements. The guidance also highlights important obligations of processors under the GDPR.
We give you an overview of the most notable points:
Due diligence obligations
Q: Does a controller have to identify (sub-)sub -processors beyond the first line of sub-processors engaged by the processor?
Yes, the EDPB considers that controllers should have identity information for all processors, sub-processors "etc." readily available at all times. Having such information available is "necessary" for a controller to be able to comply with the GDPR.
Identity information should include the name, position and contact details of the (sub-) processor and a description of its task (if applicable, including the delimitation of the task compared to other sub-processors).
To enable the controller to comply, processors should proactively provide the required and up-to-date identity information of all relevant sub-processors to the controller. How this information is communicated can be specified in the data processing agreement.
Q: How does the controller have to verify and document the sufficiency of the safeguards provided by (sub-)processors?
For the initial processor, controllers must conduct a case-by-case analysis (to be reviewed at appropriate intervals), taking into account only the safeguards effectively demonstrated by the processor "to the satisfaction of the controller."
This "satisfaction" can be achieved by exchanging information (eg recognised international certifications (such as ISO 27000), external data protection audit reports privacy policy, terms of service, record of processing activities, policies).
The EDPB doesn't determine an exhaustive set of actions or information that the controller needs to undertake or obtain, but appropriate action may, depending on the circumstances, include sending questionnaires or document requests, relying on publicly available info, reviewing certifications or audit reports. The higher the risk, the more extensive the verification must be.
For sub-processors, the EDPB accepts that controllers (partly) rely on useful information provided by its processor, eg upon engagement of new sub-processors. Processors need to proactively provide all relevant information, including the locations, proof of implemented safeguards and a description of sub-processors' tasks. Controllers can't, however, hide behind their processor's information obligations. If relevant, controllers should ask for additional information and/or further verify the information received from processors.
Q: Should the controller verify whether its processor has imposed the same obligations in contracts with sub-processors?
Not systematically. It's important to remember that, in the EDPB's opinion, controllers have the right to ask processors to provide copies of the relevant sub-processing agreements. Controllers don't have an obligation to request by default the sub-processing agreements between its processors and their sub-processors (or further down the chain). But the need for a review must be determined on a case-by-case basis and the controller should have a process in place to check compliance by sampling verifications.
Data processing agreements
Q: Should the data processing agreement expressly include the exception provided for in Article 28(3)(a) “unless required to do so by Union or Member State law to which the processor is subject”?
No, it's not strictly required to include ad verbatim the GDPR's (or very similar) language, but the contract must include an obligation for a (sub-)processor to inform the controller when the processor is legally required to process personal data other than upon the controller’s instructions.
Q: Can the data processing agreement include an exception that's broader than the exception provided for in Article 28(3)(a)?
No. By means of background, some processor template agreements don't explicitly include the wording of article 28(3)(a) GDPR, but instead omit the reference to EEA or member state law (eg "unless required to do so by law or binding order of a governmental body”). This practice could be interpreted as an attempt to broaden the scope of the exception to the rule that personal data can only be processed upon the controller's documented instructions.
The EDPB is of the opinion that including a "broader" exception is part of the parties' contractual freedom and doesn't per se infringe the GDPR. Such an exception is, however, without prejudice to the GDPR's transfer restrictions and cannot be interpreted as an "instruction" of the controller to transfer personal data.
(Onward) Data transfers
Q: Which assessment must a controller conduct for (onward) transfers from a (sub-)processor to another (sub-)processor?
If a (sub-)processor acts as the data exporter, controllers are still responsible for ensuring compliance with GDPR transfer obligations, in addition to the data exporter. Controllers can individually be held liable for unlawful transfers even if they're not carried out directly between that controller and a processor.
The fact that an (onward) transfer takes place in the processing chain is considered to increase the risk and therefore the controller's due diligence duty.
According to the EDPB, where a (sub-)processor acts as a data exporter for (onward) transfers, the responsibilities of the data exporter and the controller are as follows:
Responsibility (sub-)processor acting as data exporter
What? The personal data transferred, the location and the purpose of the transfer to be provided to controller.
When? Before engaging the (sub-)processor.
Due diligence responsibility controller for transfers carried out by (sub-)processors
Step 1: Document receipt of relevant information.
Step 2: Review information received.
Step 3: If the information received raises further questions, controllers should conduct further checks.
Responsibility (sub-)processor acting as data exporter
What? Transfer mechanism to be confirmed to controller for initial and onward transfers.
When? Before initiating the transfer.
Due diligence responsibility controller for transfers carried out by (sub-)processors
Same Steps 1-3 as above. Controller to verify mechanisms for initial and onward transfers.
For adequacy decisions, verify whether decision is still in force and transfer falls within the scope.
For other transfer mechanisms, further checks and documentation required (see below).
Responsibility (sub-)processor acting as data exporter
What? For (onward) transfers that aren't based on an adequacy decision, data exporter to provide (i) transfer impact assessment (TIA) and (ii) and possible supplementary measures.
When? Before initiating the transfer.
Due diligence responsibility controller for transfers carried out by (sub-)processors
Same Steps 1-3 as above.
For (onward) transfers that aren't based on an adequacy decision, check whether:
- TIA and supplementary measures are in line with EDPB Recommendations 1/2020; and
- the data exporter has assessed impact of local laws on effectiveness transfer mechanism.
If the information received raises further questions, controllers should conduct further checks.
The new guidance shows that the EDPB is adopting a strict interpretation of the due diligence obligations of controllers. And processors are subject to heavy documentation obligations according to its interpretation of the GDPR. Many organisations will have to review their vendor management process.
We're happy to further discuss how your organisation can bring its vendor due diligence procedures in line with this new EDPB guidance.
