5 Copy Ready Data Processing Agreement Clauses for US In House Counsel
A data processing agreement (DPA) is the contract that tells a vendor exactly what it can do with your company’s personal data, and it’s non-negotiable the moment a third party touches that data on your behalf. The rule of thumb is simple: no data flows to a vendor until the DPA is signed. Before you get there, check three things: does the FTC’s reasonable security standard apply, does California’s service provider rules kick in, and does any protected health information mean you need a HIPAA business associate agreement (BAA) instead of, or alongside, the DPA.
TL;DR:
Most companies must incorporate a DPA whenever a vendor handles personal data, especially for cloud, analytics, payroll, or customer support services.
Core clauses should specify data scope, processing instructions, security measures, subprocessor obligations, breach notification timelines, and data destruction procedures.
For vendors handling protected health information, a HIPAA Business Associate Agreement is mandatory, replacing or supplementing the standard DPA.
Continuous verification through audited security reports and regular compliance checks are essential, with a focus on SOC 2 Type II, ISO 27001, and penetration testing.
Managing a DPA program effectively requires ongoing vendor risk assessment, routine evidence collection, and a dedicated legal process, not just signing templates.
Chief Legal Officechieflegaloffice.comMake Your DPA Program WorkChief Legal Office helps technology companies organize contracts, governance, risk, and recurring legal work through a fractional in-house legal department.Learn about Chief Legal Office
Table of Contents
What Is a Data Processing Agreement, and When Do You Need One?
Core Clauses Every DPA Should Include
Security Verification: Making the Contract Promises Enforceable
HIPAA, CCPA, and Cross-Border Rules That Change Your DPA
Copy-Ready Clause Language You Can Adapt
Negotiating a DPA: Priorities and Red Flags
How an In-House Legal Team Actually Runs a DPA Program
The Gap Between a DPA Template and a DPA Program
Getting Ongoing Help With Your DPA Program
Sources
FAQ
What Is a Data Processing Agreement, and When Do You Need One?
A DPA is a contract between a data controller (the company that decides why and how personal data gets used) and a data processor (the vendor that handles that data on the controller’s instructions). If you’re a SaaS company collecting customer data, you’re usually the controller. Your cloud hosting provider, your analytics tool, your payroll processor, and any contractor with database access are usually processors.
You need a DPA whenever a vendor touches personal data on your behalf, not just when a contract “feels sensitive.” That includes:
Cloud infrastructure and SaaS platforms storing customer or employee data
Analytics and marketing tools that ingest user-level data
Payroll and HR platforms handling employee Social Security numbers and bank details
Contractors or freelancers with direct access to your production database
Customer support tools that log tickets containing personal information
A DPA is not the same thing as an NDA. An NDA protects confidential business information from disclosure. A DPA governs what a processor can do with personal data, how long it can keep it, and what happens when the relationship ends. Most companies attach the DPA as an addendum (sometimes literally called a “data processing addendum”) to a master services agreement (MSA), rather than negotiating a standalone contract every time. And if the vendor touches protected health information, the DPA gets replaced or supplemented by a HIPAA BAA, which carries its own statutory content requirements that a generic DPA doesn’t satisfy.
Core Clauses Every DPA Should Include
A DPA that just restates privacy law in different words isn’t doing its job. It needs to specify actual processing operations and the technical and organizational measures (TOMs) tied to the risks your vendor relationship actually creates. Here’s what belongs in a functioning DPA, along with what to watch for during review.
Scope and purpose. Name the categories of data (names, emails, payment data, health records) and the specific purpose of processing. Vague scope language (“as needed to provide services”) is a red flag, not boilerplate.
Instructions and duration. The processor may only act on your documented instructions, and the agreement should state how long processing continues and what triggers termination.
Return or destruction. When the relationship ends, does the vendor return your data, delete it, or both? Ask for a certificate of destruction, not just a promise. Enterprise contracts, like the AT&T standard contractual clauses amendment filed with the SEC, show how larger companies build retention tables and destruction certificates directly into the contract language.
Security TOMs. Encryption in transit and at rest, access controls, employee training, and incident response procedures should all be named, not implied.
Subprocessors. The vendor’s own subcontractors need to be bound by equivalent obligations. This is the “back to back” flow down requirement, and it’s the clause most often missing when a vendor outsources part of its infrastructure.
Audit and cooperation rights. You need the contractual right to verify compliance, even if you rarely exercise it. Cooperation obligations should cover regulatory inquiries and litigation holds too.
Breach notification. Set a specific timeline (72 hours is common, though some contracts negotiate shorter windows for higher risk data) and require enough detail for you to meet your own downstream notification obligations.
Liability and insurance. Data breach liability caps are one of the most contested points in any DPA negotiation. Vendors want low caps; you want carve-outs for security failures and regulatory fines.
International transfer mechanics. If data crosses borders, the DPA needs the contractual mechanism, typically Standard Contractual Clauses (SCCs), that makes the transfer lawful.
Pro Tip: Don’t let a vendor bury the security exhibit in an appendix nobody reads. Pull the TOMs into the main body of the agreement or reference them by a specific, dated document name, otherwise “reasonable security measures” becomes whatever the vendor decides after the fact.
Security Verification: Making the Contract Promises Enforceable
Contract language alone doesn’t stop a breach. The Federal Trade Commission has been clear that companies need to move past written promises and build in ways to actually verify a vendor’s security practices, including audit rights and requirements for encryption, firewall logging, and vendor testing.
That means your DPA should require the vendor to produce specific, current evidence before you sign, not after something goes wrong; see how vendor security measures and auditability can be framed in contracts for regulated industries. Acceptable evidence typically includes:
SOC 2 Type II reports, which cover a period of time rather than a single point-in-time snapshot
ISO 27001 certification
Recent penetration test summaries
PCI attestations of compliance, where payment data is involved
Requiring SOC 2 Type II reports or penetration-test results gives you practical leverage that contract language by itself cannot. It’s the difference between a vendor telling you they’re secure and a vendor proving it on paper, on a schedule you control.
Audit rights need realistic scope and frequency, because “unlimited audit rights, any time” is unenforceable in practice and vendors know it. A reasonable structure is one audit per year, with additional audits permitted after a confirmed incident. Pair that with explicit incident response obligations: how fast the vendor notifies you, what forensic cooperation looks like, and who pays for remediation when the vendor’s failure caused the breach.
The FTC has documented real cases where companies got burned because their vendor contracts never required these checks in the first place. Treating your Chief Legal Office’s data security overview approach as a baseline, tying evidence requests to contract signature and renewal, closes that gap before it becomes a headline.
HIPAA, CCPA, and Cross-Border Rules That Change Your DPA
Three regulatory regimes reshape what a standard DPA needs to say, and missing any one of them is how companies end up with a contract that looks fine but doesn’t actually comply.
HIPAA. If a vendor creates, receives, maintains, or transmits protected health information on behalf of a covered entity, you need a Business Associate Agreement, not a generic DPA. HHS guidance specifies that a BAA must include permitted uses and disclosures, required safeguards, mandatory breach reporting, and return or destruction obligations for PHI. The regulation backing this, 45 CFR § 164.504, also requires that any subcontractor handling that PHI sign an equivalent back to back BAA of its own. A confidentiality clause in a general vendor contract does not substitute for these statutory requirements. In limited cases, HHS guidance allows a BAA to be combined with a data use agreement, but only where the arrangement meets the conditions for limited data sets.
CCPA and CPRA. California’s privacy law imposes specific contract limits on “service providers,” restricting them from using personal information outside the purposes you specify and requiring them to assist with consumer rights requests. Get this wrong and your vendor’s misuse of data can become your liability, not just theirs.
Cross-border transfers. If personal data moves outside the country where it was collected, particularly out of the EU or UK, your DPA needs a legal transfer mechanism. Standard Contractual Clauses remain the most common tool, and a data transfer impact assessment documenting the destination country’s legal environment should accompany any SCC arrangement. Require SCC amendments whenever a vendor changes hosting regions.
Copy-Ready Clause Language You Can Adapt
Below is a compact, annotated structure covering the clauses that matter most. Use it as a starting skeleton, not a finished contract; every clause needs tailoring to the actual vendor relationship.
Definitions and scope. “Processor shall process Personal Data only as necessary to provide the Services described in Exhibit A, and only in accordance with Controller’s documented instructions.” Annotation: name Exhibit A specifically. Vague scope is the number one drafting failure.
Security measures. “Processor shall implement the technical and organizational measures described in Exhibit B, including encryption of Personal Data at rest and in transit, and shall provide a current SOC 2 Type II report annually.” Annotation: attach the actual TOMs document, don’t just reference “industry standard security.”
Subprocessors. “Processor shall not engage a subprocessor without prior written notice to Controller, and shall ensure each subprocessor is bound by data protection obligations no less protective than those in this Agreement.” Annotation: insist on advance notice, not just a public subprocessor list updated after the fact.
Breach notification. “Processor shall notify Controller without undue delay, and in no event later than 48 hours, after becoming aware of a Security Incident, and shall provide reasonably requested cooperation and forensic information.” Annotation: 48 to 72 hours is standard; PHI and payment data relationships sometimes negotiate tighter windows.
Return or destruction. “Upon termination, Processor shall, at Controller’s election, return or destroy all Personal Data within 30 days and certify such destruction in writing.” Annotation: always ask for the certificate. A promise to delete data isn’t the same as proof.
Pro Tip: When adapting this template for a subcontractor rather than a SaaS vendor, tighten the subprocessor clause into a flat prohibition. Subcontractors handling your data directly rarely need permission to bring in their own downstream vendors.
Negotiating a DPA: Priorities and Red Flags
Not every clause deserves the same fight. Prioritize based on what data is actually at risk. A DPA covering payment card data or PHI justifies pushing hard on audit rights and liability caps. A DPA covering a marketing tool that only sees email addresses does not need the same intensity.
Common red flags to watch for during review:
Liability caps that exclude data breach damages entirely, leaving you exposed if the vendor’s negligence causes the incident
No subprocessor notification requirement, meaning your data can move to a fourth party you’ve never vetted
Vague breach notification timing like “promptly” instead of a specific number of hours
Refusal to provide any third-party security evidence, insisting instead on “our security is proprietary”
When a vendor refuses on-site audit rights, a reasonable fallback is accepting certified reports, like SOC 2 Type II or ISO 27001, in lieu of physical inspection. That’s a fair trade for most vendors. What isn’t fair is a vendor refusing both audit rights and any certified evidence. That combination means you have no way to verify anything they’ve promised, and it’s the point where this stops being a negotiation and starts being a decision about whether to walk away.
Escalate to senior counsel when the vendor touches PHI, processes payment data at scale, handles data belonging to minors, or when the liability cap sits meaningfully below your actual exposure. Those aren’t judgment calls a junior team member should make alone.
How an In-House Legal Team Actually Runs a DPA Program
Signing one DPA is easy. Managing fifty of them, across fifty vendors with fifty renewal dates, is where most companies fall apart. A functioning program starts with a vendor inventory: every third party touching personal data, tagged by risk tier (PHI, payment data, general PII, public data) and reviewed on a schedule, not just when someone remembers.
Risk-tiering determines how much scrutiny each vendor gets. A payroll processor handling Social Security numbers gets the full treatment: SOC 2 Type II reports, annual review, tight breach timelines. A tool that only stores anonymized analytics gets a lighter touch. This is the practical discipline behind treating DPAs as risk-management instruments rather than paperwork, and it’s what lets legal report to the board in plain terms: which vendors matter, what evidence backs their security claims, and where the gaps are.
Board reporting works best as a simple table: vendor name, risk tier, data types, last evidence received, renewal date. If your legal function can’t produce that table in an afternoon, the vendor management IT practices that support it probably need rebuilding, not just the templates.
The Gap Between a DPA Template and a DPA Program
Most of the DPA advice floating around treats the contract as the finish line. Sign it, file it, move on. That’s backwards. A signed DPA with no follow up is a document proving you once had a good intention.
The real work happens after signature: chasing the SOC 2 report every year, confirming subprocessors haven’t quietly expanded, checking that breach notification timelines actually get honored when something goes wrong. Templates are useful and I’d rather a founder use an imperfect template than nothing. But a template answers “what should this contract say.” It doesn’t answer “who is checking whether the vendor is still doing what they promised eighteen months later.”
That’s the part conventional advice underweights. Prioritize building the verification habit before you obsess over clause perfection. A mediocre DPA with a live audit cadence beats a flawless DPA nobody revisits. If you take one thing from this article, make it that the contract is the start of the relationship with your vendor’s data practices, not the end of your obligation to pay attention.
— Amy Natasha Osteen
Getting Ongoing Help With Your DPA Program
A template solves one contract. It doesn’t solve the fifty vendor renewals piling up next quarter, the subprocessor list nobody’s tracked since onboarding, or the breach notification clock nobody’s watching until it’s already ticking. Chief Legal Office exists for exactly that gap: a fractional in-house legal department that owns your DPA program the way a full-time General Counsel would, without the year-long hiring process.
For a growing SaaS company juggling dozens of vendor contracts, that means someone actually reviewing SOC 2 reports as they come in, flagging subprocessor changes before they become a problem, and keeping a board-ready vendor inventory current instead of reconstructed from memory during due diligence. If you’re negotiating a complex enterprise DPA with a major customer or acquirer, that work often calls for senior-level judgment, which is exactly what fractional General Counsel support is built for.
Chief Legal Office’s plans, Foundations at $1,000 per month, Embedded Access at $2,000 per month, and Strategic Growth at $5,000 per month, scale with how much of your legal function needs ongoing ownership. If your vendor list is outgrowing your ability to track it, that’s the signal to talk to a team, not just download another template.
This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.
Sources
Protecting Personal Information: A Guide for Business | Federal Trade Commission
45 CFR § 164.504 - Uses and disclosures: Organizational requirements. | eCFR | LII
EX-4.(A)(3) AT&T standard contractual clauses amendment | SEC filing
FAQ
What Is a Data Processing Agreement?
A data processing agreement is a contract requiring a vendor (the processor) to handle personal data only as instructed by the company that controls it, with defined security, breach notification, and deletion obligations. It’s distinct from a general services contract because it addresses what happens to the data itself, not just the service being delivered.
What Should Be Included in a Data Processing Agreement?
At minimum, a DPA needs scope and purpose of processing, security measures, subprocessor obligations, breach notification timing, audit rights, and data return or destruction terms. Where PHI is involved, it must instead meet the specific content requirements HHS lists for a Business Associate Agreement.
Are Data Processing Agreements Required in the US?
There’s no single federal law mandating a DPA for every vendor relationship, but sector-specific rules make one effectively required. HIPAA mandates a BAA whenever PHI is involved, California’s CCPA imposes contract requirements on service providers, and the FTC expects written security requirements in any contract involving sensitive customer data.
Is a DPA the Same as an NDA?
No. An NDA protects confidential information from disclosure to third parties. A DPA governs how a vendor is permitted to process personal data, including retention limits, security standards, and deletion obligations, which an NDA never addresses.
What’s the Difference Between a DPA and a BAA?
A DPA is the general contract for any vendor processing personal data on your behalf, while a BAA is a HIPAA-specific version required when protected health information is involved. A BAA has statutory content requirements under 45 CFR § 164.504 that a standard DPA doesn’t need to meet unless PHI is in scope.
Recommended
The lawyerly fine print: This article is for general information, not legal advice…
