Outbound Wiki

Article

Vendor due diligence obligations under the GDPR | DLA Piper

dlapiper.com

Open at publisher

Quoted on this wiki

Every place a page here uses this source, in the order the words come in it.

  1. 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 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.

    In Contact verification

  2. 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. 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).

    In Outbound data vendors

  3. 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.

    In Outbound data vendors

  4. 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. Q: How does the controller have to verify and document the sufficiency of the safeguards provided by (sub-)processors?

    In Outbound data vendors

  5. 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). 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?

    In Outbound data vendors

  6. 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).

    In Outbound data vendors

  7. 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. 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.

    In Third-country data transfers

  8. 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. 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

    In Third-country data transfers