A data processing agreement is the contract that governs what a vendor may do with personal data it handles for someone else. That one sentence explains both why enterprises refuse to buy without one and why founders keep meeting the acronym at the worst moment: mid-deal, in procurement, with a two-week detour attached. The companies that move fast through that gate are not the ones with clever negotiators; they are the ones who arrived with the paperwork already true.
This guide explains the roles, the required clauses, the subprocessor mechanics, and the small preparation that turns DPAs from a sales blocker into a trust signal. It is the B2B companion to the public-facing side covered in privacy policies and terms of service.
Controller and processor: the roles that decide everything
Data protection law splits the world into two roles. The controller decides why and how personal data is processed: your customer, deciding to run their user list through a tool. The processor handles the data on the controller's behalf: the tool. Most B2B startups are processors of their customers' data and simultaneously controllers of their own (their user accounts, their marketing lists). The DPA is the contract the law requires between those two roles, and knowing which one you occupy in each relationship is the first question every privacy conversation turns on.
Under the GDPR this is explicit: Article 28 makes a binding written contract mandatory whenever a processor acts for a controller, with penalties for skipping it that reach into the millions. US state privacy laws, led by California, arrived at a similar place with required service-provider terms. The letters differ; the architecture is the same.
What a data processing agreement contains
Strip the boilerplate and a DPA makes a short list of enforceable promises:
- Instructions only. The processor uses the data solely on the controller's documented instructions, never for its own purposes. This is the clause your AI features must survive: using customer data to improve models is exactly the kind of own-purpose use this language prohibits unless it is disclosed and agreed.
- Confidentiality and security. Personnel bound to confidentiality; technical and organizational measures appropriate to the risk, usually described in a security annex.
- Subprocessors. Engaged only with consent (specific or general-with-notice), under terms as protective as the DPA itself, with the processor remaining liable for them.
- Assistance. Help with individuals' rights requests (access, deletion) and with breach notification on defined timelines.
- End of engagement. Delete or return the data when the relationship ends, and prove it.
- Audit. A mechanism for the controller to verify all of the above, commonly satisfied through reports and certifications rather than site visits.
- Transfers. Where data crosses borders, the transfer mechanism (such as standard contractual clauses) rides along with the DPA.
A DPA is a promise inventory. Procurement is not asking whether you have the document; it is asking whether the promises in it are true of your actual stack.
The subprocessor list: small document, outsized signal
Every vendor in your stack that touches the same personal data is a subprocessor of your customers' data: hosting, analytics, email delivery, support tooling, and, increasingly scrutinized, the AI APIs behind your features. The DPA obliges you to disclose them and to flow equivalent obligations down to them. In practice that means a published subprocessor list, kept current, with a notice mechanism for changes.
For AI startups this is where the sharpest questions land. Enterprise reviewers read the subprocessor list specifically to find the model providers, then ask how customer data flows to them and whether it trains anything. Your answers must agree across three documents: this list, your DPA's instructions clause, and the upstream terms you accepted in your model-provider agreements. Inconsistency among the three is the most common way AI startups fail a privacy review.
The procurement fast lane
The preparation that separates a two-day security review from a five-week one is modest: your own DPA template consistent with your practices, a published subprocessor list including AI providers, a plain-language security summary, and answers that match across all of them. This is the same trust packet described in the enterprise AI sales checklist, and if EU data is anywhere in the picture, the transfer and scope analysis connects to the EU AI Act question. Accepting a customer's paper instead of offering yours is sometimes unavoidable at enterprise scale; reading what you sign remains mandatory either way, because DPA obligations are audited, not decorative.
- A DPA is the mandatory contract between a data controller and its processor; most B2B startups are both, in different directions.
- The core promises: instructions-only use, confidentiality, security, subprocessor discipline, assistance, deletion at exit, audit rights.
- The instructions-only clause is where AI features live or die; model improvement on customer data must be disclosed and agreed, not assumed.
- Publish and maintain a subprocessor list that includes your AI providers; reviewers read it first.
- Arriving with a true DPA, list, and security summary buys back weeks of sales cycle per enterprise deal.
The pattern, once more: the document is cheap, the delay it prevents is not, and the promises inside it must describe your actual stack. Write it once, keep it true, and the DPA stops being the moment deals stall and becomes the moment your startup looks bigger than it is.
Related reading: privacy policies and terms of service, the enterprise AI sales checklist, and AI vendor and model-provider terms. Or start a conversation about your data posture.