Data Processing Agreement Requirements by State: What Your Vendor Contracts Have to Say

Every comprehensive US state privacy law requires a written contract before a vendor may process personal data on your behalf, and the required terms are close enough between them that one well-drafted template covers most of the country. Three states break the pattern. Colorado asks for more than the rest, Utah and Iowa ask for less, and California asks for something structurally different that a European-style agreement usually fails to provide.

The short version: build to the Virginia template, add Colorado's audit and subcontractor mechanics, and treat California as a separate document rather than an appendix. The reason California cannot be folded in is not stylistic. Under the CCPA regulations a recipient without a compliant contract is not a service provider at all, and the disclosure to it may be treated as a sale.

Does every state require a data processing agreement?

Yes, in substance. Every US state with a comprehensive consumer privacy law requires a contract governing the relationship between the party that decides why data is processed and the party that processes it. Most of them use the GDPR's controller and processor vocabulary and copy Virginia's list of required terms almost word for word. California uses businesses, service providers, contractors and third parties instead, and writes its requirements as prohibitions on what the recipient may do rather than as duties it owes you.

What none of the state laws do is call the document a DPA. That name comes from GDPR Article 28, and it stuck because most US companies met the requirement for the first time when a European customer sent them a data processing agreement to sign. The state statutes just say a contract shall govern the processing.

Data processing agreement requirements by state

The table compares the three clauses that differ most across the state laws. Every row also requires the descriptive terms (instructions, nature and purpose, type of data, duration, and the parties' rights and duties), a confidentiality duty for personnel with access, and a written subcontractor contract on the same obligations, so those are left out rather than repeated six times. One caveat on that last one, covered in its own section below: the contract is required everywhere, but what you are told before it is signed is not. Statutes in this area get amended every session, so confirm a row against the current text before you build a template on it.

Why a GDPR Article 28 DPA does not satisfy California

Article 28(3) is a list of eight duties the processor takes on: process only on documented instructions, keep personnel under confidentiality, apply Article 32 security, control subprocessors, assist with data subject rights, assist with breach and impact assessment obligations, delete or return the data at the end, and allow audits. A vendor signs it and inherits a job description.

The California regulations at 11 CCR 7051 do the opposite. They require the contract to prohibit the service provider or contractor from selling or sharing the personal information, from retaining, using or disclosing it for any purpose other than the specific business purposes named in the contract, from using it outside the direct business relationship, and from combining it with personal information from other sources. They also require it to identify those business purposes specifically rather than generically, which rules out the catch-all recital that most master services agreements rely on, and to require the recipient to provide the same level of privacy protection the CCPA requires of you.

An Article 28 addendum can be fully compliant in Europe and contain none of those five prohibitions. That is the trap: the file looks complete because there is a signed DPA in it.

What happens if a vendor contract is missing the required terms?

In most states, a gap in the contract is a compliance defect you fix at the next renewal. In California it changes the legal character of the data flow. A person who does not have a contract complying with 7051(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 of personal information, for which the consumer must be given the right to opt out.

Follow that through and the consequences land somewhere you did not budget. A disclosure you have always described internally as vendor processing becomes a sale. Your privacy notice, which almost certainly says you do not sell personal information, is now inaccurate. You owe a Do Not Sell or Share My Personal Information link and you have to honor opt-out preference signals for that flow. And the opt-outs you should have been honoring stretch backward, not just forward. Section 7051 also makes the point that a business that never exercises its contractual rights loses the argument that it was unaware of the vendor's unauthorized use.

The subcontractor clause is not as uniform as it looks

Every state in the table requires the same thing on paper: if your processor hands the data to someone else, there must be a written contract binding that party to the same obligations. Because the requirement is universal it gets treated as boilerplate. What is not universal is whether anyone has to tell you it happened.

Colorado is the exception, and it is the only one. Under C.R.S. 6-1-1305(5) a processor may engage a subcontractor only after giving the controller an opportunity to object, and then under a written contract carrying the processor's own obligations. That is the same mechanism as GDPR Article 28(2), which requires prior specific or general written authorization and, under a general authorization, obliges the processor to inform you of intended additions or replacements so you can object. Virginia, Texas, Utah and Iowa require the flow-down contract and give you no notice right and no veto. The chain can lengthen without anything reaching you.

California is different again. It does not use the word subcontractor much either, but 11 CCR 7051(b) requires that a service provider or contractor engaging another entity enters a contract complying with the same rules. Combine that with the reclassification rule above and a broken link two parties down can be enough to turn the original disclosure into a sale. So the practical position across the country is that your objection rights come from what you negotiated rather than from the statute, in every state but one, which is worth remembering before accepting a vendor DPA that reserves the right to update its own subprocessor page whenever it likes. The full breakdown of authorization, notice, flow-down and liability sits in the guide to processor and subprocessor rules.

The three clauses worth negotiating

Delete or return at the end of the service. Virginia, Colorado, Texas and Iowa all require it and let you choose which. Utah does not require it at all, and California addresses it from the enforcement side instead, at 7051(a)(9), by supporting a right to require documentation that the vendor no longer retains or uses the information. Signing this clause is trivial. Evidencing it eighteen months later, when the vendor has been offboarded and the person who ran the offboarding has left, is where it fails. What a regulator asks for is which categories of data that vendor held, when the deletion instruction went out, and what came back.

The assessment right. Colorado is the strictest jurisdiction in the country on this and almost nobody prices it correctly. The processor either cooperates with audits and inspections by you or your designated auditor, or it arranges a qualified independent auditor at least annually and at its own expense, and gives you the report on request. Utah, Iowa and California require no assessment clause. If you sell software, that asymmetry is worth knowing before a Colorado customer sends you their paper.

Assistance with consumer requests. This is the clause that generates actual work. Article 28(3)(e) requires the processor to assist you, by appropriate technical and organizational measures, in responding to data subject rights requests. Virginia, Colorado, Texas and Iowa impose the equivalent duty, and California's 7051(a)(10) requires the contract to settle whether the vendor enables you to respond or whether you forward the request with what the vendor needs to act. Utah is the outlier: section 13-61-301(3) names security of processing and breach notification and stops there.

The clause is a promise about a data map you may not have

Every version of the assistance clause assumes a fact that is often untrue: that when a request arrives, you know which of your vendors holds something about that person. The statutory clock runs against you, not against them. Eighteen of the twenty comprehensive state laws give you 45 days with one 45-day extension, Florida allows only 15 extra days, and Iowa allows 90 plus 45. Whatever the number, it is spent while you email vendors and wait.

Two things make that worse than it sounds. First, the subprocessor chain: Article 28(4) makes your processor fully liable for its own subprocessors, but liability is not the same as an answer, and a support platform's analytics vendor is still a place your customer's data sits. Second, the vendors nobody wrote down. Contract registers capture what procurement negotiated. They miss the free tier someone connected to production, the trial that never ended, and the tool a department expensed. The fastest inventory of those is usually financial rather than legal, because a read-only view of cloud and SaaS spend surfaces recurring charges the vendor register never captured, and each of those charges is a candidate processor you have no contract with.

Do I need a data processing agreement 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 desk, email and marketing platforms, product analytics, cloud hosting, backup, contact center outsourcers, recruiting tools, and any AI feature that sends customer text to a model provider. You do not need a processor contract with a party that decides its own purposes for the data, but that relationship needs its own paperwork rather than none. California imposes separate third-party contract requirements at 11 CCR 7053, which no other state does, and under the GDPR a controller-to-controller transfer needs its own lawful basis.

The practical test is simpler than the legal one. If personal data leaves your systems, some contract has to cover it, and you should be able to name the document in under a minute.

How to build one contract that works everywhere

Take the Virginia list as the base, since most states copied it. Add Colorado's two extras: the opportunity to object before a subcontractor is engaged, and the annual independent audit option at the processor's expense. Add the California prohibitions from 7051(a) as a separate exhibit rather than trying to rewrite the body, because they are prohibitions on use and the rest of the document is a list of duties, and mixing the two produces a contract nobody can interpret at renewal. Name the specific business purposes rather than describing them generically. Keep an accurate subprocessor list, and treat it as an operational document instead of a compliance artifact, because it is the same list as the search scope for every access and deletion request you will ever answer.

Then close the gap between the paper and the systems. If your business is the processor in these relationships, your customers' agreements bind you to help them meet deadlines you do not control, which is why SaaS companies tend to feel this first. If you are the controller, the clause you signed is only worth what your data discovery can prove. Obtainer intakes the request, searches your product database, warehouse, support desk, billing and vendor systems, reports the source system behind every record it finds, and keeps a timestamped log of what was searched and when. A human reviews and approves anything disclosed. Obtainer helps you comply; it is not legal advice, and drafting the agreement itself stays with your counsel.

For the threshold question of which laws reach your business in the first place, start with which state privacy laws apply to your business, and note that the contract duty is one of the few obligations that can reach you even when the thresholds do not, because it flows down from a customer who is in scope. If California is your main exposure, the operational side is covered on the CCPA compliance page.