The Data Processing Agreement: A Founder's Practical Read
A data processing agreement is a contract between a SaaS company and its customers that specifies how personal data is handled, stored, and protected. Under GDPR and similar laws, any company processing personal data on behalf of a customer must have a signed DPA in place before doing so. For enterprise buyers, a missing DPA is a deal blocker.
Written by Yashveer Singh, founder of Yashveer Labs.
What you actually need to know
- A DPA is legally required under GDPR if you process personal data on behalf of EU customers. It is not optional.
- Enterprise buyers will not sign a contract without a DPA. It is one of the first items on their security checklist.
- The agreement covers four things: what data you process, why you process it, how you protect it, and who else has access.
- Subprocessors must be listed. Every cloud provider, analytics tool, and email service that touches customer data needs to be disclosed.
- You can start with a template. Get a lawyer to review before you send it to an enterprise buyer.
| DPA Maturity Level | What It Covers | Enterprise Buyer Readiness |
|---|---|---|
| No DPA | Nothing | Blocked immediately |
| Template DPA, unreviewed | Basic structure | Likely to fail legal review |
| Template DPA, lawyer reviewed | Correct structure, your specifics | Passes most evaluations |
| Custom DPA with subprocessor list | Full coverage, maintained | Passes all evaluations |
The core argument
Every enterprise SaaS sale eventually hits the legal review. This is the point where the buyer's legal or procurement team goes through a checklist of required documents before the contract is signed. The DPA is always on that list. If you do not have one, the deal stops until you do.
I have seen founders lose enterprise deals because they underestimated how seriously buyers take this. The product could be exactly what the buyer needed. The pricing was right. The technical evaluation passed. Then legal review asked for the DPA and discovered there was not one. The deal went into legal hold. It took three months to get the paperwork in place. By then, the buyer had moved on.
The DPA is not just a legal formality. It is a signal. When a founder sends over a properly structured DPA with a maintained subprocessor list, it tells the buyer that the company takes data handling seriously. When a founder sends over a generic privacy policy and calls it a DPA, it tells the buyer the opposite. Enterprise buyers read DPAs. They look at the subprocessor list. They check whether the security obligations match the SCCs. If you have done the work, it shows.
What a DPA must include under GDPR
Article 28 of GDPR specifies what must be in any data processing agreement between a controller and a processor. These are not optional provisions.
Subject matter and duration. What personal data is being processed and for how long. For a SaaS product, this is the customer data your product stores and the period of the contract plus the data retention period.
Nature and purpose. Why the data is being processed. For most SaaS products, this is providing the contracted service. The DPA should not grant you rights to use the data for your own purposes.
Type of personal data. What categories of data are involved. Names, email addresses, usage data, financial records. Be specific. A DPA that says "all types of personal data" is vague and will fail enterprise legal review.
Categories of data subjects. Who the personal data belongs to. Your customer's employees, their customers, or both.
Obligations and rights of the controller. What the customer can ask you to do with their data. Access it, delete it, export it, restrict processing. GDPR gives data subjects rights that flow through to you as the processor.
How to handle subprocessors correctly
The subprocessor section is the one that most startup DPAs get wrong. Under GDPR, if you use any third party that touches customer personal data, that party is a subprocessor, and your customer has the right to know about them.
The list needs to be current. When you switch from one email provider to another, or add a new analytics tool, the subprocessor list needs to be updated and customers need to be notified. Most DPAs require a minimum notice period (typically 30 days) before adding a new subprocessor. Check what period you committed to and maintain it.
For each subprocessor, you need a sub-processing agreement in place. This means your own DPA with your hosting provider, your email delivery service, your support platform. AWS, GCP, and most major providers offer standard data processing agreements. Sign them. Confirm they meet GDPR Article 28 requirements. This is the chain of accountability that enterprise buyers are checking.
The practical implementation: maintain a subprocessor list on a public URL on your website. Update it when the list changes. Include the effective date. Link to it from your DPA. This is the standard enterprise buyers expect.
Common mistakes founders make with DPAs
- Sending a privacy policy when a buyer asks for a DPA. These are different documents with different legal purposes. Sending the wrong one signals that you do not understand the distinction.
- Using a template without reviewing it against what your product actually does. A DPA that says you process only email addresses when your product also processes financial data is inaccurate and creates legal exposure.
- Not maintaining the subprocessor list. An outdated list is technically a breach of the DPA. Enterprise buyers check this.
- Not having sub-processing agreements in place with your own vendors. You cannot agree to Article 28 requirements with your customers if you have not agreed to them with your own vendors.
- Treating the DPA as a one-time task. Data processing agreements need to be reviewed when your product changes, when you add or remove subprocessors, and when data protection law in your customers' jurisdictions changes.
Where to start: a 3-step DPA implementation plan
Step 1: List every third-party service that touches customer data. Your hosting provider, database service, email delivery, analytics, support platform, monitoring tools. This is your subprocessor list. For each one, locate their standard data processing agreement and confirm it is signed.
Step 2: Get a template DPA and customize it to your product. The IAPP and most legal service providers offer GDPR-compliant DPA templates. Fill in the subject matter, duration, types of data, categories of data subjects, and your subprocessor list. Have a lawyer review the result before it goes to a customer.
Step 3: Publish your subprocessor list and make the DPA available. Put the subprocessor list on a public page on your website. Include the DPA as a downloadable document in your legal section or make it available on request. Enterprise buyers will ask for it during evaluation.
What You Get When You Work With Me
Yashveer Singh. Founder of Yashveer Labs. The work I do includes the technical implementation of the systems these agreements describe. I have built the GDPR tooling, the data export features, the audit logs. The DPA is the document. The code behind it is what I build. If you need someone who can connect the legal requirement to the engineering work, that is the combination I bring.
Related reading
Frequently asked
The reason I write these
I write these because the writing is the proof. Yashveer Singh, founder of Yashveer Labs. The systems I build are not theoretical. They are running right now, serving real users, generating real revenue. That is the bar I hold this writing to. If you want to hire someone who can match that bar, I am the call.
Posts that line up with this one.
- Security, Auth, and Compliance
Single Sign On for Enterprise SaaS: SAML and OIDC Compared
SSO is a procurement requirement for enterprise deals. Here is what SAML and OIDC each mean for your engineering roadmap.
- Security, Auth, and Compliance
SOC 2 Type I vs Type II: A Founder's Guide to Both
SOC 2 Type I proves you have the controls. Type II proves they work over time. Here is what each means and when you need them.
- Security, Auth, and Compliance
Encryption at Rest vs in Transit: What Customers Will Ask
Encryption at rest and in transit are the two questions enterprise customers ask first. Both are easy to get right. The teams that have not thought about either stumble on the easiest part of a security review.
- Security, Auth, and Compliance
How to Sell to Enterprise Without a Full Compliance Stack
You do not need SOC 2 Type II and HIPAA certification before your first enterprise conversation. Here is what you actually need and how to close the deals while you build toward the rest.