A data processing agreement is a binding contract that spells out how an outside vendor must handle personal data it processes on your behalf. Under the EU’s General Data Protection Regulation and roughly 20 US state privacy laws, you need one signed before any third party starts touching that data. Get it wrong or skip it entirely, and you face regulatory fines, direct liability for breaches you didn’t cause, and a compliance hole that’s hard to patch after the fact.
Who the Agreement Is Between
Every DPA sits between two parties. The data controller is the organization that decides why personal data is collected and what happens to it. Run an online store that gathers shipping addresses, payment details, and order histories? You’re the controller. You set the purpose and the rules.
The data processor is the outside organization that handles that data according to your instructions. A cloud host storing your customer database, a payroll vendor calculating paychecks, an email platform sending your newsletters. Processors don’t decide what to do with the data. They do what you tell them to do, within the boundaries the DPA sets.
The distinction matters because the law holds each role to different obligations. Controllers bear the primary responsibility for choosing trustworthy processors and ensuring data stays protected. Processors must follow the controller’s documented instructions and can face direct liability if they step outside those instructions or ignore their own regulatory duties.
When You Need One
Whenever personal data leaves your organization and lands with a third party that processes it for you, a DPA has to be in place first. GDPR Article 28 makes this explicit: a binding contract between every controller and processor before processing begins.1GDPR Info. Art. 28 GDPR – Processor
In the United States, roughly 20 states now have comprehensive privacy laws, and nearly all of them require written contracts governing how processors handle personal data. Some laws use “service provider agreement” or “contractor agreement” instead of DPA, but the core obligation is the same: enforceable contractual terms controlling what the processor can and cannot do.
Common situations that trigger the requirement include outsourcing to a cloud hosting provider, using a customer relationship management platform, running analytics tools that touch customer data, hiring a payroll company, or working with a marketing agency that handles your contact lists. If personal data is shared with, transferred to, or stored by any external service, a DPA should already be signed before that data moves.
What Has to Be in the Contract
GDPR Article 28 sets out the mandatory contents. US state privacy laws track these requirements closely, though wording varies. Every DPA needs to cover the following ground.
Scope and Purpose
The DPA has to describe the subject matter and duration of the processing, the types of personal data involved, the categories of people whose data will be processed, and the specific purpose.1GDPR Info. Art. 28 GDPR – Processor Vague language is a red flag. “Marketing purposes” is too broad. “Sending promotional emails to opted-in customers using their email addresses and first names” is specific enough to be enforceable.
Documented Instructions
The processor can only handle personal data based on the controller’s documented instructions. If a local law compels the processor to do something outside those instructions, it must notify the controller before proceeding, unless the law itself prohibits notification.1GDPR Info. Art. 28 GDPR – Processor Without this clause, you’ve handed over data with no guardrails.
Security Measures
The processor has to put in place technical and organizational safeguards appropriate to the risk. The GDPR specifically references encryption, the ability to maintain confidentiality and availability of processing systems, the ability to restore access after an incident, and regular testing of those measures.2Information Commissioner’s Office. What Needs to Be Included in the Contract? Most DPAs translate this into concrete requirements like access controls, logging, vulnerability assessments, and incident response plans.
Confidentiality
Every person at the processor’s organization who touches the personal data must be bound by a confidentiality obligation, either by contract or by statute.1GDPR Info. Art. 28 GDPR – Processor A promise of security in the abstract isn’t enough. The actual people handling data have to be legally bound to keep it confidential.
Data Subject Rights
When an individual submits a request to access, correct, or delete their personal data, the controller is responsible for responding. The DPA has to require the processor to help fulfill those requests through appropriate technical and organizational measures.2Information Commissioner’s Office. What Needs to Be Included in the Contract? In practice, the processor needs systems capable of locating, exporting, and deleting a specific individual’s data on request.
Breach Notification
The processor must notify the controller without undue delay after discovering a personal data breach.3GDPR Info. Art. 33 GDPR – Notification of a Personal Data Breach to the Supervisory Authority Many DPAs go further and specify a concrete window, 24 or 48 hours being common, because “without undue delay” is vague enough to invite disagreement in the middle of a crisis. The agreement should also require the processor to help the controller meet its own notification obligations to regulators and affected individuals.2Information Commissioner’s Office. What Needs to Be Included in the Contract?
Sub-Processors
Processors often rely on their own vendors to handle parts of the work. The GDPR prohibits a processor from engaging a sub-processor without the controller’s prior written authorization, which can be specific (approving each one individually) or general (allowing sub-processors as a category, with an obligation to notify the controller of changes so the controller can object).1GDPR Info. Art. 28 GDPR – Processor The sub-processor has to be bound by the same data protection obligations as the processor itself.
Data Return and Deletion
When the contract ends, the processor has to either delete all personal data or return it to the controller, at the controller’s choice. Existing copies must be destroyed unless a legal obligation requires retention.1GDPR Info. Art. 28 GDPR – Processor A good DPA specifies the format for returned data, the timeframe for deletion, and how the processor will certify that deletion actually happened.
Audit Rights
The controller keeps the right to audit the processor’s compliance. The processor has to make all relevant information available and cooperate with audits or inspections carried out by the controller or an independent auditor the controller appoints.2Information Commissioner’s Office. What Needs to Be Included in the Contract? Some processors push back on on-site inspections by offering third-party audit reports (SOC 2, ISO 27001) instead. That can be reasonable, but the contractual right to audit directly should still exist as a fallback.
International Transfers Need More Than a DPA
If your processor sits outside the European Economic Area, the DPA alone isn’t enough. You also need a legal mechanism authorizing the cross-border transfer. The most widely used tool is the European Commission’s Standard Contractual Clauses, adopted in June 2021, which provide pre-approved contract language for transfers to countries without an EU adequacy decision.4European Commission. New Standard Contractual Clauses – Questions and Answers Overview
For controller-to-processor and processor-to-processor transfers, the SCCs already incorporate the Article 28 DPA requirements. You can use the SCCs as your DPA and your transfer mechanism in a single document rather than maintaining two separate agreements.4European Commission. New Standard Contractual Clauses – Questions and Answers Overview If the processor is in a country with an adequacy decision, SCCs aren’t required for the transfer, though you still need a DPA covering the Article 28 obligations.
Liability When Something Goes Wrong
Under the GDPR, both controllers and processors can be held directly liable to individuals who suffer damage from a data protection violation. A processor is on the hook for damage caused by processing that violated its specific GDPR obligations or that went beyond the controller’s lawful instructions. Where both share responsibility, each can be held liable for the full amount so the affected person gets compensated, and the party that overpays can then claim back the other’s share.
A well-drafted DPA addresses this with an indemnification clause that allocates financial responsibility for breach-related costs: notification expenses, regulatory fines, legal fees, and compensation to affected individuals. Without clear indemnification terms, standard limitation-of-liability caps (often pegged to the contract’s annual fees) can leave you absorbing most breach costs even when the processor caused the problem.
Fines for Missing or Weak Agreements
The GDPR treats a missing or inadequate DPA as a violation of Article 28 and puts it in the higher penalty tier. Regulators can impose fines up to €20 million or 4% of the organization’s total worldwide annual revenue from the prior year, whichever is greater.5GDPR Info. Art. 83 GDPR – General Conditions for Imposing Administrative Fines Those are ceiling figures. Actual fines depend on the severity of the violation, the number of people affected, and whether the organization cooperated with the investigation. European regulators have issued fines in the tens of millions for processor-related failures.
In the United States, enforcement penalties vary by state but typically run between $7,500 and $10,000 per violation. Because penalties can apply per affected individual, aggregate fines from a single incident involving thousands of consumers can reach into the millions. State attorneys general, and dedicated privacy agencies in some states, can bring enforcement actions when businesses fail to include required contractual terms in their processor agreements.
Beyond the fines, operating without a DPA leaves you without any contractual mechanism forcing the processor to follow instructions, report breaches promptly, delete data at the end of the relationship, or cooperate with audits. Regulators will still hold you responsible as the controller for choosing a processor that lacked adequate safeguards, and the DPA is the document they ask for first when examining a controller-processor relationship.1GDPR Info. Art. 28 GDPR – Processor
Standalone Agreement or Addendum
A DPA can take two forms. A standalone agreement is self-contained and covers every required element from scratch. It works well when two parties are entering a new relationship and can negotiate all terms at once. A data protection addendum, by contrast, bolts onto an existing master services agreement and adds the required data protection clauses without reopening the broader contract. Addendums are more common in practice because most processor relationships start with a services contract that was already signed before anyone thought about privacy compliance.
The legal effect is the same either way. Both are binding contracts that satisfy the Article 28 requirement. The practical difference is that addendums tend to be shorter and narrowly focused on processing specifics, while standalone agreements can address liability, dispute resolution, and governing law in greater detail. If your master services agreement already has weak limitation-of-liability terms, an addendum may not be the right vehicle to fix them. Renegotiating the underlying contract or using a standalone DPA gives you more room to get the indemnification and liability terms right.