What Is a DPA (Data Processing Agreement) and When Do You Actually Need One?

At some point, usually right as a deal is about to close, an enterprise customer's procurement or legal team sends over a Data Processing Agreement and asks you to sign it, or asks for yours. If you don't have one ready, this can stall a deal for weeks. Here's what the document actually is and why it exists.

What a DPA is

A Data Processing Agreement is a contract that governs how a data processor (you, if you're handling personal data on behalf of a customer) is allowed to handle that data. It sits alongside your main SaaS or services agreement — it doesn't replace it.

Under GDPR and UK GDPR, a DPA is legally required whenever a "controller" (typically your customer, who determines why data is collected) uses a "processor" (typically you, processing it on their behalf) to handle personal data. This isn't optional paperwork — Article 28 of the GDPR specifically requires this agreement to exist in writing.

When you need one

• Your customer is a business (not a consumer) and their end users' or employees' personal data flows through your product
• You or your customer operate in the EU or UK, or serve people located there
• Your customer's own legal or security team requires one as a condition of the deal — increasingly common even outside the EU/UK, since many US enterprises now require DPAs as standard vendor practice

You generally don't need one for a pure consumer product with no B2B data-processing relationship, though your privacy policy still needs to cover how you handle that consumer data.

What has to be in it

• Subject matter and duration of the processing
• Nature and purpose of the processing, and the categories of data and people involved
• Sub-processors — who else touches the data (your hosting provider, your email service, any AI vendor), and the obligation to flag changes
• Security measures you have in place
• Assistance obligations — helping the customer respond to data subject requests, breach notifications, and audits
• Deletion or return of data at the end of the relationship
• International transfer mechanism if data moves across borders — usually Standard Contractual Clauses

Standard clauses vs. custom DPAs

Most companies maintain one standard DPA that gets attached to every customer contract, sometimes with an annex listing sub-processors that updates as vendors change. Larger enterprise customers sometimes insist on their own DPA template instead — worth having someone review before you sign it, since some of these shift obligations further onto the processor than a standard document would.

What happens if you don't have one ready

In practice: the deal stalls while your legal counterpart drafts one for you (on their terms, not yours), or the customer's procurement team flags your company as a compliance risk during vendor review — which shows up again at renewal time, not just at signature.

Frequently asked questions

Is a DPA the same as a privacy policy?

No. A privacy policy is a public notice to individuals about how you use their data. A DPA is a private contract between two businesses governing a processing relationship — they serve different audiences and different legal purposes.

Do US-only companies need a DPA?

If none of your data subjects or customers are in the EU/UK and no applicable US state law requires one, strictly speaking no — but many enterprise buyers now request one as standard vendor due diligence regardless of jurisdiction, so having one ready removes friction either way.

Can I use a free DPA template?

A template gets the structure right but usually needs your actual sub-processors, security measures, and transfer mechanism filled in accurately — a DPA that lists the wrong sub-processors or an outdated security posture creates liability rather than removing it.

This article is general information about how these documents and obligations usually work. It is not legal advice on your specific situation, and reading it does not create a lawyer-client relationship. Laws referenced here change — verify current requirements before relying on this for a live decision.