Why the EDPB Should Not Torpedo BCR for Processors

Many global service providers (“processors”) and their customers (“controllers”) rely on Binding Corporate Rules for Processors (BCR-P) to transfer EEA customer data to processors outside the EEA. There are strong indicators that the European Data Protection Board (EDPB) is about to restrict the application of BCR-P to internal transfers within the processor group of companies. This would mean that BCR-P can no longer be used as a mechanism for transfers from an EEA customer directly to a processor outside the EEA. This would torpedo current BCR-P data transfer practices. For years, the market has relied on BCR-P for direct controller-to-processor transfers, in accordance with the BCR-P guidance of the EDPB and its predecessor, the Working Party 29 (WP29). If the EDPB adopts this kind of guidance, it would single-handedly invalidate a transfer mechanism relied upon in tens of thousands of service agreements covering EEA customer data.

If the EDPB were to make such restrictions to BCR-P, non-EEA processors with BCR-P will have to enter into Standard Contractual Clauses (SCCs) with each of their EEA customers. This creates the exact situation that the BCR-P were intended to resolve in the first place. We note that both the current and the new SCCs can only be used by and between an EEA data exporter and a non-EEA data importer. This means that, when a processor has such SCCs with its customers in place, there is no longer a need for BCR-P to cover intra-group processor transfers and thus the whole purpose of having BCR-P will be vitiated.

Restricting BCR-P would be a departure from the current BCR-P guidance, which does not limit the BCR-P to internal transfers within the processor group of companies. In fact, BCR-P are specifically intended to be relied upon by controllers for their data transfers to non-EEA processors. As aptly illustrated by the press release issued by the WP29 alongside the original BCR-P guidance, the main reason to introduce BCR-P was to avoid processors having to enter into SCCs with each controller:

Once a BCR for processors is approved it can be used by the controller and processor, thereby ensuring compliance with the EU data protection rules without having to negotiate the safeguards and conditions each and every time when a contract is entered into. (…) BCR for processors will be part of the guarantees brought by a controller to data protection authorities in order to demonstrate adequate protection (…) of their processors (for example subprocessors and data centers) (emphasis added). (See WP29 Press Release, page 1.)

What’s at stake?

When an EEA controller involves a non-EEA processor, it must comply with EEA data transfer rules. In many cases, the controllers transfer data directly from the EEA to the non-EEA processor, rather than first transferring the data to an EEA affiliate of the processor. This is because the EEA affiliates of, for example, U.S. service providers are often not involved in the actual delivery of the services, but rather provide only marketing and contracting services. In other words, there is often a split between the contracting entities and the service delivery entities performing the processing activities. Multinational customers often contract with service providers on a global basis. A U.S. headquartered controller may have a contract with the U.S. entity of the processor, which also covers the data processing for its EEA affiliates. This is a well-known and established practice, of which the EDPB and individual EU data protection authorities are well aware. The whole point is that once a processor has put BCR-P in place, a controller can share information with any member of the group of companies associated with the processor and not have to worry about the exact data flows.

It was precisely these global processing practices and the requirement for processors to enter into individual SCCs with each controller for the transfers that led to the request to facilitate BCR-P in the first place. We refer to the Explanatory Document on BCR-P adopted in 2013, in which the WP29 acknowledged that despite the SCCs having been updated three years before to allow for “the outsourcing of processing activities to sub-processors,” these updates were not sufficient “due to the increasing number and complexity of international data transfers (resulting from e.g. cloud computing, globalization, data centers, social networks, etc.)”:

While standard contractual clauses appear to be efficient to frame non-massive transfers made by a data exporter located in the EU to a data importer located outside the EU, the outsourcing industry has been constant in its request for a new legal instrument that would allow for a global approach to data protection in the outsourcing business and officially” recognize internal rules organizations may have implemented. (See Explanatory Document, page 5.)

Processors with BCR-P have ensured that their BCR-P provide for adequate protection of EEA personal data throughout their entire organization, to prevent having to track the individual data flows. The BCR-P cover transfers of customer data governed by GDPR, regardless of how the actual transfer takes place, i.e., by the EEA customer entity directly to the non-EEA processor or first to an EEA processor and then to a non-EEA processor, or even via a non-EEA customer entity. It is only relevant to determine whether the customer data was at some time governed by GDPR and therefore subject to the GDPR transfer rules. That is the whole point of the BCR-P—to facilitate the transfer to the group that has promised to protect the data no matter where it is processed.

BCR-P guidance in detail

In 2012, the WP29 adopted its first working document setting up a table with the elements and principles to be found in BCR-P (the “BCR-P referential”) and an application form for submitting
BCR-P (“Application Form”). In 2013, the WP29 issued its Explanatory Document on the BCR-P, which described the scope and intention of the BCR-P. This document cannot be more clear in its intention that the BCR-P should be relied upon by the relevant controller for its transfers to a processor:

BCR for Processors are meant to be a tool which would help frame international transfers of personal data that are originally processed by a Processor on behalf of an EU Controller and under its instructions, and that are sub-processed within the Processor’s organisation. Therefore, BCR for Processors shall be annexed to the Processor contract which is signed between the external Controller and the Processor.(…) BCR for Processors should be understood as adequate safeguards provided by the Processor to the Controller (Art. 26.2 of EU Directive 95/46) allowing the latter to comply with applicable EU data protection law. (See Explanatory Document, page 6.)

When GDPR came into force, the BCR-P referential was updated. This document again confirmed that the BCR-P are applicable to transfers between controllers and processors, this was in contrast to BCR for Controllers (BCR-C) that only apply to internal transfers within the controller group of companies:

It should be recalled that BCR-P apply to data received from a controller established in the EU which is not a member of the group and then processed by the group members as processors and/or sub processors;(…) whereas BCRs for Controllers (BCR-C) are suitable for framing transfers of personal data from controllers established in the EU to other controllers or to processors established outside the EU within the same group. (See BCR-P referential, page 2.)

As the BCR-P provides safeguards towards the controller, the BCR-P referential, the Application Form as well as the Explanatory Document each specify that the BCR-P must be made binding towards the controller via a service agreement. (See also the quote above.)

The relevant clause of the service agreement needs to be submitted as part of the BCR-P authorization procedure, and is reviewed and authorized as part thereof. The BCR-P guidance does not require that the services contract should be entered into by an EU entity of the controller or with the EU establishment of the processor. In all of the BCR-P guidance issued over the past decade, references to controllers and processors are always generic. And rightly so, as the long-arm reach of GDPR may well apply to controllers and processors that are not established in the EEA, and may also apply if the data are not processed within the EEA. (See art. 3(1) GDPR.) 

Restricting BCR-P has no benefits, only downsides

If the EDPB were to make these restrictions, this would leave processors and their customers with two options. Either, processors would restructure their actual transfers to fit the model of the EDPB, including redoing all of the service contracts with their EU entities. Alternatively, they could enter into SCCs with their EEA customers and make their BCR-P obsolete.

Both options would have tremendous practical and cost implications and add an administrative burden.  The GDPR was intended to be technologically neutral and lessen administrative burden and thus this move would be counter to that intention. At the risk of stating the obvious, the legal protection of customers and data subjects is equal under the SCCs and the BCR-P. This is exactly what the EDPB aimed for when drafting the BCR-P requirements. Under BCR-P, the “EU headquarters with delegated data protection responsibilities” is directly liable to both customers and data subjects, for any violations of the BCR-P by a non-EEA processor entity or third party sub-processor (as if it had committed the breach itself). After all, BCRs are widely acknowledged to be the most robust data transfer mechanism, as also stated by the WP29 itself:

while standard contractual clauses are usually signed without the need for any particular implementation, BCR is based on the organisation having a sufficiently satisfactory and robust data protection regime. (See BCR-P Explanatory Document, page 5.)

Conclusion

If the EDPB were to make a drastic change in course, it could undermine the legitimate expectations of the organizations and markets that rely on the EDPB’s consistent guidance on BCR-P. After more than 10 years of investments by global processors that obtained BCR-P authorizations and implemented them within their organizations, and with so many of their customers subsequently relying on BCR-P in thousands of service contracts, such a restriction would be nothing short of a violation of the principles of proper government. We call upon the EDPB to keep these significant considerations in mind before taking its final position on the matter.   

This op-ed was previously published by IAPP.