What is a DPA?
Privacy, law and compliance
In this article, DPA means Data Processing Agreement. It is the written contract or legal agreement that sets out how a processor may handle personal data on behalf of a controller. In AI work, a DPA helps define instructions, security, sub-processors, data subject rights, deletion, audit rights and what the vendor may or may not do with personal data.
What this means
DPA can mean more than one thing. In UK privacy law, people may use DPA to mean the Data Protection Act 2018. In vendor and AI-tool procurement, DPA usually means Data Processing Agreement. This article uses DPA in that second sense: the agreement between a controller and a processor.
A controller decides why and how personal data is processed. A processor acts on the controller's behalf. When a processor handles personal data for a controller, the UK GDPR requires a written contract or other legal act that sets out specific terms.
For AI work, a DPA is not a ceremonial attachment to a software order form. It is the document that should make the vendor relationship operationally usable: what data is processed, for what purpose, under whose instructions, with what safeguards, with which sub-processors and what happens when the contract ends.
Why it matters
AI tools often sit in the middle of live data workflows. They may summarise customer messages, transcribe meetings, classify support tickets, enrich records, search internal documents or generate draft responses. If those workflows contain personal data, the organisation needs to understand the vendor's role.
A DPA matters because it turns broad assurances into specific obligations. It should help the controller demonstrate accountability, respond to DSARs, manage breaches, review security, control sub-processors and ensure personal data is deleted or returned when the service ends.
For small and mid-sized organisations, the practical danger is buying a tool first and asking data questions later. Once staff have built a workflow around a vendor, weak contract terms become harder to fix.
How it works
The ICO says that whenever a controller uses a processor, there must be a written contract or other legal act in place. The contract should set out the subject matter, duration, nature and purpose of the processing, the type of personal data, categories of data subject and the controller's obligations and rights.
The contract must also include terms covering documented instructions, confidentiality, security, sub-processors, assistance with people's rights, assistance with security, breach notification and DPIAs, end-of-contract deletion or return, and audit information.
In an AI procurement process, the DPA should be reviewed alongside the product terms, security information, data retention settings, training-use statements and any international transfer mechanism. The DPA may say "processor", but the actual product configuration may still matter. A vendor that uses customer prompts to improve its own models may raise different questions from a vendor that only processes data to deliver the contracted service.
The agreement should also be read against operational realities. If staff can paste any document into a tool, the contract alone will not prevent excessive data use. If an integration syncs a whole mailbox or document store, the processing description should not pretend the vendor only sees a narrow field list. The DPA should match the configured workflow closely enough that a manager can understand the risk without reading every technical schedule.
Examples
A customer service team adopts an AI summarisation tool for tickets. The DPA should explain that the vendor processes ticket content on documented instructions, protects it, helps with DSARs, controls sub-processors and deletes or returns data at the end of the contract.
A professional services firm connects an AI search tool to its document store. The DPA should support clear limits around indexing, access controls, logs, retention, sub-processors and whether documents are used for any model improvement outside the firm's instructions.
An HR team trials an AI note-taking tool. Before rollout, the organisation should check whether employee, candidate or client personal data is captured, whether special category data could appear in transcripts and whether the DPA supports retrieval, deletion and access requests.
Common misunderstandings
A DPA means the vendor is safe. It does not. It is one control. You still need suitability checks, security review, configuration, user rules and workflow governance.
All SaaS vendors are processors. Not always. Some vendors may be controllers for some purposes, processors for others or joint controllers in limited situations. The role depends on the real processing.
The main contract is enough. The main contract may not include the specific UK GDPR terms needed for processor processing.
Sub-processors are just a vendor problem. The processor needs authorisation and written terms with sub-processors, but the controller should still understand the chain for material AI workflows.
Deletion is automatic. End-of-contract handling should be explicit. Backups, logs, indexes and derived records may need separate attention.
Risks and boundaries
The biggest risk is role confusion. If the organisation assumes the AI vendor is only a processor, but the vendor determines its own purposes for some data, the contract may not match reality. Another risk is weak sub-processor control, especially where AI services depend on multiple infrastructure, model and analytics providers.
There is also a settings risk. A DPA can say the right things while product settings allow data retention, training, broad admin access or unmanaged integrations. Contract review should therefore be paired with technical and workflow review.
A DPA does not make high-risk processing lawful by itself. It does not replace a lawful basis, privacy notice, DPIA where needed, data minimisation, security testing or human review. This article is not legal advice and should not be used as a substitute for reviewing actual contracts.
A further boundary is controller-to-controller sharing. If a supplier decides its own purposes for some data, a processor DPA may not be the right instrument for that part of the relationship. The organisation may need separate transparency, lawful basis and sharing analysis. This is why vendor review should ask what the supplier does with prompts, files, metadata, usage logs and feedback, not only whether a standard DPA exists.
What to do next
Build a simple vendor intake checklist for AI tools that process personal data. Capture the proposed workflow, data categories, people affected, vendor role, data location, sub-processors, retention, training-use terms, DSAR support, breach support and deletion process.
Then map each approved AI vendor to your ROPA. Where the workflow is material, keep the DPA, security documentation and configuration notes together. The aim is not paperwork for its own sake. It is to make sure the operating team can answer basic questions before the tool becomes embedded in daily work.
Use plain questions during procurement. Will our data train or improve shared models? Where is it stored? Who can access it? Which sub-processors are involved? How do we retrieve data for a DSAR? How do we delete prompts, outputs, logs and indexes? A vendor that cannot answer these questions may still be usable for low-risk work, but it should not be quietly embedded in sensitive workflows.
Review negotiation results, not just documents. If the vendor changes a data-use clause, adds a new sub-processor, enables a retention setting or launches a model-improvement feature, the operational record should be updated and the business owner should know what changed before staff rely on the tool.
FAQs
Does DPA mean Data Processing Agreement or Data Protection Act?
It can mean either. In this article it means Data Processing Agreement. When discussing UK legislation, Data Protection Act 2018 should be written out to avoid confusion.
When do we need a Data Processing Agreement?
You need a written contract or other legal act when a controller uses a processor to process personal data on its behalf.
Does a DPA cover AI model training?
It should cover any processing of personal data by the vendor. If prompts, documents or outputs may be used for model improvement, the organisation should review whether that fits the agreed role, purpose and instructions.
Can we accept a vendor's standard DPA?
Sometimes, but it should still be reviewed against the actual workflow. Standard terms may be acceptable for low-risk use and inadequate for sensitive or high-impact processing.
Is a DPA enough for international transfers?
No. If personal data is transferred outside the UK, appropriate transfer safeguards may also be needed. The DPA should be reviewed alongside the transfer position.