Twelve questions to ask about your host's GDPR measures
Your host's GDPR measures should answer precise questions. Twelve to ask about data location, access, encryption, backups, disk erasure and breach notice.
When you put personal data on a hosting provider's infrastructure, the provider becomes your processor under the GDPR. Article 28 says you may only use processors that give sufficient guarantees, and Article 32 says what those guarantees are about: appropriate technical and organisational measures, usually called the TOM. Many providers can send you a TOM document. Fewer can answer precise questions about it. Here are the questions that separate the two, and why each one matters.
Where the data lives
1. Where are the primary copies, the replicas and the backups? "Our servers are in the EU" often describes only the primary copy. Replicas for resilience and backups for recovery are copies of personal data too. Ask for the location of each, explicitly.
2. From where is the infrastructure administered? Remote administrative access from outside the EU can itself amount to a transfer, because personal data becomes accessible from there. Ask where the people and systems that manage your servers are located.
3. Is there a public cloud underneath? Some providers resell capacity from a hyperscaler under their own name. That adds a sub-processor and a jurisdiction you may not have agreed to. Ask whose hardware your data actually sits on.
Who can touch it
4. Who are the sub-processors, and how will you hear about changes? Article 28 requires your authorisation for sub-processors. You should have a current list and a defined way of being told before it changes.
5. How do staff authenticate to management systems? Look for multi-factor authentication on the provider's VPN and on management web interfaces, key-based administrative access to servers, and a management network that customer traffic cannot reach.
6. How are customers separated from each other? The answer should cover the network, storage and virtualisation layers, not just "each customer has their own login".
7. What confidentiality obligations bind the people with access? Article 28(3)(b) requires that persons authorised to process the data are bound by confidentiality. Ask how that is done for the provider's own staff and for the datacenter operator's. Our answer: every EuroVPS employee and contracted engineer is bound by written confidentiality obligations that continue after their engagement ends, and the datacenter operator binds its own staff the same way under its audited controls.
How it is protected and recovered
8. Is data encrypted in transit and at rest? In transit between sites and to management locations, and at rest on storage and in backups. Ask whether encryption at rest is the default or an option you must request.
9. Can a compromised server reach its own backups? This is the question that matters most for ransomware. If production servers can write to, or even see, the backup system, an attacker who takes a server can destroy its backups. The safer design is pull-only: the backup side pulls from production, and production has no network path to the backup plane at all.
10. How often are restores actually tested? Ask how often restore tests run and what evidence is kept.
11. What happens to disks that leave service? Ask how drives are sanitised and whether there is a per-disk record. A good answer names the erasure method or tool and states that a certificate is kept for every disk wiped.
When something goes wrong
12. How and when will you notify us of a personal data breach? Article 33(2) requires a processor to notify the controller without undue delay after becoming aware of a breach. Ask what "without undue delay" means in practice, through which channel, and what information the first notice will contain.
Ask for evidence, not adjectives
Words like "robust", "industry standard" and "state of the art" appear in many TOM documents and prove nothing. For each answer, ask what would show it to an auditor: a certificate and its scope, a configuration policy, a sample erasure certificate, the date and result of the last restore test. A provider that runs these measures has the evidence to hand. A provider that only describes them will need time to find it.
Red flags in the answers
- Locations given only for the primary copy.
- "We are working on MFA."
- Backups on a share that production servers mount.
- No restore test in living memory.
- Disk disposal described as "handled by the datacenter" with no records.
- A TOM document that reads like a generic template, with no names of systems, methods or tools in it.
How we answer them
We publish our TOM behind a request form, and these are its short answers. Data hosted in our European datacenters (Athens at Digital Realty, and Amsterdam) stays there, and replicas and backups of EU-hosted data stay inside our own EU infrastructure. Our corporate headquarters is in Cyprus, also in the EU. The servers, storage, networks and backup systems are our own, not resold public cloud. Administrative access is by key through our own gateways, behind MFA, on a management network customer traffic cannot reach. Traffic between our sites crosses our own encrypted backbone, and data on storage and in backups is encrypted at rest by default. Backups are pull-only, enforced on firewall appliances. Restores are tested regularly, as often as weekly. Retired drives are sanitised with Blancco, and we keep the erasure certificate for every disk. We work under our own Data Processing Agreement, the same for every customer, and the TOM is signed by a Director.
We also certify the management systems behind those answers: ISO/IEC 27001 with ISO/IEC 27017 and ISO/IEC 27018, the code of practice for personal data in cloud services.
If you are reviewing your processors and want our TOM, or want help reading someone else's, ask us. Talk to an engineer
Published 22 October 2026.
All field notes