GDPR Data Processing Agreement (DPA)

Under the EU and UK GDPR, whenever you (the 'controller') use a vendor (the 'processor') to process personal data, Article 28 requires a written contract, the Data Processing Agreement, that binds the processor to specific obligations: processing data only on your documented instructions, keeping it confidential, implementing appropriate security, assisting with data-subject requests, notifying you of breaches, and either deleting or returning data at the end of the relationship. Without a DPA in place, using the vendor on EU or UK personal data is itself a compliance gap.

The DPA is where the real detail lives

For AI tools, the DPA is usually where the vendor's subprocessor list, data-retention commitments and international-transfer mechanism (Standard Contractual Clauses, an adequacy decision, or the EU-US Data Privacy Framework) actually live, more so than the public privacy policy, which is written for end users rather than for compliance review. When you are checking GDPR readiness, the DPA is the document to actually read, not just confirm exists.

Necessary, but not the whole story

A DPA is necessary but doesn't answer every GDPR question on its own. You still need to confirm the lawful basis for the processing, whether the tool supports data-subject rights in practice (export, deletion), and whether EU data residency is offered if that matters for your risk tolerance: some vendors process globally by default and only add regional options on higher tiers.

Now table stakes for business tools

Almost every AI vendor aimed at business customers now offers a standard DPA; it has become table stakes rather than a differentiator. Where vendors genuinely differ is EU data residency, subprocessor transparency, and whether the DPA is available to every plan or gated to enterprise contracts. ModelCharter's GDPR compliance hub and the AI Tool Risk Directory flag which tools publish a DPA.