DPA Agreement Requirements: What a Data Processing Agreement and Data Processing Addendum Must Contain
A DPA is the document that names which vendors are allowed to touch personal data on your behalf and what they owe you when someone asks for their data back. Signing one takes an afternoon. Honoring the clause that actually costs you something, the one where your processor helps you answer an access or deletion request inside your deadline, means being able to say which vendor holds what about a specific person. Obtainer answers that question across your systems and keeps the evidence that you asked it.
found
scanned
Assembling the cover letter from the template...
Helps you comply, not legal advice
In short
A data processing agreement, usually shortened to DPA and often issued as a data processing addendum to an existing contract, is the written agreement that governs a vendor processing personal data on your behalf. Under the GDPR it is required by Article 28(3), which says the contract must set out the subject matter and duration of the processing, its nature and purpose, the type of personal data and the categories of data subjects, and must bind the processor to eight specific duties: process only on your documented instructions, ensure that everyone authorized to handle the data is under a confidentiality commitment, apply the Article 32 security measures, engage another processor only under the conditions in Article 28(2) and (4), assist you in responding to data subject rights requests under Chapter III, help you meet your obligations under Articles 32 to 36 covering security, breach notification and impact assessments, delete or return all the personal data at the end of the service at your choice, and make available the information needed to demonstrate compliance and allow for audits. Article 28(9) says the contract must be in writing, including in electronic form, so a click-accepted online DPA counts. Article 28(4) adds the part vendors forget: if a subprocessor fails, the original processor remains fully liable to you.
US state privacy laws require the same paperwork under different words, and one state requires something else entirely. Most of the comprehensive state laws follow the Virginia template at Va. Code 59.1-579(B), which requires a contract setting out instructions, nature and purpose, type of data, duration and the parties' rights and duties, plus a confidentiality duty, deletion or return of the data at the controller's direction at the end of the service, an obligation to make available what is needed to demonstrate compliance, an assessment right, and a written subcontractor contract on the same terms. Colorado at C.R.S. 6-1-1305(5) goes furthest: the processor either cooperates with your audits or arranges a qualified independent auditor at least annually and at the processor's own expense, and it must give you an opportunity to object before engaging a subcontractor. Utah at 13-61-301 and Iowa at 715D.5 are the thinnest in the country, requiring the descriptive terms, a duty of confidentiality and subcontractor flow-down, with no delete-or-return clause and no assessment right at all.
California does not use the word processor. The CCPA regulations at 11 CCR 7051 require a contract with a service provider or contractor written as prohibitions: no selling or sharing the personal information, no retaining, using or disclosing it for any purpose other than the specific business purposes named in the contract, no use outside the direct business relationship, no combining it with personal information from other sources, and a duty to give the same level of privacy protection the CCPA requires of you. Section 7051(a)(7) contemplates you verifying that with assessments, audits or other technical and operational testing at least once every 12 months, and 7051(a)(10) requires the contract to settle how consumer requests are handled between you. The consequence of a missing clause is the part most teams have never priced: a recipient that does not have a contract complying with 7051(a) is not a service provider or contractor, and your disclosure of personal information to it may be treated as a sale or sharing, which pulls in opt-out rights, notice obligations and a Do Not Sell or Share link you had not planned for. Section 7053 then adds a separate contract requirement for third parties, which has no equivalent in any other state.
Underneath all of these sits one identical operational promise: your processor will help you answer an access, deletion, correction or portability request inside your statutory deadline. That promise is only worth what your data map is worth.
Obtainer covers the operational half. It intakes the request, searches your product database, warehouse, support desk, billing, marketing tools and vendor systems, reports the source system behind every record it surfaces, compiles one reviewable manifest, tracks the statutory clock, and keeps a timestamped record of what was searched and when. Nothing is disclosed or erased automatically. A human reviews, redacts and approves. Obtainer helps you comply. It is not legal advice, so drafting, negotiating and signing the DPA itself stays with your counsel. Self-serve from a planned $49/mo.
Last updated August 2026
Why it fits
Privacy, legal, and vendor management teams who sign DPAs and then have to honor them.
In California, a missing clause turns a vendor transfer into a sale
This is the single most expensive detail in US vendor contracting and it is not in the statute, it is in the regulations. Under 11 CCR 7051 a business must have a contract with each service provider and contractor containing a specific set of prohibitions. A person who does not have a contract complying with subsection (a) is not a service provider or a contractor, and the business's disclosure of personal information to that person may be considered a sale or sharing for which the consumer must be given an opt-out. That reclassification is not a paperwork foul. It changes what your privacy notice has to say, obliges you to honor opt-out signals for that flow, and puts a category of disclosure on your books that your last CCPA disclosure said did not exist. A GDPR Article 28 DPA signed by a European vendor does not fix it, because the required California terms are written as prohibitions on use rather than as duties of a processor.
Every DPA promises help with data subject requests. That is a discovery commitment with a clock on it.
Article 28(3)(e) requires the contract to oblige the processor to assist you, by appropriate technical and organizational measures, in fulfilling your obligation to respond to data subject rights requests. The state laws say the same thing in plainer language, and 11 CCR 7051(a)(10) requires your service provider contract to specify either that the vendor enables you to comply with consumer requests or that you inform it of a request and give it what it needs to act. Read that from the other direction and it is a commitment about response time made on behalf of systems you do not operate. When a request lands, the question is not whether the clause exists. It is which of your forty vendors holds anything about this person, who at each one you ask, and whether their answer arrives with enough of your 45 days left to review it.
Delete or return at the end of the service is the clause nobody can evidence
Article 28(3)(g) and the state equivalents require the processor to delete or return all the personal data at the end of the provision of services, at your choice, unless retention is required by law. California approaches the same problem from the enforcement side: 7051(a)(9) contemplates requiring the vendor to provide documentation that it no longer retains or uses the information after a deletion request. Both are easy to sign and hard to prove. Offboarding a vendor usually ends with an email saying the data was deleted, filed by someone who has since left. What an auditor or a regulator asks for later is which categories of data that vendor held, when the instruction went out, and what came back. Running offboarding through the same discovery-and-record process you use for requests turns that from a memory into a record.
Your subprocessor list is the search scope for every request you will ever answer
The DPA chain is the only authoritative map of where personal data legitimately goes. Article 28(2) requires prior authorization before your processor adds another, Colorado requires an opportunity to object before a subcontractor is engaged, and Utah and Iowa both require flow-down contracts on the same duties. The EDPB went further in Opinion 22/2024, taking the position that a controller should have the identity of every processor and subprocessor in the chain readily available, including name, address and a contact person, which makes the register your obligation rather than your vendor's. Teams treat maintaining that list as a compliance chore. It is the same artifact as your search scope: the set of places you have to look when someone asks what you hold about them. When the list and the reality diverge, and they diverge quietly through a free trial, a departmental credit card or an integration switched on for one project, you get incomplete responses and disclosures you cannot account for. Obtainer reports the source system behind every record it finds, which is how the two lists get reconciled against evidence rather than against memory.
More use cases
Related features
Questions
Common questions about this
What is a DPA agreement?
A DPA agreement is a data processing agreement: the written contract between a business that decides why personal data is processed and a vendor that processes it on that business's behalf. It fixes what the vendor may do with the data, what security it must apply, whether it can use subcontractors, how it helps with data subject requests, and what happens to the data when the relationship ends. It is required by GDPR Article 28(3) in Europe and by every comprehensive US state privacy law, though California writes its version as a set of prohibitions rather than as processor duties.
What should a data processing agreement include?
At minimum the six descriptive terms and eight duties in GDPR Article 28(3): subject matter, duration, nature and purpose of the processing, the type of personal data, the categories of data subjects, and the parties' rights and obligations, plus processing only on documented instructions, confidentiality commitments from authorized personnel, Article 32 security measures, controls on engaging subprocessors, assistance with data subject rights requests, assistance with security and breach obligations, deletion or return of the data at the end of the service, and audit and information rights. For US vendors add the California terms in 11 CCR 7051, which are drafted as prohibitions on selling, sharing, retaining, combining and using the data outside the specific business purposes named in the contract.
Is a data processing agreement a legal requirement?
Yes, in essentially every jurisdiction that regulates personal data. GDPR Article 28(3) makes the written contract mandatory and Article 28(9) allows electronic form. Every comprehensive US state privacy law requires a contract between the controller and the processor before processing begins, and California requires one with service providers, contractors, and separately with third parties under 11 CCR 7053. It is not a best practice you can defer to the next contract cycle. In California the absence of compliant terms changes the legal character of the disclosure itself.
What is the difference between a data processing agreement and a data processing addendum?
Almost nothing in substance. A data processing agreement is a standalone contract. A data processing addendum is the same set of terms attached to an existing master services agreement or terms of service, which is how most SaaS vendors publish theirs so it can be incorporated by reference at signup. Both satisfy the written-contract requirement, and GDPR Article 28(9) accepts electronic form. What matters is whether the required clauses are present and whether the document actually binds the entity that holds the data, not which of the two names appears at the top.
Does the CCPA require a data processing agreement?
It requires a contract, but not one that looks like a GDPR DPA. California has no controller and processor. It has businesses, service providers, contractors and third parties, and 11 CCR 7051 sets out what the contract with a service provider or contractor must say: it must prohibit selling or sharing the information, identify the specific business purposes rather than describing them generically, prohibit retention, use or disclosure outside those purposes, prohibit use outside the direct business relationship, prohibit combining the data with information from other sources, and require the recipient to provide the same level of privacy protection the CCPA requires of you. A European-style DPA dropped into a California vendor file usually misses several of these.
Do I need a DPA with every vendor?
You need one with every vendor that processes personal data on your behalf, which is a wider set than most inventories show. Payroll, support desks, email and marketing platforms, analytics, cloud hosting, backup providers, contact center outsourcers, recruiting tools and AI features that send text to a model provider all qualify. You do not need a processor contract with a party that determines its own purposes for the data, but that relationship needs its own paperwork: in California, 11 CCR 7053 imposes separate contract requirements for third parties, and under the GDPR a controller-to-controller transfer needs its own lawful basis. The safest rule is that if personal data leaves your systems, some contract has to cover it.
Does a data processing agreement need to be signed?
It needs to be in writing and binding, which is not the same as wet-signed. GDPR Article 28(9) says the contract or other legal act must be in writing, including in electronic form, so a click-accepted online DPA, a countersigned PDF or terms incorporated by reference into a signed master agreement all work. The state laws likewise say a contract shall govern the processing without prescribing a signature ceremony. The practical failure is not the signature. It is that nobody can locate the executed version, or the entity named in it is not the entity that actually holds the data.
How does a DPA affect how we answer a data subject access request?
It sets the terms of the help you can demand and the deadline you are still accountable for. Article 28(3)(e) obliges the processor to assist you with rights requests, and 11 CCR 7051(a)(10) requires your California contracts to specify how consumer requests are routed. What none of them change is that the response is yours: the 45-day state clock and the GDPR one-month clock run against you while you wait on vendors. That is why the subprocessor list in your DPA chain is worth treating as an operational asset. It tells you where to look, who to ask, and how much of the deadline you can afford to spend asking.
Run a data subject access request end to end
Obtainer finds where a person's data lives across your systems, compiles it into one manifest, drafts the deadline-safe response, and tracks the GDPR and CCPA clock. You review, redact, and approve what gets disclosed. Helps you comply; not legal advice.