Data processors play a vital role in the digital economy. All organizations rely on data processors in one way or another: emails, cloud services, and electronic payments would be entirely impossible without them.

In this article, we will explain exactly what a data processor and a data processing agreement are and what a data processing agreement needs to cover.

1. What are controllers and processors?
2. What is a data processing agreement?
3. Why do you need a data processing agreement?
4. Once I sign a DPA, can I disclose the data?
5. Is my data disclosure GDPR compliant?
6. Am I exempt from liability after signing a DPA?
7. Conclusions

Let’s dive in!

What are controllers and processors?

“Data controller” and “data processor” are very important notions in the GDPR and privacy law. In fact, somewhat similar notions exist in many privacy laws other than the GDPR, such as The California Online Privacy Protection Act of 2003 (CalOPPA) and similar agreements

Under the GDPR, a controller decides what personal data are processed, how they are processed, and for what purpose. In other words, it calls the shots. On the other hand, a processor handles the data on behalf of the controller and under its instructions. It is also possible for a processor to process data on behalf of another processor, which is called a sub-processor.

For instance, most web analytics services only use visitor data to give their customers insights. In such a scenario, the customer is a controller because they decide which data to collect and analyze and for what purpose. On the other hand, the analytics provider is a processor. The analytics provider often relies on sub-processors for data storage, content delivery, and such.

This sounds simple enough, but it really isn’t. There is a fair bit of a gray area between controllership and processorship, which makes some scenarios tricky to classify.

To make things more complicated, joint controllership is also possible under the GDPR. Joint controllership occurs when two or more controllers process the same data while pursuing their own goals. Joint controllers agree on how some responsibilities will be shared but do not take instructions from one another.

Here’s an example. Say a corporation decides to rely on the services of an AI firm to help with market research based on personal data from customers. The AI firm uses the data for two distinct purposes: market research and training its AI model to further improve its performance. In this case, the two businesses are joint controllers, as they both play a role in the processing while pursuing their own goals.

Google Analytics is another example. Google’s role in providing the service depends on the settings chosen by the customer (that is, the owner of the website that uses Google Analytics). If the data sharing setting is disabled, Google acts as a data processor and only uses the data collected by Google Analytics to provide the customer with analytics.

On the other hand, if data sharing is enabled by the customer, Google also uses the data to improve other services in the Google ecosystem. In that case, Google decides what to do with the data and is a joint controller along with the customer.

Two more things need to be noted. First, the notions of controller and processor only make sense when referring to personal data. You cannot be a controller or processor of non-personal data because the GDPR does not apply to such data.

Second, controller and processor are substantive notions. In other words, they entirely depend on what you do with the data instead of what you call yourself in your DPA, terms of service, and such. If you act like a controller, courts will treat you like a controller regardless of what your legal paperwork says.

What is a data processing agreement?

The GDPR only allows reliance on a processor when a contract regulates certain aspects of data processing. This contract is called a data processing agreement or DPA (not to be confused with data protection authorities, which are also shortened to DPAs).

A valid DPA needs to include certain stipulations. The processor:

• must follow the controller’s instructions and may not process data for its own purposes
• must process the data in a secure way
• needs to ensure that all the staff involved in the processing are under an obligation of confidentiality
• when possible, must assist the controller in responding to requests under the GDPR (such as access or erasure requests)
• must erase or return personal data as soon as the service ends
• must help the controller with certain obligations under the GDPR, including notifying data breaches and carrying out data processing impact assessments (DPIAs)
• must be available for auditing from the controller.

A DPA is also needed when a processor engages a sub-processor. In this case, the processor needs written authorization from the controller, and the DPA with the sub-processor must preserve all the data protection obligations included in the original DPA with the controller. In other words, privacy protections cannot be diluted down the line.

That’s a lot to remember, but don’t worry: you probably won’t need to write any of this yourself. Companies acting as processors as a core part of their business typically have standard customer DPAs.

That being said, if you have a general idea of what should be in a DPA, you can skim through one and ensure everything is in place (and, of course, you can always check Article 28(3) GDPR to refresh your memory).

Why do you need a data processing agreement?

That’s all well and good, but why does the GDPR require a DPA?

Well, controllers have obligations under the GDPR. They must process data lawfully, fairly, and transparently, ensure security, respond to access requests, notify data breaches, and so on. All of these duties aim to ensure certain standards for data protection.

DPAs protect these standards when a data processor or sub-processor gets involved. They play an important role in privacy because the value chains of data processing can be quite long and complex.

In a nutshell, DPAs are not just annoying legal paperwork: they protect your data.

Additionally, a well-written DPA is helpful to the parties themselves because they can refer to it to know exactly how the data processing responsibilities are shared between them.

Once I sign a DPA, can I disclose the data?

Under the GDPR, all processing of personal data needs to respect certain rules. This also goes for disclosing personal data to a processor. So signing a DPA does not guarantee you can legally disclose the data.

For instance, you must have a legal basis for processing the data (we discussed the topic here), provide transparent information, ensure that you are relying on the right safeguards for any data transfers outside the EU, and respect the principle of data minimization (that is, only take the data you really need and handle it in the least invasive way possible).

These are only some of the criteria which, together, determine whether a disclosure of personal data is allowed under the GDPR. If you are the data controller, ensuring compliance is your responsibility. Signing a DPIA does not automatically mean that your disclosure of personal data checks all the boxes- you need to look at things from a broader perspective.

As we said, a valid DPIA is only one of many checkboxes. So what are the others?

A checklist would be of little use here. Most rules that apply to data disclosures are general rules that apply to any processing of personal data- whether that means collecting, storing, or even erasing them. That makes for a really long list because it’s nearly the entire GDPR we are talking about,

If you want to ensure the data disclosures to your processor is GDPR compliant, it is better to start from the basics instead. [Article 5 GDPR](https://gdprhub.eu/Article_5_GDPR#:~:text=Article%205(1)(d,have%20major%20effects%20on%20them.) lists all the core principles of the GDPR. The article is far more valuable than any compliance checklist we could develop because it offers a glimpse into the meaning of the GDPR.

With some understanding of the general principles, you can look at your data disclosure and start asking yourself the right questions. For instance:

• Do I really need to disclose the data to a processor?
• Am I only disclosing the data my processor really needs to do its job?
• Will my processor erase the data after a reasonable time?
• Do I know what makes the disclosure lawful? If someone asked me, would I be able to explain?

Don’t forget to also look at the disclosure from the perspective of the data subjects- that is, the people the data refer to. Your data subjects could be your customers, website visitors, or someone else who has no relationship with you at all-, for instance, the people whose personal data you are using to train an AI model.

(By the way, AIs raise very serious privacy issues. If you are training an AI model on personal data, please get privacy professionals involved from the design stage!)

Data subjects have a right to information. Did you take steps to inform the data subjects that your processor is involved? Did you provide this information in a clear and accessible way?

Data subjects can also exercise specific rights under the GDPR. For instance, they can require the controller to correct or erase their personal data or provide them access to it.

What happens if a data subject exercises one of these rights? Can you comply with the request independently, or does your processor need to get involved? Is your processor really able and willing to help you out with such requests, regardless of what your DPA says?

These are some of the questions you should ask yourself when you look at the issue from the data subject’s perspective. It is easy to focus on your organization's position and lose sight of the whole picture. But there are people behind the data, and you must put yourself in their shoes to comply with privacy law.

Am I exempt from liability after signing a DPA?

No. Signing a DPA does not make you exempt from liability. This is why relying on trusted and GDPR-compliant processors is crucial.

This does not mean that you will necessarily be held liable if something goes wrong. But under the GDPR, there is a sort of presumption that if something goes wrong privacy-wise, the controller is at fault. You can avoid liability by proving that you are not responsible for the incident, but the burden of proof is entirely on you, which is risky.

This is why large organizations thoroughly assess the compliance of their processors and document the assessment. This documented assessment is called a vendor risk assessment and serves two purposes. First, it allows the controller to ensure that the processor is reliable. Second, if something goes wrong, a well-written vendor risk assessment can help the controller prove that it did its compliance homework.

Most small businesses lack the resources and expertise to conduct vendor risk assessments. However, they can still benefit from researching their processors and ensuring they have a good reputation for compliance.

Conclusions

Privacy is not about ticking boxes off a compliance checklist. It’s about understanding the reasons behind the rules and caring about the people behind the data.

At Simple Analytics care about privacy. And unlike other companies, we really mean it. Privacy is the cornerstone of Simple Analytics rather than mere coat paint. We built our software to provide organizations with all the insights they need to optimize their websites and campaigns without using visitors' personal data. If this sounds good to you, feel free to give us a try!