Alongside finalized standard contractual clauses for transfers of personal data from the EU to third countries (“transfer SCCs” – see our alert for more information), the European Commission (EC) also issued on June 4, 2021, a finalized set of standard contractual clauses to serve as a model for data processing agreements between controllers and processors that are both located in the EU (“Art. 28 SCCs”) under Article 28 of the General Data Protection Regulation 2016/679 (GDPR). The Art. 28 SCCs are effective as of June 27, 2021.
What are the Art. 28 SCCs?
Under the GDPR, controllers and processors are required to enter into a contract or other binding legal agreement that contains a number of elements listed in Article 28 of the GDPR. Although these elements are rather prescriptive, the GDPR has not imposed a specific template. However, it does set out that the EC or EU supervisory authorities (SAs) may issue their own template of standard contractual clauses. A number of SAs have already done so[1]. Now, the EC has come out with its own version, the Art. 28 SCCs.
How are the Art. 28 SCCs different from the transfer SCCs?
The Art. 28 SCCs and transfer SCCs address different issues. The Art. 28 SCCs focus on ensuring that there is a data processing agreement between a controller and processor, where both parties are located in the EU. Also, the Art. 28 SCCs are optional, meaning that companies are not required to use them and can instead put in place their own Article 28 agreements.
In contrast, the transfer SCCs enable the transfer of personal data from an exporter located in the EU to an importer outside the EU. The transfer SCCs are not optional, in the sense that the parties cannot draft their own template transfer clauses. In addition, the parties will have to adapt their current agreements down the road (by December 27, 2022 at the latest) to incorporate the transfer SCCs, which is not the case for the Art. 28 SCCs. It is also important to remember that the transfer SCCs already incorporate the requirements of Article 28 of the GDPR. Therefore, the Art. 28 SCCs are only intended to be used where a cross-border transfer does not also take place alongside the processing, for which the transfer SCCs would otherwise be used.
Ultimately, the use of the terminology “standard contractual clauses” may be misleading as there is a risk of confusing these different sets of clauses. But, in short, you could say that the Art. 28 SCCs offer a standard for data processing agreements, while the transfer SCCs are the standard for transfer purposes.
So, why use them if the Art. 28 SCCs are optional?
The Art. 28 SCCs are certainly useful for companies that need an agreement off the shelf which they know will meet the conditions of Article 28 of the GDPR. That being said, a degree of customization is still needed. The Art. 28 SCCs contain four annexes to fill out, depending on the parties’ choices. In any case, even if companies choose to use their own template, the Art. 28 SCCs may help expedite negotiations, to the extent that the parties can reference or borrow language from the Art. 28 SCCs.
What do the Art. 28 SCCs contain?
The Art. 28 SCCs contain a number of noteworthy elements, including:
- Multi-party clauses: The Art. 28 SCCs can be entered into by multiple controllers and processors from the outset.
- Accession feature: The SCCs contain an optional docking clause making it possible for additional controllers and processors to enter into the Art. 28 SCCs post-conclusion of the Art. 28 SCCs.
- Security:
- Processors should notify the controller “without undue delay” if they become aware of a personal data breach. In its draft form, the Art. 28 SCCs had set a 48-hour deadline for the processor to notify the controller; however, the drafters have rolled back that change. The revised language now follows the GDPR (Art. 33.2). In addition, guidance from the European Data Protection Board indicates[2] that the controller’s 72-hour deadline to notify SAs only starts when the processor informs it of the data breach (and not when the processor discovers it). So imposing a strict 48-hour deadline may be putting unnecessary pressure on the processor, since the clock has not yet started ticking for the controller.
- The Art. 28 SCCs create specific obligations that depend on whether a data breach occurs concerning personal data processed by the controller as opposed to the processor. However, it is unclear how that provision will apply in practice – and in particular, whether data processed only by a controller, and not the processor, should be covered by the data processing agreement at all.
- Processor vetting and compliance:
- The controller may take into account relevant certifications by the processor in assessing that processor. This is relevant considering recent certifications by the Belgian and French SAs regarding cloud computing codes of conducts for example (e.g., Belgium and France).
- At the same time, the Art. 28 SCCs also contain some other rather onerous provisions, such as making audit results available upon request by an SA, without any further condition or qualifier.
- Appointment of sub-processors:
- Where the controller grants a general authorization for the processor to engage sub-processors, the Art. 28 SCCs have been revised from their draft form so that the processor does not have to maintain the list in Annex IV of the Art. 28 SCCs. This appears to mean that processors are free to use their own list (as agreed upon with the controller) and is therefore a more flexible approach. The Art. 28 SCCs indicate that the processor has to allow the controller “sufficient time” to be able to object to the engagement of sub-processors, but do not quantify how much time will be considered sufficient.
- The Art. 28 SCCs have introduced some flexibility in relation to down streaming obligations to sub-processors. Sub-processing agreements only have to impose “in substance” the same data protection obligations as the ones between the controller and processor. That is a more lenient provision than the one under Article 28 of the GDPR, which provides for “the same obligations”. In addition, processors are entitled to redact their agreement with the sub-processor before providing it to the controller to the extent necessary to protect business secrets or other confidential information.
- Processor obligations: There is an obligation in the Art. 28 SCCs for the processor to notify the controller if it becomes aware that personal data are inaccurate or have become outdated. This seems to go beyond the direct obligations imposed on processors under the GDPR.
- Termination:
- Processors must include a third-party beneficiary right for controllers in their agreements with sub-processors: If the processor factually disappears, ceases to exist in law or has become insolvent, the controller has the right to terminate the sub-processor contract and to instruct the sub-processor to delete or return personal data.
- The processor is entitled to terminate the contract if it informs the controller that an instruction breaches applicable law and the controller insists on the processor carrying out that instruction.
Finally, being “standard” clauses, the Art. 28 SCCs are intended to satisfy requirements of Article 28 of the GDPR without requiring any further contractual assessment from the companies using them. At the same time, this is only true to the extent that the Art. 28 SCCs are used in an unaltered format. Organizations are permitted to add provisions (e.g., according to applicable law and jurisdiction) or safeguards to the Art. 28 SCCs, provided that they do not contradict the provisions of the SCCs or detract from individuals’ rights. Making additional changes or alterations will cause the Art. 28 SCCs to be an “ad hoc” Article 28 agreement, meaning that organizations are themselves responsible for ensuring that the agreement complies with Article 28 of the GDPR.
[1] See, e.g., Denmark, Slovenia and Lithuania at https://edpb.europa.eu/our-work-tools/our-documents/topic/standard-contract_en.
[2] Guidelines on Personal data breach notification under Regulation 2016/679, page 13.