Data Processing Agreement: a founder's guide to the DPA

An enterprise buyer's privacy counsel emails you a 38-page PDF titled "Data Processing Addendum" and asks you to sign it before the order form goes to legal. Nobody on your team has read a DPA end to end. The MSA is signed, the security questionnaire is cleared, and this one document is the last gate on a six-figure deal.

This is the structure you need to know before you open the PDF, and the clauses worth actually negotiating once you do.

SecurancePro is a CPA firm, not a law firm. What follows is how DPAs work in practice and how they interact with the audit reports we issue. Use it to talk to your counsel from an informed starting point, not to replace the conversation.

The short answer

A data processing agreement is a contract between a data controller and a data processor that governs how the processor handles personal data on the controller's behalf. Under the EU General Data Protection Regulation, Article 28 requires that contract and specifies what must be in it — the official Regulation text on EUR-Lex is the authoritative source. The UK GDPR carries the same requirement. California's CPRA has its own near-equivalent at Cal. Civ. Code § 1798.100(d).

You will also see the same document called a Data Processing Addendum, a Data Protection Agreement, or a DPA exhibit bolted onto the back of the MSA. The names vary. The legal function does not.

US buyers who are not themselves under GDPR increasingly ask for a DPA anyway, because their own customers or subsidiaries are. If your product touches anyone in Europe, assume every enterprise paper trail you sign for the rest of your company's life will include one of these.

Who signs a DPA, and which side you are on

Two defined roles drive the whole document.

The controller is the party that decides why and how personal data gets processed. In a standard SaaS relationship, that is your customer. They decide what data to put into your product and what purpose it serves.

The processor is the party that processes personal data on the controller's behalf, under the controller's instructions. That is usually you, the SaaS vendor. You store, transmit, back up, and run analytics on data whose purpose was set by somebody else.

A single company can be both, on different data sets. You are a controller of your own employee data and your prospects in Salesforce. You are a processor of the personal data your customer loads into your application. The DPA covers only the processor relationship, which is why its scope language is narrower than founders expect. The EDPB's Guidelines 07/2020 on controller and processor is the reference regulators read when the roles are contested; anchor your allocation to that definition before the contract does it for you.

If the contract reverses the roles, read it twice. A "processor" clause that gives your side independent discretion over processing purposes is not a processor relationship. Either the document is wrong or the commercial reality is something other than what the sales team described.

The core clauses GDPR requires

Article 28(3) is a checklist. Every compliant processor DPA must address each item, though the wording varies.

• Subject matter and duration of the processing. What data, covering what activity, for how long.
• Nature and purpose of the processing. "Hosting a CRM" is a purpose. "Whatever the controller tells us to do" is not.
• Types of personal data and categories of data subjects. Employees, end users, patients, minors, and special-category data each carry different downstream obligations.
• The controller's obligations and rights, usually cross-referenced back to the MSA and GDPR itself.
• Processor obligations to process only on documented instructions, ensure confidentiality of personnel, implement Article 32 security measures, engage sub-processors only under Article 28(4), assist with data-subject requests, assist with breach notification and DPIAs, and delete or return the data at the end of the contract.
• Audit rights. The controller's right to audit, or to accept third-party audit reports in lieu of on-site audits.

Every sophisticated DPA template on the market covers these. The variations live in the exhibits at the back: the security measures annex, the sub-processor list, and the international transfer schedule. Those exhibits are where the real negotiation happens. If your SOC 2 scope includes the Privacy criterion, the commitments you make there and in your trust services criteria description of the system should line up word-for-word with what this DPA says you do.

The MSA is where the commercial deal lives. The DPA is where the regulator lives. Read both before you sign either.

Sub-processors and the flow-down problem

Every vendor you use to deliver your service is a sub-processor under the DPA. AWS or GCP for hosting. Snowflake for the data warehouse. Datadog for logs. Stripe for billing if billing touches personal data. SendGrid for transactional email. Each one becomes a sub-processor the moment your customer's data flows through it.

Article 28(4) requires you to impose the same data-protection obligations on each sub-processor that you accepted toward the controller. That is the flow-down. Every serious sub-processor has their own DPA you sign with them, and the chain holds because each link carries the same Article 28 language.

Two operational obligations matter here:

• Maintain a current sub-processor list. Publish it, link to it from the DPA, and keep it updated. Customers will ask for the URL.
• Notify the controller before engaging a new sub-processor. Common practice is 30 days' prior notice with a right to object. If the controller objects and you cannot find an alternative, the contract terminates for that scope.

Founders underestimate this. Swapping observability vendors mid-year is not just a procurement decision; it is a notification obligation to every enterprise customer whose DPA is in force. The vendor-management controls inside a SOC 2 compliance program are where this flow-down actually lives operationally — the DPA promises it, the SOC 2 control proves it.

Standard Contractual Clauses and the US transfer question

When the controller is in the EU and the processor (you) is in the US, the data is leaving the European Economic Area. GDPR restricts those transfers unless a valid transfer mechanism is in place.

The mechanism most companies use is the Standard Contractual Clauses (SCCs), a template issued by the European Commission. The 2021 version is the current one. SCCs are usually incorporated into the DPA by reference, with the module selection (controller-to- processor, processor-to-processor) and the annexes filled in.

Post-Schrems II, signing the SCCs is not the end of the work. Controllers have to run a Transfer Impact Assessment to confirm that US surveillance law does not undermine the protections the SCCs promise. Expect the buyer's privacy team to send you a TIA questionnaire, and answer it honestly.

The EU-US Data Privacy Framework, adopted in 2023, gives companies that self-certify under it a second legal basis for transfers. It does not replace the SCCs in practice. Most buyer DPAs reference both, with SCCs as the belt and DPF as the suspenders. The framework is also subject to ongoing legal challenge, so belt-and-suspenders is the right posture regardless.

A DPA is not a BAA

Founders selling into healthcare hit this at least once. A prospect asks for "the DPA and the BAA," and someone on the team assumes they are two names for the same document. They are not.

A Business Associate Agreement is a HIPAA instrument, required under 45 CFR § 164.308(b) when a covered entity shares protected health information with a business associate. Its content is set by HIPAA, not GDPR. Our piece on who the HIPAA Security Rule applies to covers that scope. If you are building a SaaS that touches US health data, see HIPAA compliance for SaaS for the BAA mechanics.

A single customer selling a US healthcare product to EU-based employees can require both. The BAA governs the PHI. The DPA governs everything else that is personal data under GDPR. They sit side by side, cover different legal regimes, and have different breach- notification mechanics. Sign them separately and keep them filed separately.

How DPA audit rights interact with SOC 2 and ISO 27001

The audit-rights clause is where compliance reports start earning their keep.

A naive DPA gives the controller a right to conduct on-site audits of the processor's facilities and systems once a year, on reasonable notice, at the controller's cost. If you sign fifty enterprise contracts, that is fifty potential on-site audits per year. No growth- stage SaaS can absorb that.

A well-drafted DPA accepts a current third-party audit report in lieu of an on-site audit. The two most common are a SOC 2 Type II report and an ISO 27001 certificate. The language usually reads something like: "Controller agrees that Processor's most recent SOC 2 Type II report, made available under NDA, shall satisfy Controller's audit rights under this Agreement, provided the scope of the report covers the services provided under the MSA."

That one sentence is worth six figures a year in audit-response labor by year three. Push for it in every template. If a particular buyer insists on retaining on-site rights, negotiate a cost-sharing clause and a frequency cap, and make sure the scope is tied to a real incident trigger rather than a right to show up on a Tuesday. Our piece on what a SOC 2 report actually tells your buyer covers what procurement teams are looking for when they read it.

What to put in your template, what to negotiate

If you are the processor and you want to stop rewriting every customer's paper, publish your own DPA template on a public URL and propose it first. A reasonable baseline includes:

• A security-measures annex that mirrors the controls you actually run. Pull directly from your SOC 2 or ISO 27001 description of the system so the audit evidence lines up with the contract promise.
• A current sub-processor list at a stable URL, with a 30-day notice and objection right.
• SCCs incorporated by reference, with the modules pre-selected and annexes pre-populated for your typical deal.
• A DPF self-certification reference if you have one.
• Audit rights satisfied by your current SOC 2 Type II or ISO 27001 certificate under NDA, with on-site audits available only on reasonable cause and at controller cost.
• A breach-notification timeline consistent with GDPR Article 33 (72 hours from awareness, controller-to-processor notice "without undue delay").
• Deletion-or-return language on termination, with a realistic cure window.

The items most worth negotiating when the buyer's template lands on your desk: unlimited on-site audit rights, indemnity caps that explicitly exclude data-breach claims, breach-notification clocks shorter than 24 hours, and sub-processor veto rights that block your operations rather than trigger a termination path. None of those are unreasonable for the buyer to ask. None of them are reasonable for a SaaS vendor to sign without pushback.

If you are reconciling a DPA template against what a SOC 2 Type II actually covers, or you want an auditor's read on whether your audit- rights clause and your report scope match, get in touch. Our services page has the rest of what we do.