GDPR does not certify servers, and no hosting setup is “GDPR compliant” on its own: compliance belongs to the organisation and how it handles personal data. But Article 32 of the GDPR requires “appropriate technical and organisational measures” to protect that data, and most of those technical measures live on your servers and in your cloud accounts. This checklist covers what we look at when we prepare infrastructure that holds personal data of people in the EU.
This is a technical guide, not legal advice. Your data protection officer or lawyer decides what is appropriate for your processing.
What Article 32 actually asks for
Article 32 lists measures to apply “as appropriate” to the risk:
- pseudonymisation and encryption of personal data
- the ongoing confidentiality, integrity, availability and resilience of systems
- the ability to restore availability and access to data in a timely manner after an incident
- a process for regularly testing and evaluating whether these measures work
The checklist below turns those four points into concrete server and cloud settings.
1. Know where the data is
- Keep an up-to-date inventory of every server, database, bucket, backup and log store that holds personal data, and the region it runs in.
- Choose EU regions on your cloud provider for primary data and backups, if your transfer assessment requires it.
- Remember the copies people forget: backups, database replicas, log files, staging environments and support tooling.
- If data leaves the EU (including remote administration from outside it), the transfer needs a legal basis under GDPR Chapter V, for example an adequacy decision or Standard Contractual Clauses.
2. Encrypt in transit and at rest
- TLS 1.2 or 1.3 on every public endpoint, and between your own services where traffic crosses networks you do not control.
- Encrypted disks and volumes, and encryption for database storage, object storage and backups.
- Keys held in a key management service or vault with restricted access, not in the application code.
3. Control and limit access
- Named accounts for every administrator; no shared logins.
- Multi-factor authentication for cloud consoles, VPNs and SSH bastions; SSH keys instead of passwords.
- Least privilege: production database access only for the people who need it, reviewed regularly.
- Remove access the same day someone leaves or changes role.
4. Log who did what
When something goes wrong, you need to know which data was accessed and by whom. Log administrative logins, privilege use, configuration changes and access to systems holding personal data, ship the logs off the server, and protect them from tampering. Avoid writing the personal data itself into logs. Our guide to audit logging for compliance covers the details.
5. Detect and report breaches in time
Under Article 33, a controller must notify the supervisory authority within 72 hours of becoming aware of a personal data breach, where feasible, and a processor must tell the controller without undue delay. That is only possible if you find out quickly:
- Alerting on suspicious logins, privilege escalation, unexpected data exports and malware detections.
- A written incident response plan that names who decides whether a breach is reportable.
- Clear contacts and contractual duties between you and every processor, including your hosting and support providers.
6. Keep systems patched and hardened
- Apply security updates on a schedule, and critical ones within days.
- Close unused ports and services, and put administrative interfaces behind a VPN or allow-list.
- Use a web application firewall and rate limiting on public applications.
7. Back up, and prove you can restore
Article 32 asks for the ability to restore data in a timely manner. Keep encrypted backups in the same jurisdiction as the primary data, keep at least one copy that ransomware cannot delete, and test a full restore regularly. A backup that has never been restored is not evidence of anything.
8. Do not keep data forever
The storage limitation principle in Article 5 means data should not be kept longer than needed. Set retention periods for databases, backups and logs, and automate deletion. Old backups and log archives are a common place where deleted customer data quietly survives.
9. Test regularly and keep records
- Vulnerability scans and periodic penetration tests of internet-facing systems.
- Configuration reviews after major changes.
- Written records of the measures above, so you can show your work to customers, auditors or a regulator.
Working with a hosting or support provider
If a provider can access personal data on your behalf, they are usually a processor under GDPR, and Article 28 requires a contract (a Data Processing Agreement) covering what they may do with the data, their security measures, sub-processors and breach notification. Ask for it before granting access.
Get help
TechProvidence engineers implement and maintain these technical measures on Linux servers, AWS, Google Cloud and Azure as part of our cybersecurity and risk management and outsourced sysadmin support services. Contact us to review how your infrastructure handles personal data.
