The controller (defendant) operates an online music streaming service; the plaintiff is a customer of this service. The case was triggered by a data breach in November 2022 at a former processor of the controller, involving customers’ personal information (including email addresses, full names, ages, etc.).

The contract between the controller and the processor ended several years before the data breach at the end of 2019. According to the data processing agreement, the controller could choose between deletion or return of the data after the end of the processing. However, the  controller never exercised this right. A few days before the termination of the agreement, the processor informed the controller by email that the data would be deleted the following day. Almost a year later, in December 2020, the processor sent another email to the controller announcing that the deletion was imminent. Nevertheless, it was not until early 2023 and after the data breach had been reported that the processor confirmed to the controller that (some kind of) deletion had been carried out.

The Higher Regional Court ruled that the defendant was in principle liable to the plaintiff for damages within the meaning of Article 82 of the GDPR, but that the plaintiff had not credibly demonstrated any emotional damage and therefore no compensation payments were awarded.

In its judgment, the court dealt extensively with the issue of a controller’s liability for the omissions of its processor. In particular, the court addressed the monitoring and auditing measures that a controller must exercise over its processor and how these measures must be designed.

In general, the court takes the view that:

• if a company selects an IT service provider that is known in the market as a leading and reliable provider, it can generally place trust in the provider’s expertise and reliability without the need for an on-site inspection, but

• increased  requirements apply if large amounts of data or particularly sensitive data is hosted.

In the opinion of the Higher Regional Court, in the specific case this meant that the data controller was obliged to:

• exercise its rights towards the processor with respect to the deletion of the data (the data processing agreement allowed the controller to choose between deletion and return of the data);
• in case of deletion, obtain a written confirmation (i.e. a meaningful document certifying the deletion) from the processor, as detailed in the data processing agreement(s);

• immediately request the provision of the deletion confirmation, if no such confirmation has been provided within the contractually agreed period; and

• if necessary, carry out an on-site inspection (e.g., if the deletion confirmation remains outstanding).

The court also clarified that mere announcements of the data processor to delete the data (in the future) are not an adequate substitute for the confirmation that the data has already been deleted.

Conclusion and practical recommendation:

Even if the controller in the specific case has escaped being ordered to pay damages, the court has nevertheless affirmed the company’s liability.

Controllers should therefore take this judgment as an opportunity to review the robustness of their monitoring and auditing measures with regard to processors. Necessary measures must not only be introduced but also sustained and documented in such a way that they are sufficient as evidence in front of courts and supervisory authorities.

1. supply chain mapping;
2. verifying compliance with flow-down obligations.

For many financial institutions, the emphasis on these obligations should not come as a surprise. However, there are some nuanced clarifications in the opinion which could have an impact on general vendor management in the financial services sector. We have summarised the key takeaways below.

Supply Chain Mapping

Controllers should always be able to identify the processing supply chain. This means knowing all processors, and their subprocessors, for all third-party engagements – and not just their identity. The EDPB’s opinion clarifies that controllers should know:

• the legal entity name, address and information for a contact person for each processor/subprocessor;
• the data processed by each processor/subprocessor and why; and
• the delimitation of roles where several subprocessors are engaged by the primary processor.

This may seem excessive. However, the practical benefit of knowing this information stems beyond Article 28 compliance. It is also required to discharge transparency obligations under Articles 13 and 14 and to respond to data subject requests (e.g. of access under Article 15 or erasure under Article 19).

How is this achieved in reality? Vendor engagement can be tedious. While many financial institutions have sophisticated vendor onboarding processes, data protection is often an afterthought, addressed after commercials are finalised.

So, what should you do as a data controller? Revisit your contracts to ensure your processors are obliged to provide the above information proactively. At a frequency and in the format you require.   

Verification of Compliance

Controllers should be able to verify and document the sufficiency of safeguards implemented by processors and subprocessors to comply with data laws. In other words, controllers must be able to evidence a processor’s compliance with key obligations e.g.:

• making sure personal data is secure; and
• ensuring data is transferred or accessed internationally in line with the requirements of Chapter V.

The nature of this verification and documentation will vary depending on the risk associated with the processing activity. A low-risk vendor, from a commercial business perspective, may provide a service involving high-risk data processing. In this case, verification might involve seeking a copy of the subprocessor contract to review it. For lower-risk processing, verification could be limited to confirming a subprocessor contract is in place.

The EDPB suggests controllers can rely on information received from their processor and build on it. For example, through diligence questionnaires, publicly available information, certifications, and audit reports.

Where the primary processor is also an exporter of personal data outside the EEA, the EDPB clarified that the obligation is on the exporting processor to ensure there is an appropriate transfer mechanism in place with the importing subprocessor and to ensure a transfer impact assessment has been carried out. The controller should verify the transfer impact assessment and make amends if necessary. Otherwise, controllers can rely on the exporting processor’s transfer impact assessment if deemed adequate. The verification required here will depend on whether it is an initial or onward transfer, and what lawful basis is used for the transfer. This does not impact the controller’s obligation to carry out transfer mapping where it engages primary processors themselves located outside the EEA.

In that regard, the EDPB clarified a subtle but often debated provision of Article 28. The opinion notes that the wording “unless required to do so by law or binding order of a governmental body”, is unlikely to be compliant where data is transferred outside the EEA. It is therefore highly recommended to include the wording:

“unless required to [process] by Union or Member State law to which the processor is subject.”

Either verbatim or in very similar terms. This is particularly relevant in the context of transfer mapping and impact assessments. Regulated entities should be vigilant for third-party contracts which appear to meet the obligations set out in Article 28(3) with respect to the processing data for purposes outside of the controller’s instructions, but are, as confirmed by the EDPB, actually non-compliant.

What steps should you take now then?

The opinion clarifies that controllers can rely on a sample selection of subprocessor contracts to verify downstream compliance and we suggest you do so.

But when?

Regulated entities, particularly in the financial services industry, are facing a swathe of regulations that impact vendor engagement. The Digital Operational Resilience Act and NIS 2 Directive (EU) (2022/2555) require financial institutions to maintain a register of all contractual arrangements with vendors and ensure third-party service providers comply with cybersecurity standards. Effectively, these are enhancements to existing processor requirements under the GDPR. The reality is, however, that many controllers are only now firming up supply chain management to cover key data protection and cyber risks.

We recommend controllers use the clarifications in the EDPB’s opinion to improve negotiations when separately looking at uplifts required by DORA which takes effect on 17 January 2025. The clock is ticking.

Please reach out to your usual DLA Piper contact if you would like to discuss further, including if you are struggling to map these requirements against other emerging laws i.e. DORA or NIS2. We can provide assistance with the data and cyber contractual commitments in your contracts.