European Commission Adopts New Service Providers Standard Agreement (Controller-Processor SCCs)
The new standard agreement for service providers (which we’ll refer to as the Controller-Processor SCCs) adopted by the European Commission on June 4th was understandably a bit overshadowed by the release on the same date of the Standard Contractual Clauses for data transfers (see blog post here). But the new Controller-Processor SCCs, which organizations can use with their service providers to meet their GDPR Article 28 obligations, is another welcome addition to the EU’s small but growing library of standard documents.
If you are planning to use the new SCCs for data transfers, you will find that the Controller-Processor SCCs terms are already built in, so you don’t need to put the separate Controller-Processor SCCs in place. However, if you are dealing with a services agreement that doesn’t involve a transfer of personal data out of the EEA (or you are relying on a different lawful basis of the transfer) the Controller-Processor SCCs may be just the ticket.
Understanding the GDPR terminology
In most situations, we can simply think about the new SCCs as a form contract between an organization (the controller) and its service provider (the processor). In GDPR terminology, “controllers” are entities that are responsible for making decisions about how a certain set of personal data will be processed (in the words of the GDPR, a controller “determines the purposes and means of the processing”). “Processors” are entities that process personal data on behalf of the controller. “Processing” means doing anything at all with personal data, from initial collection to its eventual deletion and everything in between. In practice, processors can make minor decisions about the technical aspects of working with a given set of personal data without being considered controllers of the personal data. The key question is whether one entity (the processor) is processing personal data on behalf of the other entity (the controller), as opposed to processing the data on its own behalf. Of course, sometimes real-life business arrangements are a bit more complicated, in which case we suggest consulting the European Data Protection Board’s guidelines on the concepts of controller and processor, or speaking with your privacy counsel.
What’s the purpose of the Controller-Processor SCCs?
Article 28 of the GDPR requires a controller to enter into a written contract with its processor that covers various items as specified in Art. 28. In essence, Art. 28 acts as a kind of contractual checklist. Most organizations that are subject to the GDPR will have dealt with a number of Art. 28-based contracts. Large service providers, such as cloud service providers and other technology solutions providers, generally have their own standard contracts that cover the Art. 28 requirements for European personal data. Many other companies have also developed their own in-house standard forms. It is fine to continue using those forms, assuming that they hit all of the Art. 28 requirements. But if you want absolute certainty that you have satisfied all of the Art. 28 requirements in a way that will satisfy the European data protection authorities, you may want to consider transitioning to the Commission-approved Controller-Processor SCCs. In effect, the Controller-Processors SCCs will benefit from a presumption that they meet the requirements of GDPR Art. 28. While they could be challenged in court, the complainant would face a high bar to its challenge.
Will using the Controller-Processor SCCs expand either party’s legal obligations beyond the GDPR’s requirements?
For the most part, the Controller-Processor SCCs stay pretty close to the wording of Article 28. In a few instances, the SCCs elaborate a bit, but ultimately in ways that are consistent with other parts of the GDPR. For example, clause 7.7(e) requires the processor to include a third-party beneficiary clause in its contracts with its sub-processors, such that “the controller shall have the right to terminate the sub-processor contract and to instruct the sub-processor to erase or return the personal data” in the event that the processor has become insolvent or otherwise ceased to exist. Including a third-party beneficiary clause is not an express requirement of Art. 28, but it makes sense in light of the obligations imposed on controllers by other parts of the GDPR. Similarly, clause 9, which requires that the processor assist the controller when the controller has experienced a personal data breach through its own processing might at first glance seem to go beyond the scope of Art. 28, but it makes sense in the context of hosted services where the controller is doing the actual data processing work but using a system provided by the processor (and, we can assume, the processor’s cooperation would be necessary for the controller to investigate and remedy the breach).
What are the practical benefits of using the Controller-Processor SCCs?
In many situations, the fact that the SCCs are not open to negotiation will be a time-saver. The SCCs must be used as-is, other than completing the annexes describing the data processing and security measures (clause 2(a)). Organizations can supplement the SCCs with additional terms, or add them to a larger contract, so long as the other terms don’t “directly or indirectly contradict the Clauses or detract from the fundamental rights or freedoms of data subjects” (clause 2(b)). The optional “docking clause” is another potential time-saver – additional controllers and processors can simply sign an addendum and join onto an existing set of the SCCs. That may be helpful for more complex, multi-party collaborations, or for use within corporate groups.
When can I start using the Controller-Processor SCCs?
Technically, on June 27, 2021, which is the date when the Commission’s decision takes legal effect (20 days after the June 7th publication in the Official Journal of the European Union). However, there’s really no reason to wait until then. The new Controller-Processor SCCs meet the GDPR Art. 28 requirements, so organizations can start putting them in place immediately simply on that basis.
If you have any questions or concerns, please contact the Mintz Privacy & Cybersecurity team or your usual Mintz contact.
