GDPR roles: when to use a processor agreement and when it’s unnecessary

Not everyone who processes personal data is truly a processor. The GDPR distinguishes between two different roles: that of the controller (hereafter simply called “controller”) and that of the processor. Both process personal data, but the first decides for themselves what to do with the data, while the second processes the data solely on behalf of someone else. Only in this latter case might entering into a processing agreement be relevant.

Indeed: might! To qualify as a processor within the meaning of the GDPR, several additional conditions must also be met:

• It must not concern a party that already has its own legal authority to process the data in question. In that case, it is not the provider of the data who determines what the recipient does with it, but the legislator. An example is the processing of data by the Tax Authority or by a doctor. Both, by virtue of their role, have their own legally established responsibility and are themselves responsible for the personal data they process.
• The processing of personal data must be the primary purpose of engaging the processor. If the exchange of personal data is not the main purpose of the agreement, but only a by-product, then there is no processor, and both parties are independently responsible for their own data. For example, sending employee data to a training agency. The core of the agreement is to provide training; exchanging personal data is only a consequence of this.
• There must be no relationship of authority. The authority to give instructions is then already implied. Concluding a processing agreement with your own employees or hired staff is therefore nonsensical.

In all cases where personal data is shared with a third party, but the provider does not explicitly pull the strings (in GDPR terms: determines the “purpose and means”), there is no processor. And therefore, no processing agreement is needed.

A processor within the meaning of the GDPR is a party that processes personal data for which not they, but another party holds the role of controller. The defining feature is that the processing takes place entirely on behalf of the controller, according to strict, explicit agreements. If something goes wrong at the processor’s end, for example, in the event of a data breach, it is not the processor but the controller who is held accountable first.

A commonly cited example of a processor relationship is an external payroll administrator. The assignment here explicitly consists of processing data for which the client is responsible. Another good example is the service of cloud providers, where the service literally involves storing, i.e., processing, data. A third example is having mailings sent by an external communications agency. In all these cases, the client determines what happens with the processed data, there is no relationship of authority, and the processing of personal data is unmistakably the core of the service.

If personal data is shared but this is not the core of the agreement, the recipient of the data is responsible for it themselves and therefore not a processor. This means they decide for themselves what they use the data for and how they handle it, of course within legal and contractual boundaries. Examples of this can be found everywhere: sharing payment details with a bank, sending employee data to a pension fund, or passing on insurance details from a broker to an insurer. In all these cases, there is no processor involved. A data processing agreement is therefore not needed.

A variation on the situation where each party is responsible for its own data is when parties are jointly responsible for one processing activity. An example is a shared database, which is fed by several organizations and where the application is determined jointly. In these cases, an internal arrangement must set out the agreements made regarding the rights and obligations under the GDPR.

The only way to determine with which parties a data processing agreement actually needs to be concluded is to go through the entire list of relationships and suppliers. And in case of doubt, make explicit agreements with each other about GDPR roles. The result, at the very least, is that you become fully aware again of which data you are sharing with others—while also asking yourself whether this sharing is truly justified. Experience shows that for most organizations, ultimately only a small portion of their relationships can genuinely be considered processors.

The advice, therefore, is to limit sending processing agreements to those relationships that you are certain meet the criteria. If you are not yourself active as an external administration office, a cloud service provider, or in another clearly defined “processor business,” then the number of processing agreements you should receive should also be limited—or at least the number you actually need to sign.

Need help explaining the above to your business partners? Or struggling with other pressing GDPR questions? Feel free to contact Dorus-Jan ten Boom.