You searched for:
The Cookie Jar
International Transfers – BCRs for processors

An alternative to EU Model Clauses…

The Article 29 Working Party is developing the process for applying for approval of Binding Corporate Rules for data processors. In April 2013 it published an explanatory document (WP204) to accompany the previously released table of elements and principles (WP195) and application form (WP195a).

Binding Corporate Rules were initially developed for data controllers as a solution to the restrictions in the EU Data Protection Directive on transferring personal data out of the EEA. Designed for large multinational organisations, they provide a practical alternative to having to implement a web of EU Model Clauses for each processing operation. By having a set of legally binding rules in place which each company within the corporate group has signed up to, organisations who have had their BCRs approved by the EU data protection authorities are then deemed to have “adduced adequate safeguards” for personal data, allowing transfers to group companies outside the EEA. The application process involves a fairly substantial commitment of time and resources to achieve the required level of compliance.  However, controller BCRs have proved increasingly popular in recent years, with six multinationals gaining approval from the UK ICO in 2012.

The content of processor BCRs is broadly similar to that of controller BCRs: the BCRs must detail how the processor will comply with the data protection principles in the Directive and how this fits with its processing activities outside the EEA.  The application process is also similar, the Working Party having produced a standardised application form (WP195a) asking for information about the binding nature of the BCRs (internally and externally), training, co-operation with data protection authorities, audit etc.

Applicants for processor BCRs will also benefit from the same mutual recognition process which currently exists for controller BCRs, so that organisations can nominate one EEA data protection authority as the ‘lead authority’ to handle their application.

There is a significant degree of crossover between the EU Model Clauses for processors and the content of processor BCRs (fairly logically, since both are designed to create the same “safeguards”). Processors will be familiar with commitments to give data subjects rights where they cannot bring a claim against the data controller, giving controllers a right of audit, a commitment to co-operate with the data protection authorities, and flow down commitments to sub-processors.

However, the BCRs also contain a number of more prescriptive obligations which go significantly beyond the requirements of the Model Clauses: for example regarding the processor’s own audit systems, having in place a network of privacy officers, internal training, and requirements as regards the service agreement with the controller.

Why bother? The advantages for service providers…

The hope is that a service provider willing to take on these additional obligations would gain significant benefits from their BCRs. For example:

  • BCRs could use used as a significant selling point, marking the service provider out in a competitive marketplace as being firmly committed to information security and data protection.

 

  • Implementing the measures may also reduce the overall level of risk for the service provider, in terms of the security and oversight arrangements it has in place.
  • BCRs present significant advantages over the Model Clauses in terms of administrative simplicity. When relying on the Model Clauses, service providers are faced with the problematic requirement in the Model Clause FAQs that a separate sub-processing agreement be entered into for every controller, detailing the specific processing activities. Although various creative solutions have been put in place to manage this requirement, these may not always be 100% reliable. Happily, this does not appear to be something which has been carried across to the BCRs, and so they should allow service providers more flexibility in terms of sub-processing arrangements (although see the concerns we raise below regarding changing sub-processors).

 

  • Once the initial application process is complete, new companies can be brought into the BCRs (and old ones leave if sold off) without the need to enter into a new network of agreements.

The sticking points…

So far, so good.  However, there are a number of inclusions in the requirements for processor BCRs which are likely to raise some concerns for any service provider looking to submit an application.  The most likely ‘sticking points’ for processors are outlined below:

  • Burden of proof

 

As part of adopting BCRs, the processor must agree to accept the burden of proof in the event of an alleged breach of its data processing commitments.

As per the Working Party’s explanatory document (WP204), the BCRs must state that where a data subject or, more significantly, the controller, can demonstrate they have suffered damage and establish facts which show it is ‘likely’ that the damage occurred as a result of a breach of the BCRs, the service agreement or a sub-processing contract, it will be for the processor who has accepted responsibility for the BCRs to prove that neither the processor group member nor the sub-processor were responsible for the breach, or alternatively that the breach never took place.

The legal ramifications of this in a business-to-business service agreement are obviously very significant. Of particular concern must be the potential scope of this commitment. Litigation and allegations of breach (particularly in the context of large-scale outsourcings) will often allege a number of inter-related breaches, and it is likely that a breach of the BCRs would potentially be a breach of other contractual commitments. In which case, different standards of proof would apply to the same disputed facts.

Take, for example, a claim that a service provider failed to comply with a set of security conditions because a member of staff was negligent, and as a result some data was lost. This would be a breach of the BCRs, but would also likely breach a warranty that the work be carried out in accordance with all due skill and care. In respect of the BCRs, once the loss of data was established, the service provider would have to prove that the loss was not due to their breach; under the warranty claim, the customer would have to prove the breach under the usual standards for a civil claim (in England, the balance of probabilities).

Furthermore, the Working Party’s explanatory paper refers to a breach of the service agreement or written contract with sub-processors—in brackets, almost as an afterthought—but this inclusion, without any further detail, appears to widen the potential scope considerably. 

  • Co-operation with the controller

 

Another area where processors are required to make somewhat vague and potentially very wide commitments is as regards co-operation with the controller. The Working Party states in its table of elements and principles for processor BCRs that “processors and sub-processors will have a general duty to help and assist the controller to comply with the law”. Non-exhaustive examples given in the Working Party’s papers include executing necessary measures in respect of rectification, deletion and anonymisation of data, as well as assisting with complaints handling, and assisting with enquiries from data protection authorities. The explanatory document further states that this shall be done “in reasonable time and to the extent reasonably possible”.

It would be advisable for a service provider to include wording in the BCRs and/or its service agreements that this assistance will be provided at the cost of the controller. Nonetheless, it still creates a potential risk to a service provider of a controller seeking to rely on the BCRs to impose additional obligations on the service provider, not envisaged as part of the scope of work.

  • Controller’s right to object/terminate

 

There are two circumstances under the BCRs where the controller must be given the option to terminate the processing arrangement: if the sub-processor changes, or if the “processing conditions” change. This is potentially hugely significant—in particular for long term arrangements where the service provider may only begin to generate profits towards the back-end of the term. Furthermore, the Working Party unfortunately gives no guidance on how this termination right would work in practice (would it be a termination for breach? for convenience? could early termination charges apply?)

Sub-processing may only be conducted with the prior consent of the controller. As with the Model Clauses, the BCRs do allow for a ‘general’ prior consent to be given by the controller in the service agreement. However, the Working Party guidance states that if general consent is given, the controller should be informed of any addition or replacement of sub-processors (including those sub-processors within the group), in such a timely fashion that the controller is able to object to the change or terminate the contract, before the new arrangement is implemented.

First of all, this appears to go entirely contrary to the concept of a general prior consent—since specific consent must still be sought each time. In relation to standardised services (e.g. cloud offerings), it is also impractical—even more impractical than the requirement under the Model Clauses to send a copy of any executed sub-processing arrangement to the controller.

Any changes to the BCRs must be communicated to the data protection authorities and the controllers. Crucially, controllers must also be given the right to object and/or terminate the contract in the event to a change in the BCRs which affects the “processing conditions”. The only guidance from the Working Party on what would constitute a “processing condition” in this context is the example of the replacement of a sub-processor (not a particularly helpful example in view of the above). Furthermore, there is no requirement of materiality to trigger the termination right. A likely effect of this termination right may be that applicants for processor BCRs look to include information about ‘processing conditions’ at only a very high level in their BCRs—in order to preserve their business’s flexibility and avoid having to make subsequent amendments to the BCRs (thereby triggering the termination right).

  • Informing data subjects

 

Another potentially difficult requirement in the Working Party’s guidance is that the service agreement must contain a commitment by the controller that it will inform data subjects about the existence of processors outside the EEA and, importantly, the existence of the BCRs. This could become a very burdensome obligation for controllers who use many different processors—and although it is one which is notably placed on the controller, the processor must commit to as part of its application. This could also result in some tension here between the controller and the processor, were the controller to refuse to take on this obligation (which arguably goes beyond the standard notification requirements of a data controller), leaving the processor potentially in breach of its BCRs.

It is interesting to consider the practicalities of this obligation. For example, in the case of a service provider taking over a legacy system where the data has already been collected from a large number of data subjects (e.g. outsourcing or hosting for a bank), is it realistic to expect the controller to contact each of its customers to inform them about the BCRs? Will it be sufficient for the controller to make information available on its website? Since it seems doubtful that the vast majority of data subjects would have even heard of data transfer restrictions, much less BCRs, there would also presumably be a level of explanation required here.

Final thoughts…

Service providers who put in place processor BCRs may well be able to use these as an advantage in the marketplace—guaranteeing their customers compliance with EEA data transfer restrictions without the extra paperwork of the Model Clauses. Furthermore, the Model Clauses are viewed by many to be merely a ‘papering’ exercise. Service providers can make the argument to their customers that BCRs provide far more genuine safeguards by embedding the ‘gold standard’ protections (e.g. in terms of audit, data privacy officers etc.) into the service provider’s entire group structure.

The four points highlighted above (and there likely will be others) will, no doubt, present challenges to processors. However, a number of these arise from broad or unclear wording in the Working Party guidance, which could potentially be resolved as the application process develops. Certainly, there may be scope for individual data protection authorities to take a pragmatic view on these requirements.