When do I actually need a DPA?

Whenever personal data is processed by one party on behalf of another. If you engage a vendor that handles your customers’ personal data under your instructions - cloud hosting, email, payments, analytics, an AI API - you need a DPA with that vendor. And when your own B2B customers entrust you with personal data they are responsible for, they need a DPA with you. The trigger is the controller-processor relationship, not the size of the deal: a free-tier vendor that touches personal data still needs a DPA in place.

What are the eight mandatory obligations in a DPA?

Article 28(3) requires the contract to bind the processor to: (a) process only on the controller’s documented instructions; (b) ensure authorised personnel are under confidentiality obligations; (c) implement Article 32 security measures; (d) respect the subprocessor conditions in Articles 28(2) and 28(4); (e) assist the controller with data-subject rights requests; (f) assist with security, breach-notification, and DPIA obligations under Articles 32-36; (g) delete or return all personal data at the end of the service; and (h) make available the information needed to demonstrate compliance and allow audits. A DPA missing any of these does not satisfy Article 28.

Can I just use a vendor’s standard DPA?

Usually yes, and you often have to - large vendors will not negotiate a bespoke DPA with every customer. The right move is to read it rather than assume it. Confirm it covers all eight Article 28(3) obligations, check how it handles subprocessors (a list plus a notice mechanism), look at where data is processed and which transfer mechanism it relies on, and note the data-return-or-deletion terms. Many vendors incorporate the European Commission’s standard contractual clauses, which embed the required obligations, as a baseline.

How is a DPA different from terms of service or an NDA?

Terms of service govern the commercial relationship - pricing, acceptable use, liability. An NDA protects confidential information from disclosure. A DPA is specifically about how personal data is processed under GDPR, and it is the only one of the three that satisfies Article 28. They are complementary, not interchangeable: signing an NDA does not give you a DPA, and a terms-of-service document only doubles as a DPA if it explicitly contains the Article 28(3) terms.

Does the DPA need to list subprocessors?

The DPA sets the rules for subprocessors; the live list usually lives alongside it. In a general-written-authorisation arrangement, the DPA states that the processor may use subprocessors, points to a maintained list (commonly a public subprocessor page), and defines how the controller is notified of and can object to changes. So the DPA references the list and governs how it changes, rather than freezing a snapshot of vendors into the contract body where it would immediately go stale.

Guide / DPA

Updated 25 May 2026

The DPA guide: data processing agreements for SaaS

A Data Processing Agreement (DPA) is the written contract GDPR Article 28 requires whenever one party processes personal data on another’s behalf. It fixes the scope of processing, imposes eight mandatory obligations on the processor, governs how subprocessors are used, and is the document enterprise buyers ask for first. This guide covers what a DPA must contain and how a SaaS company handles one in both directions.

Key facts

01A DPA is mandatory under GDPR Article 28(3) wherever a processor handles personal data on a controller’s behalf - it is a contract, not a courtesy.
02It must define the processing parameters (subject matter, duration, nature, purpose, data types, data subjects) and impose the eight Article 28(3)(a)-(h) obligations on the processor.
03The subprocessor terms live in the DPA: whether authorisation is specific or general, the notice mechanism, and the requirement to flow equivalent terms down to subprocessors.
04As a SaaS company you are usually on both sides - signing vendors’ DPAs as a controller-or-processor, and offering your own DPA to your B2B customers.
05Most major vendors provide a pre-signed DPA; your job is to confirm it actually covers the Article 28(3) terms, not to assume a generic confidentiality clause does.

§ I

What a DPA is and why it exists

A Data Processing Agreement is the written contract that GDPR Article 28 requires whenever one party processes personal data on behalf of another. The first party is the controller, who decides why and how the data is used. The second is the processor, who acts on the controller's instructions.

The DPA exists to stop accountability from evaporating the moment data changes hands. A controller can comply with GDPR perfectly in its own operations and still expose data subjects to harm if it hands data to a processor with no binding obligations. The DPA closes that gap by putting enumerated, non-negotiable duties on the processor in writing. It is a legal requirement, not a nicety, and a handshake or a privacy-policy reference does not satisfy it.

§ II

What a DPA must contain

Article 28(3) has two layers. First, the contract must fix the processing parameters: the subject matter and duration of the processing, its nature and purpose, the type of personal data involved, and the categories of data subjects. These define the box the processor is allowed to operate in.

Second, the contract must impose eight specific obligations on the processor:

-(a)process personal data only on the controller's documented instructions;
-(b) ensure people authorised to process the data are bound by confidentiality;
-(c) implement the security measures required by Article 32;
-(d) respect the subprocessor conditions in Articles 28(2) and 28(4);
-(e) assist the controller in responding to data-subject rights requests;
-(f)assist with the controller's obligations under Articles 32-36 (security, breach notification, DPIAs);
-(g)delete or return all personal data at the end of the service, at the controller's choice;
-(h) make available the information needed to demonstrate compliance, and allow audits.

These are the load-bearing terms. When you review a vendor's DPA, you are really checking that all eight are present and not quietly diluted.

§ III

The subprocessor terms

Subprocessors are where most DPA friction lives, because they are the part that keeps changing after signing. The DPA must state whether the processor may engage subprocessors at all, and on what basis - specific authorisation (the controller approves each one individually) or, far more commonly, general written authorisation (the controller agrees in advance, subject to being kept informed).

Under general authorisation, the DPA does not freeze a list of vendors into the contract body - that would be stale within a month. Instead it points to a maintained subprocessor list, usually a public subprocessor page, and sets out the mechanism for notifying the controller of additions or replacements and the window in which they may object. Article 28(4) then requires the processor to flow equivalent data-protection terms down to every subprocessor by written contract, and keeps the processor fully liable if a subprocessor fails.

§ IV

Handling DPAs as a SaaS company

A SaaS company is almost always on both sides of the DPA relationship at once, and it helps to keep the two directions clear:

-Downstream - DPAs with your vendors.Every service that processes your customers' personal data needs a DPA in place with you. Collect them, store them somewhere you can find them in a security review, and re-check them when a vendor changes terms or you change vendors.
-Upstream - your DPA with customers. Your B2B customers, as controllers, need a DPA with you. Offer a clear standard DPA they can sign, with your subprocessor list referenced and your notification mechanism defined. Making this easy removes a recurring blocker from your own sales cycle.

On request, you can also generate a ready-to-review DPA that pre-fills your current subprocessor list as the annex - which is what turns “send us your DPA” from a scramble into a download.

FAQ

Frequently asked questions

When do I actually need a DPA?: Whenever personal data is processed by one party on behalf of another. If you engage a vendor that handles your customers’ personal data under your instructions - cloud hosting, email, payments, analytics, an AI API - you need a DPA with that vendor. And when your own B2B customers entrust you with personal data they are responsible for, they need a DPA with you. The trigger is the controller-processor relationship, not the size of the deal: a free-tier vendor that touches personal data still needs a DPA in place.
What are the eight mandatory obligations in a DPA?: Article 28(3) requires the contract to bind the processor to: (a) process only on the controller’s documented instructions; (b) ensure authorised personnel are under confidentiality obligations; (c) implement Article 32 security measures; (d) respect the subprocessor conditions in Articles 28(2) and 28(4); (e) assist the controller with data-subject rights requests; (f) assist with security, breach-notification, and DPIA obligations under Articles 32-36; (g) delete or return all personal data at the end of the service; and (h) make available the information needed to demonstrate compliance and allow audits. A DPA missing any of these does not satisfy Article 28.
Can I just use a vendor’s standard DPA?: Usually yes, and you often have to - large vendors will not negotiate a bespoke DPA with every customer. The right move is to read it rather than assume it. Confirm it covers all eight Article 28(3) obligations, check how it handles subprocessors (a list plus a notice mechanism), look at where data is processed and which transfer mechanism it relies on, and note the data-return-or-deletion terms. Many vendors incorporate the European Commission’s standard contractual clauses, which embed the required obligations, as a baseline.
How is a DPA different from terms of service or an NDA?: Terms of service govern the commercial relationship - pricing, acceptable use, liability. An NDA protects confidential information from disclosure. A DPA is specifically about how personal data is processed under GDPR, and it is the only one of the three that satisfies Article 28. They are complementary, not interchangeable: signing an NDA does not give you a DPA, and a terms-of-service document only doubles as a DPA if it explicitly contains the Article 28(3) terms.
Does the DPA need to list subprocessors?: The DPA sets the rules for subprocessors; the live list usually lives alongside it. In a general-written-authorisation arrangement, the DPA states that the processor may use subprocessors, points to a maintained list (commonly a public subprocessor page), and defines how the controller is notified of and can object to changes. So the DPA references the list and governs how it changes, rather than freezing a snapshot of vendors into the contract body where it would immediately go stale.

This guide is general information only and does not constitute legal advice. For advice on your specific situation, consult a qualified legal professional.

Your turn

Keep your subprocessor register current - automatically.

Registora hosts your register on your own domain, monitors every upstream provider for changes daily, and drafts the customer notification when one updates.

Start your register →Audit your site