A Data Processing Agreement (DPA) - also called a DPA agreement or, in US-origin contracts, a Data Processing Addendum - is the contract that makes it lawful for a vendor to handle your customers' or employees' data. Without one, every transfer of personal data to that vendor is potentially unlawful, no matter how reputable they are. This guide covers when you need a DPA under Article 28, what it must contain, the common mistakes, and a template to start from.
- You need a DPA with every processor that handles personal data on your behalf - hosting, email, CRM, AI tools.
- Article 28 sets the mandatory content; a DPA without specific TOM or sub-processor rules is incomplete.
- No signed DPA generally means the processing is unlawful - this is one regulators check.
When Do I Need a Data Processing Agreement?
Which vendors require a DPA?
Any time an external vendor processes personal data on your behalf, you need a DPA. In a modern SME that's most of your stack:
- Hosting and cloud (AWS, Google Cloud, Hetzner)
- Email and marketing (Mailchimp, Brevo, HubSpot)
- CRM (Salesforce, Pipedrive)
- Support tools (Zendesk, Intercom)
- AI tools (ChatGPT via API, Microsoft Copilot, Notion AI)
- HR software (Personio, Workday)
If a vendor can't provide a DPA or refuses to sign one, you may not be able to use them lawfully to process personal data.
For each vendor, check whether it processes the data solely on your instructions (processing, Art. 28 GDPR) or also uses it for its own purposes, for example to train its own models. In the second case the vendor is, to that extent, a joint controller under Art. 26 GDPR, and a DPA alone is not enough (DSK short paper no. 16). AI tools are the category where this check is most often needed.
What Must a DPA Contain?
Which clauses are mandatory under Article 28?
A legally sound DPA includes:
- Subject matter, duration, nature and purpose of the processing.
- The type of personal data and categories of data subjects.
- Obligations and rights of the controller.
- The processor's technical and organisational measures (TOM).
- Rules governing sub-processors (approval and a matching chain of obligations).
- Return or deletion of data at the end of the contract.
- Audit rights for the controller.
Each processing relationship should also appear as a recipient in your ROPA, so your records and your contracts line up.
Common DPA Mistakes
Where do DPAs fall short?
- Vague or missing TOM. "Appropriate measures" is a placeholder - the processor's actual security measures must be described.
- Sub-processors not addressed. Many SaaS vendors use further sub-processors; that chain must be documented and approved.
- Audit rights undefined. You need a documented right to inspect if a dispute arises.
- Outdated versions. When processing changes, the DPA must be updated to match.
Data Processing Agreement Template (DOCX)
DPA vs. Data Processing Addendum
Are they the same thing?
Effectively, yes. "Data Processing Agreement" is the common European term; "Data Processing Addendum" is the format you'll see in US-origin SaaS contracts, attached to the main terms. Both are legally equivalent under GDPR as long as the Article 28 content is present. What matters is the substance, not the label.
ETHYX tracks every DPA against the recipients in your ROPA and flags any vendor missing one, so an unsigned agreement - and the unlawful transfer behind it - doesn't slip through unnoticed.