Many global service providers and their customers rely on binding corporate rules for processors to transfer European Economic Area customer data to processors outside the EEA. There are strong indicators that the European Data Protection Board is about to restrict the application of BCRs for processors to internal transfers within the processor group of companies. This would mean that BCRs for processors 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 BCRs for processors data transfer practices.
For years, the market has relied on BCRs for processors for direct controller-to-processor transfers, in accordance with the BCRs-for-processors guidance of the EDPB and its predecessor the Article 29 Working Party. 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, non-EEA processors with BBCRs for processors will have to enter into standard contractual clauses with each of their EEA customers. This creates the exact situation that BCRs for processors were intended to resolve in the first place. We note that both the current and the new SCCs can only be used 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 BCRs for processors to cover intra-group processor transfers and thus the whole purpose of having BCRs for processors will be vitiated.
Restricting BCRs for processors would be a departure from the current guidance, which does not limit BCRs for processors to internal transfers within the processor group of companies. In fact, BCRs for processors 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 BCRs-for-processors guidance, the main reason to introduce BCRs for processors was to avoid processors having to enter into SCCs with each controller:
[quote]“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).” (See WP29 Press Release, page 1)[/quote]
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 via 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 BCRs for processors 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 BCRs for processors in the first place. We refer to the Explanatory Document on BCRs for processors dated from 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.)”:
[quote]"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)[/quote]
Entities with BCRs for processors have ensured that they provide for adequate protection of EEA personal data throughout their entire organization, to prevent having to track the individual data flows. BCRs for processors covers transfers of customer data governed by the EU General Data Protection Regulation, 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 the GDPR and therefore subject to GDPR transfer rules. That is the whole point of BCR-P: to facilitate the transfer to the group that has promised to protect the data no matter where it is processed.
BCRs-for-processors 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 and an application form for submitting BCRs for processors. In 2013, the WP29 issued an Explanatory Document on the BCRs for processors, which described the scope and intention of BCRs for processors. This document cannot be more clear in its intention that BCRs for processors should be relied upon by the relevant controller for its transfers to a processor:
[quote]“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 (Article 26.2 of EU Directive 95/46) allowing the latter to comply with applicable EU data protection law.” (See Explanatory Document, page 6)[/quote]
When the GDPR came into force, the BCRs-for-processors referential was updated. This document again confirmed that BCRs for processors are applicable to transfers between controllers and processors; this was in contrast to BCRs for controllers, which only apply to internal transfers within the controller group of companies:
[quote]"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 ... 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." (BCR-P referential, page 2)[/quote]
As BCRs for processors provides safeguards towards the controller, the BCRs-for-processors referential, the application form, as well as the explanatory document each specify that BCRs for processors must be made binding towards the controller via a service agreement (see also quote above).
The relevant clause of the service agreement needs to be submitted as part of the BCRs-for-processors authorization procedure, and is reviewed and authorized as part thereof. The BCRs-for-processors 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 the 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 Article 3(1) GDPR).
Restricting BCRs for processors 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 by their EU entities. Alternatively, they could enter into SCCs with their EEA customers and make their BCRs for processors obsolete.
Both options would have tremendous practical and cost implications and add 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 BCRs for processors. This is exactly what the EDPB aimed for when drafting the BCRs-for-processors requirements. Under BCRs for processors, the “EU headquarters with delegated data protection responsibilities” is directly liable both to 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 BBCRs for processors. After more than 10 years of investments by global processors that obtained BCRs-for-processors authorizations and implemented them within their organizations, and with so many of their customers subsequently relying on BCRs for processors 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.
Photo by Markus Spiske on Unsplash
