Do You Need a Data Processing Agreement (DPA) in 2026?

As privacy regulations tighten globally, standard documents like Privacy Policies are no longer sufficient on their own for B2B businesses and SaaS companies. If you handle data for clients, you need to understand Data Processing Agreements (DPAs).

Under the EU's General Data Protection Regulation (GDPR) and similar laws like the UK GDPR and California's CCPA/CPRA, a DPA is a legally mandated document between two businesses sharing personal data. The GDPR is explicit: processing carried out by a processor on behalf of a controller "shall be governed by a contract or other legal act … that is binding on the processor," per GDPR Article 28(3). Operating without one can expose your business to regulatory fines and lost enterprise deals, since most security reviews now treat a signed DPA as a precondition to closing.

This guide explains the difference between Data Controllers and Data Processors, when a DPA is required, what the law says it must contain, and how to get one set up.

The GDPR Framework: Controllers vs. Processors

To understand if you need a DPA, you first need to understand the two roles the GDPR defines in Article 4:

• Data Controller: The GDPR defines a controller as the person or body "which, alone or jointly with others, determines the purposes and means of the processing of personal data" (Article 4(7)). In plain terms, the controller decides why and how data is used. (e.g., An e-commerce store collecting customer emails for a newsletter.)
• Data Processor: A processor is a person or body "which processes personal data on behalf of the controller" (Article 4(8)) — acting on the controller's instructions rather than for its own purposes. (e.g., The email marketing software, like Mailchimp, that actually sends the newsletter using the store's email list.)

These roles are not fixed labels; they describe what you do with a given dataset. The same business can be a controller for its own employee records and a processor for the customer data its clients upload. What matters is who decides the purpose of the processing.

The core rule follows directly from these definitions: whenever a Controller hands personal data to a Processor, that relationship must be governed by a written contract. The UK's Information Commissioner's Office (ICO) states the same in its guidance on controller–processor contracts: whenever a controller uses a processor, there must be a written contract binding the processor to the controller. A DPA is the document that satisfies this requirement.

Scenarios: Do You Need a DPA?

Let's look at a few common business models in 2026 to see if a DPA is required.

1. You run a B2B SaaS platform (You are a Processor)

If you run a CRM, an HR tool, or an analytics dashboard where your clients upload their clients' data, you are a Data Processor. You definitely need a DPA. You should have a standard DPA available for your enterprise clients to sign before they use your platform.

2. You are an agency handling client data (You are a Processor)

If your marketing agency manages Facebook Ad campaigns using custom audiences (emails) provided by your client, you are processing their data. You need a DPA with your client.

3. You run a B2C E-commerce site (You are a Controller)

You collect data directly from the consumer, so you don't need consumers to sign a DPA (that's what your Privacy Policy is for). However, you need DPAs from the third-party tools you use (like Stripe, Shopify, or AWS). These major platforms usually have a DPA built into their standard terms.

4. You are a freelance web developer

If you frequently log into client databases containing live user data (like fixing bugs in a production database), you act as a Data Processor. Signing a simple DPA with your client protects both of you.

What Must a DPA Include?

This is not a document you can improvise. GDPR Article 28(3) sets out a specific list of terms the contract must contain. At a minimum, it must bind the Processor to:

• Process the personal data only on documented instructions from the Controller, including for any transfers to a third country (Article 28(3)(a)).
• Ensure that people authorised to process the data have committed to confidentiality or are under a statutory duty of confidentiality (Article 28(3)(b)).
• Take all security measures required under Article 32 — appropriate technical and organisational measures such as encryption and access controls (Article 28(3)(c)).
• Engage sub-processors only with the Controller's authorisation, and pass the same data-protection obligations down to them (Article 28(3)(d)).
• Assist the Controller in responding to data subject requests, such as the right of access or the right to erasure (Article 28(3)(e)).
• Help the Controller meet its security and breach obligations under Articles 32 to 36, including breach notification and data protection impact assessments (Article 28(3)(f)).
• Delete or return all personal data at the end of the services, at the Controller's choice (Article 28(3)(g)).
• Make available all information needed to demonstrate compliance and submit to audits and inspections (Article 28(3)(h)).

The UK ICO mirrors this list for the UK GDPR and notes that approved standard contractual clauses, used without amendment, are designed to meet the Article 28 requirements. If a draft DPA is silent on any of the points above, it is not compliant — just incomplete.

What's at Stake If You Skip It

Failing to put a compliant DPA in place is not a paperwork footnote; it is an infringement of the GDPR in its own right. Infringements of a controller's or processor's obligations under Article 28 fall within the lower of the GDPR's two fining tiers under Article 83(4), which permits administrative fines of up to €10 million, or, in the case of an undertaking, up to 2% of total worldwide annual turnover of the preceding financial year, whichever is higher. The most serious violations, such as breaching the core data-processing principles, sit in the higher tier under Article 83(5), at up to €20 million or 4% of worldwide turnover.

Beyond fines, the commercial cost is often more immediate. Enterprise buyers and their security teams routinely require a signed DPA before onboarding a vendor, so a missing or weak DPA can stall or kill a deal long before any regulator is involved.

Frequently Asked Questions

Practical Steps to Get a DPA in Place

If you've worked out that you need one, the path is mechanical:

• Map your data flows. For each tool, client, or contractor you exchange personal data with, decide whether you are the Controller, the Processor, or both for that data.
• Collect the DPAs you receive. Many major platforms publish a standard DPA, often built into their terms — locate and sign these for the services you rely on.
• Provide a DPA where you are the Processor. If clients send you their users' data, have a standard DPA ready to sign as part of onboarding.
• Check it against Article 28(3). Use the eight-point list above as a checklist; a DPA missing any of those terms is incomplete.
• Keep records. Store signed agreements and sub-processor lists so you can produce them during a security review or to a regulator.

This article is general information about how data protection law treats DPAs, not legal advice. Whether a DPA is required in your circumstances — and what it should say — depends on the facts and the jurisdictions involved. For a specific situation, consult a qualified lawyer or your data protection authority.

Generate Your DPA Instantly

Don't let enterprise deals fall through because you are missing critical compliance documents. Create a Data Processing Agreement in minutes using our free generator, then have it reviewed for your specific needs.

• 🤝 Free DPA Generator