What is the difference between a controller and a processor?

A controller determines the purposes and means of processing personal data, while a processor handles that data on the controller's behalf and only on documented instructions. The designation is determined by what each party actually does, not by what the contract labels them.

Is a DPA legally required?

Under the GDPR, Article 28 requires a binding contract whenever a controller engages a processor, and it specifies terms that contract must contain. Requirements in other jurisdictions differ, so the applicable law for the specific data and parties should be confirmed with counsel.

Does a signed DPA mean a vendor is compliant?

No. A DPA is one required element of a compliant processing relationship. It does not establish a lawful basis for processing, satisfy transparency obligations to data subjects, or demonstrate that the described security measures are actually implemented.

What Is a Data Processing Agreement? A Practical Definition

Glossary · enterprise · 5 min read · last verified 2026-07-21

Reviewed before publication Editorial board Independent commercial review

In shortA DPA is a contract that governs how a processor handles personal data on a controller's behalf. The controller-processor designation is the single line that determines everything else in it.

A data processing agreement (DPA) is a contract between a data controller and a data processor that governs how the processor may handle personal data on the controller's behalf, and under the GDPR it is required whenever a controller engages a processor.

What follows describes common commercial patterns, not legal advice. Positions vary by jurisdiction and by the data involved, and counsel should decide the actual terms.

What a data processing agreement is

A DPA is usually an exhibit or addendum to a larger commercial contract rather than a standalone document. Its job is narrow: it sets the rules for a defined processing activity and allocates responsibility between the two parties for that activity.

The roles it allocates are the whole point:

The controller determines the purposes and means of processing — what personal data is collected, why, and for how long.
The processor processes personal data on the controller's behalf and only on the controller's documented instructions.

Under Article 28 of the GDPR, that relationship must be set out in a binding contract. Article 28(3) enumerates what the contract has to cover, including the subject matter and duration of the processing, its nature and purpose, the type of personal data and categories of data subjects, and a set of specific processor obligations: process only on documented instructions, ensure personnel confidentiality, apply appropriate security measures, respect the rules on engaging sub-processors, assist the controller with data subject requests and with breach and impact-assessment duties, delete or return the data at the end of the engagement, and make available the information needed to demonstrate compliance.

Why the controller-processor line matters

One designation drives the rest of the document. A processor's obligations are largely defined by the controller's instructions, which is why a processor negotiates hard over the scope of those instructions and over what counts as an audit right. A controller carries the primary accountability to regulators and to data subjects, which is why controllers push for deletion certainty, breach notification speed, and sub-processor veto rights.

Getting the line wrong is not a drafting nuance. A supplier that decides for itself what personal data to collect and why — for example, using customer data to develop its own product — is acting as a controller for that activity, whatever the contract calls it. Under Article 28(10), a processor that determines purposes and means in relation to processing is treated as a controller for that processing. Where both parties genuinely determine purposes together, the joint-controller framework applies instead, and the arrangement between them has to be set out accordingly.

Many real relationships are mixed: the same vendor can be a processor for customer account records and a controller for its own billing and marketing to the customer's staff. A DPA that pretends otherwise creates gaps that surface during an incident.

How a DPA works

In practice a DPA does five things, and reviewers read for them in roughly this order:

Defines the processing. An annex describing categories of data, categories of data subjects, purposes, and retention. Vague annexes are the most common weakness; "as described in the agreement" is not a description.
Constrains use. Documented instructions, purpose limitation, and — increasingly contested — whether the vendor may use the data to train or improve its own models or products.
Handles sub-processors. Whether the processor may engage sub-processors, whether the controller gets notice or a right to object, and the requirement to flow equivalent obligations down.
Sets security and incident obligations. Technical and organizational measures, and the timing and content of breach notification to the controller. Notification windows are negotiated and vary by contract; do not assume a market standard.
Addresses international transfers. Where personal data leaves a jurisdiction with transfer restrictions, the DPA typically incorporates a transfer mechanism such as the European Commission's standard contractual clauses, with UK and Swiss variations handled by separate addenda. See data residency requirements for how location questions interact with these terms.

Common misconceptions

"A DPA is a formality we can sign as presented." The annexes are the operative part, and signing a description of processing that does not match reality is worse than having no description.
"Signing a DPA makes us compliant." It is one required element. It does not substitute for a lawful basis, transparency to data subjects, or working security controls.
"The processor is responsible for the data." The controller retains accountability for the processing it directs. Contractual allocation between the parties does not reassign that accountability to regulators.
"The DPA and the security exhibit are the same thing." They overlap on security measures but answer different questions. Security review evidence usually arrives through a security questionnaire and audit reports, not through the DPA.

Data processing agreements in practice

DPA review sits at an awkward junction in enterprise deals. It is owned by privacy or legal, informed by security, and blocked by whichever team is slowest. Deals stall when it is treated as a late-stage signature item rather than as a parallel workstream started when the technical evaluation starts.

A few habits reduce friction without pretending the negotiation is unnecessary:

Fill the annex honestly and early. The engineering answer to "what personal data does the system actually hold" is the input, and it usually takes longer to obtain than expected.
Separate policy positions from preferences. Some terms — training on customer data, sub-processor objection rights, deletion on termination — are policy for one side and negotiable for the other. Knowing which is which shortens the exchange.
Keep the sub-processor list current. It is a standing obligation, not a point-in-time disclosure, and a stale list is discovered at the worst moment.
Align it with the master agreement. Liability caps, termination, and audit rights in the master service agreement can silently contradict the DPA, and inconsistent documents are resolved slowly.

The test of a DPA is not whether it was signed. It is whether, during an incident or a data subject request, both parties can read it and agree within an hour on who does what.