Home > Topic > IP-IT law > Don’t just sign a processor’s agreement, in particular if you are not actually a processor
Don’t just sign a processor’s agreement, in particular if you are not actually a processor

Don’t just sign a processor’s agreement, in particular if you are not actually a processor

More and more organisations require suppliers and partners with whom personal data is exchanged to enter into a processor’s agreement. Regularly, signing the processor’s agreement is even (more or less) forced upon them. Often it is insufficiently considered whether it is actually required that a processor’s agreement is signed. It can have nasty consequences. In this blog I set out why.

The processor’s agreement

If the processing of personal data is outsourced to a processor, the law then makes it compulsory to enter into a written agreement with this processor (section 14 Personal Data Protection Act – Wet bescherming persoonsgegevens, Wbp).

For example: the outsourcing of administrative work to an administrative office, the outsourcing of IT services to an IT provider, or the outsourcing of mailings to a marketing firm.

Characteristic of a processor: not for own purposes

The essence of a processor’s agreement is that the data may only be processed on instruction of the controller and not for own purposes. It concerns outsourced/delegated processing activities (which a controller could also have carried out him/herself).

Characteristic of a controller: must be for own purposes

This is the clearest difference between (the role of) the processor and (the role of) the controller. The controller does actually process the data for his or her own purposes.

In other words, the controller has its own client relationship with the data subject, whilst the processor does not.

Comparison between processor – controller

Represented in table form this leads to the following comparison, being it with some gaps.

controller processor
purposes processes for own purposes processes for purposes of client
‘ownership’ processes ‘own’ data processes ‘another party’s’ data
 new initiatives may process data for new purposes may only process data for existing purposes
client relationship has a client relationship with data subject does not have a client relationship with data subject
liability is fully liable for compliance with privacy law is only liable for processing acts

Practice is, however, less straightforward than this simple table suggests. For illustration purposes I refer to the opinion of the clause 29 working group from 2010 on the terms ‘controller’ and ‘processor’

Not every third party is a processor

In practice, we see that parties think that a processor’s agreement must be entered into with any third party with whom personal data is exchanged. This is not the case. This is only the case insofar as the relevant third party qualifies (partly) as processor.

On the exchange with the controller, totally different questions arise

Totally different questions arise on the exchange of personal data with a party who qualifies as controller. Such an exchange qualifies as ‘processing’, which (therefore) must comply with all requirements of the law.

For example: passing on personnel data to a pension fund, passing on data to the leasing company, passing on a file to a next handler, etc.

There will therefore have to be a basis for the processing, the processing must be in accordance with the purpose limitation principle, the processing must be properly secured and transparency must be guaranteed. For details, see our free online tool ‘the privacy check’.

The various issues in a table

In essence, the various issues come down to this (roughly summarised).

Exchange with a controller Exchange with a processor
  • check basis;
  • check purpose limitation;
  • check accuracy/relevant information;
  • observe transparency (agree whether the sender or recipient is transparent);
  • in the event of international situations outside EEA: check export ban.
  • check quality of processor;
  • enter into processor’s agreement;
  • supervision of processor;
  • in the event of international situations outside EEA: check export ban.

A controller who enters into a processor’s agreement holds him/herself hostage

A party who qualifies as a controller, but nevertheless enters into a processor’s agreement (under pressure from the other party) holds him/herself hostage. After all, in the processor’s agreement he/she declares not to use the data for his/her own purposes, whilst it is the essence of the role of the controller that he/she actually uses the data for his/her own purposes.

A controller who enters into a processor’s agreement therefore enters into an agreement he/she knows he/she won’t or is unable to comply with. This may lead to the termination of the processor’s agreement and so, due to conjunction, probably also termination of the main agreement. In this way, in theory in any event, the signing of the wrong privacy-law contract may lead to loss of contracts. A very unwelcome consequence. Of course practice must show whether it actually comes to this as – as far as I am aware – there is no case law on this yet.

If there is a breach of contract, there will in principle also be a claim for compensation. If it then turns out that the relevant party does not offer recourse, this could even lead to directors’ liability. The question in all this, however, is what loss has been suffered exactly (this is somewhat beyond the scope of this blog).

Fear of penalties and claims

The inclination to enter into a processor’s agreements with everybody appears to result from fear of penalties from the Dutch Data Protection Authority and claims by data subjects, in the event of data breaches, for example.

In the exchange with a controller, this fear is mostly unjustified. Both the providing and the receiving controller are after all themselves – what’s in a name – responsible for compliance with privacy legislation. Should there be a data breach at the receiving controller, then that party is responsible for the data breach.

A data breach could at most lead to a derived liability for the providing controller for inadequately guaranteeing careful processing of personal data. This is not unthinkable, but you would quickly come up against questions on the causal relationship (and the feasibility in practice).

It is of course the case that the providing controller could be held liable for the provision of personal data as such. If this exchange of personal data was not lawful, this may lead to penalties or claims. However, this is not solved by entering into a processor’s agreement. This is solved by ensuring that the actual exchange is lawful (or is omitted).

In summary

In other words:

  • don’t sign a processor’s agreement if you are not a processor;
  • do not impose processor’s agreements on parties who are not a processor;
  • check the content of the processor’s agreement before signing it;
  • are you the sending party? Then think about the capacity of the receiving party in advance and take appropriate measures (see diagram above);
  • are your the receiving party? Then before doing anything with the data, check in advance whether the correct measures have been taken (see diagram above);
  • in all of this, be aware of the fact that one party can have both capacities (controller and processor) at the same time (for different parts of the processing process).

If you have any questions about privacy law, please do not hesitate to contact us.

By Mark Jansen

Share and Enjoy:
  • Print
  • del.icio.us
  • Facebook
  • Twitter
  • email
  • Google Plus
  • LinkedIn
  • PDF

Scroll To Top