Do You Need a Data Processing Agreement? A Guide for SaaS Companies Using Third-Party Tools

If your SaaS product runs on Stripe, sends email through Postmark or Mailchimp, tracks usage with an analytics tool, and hosts on AWS or Render, you need a signed Data Processing Agreement (DPA) with every one of those vendors, and they need one with you if you process data on behalf of your own customers. GDPR requires a DPA any time a “controller” (the business that decides why data is collected) hands personal data to a “processor” (a vendor that handles it on the controller’s behalf). A privacy policy tells your users what you do with their data. A DPA is the contract that governs what your vendors are allowed to do with it, and what you’re allowed to do with your customers’ data if you sell business software.

When Does GDPR Require a DPA?

Article 28 of the GDPR requires a written contract, the DPA, whenever a controller uses a processor to handle personal data. The trigger isn’t the size of your company or whether you’re based in the EU. It’s whether personal data belonging to an EU resident passes through a third party. If your app has EU users or EU customers, and a vendor stores, transmits, or otherwise touches their personal data, Article 28 applies.

This catches most SaaS companies right away, because almost no one runs infrastructure without third-party tools anymore. Payment processing goes through Stripe or PayPal. Transactional and marketing email goes through a dedicated sender. Product analytics goes through a hosted tool. Application hosting sits on a cloud provider. Each of those vendors is a processor (sometimes a “sub-processor” if you’re the processor for your own customers), and each relationship needs its own signed DPA, not a general mention in your privacy policy that “we use third-party tools.”

Regulators have fined companies for missing or inadequate processor agreements even when the underlying data handling was reasonable. The absence of the contract is the violation, regardless of whether anything went wrong with the data itself.

Which Vendors Need a Signed DPA?

Any vendor that processes personal data on your behalf needs one. In practice, for a typical SaaS company, that means:

• Payment processors (Stripe, PayPal, Braintree) that handle billing and customer payment details
• Email and marketing tools (Postmark, SendGrid, Mailchimp, Klaviyo) that store subscriber and customer contact data
• Analytics and product usage tools (Mixpanel, Amplitude, PostHog, Google Analytics) that log user behavior tied to accounts
• Hosting and infrastructure providers (AWS, Google Cloud, Render, Vercel) that store and process the underlying data
• Customer support platforms (Zendesk, Intercom) that hold support ticket content and user identifiers

Most established vendors already have a standard DPA available. Stripe, AWS, and Google each publish one you can accept during account setup, so it’s worth locating and formally accepting each one rather than assuming it happened automatically. Smaller or newer vendors may not have one ready. If a vendor can’t produce a DPA on request, weigh that before sending them customer data.

If you’re the vendor, the same logic runs in reverse. A business software company that stores data on behalf of its own customers is the processor in that relationship, and its customers (the controllers) will expect a signed DPA before they sign a contract with you. This is where many SaaS companies first meet the requirement: a prospective enterprise customer’s procurement team asks for one, and there isn’t one to send.

What Must a DPA Contain?

Article 28(3) lists specific terms a DPA has to include, and a document that skips them isn’t a valid DPA even if it’s labeled one. The core requirements are:

• Scope and purpose of processing: what categories of personal data are involved, whose data it is, and what the processor is allowed to do with it
• Duration: how long the processor retains the data and what happens to it when the relationship ends
• Sub-processor list and approval process: which other vendors the processor uses (a payment processor might use a fraud-detection sub-vendor, for example), and a mechanism for the controller to be notified of and object to new sub-processors
• Security measures: the technical and organizational safeguards in place, encryption, access controls, and staff confidentiality obligations
• Breach notification terms: how quickly the processor must tell the controller about a data breach, GDPR expects this fast enough that the controller can meet its own 72-hour regulator notification window
• Audit rights: the controller’s right to verify the processor’s compliance, directly or through a third-party audit
• International transfer terms: if data leaves the EU/EEA, the safeguard used (Standard Contractual Clauses, an adequacy decision, or another approved mechanism)

A one-line clause buried in your terms of service (“we may share data with service providers”) doesn’t satisfy this. It needs to be a separate, labeled agreement or addendum that a vendor or customer’s legal team can review and sign on its own.

How Is a DPA Different From a Privacy Policy?

The two documents look similar on the surface, both describe data handling, but they serve different audiences and different legal purposes.

A privacy policy is a one-way disclosure: you publish it, and a visitor reads it (or doesn’t) before using your product. A DPA is a two-way, negotiated contract that both parties sign, and it exists specifically to allocate legal responsibility if something goes wrong with a subprocessor further down the chain. Having a strong privacy policy does not substitute for a missing DPA, and regulators treat them as separate obligations.

Getting a DPA in Place

If you’re evaluating a new vendor, ask for their standard DPA before you send them customer data, not after. If you’re the one being asked for a DPA by a customer’s procurement team, having a ready document covering sub-processors, security measures, and breach notification terms can turn a stalled sales conversation into a same-day signature. The DPA generator puts together a document covering each required Article 28 term based on your own vendor and sub-processor setup, so you’re not drafting one from scratch the next time a customer’s legal team asks.