What Is a DPA? Data Processing Agreements Explained

What is a DPA under the GDPR

A data processing agreement is the contract (or other binding legal act) that must sit between a controller and a processor when personal data is processed on the controller’s behalf. In short, what is a DPA: it is the Article 28 instrument that turns a commercial SaaS relationship into a GDPR-compliant processor appointment.

If you buy cloud software, use a payroll bureau, or hire an agency that handles customer or employee personal data on your instructions, you almost certainly need one. This post explains the definition, when the duty bites, and how Article 28 frames the document. It is not a field-by-field review checklist; that is a different exercise once you already know you need the contract.

The legal hook: Article 28(3)

Article 28(3) of the GDPR is unambiguous. 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.

That contract must, in particular, require the processor to:

• process personal data only on documented instructions from the controller (including on transfers), unless Union or Member State law requires otherwise;
• ensure confidentiality for people authorised to process the data;
• take the security measures required by Article 32;
• respect the rules on engaging another processor (subprocessors);
• assist the controller with data-subject rights and with Articles 32 to 36;
• delete or return personal data at the end of the service, at the controller’s choice;
• make available the information needed to demonstrate compliance and allow audits.

Article 28(9) adds that the contract must be in writing, including electronic form. A click-through DPA accepted at signup can satisfy the form requirement if it is binding and contains the substance. A marketing PDF that nobody signed usually does not.

Teams that ask what is a DPA after a vendor review often discover they already have something labelled “Data Processing Addendum” buried in the order form. The label matters less than whether Article 28(3)’s content is present and enforceable.

When you need a DPA

You need a data processing agreement when three conditions line up.

1. You are a controller (or a processor appointing a subprocessor). You determine the purposes and means of the processing, or you are cascading Article 28 duties down the chain.
2. The other party is a processor. It processes personal data on your behalf, on documented instructions, without deciding the purposes for itself.
3. Personal data is in scope. The service actually handles information relating to identified or identifiable people, not only anonymous telemetry or purely company data.

Classic SaaS examples: a CRM that stores your contacts, a support desk that opens tickets about named customers, a payments provider that processes end-customer data for your checkout, an HR platform that holds employee records. As of our checks on 25 September 2026, vendors such as Stripe, HubSpot and Atlassian publish DPAs that set breach-notification windows, subprocessor notice periods and transfer tools precisely because they act as processors for those workloads.

You generally do not need a DPA where the other party is an independent controller (for example many professional advisers deciding their own purposes), a pure joint-controller arrangement under Article 26 (which needs an arrangement, but not an Article 28 processor contract), or a recipient that does not process on your behalf. Mis-labelling a controller-to-controller deal as a DPA creates false comfort and the wrong audit trail.

What “good enough” looks like without becoming a checklist

Knowing what is a DPA is half the job; knowing whether yours is empty is the other half. Without turning this into a line-by-line review playbook, watch for five signals that the document is doing Article 28 work:

Instructions and purpose. The DPA should describe what the processor may do and forbid processing for the processor’s own purposes (including training models on your content, unless you expressly instruct that).

Subprocessors. General or specific authorisation, a way to learn of additions or replacements, and an opportunity to object, as Article 28(2) requires. As of 25 September 2026, Stripe, HubSpot and Atlassian each commit to roughly 30 days’ notice in the DPAs we have read.

Security and breach notice. Article 32 measures, plus how fast the processor tells you about a personal data breach. The GDPR gives processors “without undue delay” toward the controller (Article 33(2)); many DPAs add a clock. Stripe’s DPA, as of our 25 September 2026 extract, commits to notice no later than 48 hours for GDPR-relevant incidents; HubSpot’s and Atlassian’s commit to no later than 72 hours.

Transfers. Which Chapter V tool the vendor relies on (standard contractual clauses, the EU–US Data Privacy Framework, binding corporate rules, adequacy). See our guide comparing SCCs and the Data Privacy Framework when the destination is outside the EEA.

End of contract. Delete or return, and what happens to backups. Article 28(3)(g) puts the choice with the controller unless law requires retention.

If those themes are missing, the document may be a privacy notice, a security white paper, or an MSA clause about confidentiality, not a DPA.

DPA, MSA, privacy notice: keep the roles straight

A master service agreement sets commercial terms: fees, liability caps, service levels. A privacy notice tells data subjects what you (or the vendor, for its own controller processing) do with personal data. A DPA is the controller–processor operating manual required by Article 28.

They interact. Liability caps in the MSA can blunt audit or breach remedies promised in the DPA. A privacy notice that lists “service providers” does not replace the contract those providers must sign with you. Controllers who treat the privacy policy URL as the DPA fail Article 28(3) on day one.

For how subprocessors fit the same picture from the controller’s side, see our learn guide on what a subprocessor is. For the terms we extract from vendor DPAs in the directory, start at what we watch.

The one check worth making this week

Open the contract pack for your highest-risk SaaS vendor. Find the document that claims to be the DPA (or “Data Processing Addendum”). Confirm it is signed or click-accepted, names you as controller and the vendor as processor, and contains a subprocessor clause plus a breach-notification commitment. If you cannot find that document in ten minutes, you do not have an operable Article 28 contract on file, regardless of what the sales deck said.

ClauseTrail reads vendors’ DPAs and related documents and turns the commitments that matter (breach windows, subprocessor notice, transfer tools, retention, audit rights) into tracked facts with quotes. See a vendor page such as HubSpot’s or browse clausetrail.com. Plans are on pricing.

Frequently Asked Questions

What is a DPA in plain English?

It is the binding contract between a controller and a processor that Article 28 of the GDPR requires when the processor handles personal data on the controller’s behalf. It sets the instructions, security, subprocessor rules, assistance duties, deletion or return, and audit cooperation. Without it, the processor appointment is not properly governed under the Regulation.

Is a DPA the same as a data processing addendum?

Usually yes in SaaS. Vendors often call the Article 28 contract a “Data Processing Addendum” annexed to the MSA or online terms. What matters is the Article 28(3) content and that it binds the processor, not whether the filename says agreement or addendum.

Do I need a DPA if the vendor is outside the EU?

If you are in scope of the GDPR as a controller and the vendor processes personal data on your behalf, yes: Article 28 still requires a contract. Separately, transfers out of the EEA need a Chapter V mechanism. The DPA usually incorporates SCCs or records DPF or BCR reliance; it does not replace those transfer tools.

When do I not need a DPA?

When the other party is not your processor: for example an independent controller, a joint controller under Article 26, or a party that never processes personal data for you. Buying a purely anonymous analytics feed, or sharing data with another controller under a controller-to-controller agreement, are different instruments.

Can standard contractual clauses replace a DPA?

No. Commission SCCs (Implementing Decision (EU) 2021/914) are a transfer tool under Article 46. Article 28 still needs a processor contract covering instructions, security, subprocessors and the rest. Many DPAs incorporate Module 2 SCCs for restricted transfers; they answer different legal questions.

Who should sign the DPA inside my organisation?

Someone with authority to bind the controller on privacy and vendor terms, typically legal or the data protection officer working with procurement. Keep the signed or accepted version with the MSA, and make sure operations know which notice emails to monitor for subprocessor and breach communications.