Data Processing Agreement (DPA)

What is a data processing agreement?

A data processing agreement (DPA) is a contract that sets the rules for how a vendor handles personal data on your behalf. Personal data means information about an identifiable person, such as your customers' names, emails or usage records.

The DPA exists because of how privacy law splits roles. You decide why and how the data is used, so you are the data controller. The vendor stores or handles it for you, so it is the data processor. The comparison controller vs processor explains the two roles.

A DPA is not the same as the vendor's privacy policy, which covers data the vendor collects for itself; see DPA vs privacy policy.

Under the GDPR, this is not optional. Article 28 says processing by a processor must be governed by a binding contract. If the GDPR applies to your data, every vendor that processes personal data for you needs one. Many SaaS vendors publish a standard DPA on their legal pages, such as Stripe and Atlassian.

US law has a similar idea. Under the CCPA, a service provider must have a written contract that bars it from selling or sharing the data or using it beyond the business purposes in the contract. Many vendors cover this in the same DPA. See CCPA service provider.

What Article 28 requires

The GDPR lists what the contract must cover. It must describe the subject, length, nature and purpose of the processing, the types of data and the people the data is about. It must also require the vendor to:

• Process data only on your documented instructions.
• Make sure staff who see the data are bound by confidentiality.
• Use proper security, often listed as technical and organizational measures.
• Follow the rules for using other processors, called subprocessors.
• Help you answer people's requests to see or delete their data.
• Help you with security, breach reporting and risk assessments.
• Delete or return the data when the service ends, at your choice.
• Give you the information needed to show compliance, and allow audits.

The full list is in Article 28 GDPR.

The subprocessor clause

A subprocessor is another company your vendor uses to handle your data, such as its cloud host or an AI model provider. Article 28(2) says a processor needs the controller's written permission to use one. Permission can be general, but then the vendor must tell you about planned additions or replacements and give you a chance to object.

That is why DPAs come with a subprocessor list and a notice process. Here is how the process usually runs:

1. You subscribe to the vendor's subprocessor update emails.
2. The vendor adds a planned new subprocessor to its list and emails subscribers.
3. A notice window starts, often 30 days.
4. You object in writing within that window, or the new subprocessor is treated as accepted.
5. If you object and the two sides cannot agree, your remedy is often to end the affected service.

Real DPAs follow this shape. Stripe's DPA promises email notice "at least 30 days before the changes take effect" to users who subscribe. Salesforce's Data Processing Addendum gives subscribed customers 30 days to object in writing. Atlassian's DPA gives at least 30 days' notice, and its remedy for an objection is to end the affected order. The rules for this step are covered in subprocessor change notification.

Breach notification

If the vendor has a data breach, how fast must it tell you? The GDPR sets different duties for each side. Under Article 33(2), a processor must tell the controller "without undue delay" after it learns of a breach. The 72-hour deadline in Article 33(1) belongs to you as the controller: it is your deadline, where feasible, to tell the regulator.

That is why the hours in your vendor's DPA matter. If the vendor takes three days to tell you, your own clock is already running. Some vendors promise a number. Stripe's DPA says "no later than 48 hours" for data under the GDPR or UK GDPR. Atlassian's DPA says where feasible no later than 72 hours. Salesforce's says "without undue delay." See breach notification clause.

What it looks like in a vendor's terms

A typical clause reads like this:

Provider will process Customer Personal Data only on Customer's documented instructions. Customer gives general authorization for Provider to engage Subprocessors listed on its website. Provider will notify Customer of new Subprocessors at least 30 days in advance, and Customer may object on reasonable grounds within that period. Provider will notify Customer of a Personal Data Breach without undue delay. Provider may update this DPA from time to time, provided the update does not materially reduce the protection of Customer Personal Data.

• "Documented instructions": the vendor may use the data only as you direct, which usually means as the contract and your settings allow.
• "General authorization": you approve the current list and future additions in advance, subject to notice.
• "Object on reasonable grounds": you need a real reason, and the vendor often decides what happens next.
• "Without undue delay": no fixed number of hours, so look for a firmer promise elsewhere in the DPA.
• "May update this DPA": the vendor can change the contract without your signature, with a promise not to weaken protection.

How a DPA changes without your signature

Many DPAs are web pages that the main agreement pulls in by link. When the vendor edits the page, your contract can change. Atlassian's Customer Agreement, for example, lets Atlassian modify the agreement, including the DPA, by posting changes on its website, with efforts to post them at least 30 days in advance.

A real change we caught

Venpo flagged this exact pattern: Hotjar's DPA can now change without your signature. Once a DPA allows changes by posting, the version you reviewed during procurement may not be the one in force today.

Another example shows how a DPA can shift work onto you: Retool's DPA now makes you check that your use of Retool meets privacy law.

Why it matters to you

• You stay responsible: as the controller, you answer to your customers and regulators for what your vendors do with their data.
• Your promises flow down: if your contract with a customer promises a breach notice within a set time, your vendors' DPAs need to support that timeline. See flow-down obligations.
• Customer requests: when a customer sends you its own DPA, you need to know what your vendors promise you first.
• New subprocessors: missing a 30-day objection window means you have accepted a new company handling your data.

What to check

• Scope: confirm the DPA covers all products you use, including beta and AI features.
• Breach notice: look for a number of hours, not only "without undue delay."
• Subprocessor notice: find the notice period, how notice is sent and whether you must subscribe to get it. Then subscribe.
• Objection remedy: check what happens if you object, and whether you get a refund if you leave.
• Change clause: check whether the vendor can update the DPA by posting, and whether it promises not to reduce protection.
• Deletion and audits: check how long after termination the data is deleted and what audit evidence (like a SOC 2 report) you can get.

Data Processing Addendum

A data processing addendum is the same thing as a data processing agreement, under a different name. Both are shortened to DPA, and both do the job Article 28 requires.

The word "addendum" means a document added to a main contract. Vendors use it because the DPA usually sits on top of the terms of service or master agreement, rather than standing alone. Salesforce and Atlassian both call theirs a Data Processing Addendum. Stripe calls its version a Data Processing Agreement.

The name does not change the legal effect. What matters is the content: the subprocessor rules, breach notice timing, security measures, transfer terms and deletion rules.

The name can hint at one thing, though. An addendum is usually tied to the main agreement, so its change rules may come from that agreement. Read both documents to see how the DPA can be updated. For the general difference between the two kinds of documents, see amendment vs addendum.

How Venpo helps

Venpo watches your vendors' public DPAs and subprocessor lists and emails you a plain-English alert when they change, including new subprocessors and changes to breach notice or update rules. Each vendor has a change history, so you can see which version was in force when.