In plain English
You need a DPA when a vendor (or you) processes personal data on someone else's behalf, not because a sales deck said "SOC 2." If employee, customer, or end-user personal data will be processed by a third party, attach a Data Processing Agreement (or equivalent), then check transfers, subprocessors, and breach notice, without fake jurisdictional certainty.
Not legal advice. Privacy and transfer rules vary by jurisdiction, product, and facts. Escalate regulated or high-volume personal data deals to counsel.
By version90 staff Published How this was made
What is a DPA, in founder/ops English?
A Data Processing Agreement (DPA) is the exhibit that says how a processor may handle personal data for a controller (or how a processor may use subprocessors). It is not an NDA, not a SOC 2 PDF, and not an MSA sentence that says "we comply with applicable law."
The MSA sets payment, IP, and liability. The DPA is the operational annex: what data, for what purpose, who else touches it, breach notice, and deletion. Treat a missing DPA like a missing SOW: Startup MSA redline checklist · How to review an MSA without a lawyer.
When do startups actually need one?
You likely need a DPA (or equivalent processor terms) when personal data will be processed by a party that is not using it solely for its own independent purposes: you host customer or employee data; a vendor will see tickets, HR records, or people-tied analytics; a contractor or AI vendor is fed personal data; a customer asked for your DPA because you process their end users.
You may not need one for a talk that only shares business secrets (that is NDA territory) or when both parties are independent controllers. "May not" is not "definitely not." If a human could reasonably be identified in the data, ask "controller or processor?" before "where's the discount?"
Why do controller, processor, and subprocessor labels matter?
Labels decide whose DPA you sign and whose instructions win.
| Role (plain) | Typical startup example | Paper you usually want |
|---|---|---|
| You are controller; vendor is processor | CRM, support, payroll, host of customer data | Vendor DPA with you as controller |
| You are processor; customer is controller | B2B SaaS hosting the customer's end users | Your DPA, signed with the customer |
| Vendor is subprocessor | Host or email vendor under your customer DPA | Flow-down: your DPA must allow them |
| Independent controllers | Co-marketing lists, each for its own use | Often a different addendum, not a default processor DPA |
Do not let sales rename the relationship. If they "just host your data to provide the service," that is processor-shaped even if the homepage says partner.
What should a startup skim in a DPA?
You are checking that the exhibit exists, matches the product, and does not contradict the MSA.
- Instructions: What data, for what service, on documented instructions.
- Security: Measures you can meet, not "industry standard" as a personality trait.
- Subprocessors, A list or notice plus an objection window you can hit.
- Breach notice: Hours/days defined. "Promptly" is not a clock.
- Deletion / return, You can get data out; they delete on exit.
- Transfers, A mechanism is named (below), not hand-waved.
- Liability, Whether DPA breaches sit inside or outside the liability cap. Accidental uncapped privacy liability is a classic mismatch.
If AI assists, demand citations and verify: AI contract review with citations.
What should you know about SCCs and transfers?
If personal data will move across borders, many privacy regimes expect a transfer mechanism: standard contractual clauses (SCCs), a statutory exception, a certification, or another tool the law actually recognizes. Which tool fits your data, your countries, and this year's guidance is a counsel question. This page will not pick your module.
Fair ops questions without fake certainty: Does the DPA identify a mechanism, or just say "we may transfer globally"? Are foreign subprocessors listable? Do MSA and DPA conflict on where data may live? Laws change, do not freeze a 2018 blog post into your playbook.
How is a DPA different from an NDA or a SOC 2 report?
| Artifact | Job | Not the job |
|---|---|---|
| NDA | Protect business secrets between talkers | Process personal data on instructions |
| DPA | Processor terms for personal data | Silently replace the MSA liability bargain (read precedence) |
| SOC 2 / ISO report | Evidence of controls at a point in time | A contract; reports expire |
| Security questionnaire | Diligence snapshot | Signed deletion, breach, and transfer terms |
Customers will ask for all four. Notice which is missing.
What should be on a startup DPA checklist?
- Personal data will (or will not) be processed, written down, not assumed
- Roles labeled: controller / processor / subprocessor, matching the product
- DPA listed as an MSA exhibit and actually attached
- Precedence: DPA vs MSA vs order form is clear on privacy terms
- Subprocessor notice + objection path is operational
- Breach notification has a number, not a mood
- Deletion / return on termination is practical
- Transfer mechanism named if cross-border processing is in play, then counsel confirms fit
- Cap / indemnity / DPA liability read as a package
- One canonical
.docx; Track Changes on; no "DPA coming later"
About this page
Who. Written by version90 staff at Latent Ape LLC, the company that builds version90, working with AI tools. We build contract software and run our own contracts through it; we are not a law firm, and nothing here is legal advice.
How. Each piece starts from the review workflow version90 is built around. AI drafts and structures the text; staff edit, fact-check, and rewrite it before it is published, and we update the date shown above whenever the substance changes.
Why. The library exists to give founders and ops teams a shared standard for reviewing contracts without a legal department. If you spot an error, email [email protected] and we will fix the page.