Last month, on April 19, the Article 29 Working Party adopted an explanatory document that provides guidance on the use of Processor BCR for international transfers of data that are sub-processed within the Processor’s group.

Main Principles

Firstly, Article 29 WP emphasizes that Processor BCR do not replace or decrease the relevance of the agreement that should be signed between the Processor and the Controller.

The Processor BCR should be seen as an additional safeguard as far as international data transfers are concerned and be annexed to such agreement.

Within the Processor’s group, transparency and consent (more or less demanding as agreed with the Controller) should be the key, exempting the Processor to sign agreements with each sub-processor.

Outside the Processor’s group, Processor BCR should not apply and therefore the transfer should lay on a written agreement between the Processor and the external sub-processor in order to ensure that the later will comply with the same obligations and level of protection the Processor undertook towards the Controller.

Secondly, while Processor BCR should be approved or authorised, as applicable, on an EU level the Controller should independently seek authorisation for the international transfer to the Processor.

Thirdly, Processor BCR will be more reliable as (i) more effectively binding they are throughout the group and also outside whenever external sub-processors are involved and (ii) more enforceable from not only the data subject’s (third party) perspective but also from the controller and data protection Authorities’ perspectives without forgetting the mandatory requirements of national law applicable to each member of the Processor’s Group.

Finally, Processors must recall that a breach of the BCR by a member of the Processor’s group could mean the withdrawal of the authorisation given to the Controller to transfer personal data based on BCR for Processors.

But what should Processor BCR address and foresee?

According to Article 29WP, the EU rules as far as data protection is concerned should be included in an intelligible and comprehensive way so they can be enforced within the Processor’s Group and by all and each of them.

However, as Article 29WP stresses, if the description of the transfers in the BCR must be general within a specific transfer of a specific Controller a more detailed description is required to allow the Data Protection Authority (DPA) to evaluate if the level of protection required under the EU rules is adequate.

It goes on acknowledging that amendments to the BCR are needed but should be reported to (i) all group members (ii) the DPAs and (iii) the Controller.

Nevertheless, in case of changes that affect the processing conditions, the Controller should be informed with a reasonable prior notice to allow the Controller, in case of disagreement with such changes, to terminate the contract before those changes are effective.

What about updates?

Updates to the BCRunderstood in the sense that working procedures may change and the rules would need to be adapted to such changing environments – or to the list of members of the BCR for Processors do not need to be prior reported to the DPAs as long as:

  1. there is a person in charge of keeping the list updated with all the members of the group and the sub-processors involved and available to the Controller and the DPAs;
  2. such person follows and file any updates to the BCR, which should also be informed on a regular basis to the Controller and made available to the DPA ;
  3. new members shall only import/export data after being bound to the Processor BCR; and
  4. any substantial changes to the BCR and/or to the list of members are reported and explained on an yearly basis to the DPAs that have authorized the Controller’s transfer.

Specific Provisions

Finally, Article 29WP underlines the need of any BCR for Processor to include provisions able to deliver compliance and guarantee enforcement, such as:

  1. Compliance

Privacy policies must be made and included but, above all, the BCR should foresee provisions to ensure that (i) such policies are of all the Processor’s Group, sub-processors and their employees’ knowledge(ii) all of them have a precise understanding of the policies and their obligations and (iii) they are indeed implemented by all of the members.


  1. Audits

Data protection audits should be foreseen in a regular basis and reported to the Privacy Officer and to the board of the parent company. Such audits and its results must be made available to the Controller and its DPA, respectively, upon their request.

Audits to the data processing facilities of any processor and sub-processor should also be ensured to the Controller within its processing activities.


  1. Complaint handling

A contact point to receive any claims or requests from the data subject must be envisaged being all the members of the Processor BCR required to inform without delay the Controller of such claims or requests.


  1. Duty of co-operation with the Controller and DPA

All members of Processor BCR should:

  1. act on behalf and under the instructions of the Controller, undertaking the commitment to assist the later in a reasonable time and as much as possible on complying with the data protection law; and
  2. liaise closely with the DPAs being aware that failure to accomplish it could lead to the withdrawal of the authorisation given to the Controller to transfer personal data based on BCR for Processors.

In this respect, Article 29WP also highlights that “There must also be an unambiguous undertaking that the organisation as a whole and any of its members separately will abide by the advice of the competent Data Protection Authority on any issues related to the interpretation and application of these BCR for Processors”.

  1. Liability

The Processor BCR should foresee that third party beneficiary rights (data subjects) and the right of redress (Controller) should include judicial remedies and compensation for any damage.

In case the BCR are breached and in order to effectively entitle data subjects to enforce those rules against the Processor’s group members, an EU-based member should be appointed to accept liability, remedy any acts and breaches of any of its members and pay compensation for any damage as if it was itself and in the Member State it is based in.

The same applies to the Controller that also is entitled to pursue remedies against any external sub-processor at the origin of the breach.

Finally, the BCR should also provide for the burden of proof to be reversed, i.e., “it will be for the member of the group that has accepted liability to prove that the member of the organisation outside of EU or the external sub-processor was not responsible for this breach giving rise to those damages or that no such breach took place”.


  1. Jurisdiction

Data subjects (if incapable of claiming against the Controller) and the Controller should be entitled to bring legal action against the Processor’s organisation and to choose the jurisdiction.


  1. Transparency

Within the transparency principle the BCR for Processor should be (i) made easily available on the Processor’s organization website to all data subjects or at the best an explanatory document as far as all the third party beneficiary rights and (ii) included as an annex to the agreement signed with the Controller.

Steps (that still need) to be taken

Notwithstanding this guidance of the Article 29WP, there are still other steps to be taken as far as BCR are concerned, as I would like to recall that there are a few EU Countries – such as Portugal and Hungary – where DPAs do not accept BCR as a mean of legitimising transfer of data. In Portugal, the DPA is of the opinion that BCR are not enforceable in the Portuguese jurisdiction and therefore cannot give rise to obligations.