"GDPR-compliant" appears on a lot of hosting pricing pages. It's a marketing phrase, not a legal instrument, and it carries no weight on its own during an audit.
The actual legal instrument is a Data Processing Agreement. If a hosting provider can't produce one when you ask, the badge on their homepage isn't doing anything for you, and the gap becomes your compliance problem too, since you're the one a regulator asks to demonstrate the arrangement.
This piece covers what a DPA is, what it has to contain, and the specific things to look for when you're trying to tell a real one from a privacy policy wearing a different hat.
What is a Data Processing Agreement?
GDPR splits responsibility between two roles. The data controller decides why and how personal data gets processed, which is almost always the business collecting it. The data processor handles that data on the controller's behalf, which is where hosting providers, backup services, email platforms, and most SaaS vendors sit.
Article 28 of GDPR requires a written contract between those two parties whenever a processor handles personal data for a controller. That contract is the Data Processing Agreement, usually shortened to DPA. It isn't optional, and it isn't satisfied by general terms of service that happen to mention privacy.
The threshold for needing one is lower than most small businesses assume. If you collect customer names, email addresses, order histories, or support tickets, and that data sits on a hosting provider's infrastructure, you're a controller using a processor. A one-person business with a contact form and a customer database is fully inside this requirement.
What a DPA actually has to include
A compliant DPA has to describe the processing itself: its subject matter, duration, nature, and purpose, along with the types of personal data involved and the categories of people the data relates to. This is the part that makes a DPA specific rather than generic, and it's the first place a thin template shows its limits.
It then has to set out the processor's obligations. The processor may only act on the controller's documented instructions, must keep staff handling the data under confidentiality obligations, must implement appropriate technical and organizational security measures, must assist the controller with data subject requests, must notify the controller of personal data breaches, and must delete or return the data when the contract ends. It also has to allow the controller to audit or inspect compliance, which in practice usually means accepting documentation or third-party certifications rather than literal on-site visits.
Sub-processors get their own treatment. If your hosting provider uses third parties to deliver the service, a backup vendor, a monitoring platform, a CDN, those are sub-processors. The provider generally needs your authorization before engaging new ones, has to inform you of changes, and remains responsible to you for their compliance. A DPA that says nothing about sub-processors is incomplete.
Why a DPA matters beyond the paperwork
The first reason is simply that using a processor without one is itself a GDPR failure, independent of anything else. You can be hosting exclusively in Germany, encrypting everything, and collecting the minimum viable data, and still be non-compliant purely because the contract that formalizes the arrangement doesn't exist.
The second reason is that the DPA is what determines who is responsible for what when something goes wrong. If there's a breach, the agreement defines notification timelines, who communicates with whom, and which party owes what to affected individuals and regulators. Sorting that out during an active incident, without a document to point to, goes badly.
The third reason is evidentiary. GDPR's accountability principle means you're expected to be able to demonstrate compliance, not just assert it. A signed DPA is one of the cleanest pieces of evidence you can hold, and its absence is one of the easiest gaps for a data protection authority to identify.
How to tell if your host actually offers one
A real DPA is a specific, signable document you can read before agreeing to it. If asking for one produces a link to a privacy policy, a paragraph in the terms of service, or a reassurance that the company "fully complies with GDPR," you haven't been given a DPA.
When you do get the document, check a few things. Does it reference GDPR Article 28 explicitly, or at least mirror its required contents? Does it name sub-processors, or link to a maintained list that gets updated when they change? Does it address international transfers, with standard contractual clauses or an equivalent mechanism, if any processing happens outside the EU or EEA? Transfers to the US are the case worth reading carefully: certified providers can currently rely on the EU-US Data Privacy Framework, but two predecessor arrangements were invalidated and the current one is under appeal, so a DPA that names the specific transfer mechanism it relies on is more useful than one that gestures at compliance generally. The same logic applies to choosing a jurisdiction in the first place.
Also pay attention to how easily you got it. A provider that publishes its DPA for download, or lets you accept it inside the control panel, is signaling that this is routine for them. One that requires a sales conversation before showing you the document is a slower path, though not necessarily a red flag. A provider that can't produce one at all has told you something important.
What good practice looks like on an ongoing basis
Signing a DPA once and filing it away isn't quite enough, because the facts underneath it change. Providers add and replace sub-processors, move workloads between facilities, and update their security documentation, and a DPA is supposed to reflect current reality rather than the arrangement as it stood when you signed.
A reasonable rhythm is to re-check your providers' sub-processor lists and DPA versions annually, and to keep copies of the versions you actually agreed to rather than relying on whatever is currently published. If a provider notifies you of a new sub-processor and you have concerns, the DPA is also the mechanism that gives you standing to raise them.
It's worth keeping this inventory alongside your other vendor documentation. Most businesses discover during their first real compliance review that they have more processors than they thought, since every analytics tool, email sender, and backup service is one, which is part of why some teams self-host analytics rather than adding another processor to the register.
Wrapping up
A hosting provider describing itself as GDPR-compliant and a hosting provider that can hand you a signed DPA covering your specific processing are two different situations, and only the second one holds up under scrutiny.
The check itself takes one email. Ask for the DPA, read what it says about sub-processors and international transfers, and keep a copy. If that request produces anything other than an actual document, you've learned something useful before it becomes a problem.
Thanks for reading! QDE runs unmanaged KVM VPS hosting from a Tier III data center in Amsterdam under Dutch and EU law, with minimal data collection by default. Its DPA is published for download rather than held behind a sales conversation, covering its obligations as a processor under GDPR, and any customer can request a copy.
Have questions about your specific setup? Contact our team, we're happy to help.
Frequently asked questions about Data Processing Agreements
Do I need a DPA even for a small VPS with just one customer's data on it?
Yes. GDPR Article 28 is triggered by the processing of personal data, not by volume. A single customer record containing a name and email address is enough to make you a controller and your host a processor, which means the contract requirement applies.
Who signs a DPA, the business or the hosting provider?
Both. The controller and the processor are parties to the same agreement. In practice most providers offer a standard DPA that you accept or counter-sign rather than negotiating from scratch, which is normal and perfectly valid as long as it still describes your actual processing rather than gesturing at compliance in general terms.
Is a DPA the same as a company's privacy policy?
No, and conflating the two is the most common mistake here. A privacy policy is a public-facing notice explaining how a company handles data about its own users. A DPA is a contract between two businesses governing how one handles data on the other's behalf.
What happens if a hosting provider changes sub-processors without telling me?
A compliant DPA obliges the processor to inform you of intended changes and gives you a mechanism to object. If a provider swaps sub-processors silently, that's a contractual failure on their side, and it's also a practical reason to re-check published sub-processor lists periodically rather than assuming notification always arrives.
Does having a DPA in place guarantee GDPR compliance?
No. It satisfies one specific requirement. You're still responsible for having a lawful basis for processing, keeping data minimal, securing it appropriately, honoring data subject requests, and documenting your own processing activities.
Can I request a DPA from any hosting provider?
You can always ask, though not every provider has one prepared. Worth knowing: processor status follows from the fact that they're handling personal data on your behalf, so a provider without a DPA isn't exempt from the role, just unready for it. The response itself is informative, and a provider that produces the document quickly has clearly been asked before.