DPA vs terms of service: why they're not the same document

A customer’s security team asks for your DPA. You forward your hosting provider’s terms of service because it has a section about data. They come back and say that’s not what they asked for. If you’ve been in that exchange, you’ve hit one of the most common compliance mix-ups for small teams: treating the terms of service as if it were the data processing agreement. They’re different documents, and only one of them satisfies GDPR.

The confusion is understandable. Both are legal documents from the same provider, both mention data, and nobody reads either one closely. But they cover different things, and knowing which is which saves you from the awkward realization that the document you’ve been relying on doesn’t actually do the job.

What each document is for

Terms of service (sometimes “terms of use” or “master service agreement”) govern the commercial relationship. They cover things like:

What the service is and what you’re allowed to do with it
Payment, billing, and cancellation
Uptime promises and service levels
Liability limits and warranties
Acceptable use and what gets you banned

The terms of service answer the question: “What are the rules of us doing business together?”

A data processing agreement (DPA) governs one specific thing: how the provider is allowed to handle personal data on your behalf. It exists because GDPR’s Article 28 requires it. A DPA covers:

That the provider processes personal data only on your documented instructions
The security measures they apply to that data
The sub-processors they use, and notice before adding new ones
Whether data leaves the UK/EU, and the transfer mechanism if it does
How they’ll notify you of a breach so you can meet your own deadlines
What happens to the data when the contract ends (deletion or return)

The DPA answers a narrower, legally required question: “How, exactly, does this provider protect the personal data I’m trusting it with, and what are its obligations if something goes wrong?”

GDPR splits data roles into controllers and processors. If you run an app, you’re usually the controller: you decide why and how personal data is used. Your providers, the ones that host, store, or send that data, are processors acting for you.

Article 28 says a controller may only use a processor bound by a contract that sets out specific data-protection terms, and it lists what that contract must contain. That list is basically the DPA’s table of contents above. The point is that GDPR names the ingredients. A document that doesn’t contain them isn’t a DPA, no matter what it’s titled, and a document that does contain them is one, even if it’s an annex to something else.

That’s why the terms of service usually can’t stand in. General commercial terms weren’t written to hit Article 28’s checklist. They might mention data protection in passing, but “mentions data” and “meets Article 28” are far apart.

How to check what you actually have

Go provider by provider for every service that touches personal data (hosting, database, email, analytics). For each:

Find both documents. Look for a “DPA,” “Data Processing Agreement,” or “Data Processing Addendum” separately from the main terms. Many providers keep the DPA on a dedicated legal page, sometimes as a self-serve document you accept in the dashboard.
If you only find terms of service, that’s a flag. It doesn’t automatically mean no DPA exists, but it means you haven’t found it yet. Ask support: “Where is your GDPR data processing agreement?”
Check the DPA against the Article 28 checklist. Does it name you as controller? List sub-processors? State the security measures? Cover breach notice, data location, and deletion on exit? If a real DPA is missing several of these, treat it as incomplete.
Watch for a document titled “DPA” that’s really just terms. Some providers slap “Data Processing Addendum” on a page that’s thin on the required content. The title isn’t the test. The content is. Read for the Article 28 ingredients.
Save a copy. When you find the genuine DPA, download it as a PDF. That’s the file you hand to a customer’s security team, so you’re not scrambling later.
Note the gaps. Any provider with no real DPA is a gap to close, either by getting one on request or reconsidering whether to send them personal data at all.

The short version

The terms of service is the “how we do business” document. The DPA is the “how you protect my data” document that GDPR specifically requires. You need both, they’re not interchangeable, and the title on the page doesn’t decide which is which. The content does. If you want the deeper walk-through of what a good DPA actually contains, our post on reading a SaaS hosting DPA goes clause by clause.

Or, we do it for you

Chasing down the real DPA from every provider your app touches, and checking each one against the Article 28 list, is exactly the kind of admin that stays undone until a customer forces it. We handle that as part of onboarding an app and keep the paperwork current. See our for-SME page.

FAQ

Can a single document be both the terms and the DPA?

Sometimes. A provider can bundle data-processing terms into a larger agreement, often as a clearly labelled annex or schedule. What matters is that the DPA content, the Article 28 ingredients, is genuinely present and identifiable, not that it lives in its own PDF. If the “data” content is just a stray sentence in the general terms, it’s not a DPA.

The provider calls their document a “DPA” but it’s very short. Is that fine?

Read it against the required content, not the length. A short DPA that still names you as controller, lists sub-processors, covers security, breach notice, transfers, and deletion can be perfectly valid. A short one that’s missing those is a DPA in name only. Judge by contents.

We only have terms of service, no separate DPA. Are we non-compliant?

You have a gap for any provider processing personal data for you. First, ask the provider directly, since many offer a DPA on request that isn’t obvious from the marketing site. If they genuinely don’t offer one, you have to weigh whether to keep sending them personal data, because a processor with no DPA is a real Article 28 problem.

Does a free-tier provider still need to give me a DPA?

Yes. GDPR’s requirement doesn’t depend on whether you’re paying. If a free service processes personal data on your behalf, it’s a processor and the Article 28 contract requirement applies. Plenty of free tiers do offer a DPA; you may just have to go find it.