Understanding the Data Processing Agreement (DPA)

A Data Processing Agreement (DPA) is a contract that must be in place when using certain service providers under the EU or UK General Data Protection Regulation (GDPR).

A DPA must meet certain legal requirements, and is mandatory whenever a “controller” engages a “processor”. Failing to implement a DPA when required can cause serious legal issues for both parties.

This article will walk you through the key elements of a DPA, explore when a DPA is necessary, and provide some key tips for drafting a DPA that works for your business and its customers.

What is a Data Processing Agreement (DPA)?

Under the GDPR, a DPA is a contract requiring a “processor” to act under the instructions of a “controller”.

Many types of companies provide services under a DPA, including Cloud Services Providers (CSPs), network security providers, and marketing companies.

A DPA can be a standalone contract or incorporated into another contract, such as a Terms of Service (ToS) or Master Services Agreement (MSA). A DPA is sometimes called a “Data Processing Addendum”.

Controllers and processors

A DPA governs the relationship between a controller and a processor under the GDPR. We’ll consider these terms in more detail later in the article, but here’s a brief explanation of each:

A controller “determines the purposes and means of the processing of personal data”: It has a reason for processing personal data and decides how to do so.
A processor “processes personal data on behalf of the controller”: It provides services to the controller and only uses personal data for the controller’s purposes

Note: “Personal data” is a broad term under the GDPR, and includes any information relating to an identifiable individual. “Processing” personal data means collecting it, storing it, or otherwise using it in practically any way.

Most of the GDPR’s rules apply directly to controllers, who are chiefly responsible for the personal data they collect and use. A controller remains accountable for personal data even when a processor processes it on the controller’s behalf.

A DPA makes this principle “real”—if the processor violates the GDPR, the controller will normally remain legally responsible. However, the controller may be able to recover any damages caused by the processor by violating the DPA.

As well as being a core requirement under the GDPR, a DPA benefits both the controller and the processor:

The controller benefits by having a legally binding agreement restricting how the processor uses personal data on its behalf.
The processor benefits because it is not primarily liable for GDPR compliance as long as it obeys the controller’s instructions under the DPA (with some exceptions).

When Must an Organisation Use a Data Processing Agreement?

Under the GDPR, processors may only operate under a DPA. As such, a DPA is necessary whenever another organisation processes personal data on behalf of a controller.

Processors can be tricky to spot. Here are some common examples of controller/processor relationships:

A retail business (controller) stores personal data remotely via a Cloud Services Provider (CSP) (processor), such as Google Drive.
A government department (controller) manages employee records using an HR software provider (processor), such as Workday.
A website operator (controller) analyses the use of its website via an analytics provider (processor), such as Google Analytics.

A processor doesn’t decide the “how” or the “why” of processing personal data, and doesn’t process personal data for its own purposes or benefit (except to the extent that it makes money from its providing services).

How a Processor Becomes a Controller

If a processor uses personal data covered by a DPA for its own purposes, Article 28 (10) GDPR says the processor will be a controller for that processing.

This is bad news for the processor, as it will lose any protection provided by the DPA and become directly liable for violating the GDPR.

For example, the Greek regulator fined a processor €5,000 under Article 28 (10) after it disclosed personal data to a court against the orders of the controller.

Processors should be explicit about how they intend to use personal data they process on behalf of controllers, and controllers should read DPAs and other agreements carefully to ensure they understand how service providers will use personal data.

Key Components of a Data Processing Agreement

Article 28 of the GDPR lists the components that must be present in DPA. Here’s a look at each of the key elements.

Introduction or Preamble

First, there are some provisions you will likely wish to include in your DPA even though they’re not listed as mandatory under the GDPR.

Names of the parties: As with any contract, it’s best to begin by listing the parties involved, i.e., the legal names of the controller and the processor and, if applicable, whoever is signing on each party’s behalf.
Definitions: You can define key terms (such as “controller”, “processor”, and “personal data”) and reference the applicable law (namely, the GDPR, or in the UK, the UK GDPR).
Other agreements: You should list any other agreements incorporated or referred to in your DPA, such as a Master Services Agreement (MSA). Note that other agreements cannot override the mandatory parts of the DPA.
Review period: Some DPAs include a regular review period where the parties check that the DPA is still relevant, or identify an event that triggers a review, such as when the processing activities or relevant types of personal data change.

Details of the Processing

According to Article 28 (3) of the GDPR, a DPA must set out certain details about the arrangement between the controller and the processor, namely:

The subject matter: What the DPA is for, such as cloud services, marketing services, fraud detection, etc.
The duration of the processing: How long the processing will take, including whether it’s a one-off transaction or an ongoing business relationship (you don’t need to provide a specific number of months or years).
The nature and purpose of the processing: What types of services the processor is providing, and why.
The type of personal data: What types of information will be covered by the DPA, such as names, email addresses, or device IDs.
The categories of data subjects: The types of people whose personal data will be processed under the DPA, such as customers, employees, or users of the controller’s app or website.
The obligations and rights of the controller: Some DPAs include a paragraph explaining that the controller is obliged to ensure overall compliance with data protection law and has the right to make decisions about the processing of personal data.

Processor’s requirements

The bulk of your DPA will impose data protection requirements on the processor.

These requirements are mandatory in every DPA, and they are set out at Article 28 (3) (a)-(h) of the GDPR. Here’s an overview of the processor’s requirements:

Documented instructions: The processor must only process personal data on the “documented instructions” of the controller. These instructions can appear in the DPA itself (for example, in the “details of the processing” section, above) or another agreement, as long as you make this clear in your DPA.
International transfers: The processor must (at a minimum) inform the controller before conducting any “international data transfers” involving the personal data. See this article for more information on international data transfers.
Confidentiality: The processor must ensure anyone with access to the personal data is under a duty of confidentiality, either because they’ve signed a contract or because they are under a legal obligation.
Security: The processor must “take all measures to comply with Article 32” of the GDPR, which sets out the law’s data security requirements. The DPA doesn’t need to set out which security measures the processor must implement, but it might be appropriate to do so in some cases.
Subprocessors: Under certain conditions, a processor may engage other processors to handle the controller’s personal data on its behalf, known as “subprocessors”. We’ll look at subprocessors in more detail below.
Data subject rights: The processor must agree to assist the controller in upholding data subject rights, where possible and appropriate.
Articles 32-36: The processor must assist the controller in complying with the GDPR’s requirements regarding security, personal data breaches, and Data Protection Impact Assessments (DPIAs). For example, the processor should notify the controller of any data breaches. We’ll look at this in more detail below.
Termination: Once the processor stops providing services to the controller, the processor must “delete or return” all the relevant personal data. The controller can choose whether to require the processor to “delete” or “return” the data and will sometimes specify this in the DPA.
Audits: The processor must agree to provide the controller with “all information necessary to demonstrate compliance” with Article 28 of the GDPR, including by complying with audits and inspections organised by the controller.

Processors and Subprocessors

As noted above, a processor may need to appoint “subprocessors”. Subprocessors are like the “processor’s processors”—other organisations that help the processor carry out its obligations under the DPA.

For example: Like many processors, Amazon Web Services (AWS) provides a running list of its subprocessors, which include other businesses in the Amazon corporate group, security companies, and software providers that provide location and notification services.

The GDPR provides several rules around the appointment of subprocessors:

The processor must implement DPA with the subprocessor that meets all the requirements of Article 28 of the GDPR.
The processor is liable for the subprocessor if it fails to meet its obligations under the DPA (the controller can sue the processor for its subprocessor’s non-compliance, with some limited exceptions).
The processor must get the controller’s “prior written authorisation” before appointing a subprocessor.

There are two ways a controller can authorise a processor to appoint subprocessors:

General authorisation: The controller allows the processor to appoint new subprocessors at the processor’s discretion, as long as the processor gives the controller notice and the opportunity to object to the appointment.
Specific authorisation: The processor must get the controller’s written authorisation each time it wishes to appoint a new subprocessor.

The DPA should specify whether the controller gives the processor general or specific authorisation.

Drafting and Negotiating a Data Processing Agreement

We’ve looked at how to recognise the need for a DPA, and summarised the DPA’s mandatory elements. Now let’s consider how to put these requirements into practice.

Developing a Standardised DPA

Many controllers use a standardised DPA that they require new processors to sign.

Using a template can help controllers manage their relationships with processors. But the controller must always ensure the DPA complies with the GDPR.

Here are some things to consider when using a template DPA:

Does the DPA include everything required under Article 28 of the GDPR?
Does the DPA include other terms that are not required under Article 28?
Was the DPA designed for a particular context that does not apply to the processor?
Is the DPA clear?
How does the DPA treat the more flexible parts of Article 28? For example: some text
- Does the DPA give the processor general or specific authorisation to appoint subprocessors?
- Does the DPA specify whether the processor must delete or return the personal data at the end of the contract?
- Does the DPA limit the number of audits that the controller may conduct?

Some larger processors may refuse to accept a controller’s standard DPA. But smaller processors might provide a DPA that doesn’t meet the GDPR’s requirements—or might not have a DPA prepared at all.

As such, a controller’s standard DPA can be adapted for different processors or serve as a starting point for negotiations with new service providers.

Negotiating a DPA

Most aspects of a DPA are non-negotiable, such as the requirements for processors to act on the instructions of the controller, assist the controller with data subject rights requests, and comply with the GDPR’s security obligations.

However, some parts of the DPA are open to negotiation between the controller and the processor. For example:

The parties must agree on whether the processor has “general” or “specific” authorisation to appoint subprocessors. The processor might prefer to have general authorisation, whereas risk-averse controllers might prefer specific authorisation.
Article 33 of the GDPR says that the processor must notify the controller about a personal data breach “without undue delay”. Some DPAs specify that the processor must notify the controller within a specific period, such as 24 hours.
Some DPAs impose a blanket prohibition on the processor transferring personal data outside of the European Economic Area (EEA) (or the UK, if relevant), whereas others say that the processor must notify the controller before conducting an international data transfer.

In addition to these negotiation points, the controller should seek assurances about the processor’s data security arrangements.

If the processor fails to demonstrate that it can meet the security requirements at Article 32 of the GDPR, the controller should consider imposing specific security measures before engaging the processor. Some controllers add a “data security addendum” or similar agreement to the DPA.

Signing a Processor’s Standard DPA

Some larger processors provide their own DPA and require their customers (controllers) to sign it. Google, for example, provides Cloud Data Processing Addendum for Google Workspace customers. Microsoft’s Products and Services Data Protection Addendum covers Office 365 and other software.

Under the GDPR, the controller should call the shots (and it carries most of the liability). However, larger processors sometimes offer their services on a “take it or leave it” basis, and they might be reluctant to modify their standard DPA for smaller customers.

It’s perfectly legal for a controller to sign a DPA prepared by the processor—as long as the DPA includes all the mandatory terms set out at Article 28 of the GDPR.

But whether the processor is a tech giant like Google or a tiny startup with no GDPR experience, the controller must ensure there is a valid DPA to protect the personal data in its control.

Frequently Asked Questions about Data Processing Agreements

What are the penalties for not having a DPA in place?

If a controller does not have a valid DPA in place with a processor, a Data Protection Authority can impose a fine of up to €10 million (£8.7 million) or 2% of global annual turnover, whichever is greater.

As noted above, a processor can also be fined for violating the terms of a DPA or failing to meet its security obligations.

In August 2024, the UK Information Commissioner’s Office (ICO) announced a provisional £6 million fine against a processor, Advanced Computer Software Group Ltd, for allegedly violating Article 32 of the UK GDPR.

Can a DPA be retroactively applied?

No, a DPA must be in place before the processor processes any personal data on behalf of the controller.

This includes processors that offer a free trial of their services—if any personal data is involved in the free trial, it must be covered by a DPA.

How often should DPAs be reviewed and updated?

The GDPR doesn’t specify how often DPAs should be reviewed. The parties might agree to a regular review. If the processing is handling particularly sensitive personal data, it makes sense to review the DPA regularly.

A DPA should be updated, or a new DPA should be implemented, if anything about the processing activity significantly changes. For example:

The processor provides new services to the controller
The controller expands the types of data processed by the processor
The processor is acquired by another company or changes location

Controllers should consider establishing a process for regularly reviewing DPAs.

What is the difference between a DPA and a data sharing agreement?

Whereas a DPA is implemented between a controller and a processor (or a processor and a subprocessor), a data sharing agreement is generally implemented between two controllers.

Data sharing agreements are not mandatory under the GDPR, but they can be a good way to manage liability and clarify responsibilities when sharing data with another organisation.

For example, two advertising companies might implement a data sharing agreement when combining datasets for data “enrichment” purposes. Each company requires a valid legal basis for processing personal data, and each will use the resulting analytics data for its own purposes.

A data sharing agreement is not the same as a joint controller agreement, which is required when two controllers jointly decide how and why to process the same personal data.

Best Practices for Implementing Data Processing Agreements

DPAs are a cornerstone of data protection. Controllers should consider the following steps to ensure all relevant activities are covered by a valid DPA:

Data mapping: Understanding your organisation’s data flows can help identify which service providers are acting as processors. Use data mapping to ensure visibility of all data processing activities, and make sure all processors are acting under a DPA.
Review process: Keep your DPAs under regular review. If a processor notifies your company of a change to its services, make sure your DPA remains valid and relevant.
Record-keeping: Keep your DPAs well-organised and accessible to your organisation’s data protection or legal teams. Link your DPA repository to your Records of Processing Activities (RoPA) to ensure good data governance.

Understanding the Data Processing Agreement (DPA)