When it comes to GDPR compliance, contracts are some of the most powerful tools you have to show to regulators. They allow you to receive legal guarantees from your service providers and third parties that protect you from liability in the event of a breach in compliance. You aren’t off the hook for everything, but at the very least you won’t be liable for negligence.
When we talk about processing personal data, the contract you’re going to be most concerned with is the data processing agreement, or DPA. There’s some confusion as to where the chain ends when it comes to processing contracts. For instance, if you hire a company to process data, and they contract another company to help, do you need an additional DPA? Before we get into the specifics, lets look at what a data processing agreement is and who needs one.
What is a data processing agreement?
The GDPR, in Article 28 Section 3, goes into what it expects with regard to how processors handle data. It states that:
“Processing by a processor shall be governed by a contract or other legal act under Union or Member State law, that is binding on the processor with regard to the controller and that sets out the subject-matter and duration of the processing, the nature and purpose of the processing, the type of personal data and categories of data subjects and the obligations and rights of the controller.”
This means that if you are contracting a third party to process personal data, you need a contract that guarantees the protection of that data. Every company that is required to comply with GDPR is obliged to obtain DPAs from their data processors. There aren’t any exceptions here. Unless you’re processing everything in-house, you need DPAs from every processor.
DPAs will include the processing that is going to occur, what kinds of security measures are involved, and any details about how the data is handled—such as retention time. Some processors sign and provide a DPA to all of their customers by default, while others may require a conversation with their sales and legal teams before having both parties sign the DPA.
If you’re a controller
One confusing thing about DPAs is how they apply to subprocessors. Article 28, Section 4 references this:
“Where a processor engages another processor for carrying out specific processing activities on behalf of the controller, the same data protection obligations as set out in the contract or other legal act between the controller and the processor as referred to in paragraph 3 shall be imposed on that other processor by way of a contract or other legal act under Union or Member State law, in particular providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that the processing will meet the requirements of this Regulation.”
This means that technically the same rules apply. You as the controller need a legal guarantee from the subprocessors that they will act to protect the personal data. If they fail to uphold their guarantee, the processor will become liable.
So do you need a DPA from each processor’s subprocessors? Not exactly. In the majority of cases, including the example that provided by the European Commission, your data processing agreement with a processor will include a line stating that any subprocessors can only be used if required or authorized by the controller. Your processors will have agreements with subprocessors, and these agreements carry over to you as part of your contract with the processor.
How this manifests for each processor varies. Some will directly list their subprocessors in the DPA. Others may have a data processing addendum (also, confusingly, called a DPA), and others will include subprocessors in their privacy policy.
Let’s take an example of a fictional error logging service called Bugfunnel. You, the controller, use Bugfunnel to store, filter, and better manage any errors your application throws. Ideally you wouldn’t send any personal data to a logging service, but your use case requires it to help customers directly. Bugfunnel provides you with a DPA that describes how they handle the data you send, how long they store it, and so on. They may also make claims about their GDPR compliance, and provide a list of the subprocessors they use. That may be the extent of the contract you have with these subprocessors, as you only ever directly interface with Bugfunnel.
In instances where you have a direct sales contact with the third party—like our fictional Bugfunnel—you may be able to dictate how you’d like subprocessors to be included, and what the scenario for newly introduced subprocessors looks like.
If you’re a processor
On the processors end, it looks quite similar to the controller’s perspective. You will be providing a data processing agreement to the controller. You in turn need guarantees, such as your own data processing agreements, with each of your data subprocessors.
Not only that, but you’ll also need some system in place to notify, request authorization, and update any documentation when a new subprocessor is added. Your DPA with your customer likely includes a line like the following:
“Processor shall not appoint (or disclose any Company Personal Data to) any Subprocessor unless required or authorized by Controller.”
This means any time you add a new subprocessor, you’ll need to get authorization from your customers.
Building on our example from above, you are now Bugfunnel the data processor. You use a cloud storage platform to store the error logging data and a cloud search service to index and make the data easily searchable. You need to have contracts, DPIAs, with both of those services that meet the same standards you are promising to your customers. It is as if you are the controller, and these services are your processors. The difference is, you will list these two services in your list of subprocessors that you provide to your customers. This way they know who else is processing the data, and are assured that the data is safely—privately—processed.
So, should you have one?
Even in instances when regulation may not demand one, you should make DPAs a requirement as part of your data security policies. Data processing agreements are only valuable if you can ensure that every processor used by your organization has one. The best way to manage this is the same way you manage all personal data. In a catalog. Most records of processing activities (ROPA) include a section to link to any contract with the processor (or controller in the case of processors). You can go even further and incorporate the documenting of DPAs directly into your DevSecOps workflows and document them in your component inventory. A good data mapping and component inventory tool will allow you to attach DPAs directly to the components and data that they apply to, so you don’t need to worry about missing documents.
Whether this is a manual process that your data protection officer handles, or a more integrated process that fits into your product life cycle, ensuring full coverage of data processing agreements for every piece of personal data processed by third parties is an essential part of GDPR compliance and maintaining a good data protection foundation.
