On June 6, 2012, the Article 29 Working Party adopted its long awaited Working Document on elements and principles for Processor Binding Corporate Rules.
Article 29 Working Party, WP 195, http://ec.europa.eu/justice/data-protection/article-29/documentation/opinion-recommendation/files/2012/wp195_en.pdf
Processor BCR are a data protection code of conduct, which is to be implemented internally by a large internationally operating enterprise. They are intended to provide an adequate level of data protection within a company allowing data transfer to outside of the European Economic Area without further contracts or authentication. The longer established BCR for data controllers were not enabling globally operating data processors such as most Cloud Service Providers (CSP) to profit.
Processor BCR could prove to be a vital cloud enabler since they address one of the most crucial issues from a European point of view: the global data flow of borderless clouds. It allows big multinational CSPs to apply to EU customers without reserving only EU facilities for these customers or providing complex individual contracts for each customer. The implementation of Processor BCR within a globally operating commodity CSP could give this CSP a significant competitive advantage with regard to European customers. Using a CSP with authorised Processor BCR in place is as legally compliant as using a solely EU based cloud without complex additional contracts allowing the data transfer.
The Working Document sets up a table with requirements and principles for Processor BCR. Parallel to BCR for controllers the requirements include:
- How to ensure the binding nature of the Processor BCR internally and externall
- The effectiveness based on audits, oversight and training programmes
- Duties for cooperation with the controller and the competent DPAs
- A specification of the data processing and the material and geographic scope of the BCR
- An effective management of changes and updating of the BCR
- General data protection safeguards
In the following I will highlight some requirements for Processor BCR highly affecting CSPs that want to establish this code of conduct.
Public Availability
Contractually seen, Processor BCR would be part of the contract between the customer and the CSP implementing the BCR. A CSP is required to reference the BCR in his Service Level Agreements and publish them e.g. on his website. Therefore, some provisions of the BCR may unfold binding character for the customer as well, depending on how they’re phrased.
Liability
A key provision in the Processor BCR is the processor’s (including CSPs) acceptance of a liability for paying compensation for any damages resulting from the breach of BCR. Liable will be the main EU based member of the processor’s corporate group. This member would assume liability for any breach committed by another member of the group or a subprocessor. The liable member therefore has to prove that it has sufficient assets when applying for acceptance of its Processor BCR. In case that the corporation does not have an EU-based member, the corporations headquarter must assume liability.
Additionally, the processor has to grant third-party beneficiary rights to data subjects in the event the data controller factually disappears, ceases to exist in law or becomes insolvent, including judicial remedies and compensation for any breach of the data subject’s rights by the processor.
Commitment to cooperation
Processor BCR require the processor to commit to cooperation with the controller and European DPAs. This includes accepting audits by the competent DPA and reasonably assisting the controller in complying with data protection laws, including handling complaints and requests of the data subject and responses to DPA inquiries.
For a CSP with multiple customers in the EU this would mean to cooperate with several DPAs. It is therefore absolutely necessary to unify the European data protection framework and standardize the audit procedure.
Transparency on subcontractors
Outsourcing of data processing to subcontractors that are not part of the Processor BCR is limited. The cloud customer must give his prior consent to this onward transfer to external subcontractors. This can happen via a general consent to subcontracting given when the SLA is agreed upon. In this case the customer still needs to be informed about all subcontractors and all intended replacements or additions of sub processors. For any intended change the customer would have the chance to object or terminate the contract prior to the onward transfer of data. The involvement of subcontractors must only happen on basis of a written agreement between the CSP and the subcontractor that the level of protection mirrors the Processor BCR and SLAs of the CSP.
This requirement could prove to be a major drawback in the highly dynamic cloud market. The Processor BCR are clearly tailored to processors with small fluctuation among its subcontractors.
