Personal data flows through vendor relationships every day: payroll tools, cloud storage, marketing platforms, HR systems. The contract that governs what happens to it is the Data Processing Agreement. Most organisations have one. Far fewer have one that actually holds up under scrutiny.
Data Processing Agreement (DPA): A legally binding contract between a data controller and a data processor that specifies the purpose, scope, and safeguards governing the processing of personal data, as required by GDPR Article 28 and equivalent privacy laws.
What most guides stop short of is the harder part: knowing exactly when a DPA is mandatory, what it must contain, how to negotiate one without giving away too much, and what happens when your vendor portfolio grows to 50 contracts you’re supposed to be monitoring in parallel.
Why a Missing DPA Is a Compliance Failure
Regulators don’t treat a missing DPA as a paperwork oversight. They treat it as a compliance failure.
Under the General Data Protection Regulation (GDPR), processing personal data without a DPA in place can result in fines of up to €20 million or 4% of annual global turnover, whichever is higher. In the US, the California Consumer Privacy Act (CCPA) carries fines of up to $7,500 per intentional violation. Both figures apply per incident, not per audit.
Beyond the financial exposure, a missing or inadequate DPA leaves your organisation without contractual leverage if a vendor suffers a data breach. If there is no documented agreement on breach notification timelines, security standards, or data deletion obligations, you are left managing the fallout with less contractual leverage and a less clearly documented basis for recovery.
What Is the Difference Between a Data Controller, a Data Processor, and a Sub-Processor?
Understanding these three roles is essential before drafting or reviewing any DPA. They determine who bears legal responsibility for what, and who owes whom contractual obligations.
What Is a Data Controller?
The data controller is the organisation that decides why personal data is being processed and how. It holds primary legal accountability for ensuring that processing is lawful, fair, and transparent. If your company collects employee data to run payroll or captures customer data to fulfil orders, your company is the data controller.
What Is a Data Processor?
A data processor handles personal data on the controller’s behalf, strictly following the controller’s documented instructions. It must not use the data for its own purposes within the controller-processor relationship. If it determines the purposes and means of that processing, it may be treated as a controller for that processing and assume the corresponding obligations. Cloud storage providers, payroll vendors, HR software platforms, and marketing tools are all common examples.
What Is a Sub-Processor?
A sub-processor is a third party engaged by the processor to carry out specific processing activities. The processor remains fully liable for the sub-processor’s compliance, even though the controller has no direct contractual relationship with it. Under GDPR Article 28, the processor must obtain written authorisation before bringing any sub-processor on board.
The Three Roles: At a Glance
| Role | Who they are | Example |
|---|---|---|
| Data Controller | Decides why and how personal data is processed | Your company collecting employee payroll data |
| Data Processor | Handles data on the controller’s behalf | Your payroll software vendor |
| Sub-Processor | Engaged by the processor for specific tasks | The vendor’s cloud hosting provider |
When Is a Data Processing Agreement Required?
or equivalent data-processing contract is generally required when an organisation engages a third party to process personal data on its behalf, where the parties have a controller-processor relationship. The specific legal obligation varies by jurisdiction, but the practical trigger is consistent: if a vendor touches your personal data, a DPA belongs in place before processing begins.
When Does GDPR Require a DPA?
GDPR Article 28 makes a DPA mandatory for every controller-processor relationship, with no exceptions based on company size, data volume, or the processor’s geographic location. If the GDPR applies to the processing, an Article 28 contract is required for a controller-processor relationship regardless of where the vendor is headquartered.
The agreement must be in writing. An email confirmation or a blanket reference to a vendor’s standard terms may be insufficient unless it clearly forms part of a written agreement that contains or incorporates the required terms.
Which US State Laws Require a DPA or Equivalent Contract?
The US has no single federal privacy law equivalent to GDPR, but state-level legislation now creates similar obligations across much of the country. As of 2026, at least a dozen states have enacted comprehensive consumer privacy laws, most of which require written contracts with service providers that process personal data.
The table below covers the most widely applicable frameworks:
| State / Law | Contract Required? | Core Obligation |
|---|---|---|
| California (CCPA/CPRA) | Yes | Written contract with service providers and contractors processing personal information |
| Colorado (CPA) | Yes | Data processing agreement with processors |
| Connecticut (CTDPA) | Yes | Contract specifying processor obligations |
| Virginia (VCDPA) | Yes | Data processing agreement required |
| Utah (UCPA) | Yes | Written contract required |
| Texas (TDPSA) | Yes | Contract with service providers |
| Oregon (OCPA) | Yes | Contract specifying processing instructions |
If your organisation operates across multiple US states or processes data from EU residents, you may need a single DPA that satisfies both GDPR and applicable US state requirements simultaneously.
What Must a Data Processing Agreement Contain?
A compliant DPA must address the ten elements set out in GDPR Article 28(3). US state privacy laws follow a broadly similar structure. The following checklist covers every mandatory component.
DPA Requirements
- 1 Scope, purpose, and duration What data is processed, why, for how long, and what happens when the contract ends.
- 2 Personal data and data subjects The types of data involved and the people the data relates to.
- 3 Controller and processor obligations The processor may act only on the controller’s documented instructions.
- 4 Security measures Required technical and organisational safeguards, including access controls and incident response.
- 5 Sub-processor rules Approval requirements and accountability for sub-processors.
- 6 Data subject rights How the processor supports access, rectification, erasure, and portability requests.
- 7 Breach notification The timeline and process for notifying the controller about a personal data breach.
- 8 Audit and inspection rights The controller’s right to assess the processor’s compliance.
- 9 Data deletion or return What happens to personal data when the agreement ends.
- 10 International data transfers The safeguards used when data is transferred outside the EU or UK.
How Do You Draft a Data Processing Agreement?
There are three practical approaches to drafting a DPA, and the right one depends on your vendor relationship, team capacity, and regulatory exposure.
Option 1: Start with a standard template
The European Data Protection Board (EDPB) and national supervisory authorities publish guidance that informs standard DPA templates. Templates are a sound starting point, but they require customisation. A generic template will rarely reflect the specific data flows, processing activities, and risk profile of any individual vendor relationship. Use it as a structure, not a final document.
Option 2: Build from your contract lifecycle management system
If your legal team manages multiple vendor contracts, a contract management platform lets you draft DPAs from a standardised template, track clause variations across your vendor portfolio, and manage renewals from a single system. You apply a consistent playbook rather than rebuilding each agreement from scratch.
Are you set up for a smooth CLM rollout?
Follow five essential steps from design, configuration, and data migration to onboarding and go live. Get expert tips to keep your implementation on track and your team aligned.
Option 3: Negotiate from the processor’s standard terms
Many large SaaS providers publish their own standard DPAs. Reviewing a vendor’s published DPA against your requirements is often faster than drafting from the ground up. The key risk: standard processor DPAs are written to protect the processor. Know which clauses to push back on before you sign.
How Do You Review and Negotiate a DPA?
When reviewing a vendor’s DPA, start with the four clauses most likely to be inadequate in a processor’s standard template: audit rights, sub-processor lists, breach notification timelines, and data deletion obligations.
Most in-house legal teams receive a vendor’s standard DPA and either accept it or escalate to external counsel. There is a more efficient path.
- Focus on four clauses first – Audit rights, sub-processor lists, breach notification timelines, and data deletion obligations are the terms most likely to be either missing or deliberately vague in a processor’s standard template.
- Get the sub-processor list as a formal annex – Vendors routinely include an approved sub-processor list as an attachment to their DPA. Review it carefully. Cloud infrastructure providers, analytics platforms, and customer support tools all appear on these lists. If you object to a sub-processor, your DPA should give you the right to terminate.
- Push for a 24-hour breach notification window – Vendors often default to 72 hours, which mirrors the GDPR controller-to-authority timeline. A 24-hour contractual window can provide time to assess the incident before the controller’s 72-hour notification deadline. GDPR requires the processor to notify the controller without undue delay, so the 24-hour period is a negotiated contract term, not a statutory GDPR deadline.
- Require written confirmation of deletion – “Data will be deleted upon contract termination” is common boilerplate. Written confirmation provides evidence that the obligation was completed, but the deletion obligation can still be enforceable without a separate confirmation process. Require the processor to provide written evidence of deletion within a defined timeframe after termination.
- Flag the governing law clause – International vendors will typically specify their home jurisdiction. The governing-law clause does not determine whether GDPR applies or which regulator has jurisdiction, but it can affect how the contract is interpreted and enforced. Review it alongside the applicable privacy laws and dispute-resolution provisions before signing.
What Is the Difference Between a Data Processing Agreement and a Data Processing Addendum?
A Data Processing Addendum and a Data Processing Agreement are generally used for the same purpose, but their scope depends on the wording and how the document is incorporated into the broader contract. The difference is usually structural, although the wording still determines whether the required obligations are covered.
An addendum is an attachment to an existing master services agreement or terms of service. An agreement is a standalone contract. Large SaaS vendors typically use the addendum format, incorporating their DPA by reference into the main contract. Smaller vendors or custom engagements often use a standalone agreement.
For GDPR purposes, both formats are valid, provided they contain the required content. The label matters far less than the substance inside.
Key definition:
Data Processing Addendum: A contractual attachment to a master services agreement that contains the same substantive data processing obligations as a standalone Data Processing Agreement, and satisfies GDPR Article 28 requirements in the same way.
How Do You Manage Multiple DPAs Across a Vendor Portfolio?
When a vendor portfolio grows beyond a handful of contracts, manual tracking of DPAs becomes a compliance liability rather than a management tool. The answer is treating DPAs as a structured data problem, not a document storage problem.
Consider the scenario most compliance guides skip. Your organisation uses 40 SaaS tools. Each has a DPA. Some are attached to master agreements. Some are standalone. Several have been amended since signing. A handful are due for renewal this quarter. Two vendors just updated their sub-processor lists, and you are contractually required to respond within 30 days.
If you are managing this in a spreadsheet, you are reacting, not managing.
Manual tracking breaks down in three predictable ways as portfolio size grows:
- Renewal dates slip: DPAs do not always align with the main contract term. An expired DPA creates a gap in your compliance documentation.
- Sub-processor changes go unnoticed: Vendors send notifications, but without a system to capture and act on them, response deadlines pass.
- Audit requests become painful: When a regulator or your DPO asks for evidence of your processing agreements, assembling them from email chains and shared drives takes days.
DiliTrust Contract Lifecycle Management (CLM) centralises every DPA alongside its master agreement, extracts key dates and obligations automatically, and triggers renewal alerts before deadlines pass. You get a full audit trail, linked agreements, and structured data across your entire vendor portfolio. Less reliance on spreadsheets and fewer missed deadlines.
How To Manage Multiple DPAs Across a Vendor Portfolio?
DiliTrust CLM gives legal teams one secure place to organize DPAs, link them to master agreements, extract key terms, and track every deadline.
Frequently Asked Questions
What is a Data Processing Agreement in simple terms?
A Data Processing Agreement is a written contract that sets the rules for how a vendor (the data processor) is permitted to handle personal data on behalf of your organisation (the data controller). It defines the purpose of processing, the security measures required, what happens in a data breach, and how data is deleted when the relationship ends. Without an appropriate DPA, the controller-processor relationship lacks the documented Article 28 contract required by GDPR; the DPA itself is not the lawful basis for processing under Article 6.
Is a DPA required in the United States?
There is no single federal law requiring DPAs in the US, but state-level privacy laws create equivalent obligations. California’s CCPA/CPRA, Colorado’s CPA, Virginia’s VCDPA, Connecticut’s CTDPA, and several other states all require written contracts with service providers that process personal data. If your organisation also handles data from EU residents, GDPR’s DPA requirements apply regardless of where your company is based.
Does a DPA have to be signed by both parties?
GDPR requires the agreement to be “in writing,” which the regulation confirms includes electronic format. The terms must be clearly incorporated into the parties’ agreement. A mutual signature is not always required, but a checkbox or continued use alone may not establish clear acceptance or incorporation of the required terms; a mutual signature provides stronger evidential weight, particularly in the event of a dispute or audit.
What is the difference between a DPA and an NDA?
A Non-Disclosure Agreement (NDA) protects confidential business information from unauthorised disclosure. A Data Processing Agreement governs the legal conditions under which a processor may handle personal data. An NDA does not satisfy GDPR Article 28 requirements, and a DPA does not replace an NDA. Most vendor relationships with access to personal data benefit from having both in place.
What happens if a company processes personal data without a DPA?
Processing personal data without a DPA is a compliance violation in a controller-processor relationship where the required Article 28 contract is absent. Supervisory authorities, including the UK ICO and France’s CNIL, have issued fines specifically for the absence of adequate data processing contracts. Beyond the regulatory exposure, your organisation loses all contractual leverage in the event of a breach, a sub-processor dispute, or a data deletion failure.
How long should a DPA remain in force?
A DPA should remain in force for the full duration of the underlying service agreement, plus any period required to complete data deletion or return. Most DPAs include termination provisions aligned with the master contract, with obligations such as written deletion confirmation surviving the end of the agreement itself.
Keep every DPA visible, current, and audit-ready
See how DiliTrust Contract Lifecycle Management helps legal teams centralize vendor contracts and stay in control from drafting through renewal.
