Data Processing Agreement (DPA)

Why a DPA exists

Data protection law separates two roles. The controller decides why and how personal data is processed; the processor acts only on the controller's documented instructions. When a controller hands personal data to a processor — a cloud host, a payroll provider, an AI vendor — the controller remains accountable for that data even though it no longer holds it directly.

A DPA closes that accountability gap. It converts the controller's legal obligations into contractual duties the processor must honor, and it gives the controller a basis to demand compliance, audits, and remediation. Without a signed DPA, a controller that shares personal data with a processor is exposed: it has no enforceable guarantee about how the data is secured, where it is stored, who else can access it, or what happens when the relationship ends.

The requirement is not optional. Article 28 of the GDPR states that processing by a processor must be governed by a contract that binds the processor to the controller and specifies a defined set of terms. Equivalent obligations exist in other regimes — the UK GDPR, and analogous "service provider" contract requirements under laws such as the CCPA/CPRA — but the GDPR's Article 28 is the canonical reference point for the DPA.

What a DPA must contain

A compliant DPA is not boilerplate. Article 28 prescribes the elements it must address, and a well-drafted agreement makes each one concrete:

• Subject matter and duration — what processing the agreement covers and for how long.
• Nature and purpose — why the data is processed and what operations are performed on it.
• Type of personal data and categories of data subjects — the specific data fields involved and whose data they are (customers, employees, end users).
• Controller's documented instructions — the processor may process the data only as the controller directs, including for international transfers, and not for its own purposes.
• Confidentiality — everyone authorized to process the data is bound by a duty of confidentiality.
• Security measures — appropriate technical and organizational measures to protect the data, proportionate to the risk.
• Sub-processor authorization — the processor may engage another processor only with the controller's prior authorization, and must impose the same obligations on that sub-processor.
• Assistance with data-subject rights — the processor helps the controller respond to access, erasure, and other requests from individuals.
• Breach and compliance support — the processor assists with breach notification, data protection impact assessments, and consultations with supervisory authorities.
• Deletion or return — at the end of the engagement, the processor deletes or returns the personal data, subject to legal retention requirements.
• Audits and inspections — the processor makes available the information needed to demonstrate compliance and allows audits.

These terms are interdependent. Strong security language is worth little without sub-processor controls; a deletion clause is hollow without audit rights to verify it.

Controller and processor responsibilities

The DPA allocates duties between the two parties. The controller defines the purpose and bears ultimate accountability; the processor executes within those limits and proves it did so.

The line can blur in practice — a processor that decides on its own to reuse data for model training has stepped into a controller role for that processing and assumed direct liability. The DPA's instruction clause exists precisely to prevent that drift.

Why AI tools trigger a DPA

Adopting an AI vendor that processes your users' personal data is a textbook processor relationship. The moment customer messages, support tickets, documents, or user records flow into an external model, that vendor is processing personal data on your behalf — and a DPA is required before the data is shared, not after.

AI engagements raise three concerns that a DPA must address explicitly:

Data used for model training

Many AI providers, by default, may use submitted data to train or improve their models. For a controller, that is processing beyond the controller's purpose. The DPA — and the vendor's processing terms — must establish whether customer data is excluded from training, and the controller's instructions should make that exclusion binding.

Sub-processors and the AI supply chain

AI vendors routinely rely on downstream infrastructure: the model provider, GPU hosts, vector databases, observability tools. Each is a sub-processor handling personal data. The DPA must require disclosure of these sub-processors, a mechanism to object to new ones, and flow-down of the same obligations.

International transfers

AI inference and training frequently occur outside the controller's jurisdiction. Where personal data leaves a protected region, the DPA must reference an appropriate transfer mechanism — such as the EU Standard Contractual Clauses — so the transfer remains lawful.

A signed DPA does not by itself make an AI deployment safe. It is the legal contract; the controller still needs operational controls to ensure that only permitted data actually reaches the vendor and that data flows match what the agreement allows.