Data processing agreements for SaaS hosting: what to actually check for

You signed up for a hosting platform, clicked through the terms, and moved on. Now a customer’s security team is asking for your “DPA with your sub-processors,” and you’re not sure you have one, or whether the document you do have counts. This happens to almost every small team that built something on a SaaS platform first and thought about compliance later.

A data processing agreement (DPA) is the contract that says how a third party is allowed to handle personal data on your behalf. If your app stores anything about identifiable people, and your hosting provider or database provider touches that data, you need one with each of them. The problem is that most DPAs are long, written by lawyers, and easy to file without reading. Here’s what to actually look for.

Why this document matters under GDPR

GDPR splits the world into two roles. A controller decides why and how personal data gets used. A processor handles that data on the controller’s instructions. If you run an app, you’re usually the controller. Your hosting provider, database host, email sender, and analytics tool are usually processors working for you.

Article 28 of GDPR says a controller can only use a processor that gives “sufficient guarantees” about protecting the data, and that the arrangement has to be set out in a written contract. That contract is the DPA. It’s not optional paperwork. It’s the thing that makes your use of a third-party processor legal in the first place.

Two practical consequences follow. First, a signed DPA is what a customer’s due-diligence team expects to see when they ask how you handle their data. Second, if there’s ever a breach at your hosting provider, the DPA is the document that spells out who has to tell whom, and how fast.

What to check, clause by clause

Pull up the DPA from each provider that touches personal data. For each one, work through this list. You’re not looking for perfect legal language, you’re looking for whether these points are actually covered.

1. Does it name your organization? A real DPA names you as the controller, not “the customer” in the abstract with no way to tell it applies to you. Some platforms have a self-serve DPA you accept in the dashboard, which is fine, as long as it ties to your account. If you can’t find any version that references you, you effectively don’t have one.

2. Does it list the sub-processors? Your processor almost certainly uses its own processors. A hosting company runs on someone’s data centres. A good DPA either lists these sub-processors or links to a page that does, and promises to tell you before adding new ones. Find that list. Your customers will ask for it.

3. Where is the data processed? The DPA should say which regions or countries the data sits in. If it allows processing outside the UK or EU, look for the transfer mechanism (usually “Standard Contractual Clauses” or an adequacy decision). No transfer mechanism plus data leaving the EU is a gap worth flagging.

4. What are the security measures? There’s usually a section, sometimes an annex, listing technical and organizational measures: encryption, access control, backups. Skim it. You don’t need to audit it, but you should be able to point to it if asked.

5. What happens on a breach? Look for a clause that says the processor will tell you “without undue delay” if they discover a personal-data breach. That’s what lets you meet your own 72-hour notification deadline. If there’s no notice commitment, you could be the last to know.

6. What happens when you leave? The DPA should say the processor will delete or return your data when the contract ends, and not just keep it indefinitely. Check the retention wording here against your own retention policy.

7. Can you audit or get audit reports? Larger providers won’t let you personally inspect their data centre, but they should offer something: a SOC 2 report, an ISO 27001 certificate, or a written audit right. Note which one you can actually get.

The common trap

The single most frequent mistake is treating the terms of service as the DPA. They’re different documents with different jobs. The terms of service govern your commercial relationship: billing, uptime, acceptable use. The DPA governs data protection specifically. A platform can have excellent terms of service and no DPA at all, and plenty do, especially newer AI-app platforms that shipped fast.

If a provider’s only “data” document is a paragraph inside the general terms, that’s usually a sign the DPA either lives somewhere else or doesn’t exist yet. Ask support directly: “Where is your GDPR data processing agreement, and does it name my organization as controller?” The answer tells you a lot.

Or, we do it for you

Reading DPAs across every provider your app touches, and finding the gaps, is exactly the kind of thing that’s easy to postpone until a customer forces it. We run that check as part of onboarding and keep the paperwork current. See how we handle SME compliance on our for-SME page.

FAQ

Do I need a DPA if I only handle my own employees’ data?

Probably yes. GDPR covers personal data about any identifiable people, and employees count. If a third-party provider stores or processes that employee data for you, the Article 28 rule still applies. The scale is smaller, but the requirement doesn’t disappear.

Is a click-through DPA in a dashboard as good as a signed one?

Usually, yes. A DPA you accept electronically in a provider’s dashboard is a valid contract, as long as it’s tied to your account and you can produce a copy. Save a PDF of it so you can hand it to a customer’s security team without hunting through the dashboard later.

What if a provider flat-out has no DPA?

Then you have a gap to close. Either the provider offers one on request (ask support directly), or they don’t, in which case you have to weigh whether to keep using them for anything involving personal data. A processor with no DPA is a real problem a regulator or customer will not overlook.

How is a DPA different from Standard Contractual Clauses?

The DPA is the whole agreement about how a processor handles your data. Standard Contractual Clauses (SCCs) are a specific add-on inside or alongside it that legally covers moving data outside the UK or EU. If your data stays in the EU, you may not need SCCs at all. If it leaves, the SCCs are the mechanism that makes the transfer lawful.