European Commission publishes model processing agreements: should I use them?

Author info

On 4 June 2021, the European Commission announced two new sets of standard contractual clauses. One set is intended to be concluded between data controllers and processors where there is no transfer of personal data outside the EEA. The other set is intended for situations in which there is in fact a transfer of data to third countries (outside the EEA).

This blog is about the second set of standard (or model) contractual clauses, I.e. the set intended for situations where there is no transfer of personal data to third countries. In such a relationship between an EU controller and an EU processor, the current approach is for the parties to draft their own specific data processing agreement in compliance with Article 28 GDPR, but is it a good idea to replace such data processing agreements with the model of the European Commission?

What does the model say?

The European Commission's model - or “template” if you will - contains all the provisions required by the General Data Protection Regulation (GDPR), in particular Article 28.

The standard contractual clauses are, for the time being, only available in a limited number of languages.

Do I need to amend existing agreements?

You are not obliged to use the standard contractual clauses even if you conclude a new data processing agreement (e.g. with a new partner or service provider). Equally, it is not necessary to replace existing data processing agreements with the new standard contractual clauses.

Is it advisable to use the model?

For new contracts, it may seem logical to use the model provided by an official source such as the European Commission. Because the model meets the basic requirements of Article 28 GDPR, you should be completely covered, right?

The answer to this question is, perhaps unsurprisingly: it depends.

There are some important considerations to be reviewed before using these standard contractual clauses. They are presented below.

Think about your position

It is important to consider your specific position under the GDPR when drafting or negotiating a data processing agreement.  Whether you are acting as a data controller or processor can make a big difference.

Based on your position, it may be very useful to include or exclude certain clauses in your processing agreement, to adapt the language of certain provisions, or to change the scope of certain obligations to safeguard your interests as a controller or processor. Despite the fact that Article 28 GDPR defines a lot of mandatory content, it still leaves room for contractual freedom of the parties. Using a model of standard provisions does not allow you to (fully) utilise this possibility.

In addition, you also need to be sure that the relationship you are in, is one of controller and processor. After all, the qualification of the contractual relationship under the GDPR is not always straightforward, so expert advice may be needed to avoid a wrong qualification, which can have serious ramifications down the line, since all GDPR compliance efforts will have been focused on the wrong set of obligations.

Think about your specific needs

The standard contractual clauses are a general model, which means that little account is taken of specific needs of the parties, and the detailed agreements they may want to make with each other.

Consider, for example, the following topics:

1. Audits at the processor

Although the processor must allow audits to be carried out, the standard contractual clauses do not specify when (e.g. day and time) audits may take place or who will bear the costs, how long in advance the controller must give notice to the processor, the maximum duration of the audit, and other modalities. These practical arrangements are nevertheless quite important, both for the controller and the processor:

  • as a data controller, clear agreements prevent discussion on organisation and costs and ensure that you have sufficient means to actually verify the processing situation at the processor’s premises; and
  • as a processor, you can avoid having your daily operations (severely) disrupted through overly intrusive or repetitive audits and avoid having to provide extensive assistance without renumeration.

2. Assistance by the processor

Article 28 GDPR requires the data processing agreement to include that the processor must assist the controller in:

  • dealing with requests from data subjects;
  • data protection impact assessments (DPIA) and prior consultations;
  • the notification of data breaches;
  • taking technical and organisational measures for data security.

Here too, the model lacks options for specifying the practical modalities of such assistance (with the exception of the obligation to assist in notification of data breaches), which is, however, strongly recommended.

Depending on the role of your organisation, the interests will be different, so it is best to negotiate this and include it in the final agreement. The use of a general model that leaves the practical modalities of these assistance obligations in the middle may lead to discussion when assistance is requested (response times, respective responsibilities, etc.), or afterwards (e.g. about the costs and remuneration for work hours).

3. Appointment of sub-processors

Under Article 28 GDPR a processor can only engage sub-processors with prior authorization of the controller. Such authorization can be specific or general. In case of general authorization, the controller has to be given the opportunity to object to such changes. The model indeed provides this option, but does not regulate the consequence of an objection to a new sub-processor by the controller.

Contractually determining the specific consequences of an objection, is however a good idea, because in practice there are several possibilities, such as:

  • Not using the sub-processor for the objecting controller;
  • Using the sub-processor, but giving the controller the possibility to opt-out of the contract;
  • Not using the sub-processor for the objecting controller until a satisfactory solution has been found;
  • Etc.

Determining this in advance is important. For a controller for example, it may be impossible to find a suitable replacement processor if the controller objects to the use of a sub-processor and the only option given is to opt out of the main service contract with the processor. For a processor, while they may want to facilitate the wish of an objecting controller to not use an intended sub-processor for the processing done on behalf of that controller, this may not be technically or economically feasible. Hence, determining this in advance in clear contractual terms, matching the needs of the parties and particularities of the situation, will help prevent discussion and conflict afterwards.

Pay attention to filling in the model

If you have determined that despite the above considerations, the use of the standard contractual clauses is appropriate in your specific situation, bear in mind that their correct and effective use also depends on how the model is filled out. Although it is a model, there are several things that you have to elaborate on, notably including:

  • the scope of processing annexed to the standard contractual clauses; and
  • clarifying the security measures to be taken by the processor.

Defining the scope of the data processing agreement and determining the necessary security measure is very important, and must be done correctly, but the model provides little or no guidance in this regard.


For the above reasons, in many cases it is better not to limit yourself to using the standard contractual clauses, but to make specific arrangements with the other party. This is almost certainly the case if as a controller, you engage in large-scale processing of (sensitive) personal data or, as a processor, processing personal data is your main professional activity.

If the processing activity is simple, it may be sufficient to use the model, provided that you fill it out correctly and seek professional assistance if necessary. Also make sure that the relationship with the other party indeed qualifies as a controller-processor relationship, so that the standard contractual clauses can effectively apply.

Would you like more information on the correct use of the standard contractual clauses or would you like to have a specific processing agreement drawn up? Please contact us.