Building a DPA to Send Your Own Customers: A Guide for SaaS Vendors
If your product processes personal data on behalf of business customers, you're the processor now, and they'll expect a DPA from you. Here's what to put in it.
Most of our DPA content covers reviewing what a vendor sends you. If you run a SaaS product that processes personal data on behalf of business customers, though, you’re on the other side of that relationship, you’re the processor, and your customers will increasingly expect you to provide a DPA rather than ask for one.
When you need to have one ready
If any business customer’s use of your product involves you processing personal data on their behalf, their employees’ data, their customers’ data, their end-users’ data, you’re a processor under GDPR the moment you have an EU/UK customer, or under CCPA/CPRA-style “service provider” concepts for California-exposed customers. Waiting until a customer’s legal team asks for a DPA during procurement is the most common way this becomes a rushed, reactive document instead of a prepared one.
What to include
The same core provisions covered in our Article 28 checklist, written from your side of the relationship:
- Clear scope of processing, what data you process on the customer’s behalf, for what purpose, tied specifically to your product’s actual functionality.
- Your sub-processor list, published and kept current. This is the single most commonly requested piece of a SaaS DPA during customer security reviews, have it ready as a standalone page, not buried in a PDF.
- Security commitments backed by something concrete. A SOC 2 report, ISO 27001 certification, or a detailed security page substantially speeds up enterprise procurement compared to a generic “we take security seriously” statement.
- Data subject request assistance. Commit to a specific, reasonable timeline for helping your customers respond to DSARs involving data you hold on their behalf.
- Breach notification commitments with a specific timeline, not just “without undue delay,” see our breach notification guide for what customers will increasingly expect here.
- International transfer terms, SCCs or another valid mechanism if you or your sub-processors handle data outside the EU/EEA.
- End-of-contract deletion commitments, specific and time-bound, this is one of the first things a careful customer’s legal team will check for.
CookieYes
If part of your product touches visitor consent or tracking on customer sites, a consent platform's own DPA is a useful structural reference for how to scope and write your own. CookieYes's DPA is publicly available and covers exactly this kind of processor relationship.
Making it self-serve
For a product selling to small and mid-size businesses, the highest-leverage move is making your DPA available for self-serve acceptance, a checkbox in your dashboard or a document customers can countersign without a sales call, rather than requiring a manual back-and-forth for every request. Reserve negotiated terms for genuinely large enterprise deals where a customer’s legal team wants specific changes.
The bottom line
Once your product processes personal data for business customers, having a clear, complete, easy-to-access DPA isn’t just a compliance nicety, it’s increasingly a procurement requirement that can gate or slow down deals if you don’t have one ready. Building it proactively, rather than scrambling when the first enterprise customer’s legal team asks, is worth the upfront effort.
This guide is educational and not legal advice. For your specific product and customer contracts, consult a privacy attorney.