GDPR from the Infrastructure Side: What It Means in Practice

The GDPR is often experienced as a matter of forms to sign and privacy notices to publish. That’s part of the story, but not all of it. Many of the regulation’s rules play out on servers, in databases, and in backups: that is, on the infrastructure. People who run systems don’t have to give legal opinions, but it helps to understand which technical choices the regulation asks them to make. This article tries to explain that in plain terms.

One necessary note before we start: this is not legal advice. It’s a general explanation of the technical side. For the specific obligations in your own case, you need a consultant or your data protection officer.

What we’re talking about

GDPR stands for General Data Protection Regulation. It’s Regulation (EU) 2016/679, adopted on 27 April 2016 and applicable from 25 May 2018. It concerns the processing of personal data, meaning any information relating to an identified or identifiable person: a name, an email, an IP address, the details of an order.

The starting point is simple. If a system stores or moves people’s data, the way it does so is not a matter of indifference. The regulation asks that it be done sensibly and, if something goes wrong, asks that you be able to demonstrate it.

The principles that concern the people running the systems

Article 5 lists the underlying principles of processing. Three of them touch infrastructure directly.

Data minimisation. The data collected must be “adequate, relevant and limited to what is necessary” in relation to the purpose. Translated: you don’t collect everything just in case, only what you genuinely need.
Storage limitation. Data must be kept “for no longer than is necessary” for the purpose. In other words, it has an expiry date; it doesn’t pile up forever.
Integrity and confidentiality. Data must be processed in a way that ensures appropriate security, including protection against unauthorised access and against accidental loss or destruction.

There’s then a fourth principle that frames the rest, accountability: whoever processes the data must not only follow the rules but be “able to demonstrate compliance” with them. That’s the reason so many technical choices need to be documented.

Encryption: data at rest and in transit

Article 32 deals with the security of processing. Among the measures it names explicitly are “the pseudonymisation and encryption of personal data”.

Encrypting means transforming data so that it’s readable only with the right key. In practice there are two moments to distinguish.

In transit, that is, while the data travels across the network. This is the case of a site that uses HTTPS instead of HTTP, or a link between two servers inside an encrypted tunnel. Anyone intercepting the traffic sees something go by but can’t read it.
At rest, that is, while the data sits still on a disk. If the drive is stolen or a copy ends up in the wrong hands, without the key it stays unreadable, a principle that applies to cloud storage too, where for instance S3 changed its default encryption settings.

The same article considers the risks of destruction, loss, alteration, unauthorised disclosure of, or access to data “transmitted, stored or otherwise processed”. From there comes the practical distinction between data in motion and data at rest.

Logs: useful, but not forever

Logs - the records of what happens on a system - are valuable for understanding problems and reconstructing an incident. But they often contain personal data: an IP address, a username, the time of a login.

This means the same principles apply to logs too. Minimisation: record what you need, not everything out of habit. Storage limitation: decide how long to keep them, then delete or anonymise them. Keeping logs forever “to be safe” goes in the opposite direction to the one the regulation points to.

Access control and traceability

A recurring idea is that only those who genuinely need it should be able to reach a piece of data, and only for as long as they need it. On the technical side this translates into concrete things: personal accounts instead of shared credentials, permissions assigned by role, and revoking access when someone changes job or leaves the organisation, perhaps starting from a single watched entry point like a bastion host.

Alongside control there’s traceability: knowing who did what and when. It helps both to deter misuse and, in the event of an incident, to understand what happened. It’s also one of the tools with which you demonstrate that you acted sensibly.

Secure backups

Article 32 also names the ability to restore the availability and access to data in a timely manner after a physical or technical incident. In other words: backups aren’t just good practice, they’re part of the required security.

But a backup is, to all intents and purposes, a copy of the data, and it has to be protected like the original, ideally by following a structured strategy like the 3-2-1 backup rule. If production data is encrypted and the copies aren’t, the protection has a hole. That’s why a backup should be encrypted, kept somewhere safe, and tested: a copy you can’t restore protects no one.

Where the data lives

Another question the regulation makes relevant is a simple one: where is the data physically located? The GDPR sets specific conditions for transferring personal data outside the European Union. It’s not a ban, but it does require safeguards.

For anyone running infrastructure, this translates into concrete choices about how to choose a cloud provider and the region where the servers run and the backups are kept. Knowing which country the data lives in isn’t a bureaucratic detail: it’s a piece of technical information worth knowing.

An approach, not a list of rules

It’s tempting to want a fixed checklist of “minimum measures”. The regulation doesn’t work that way. As the Italian data protection authority (the Garante) points out, the list in Article 32 is open and non-exhaustive, and after 25 May 2018 there are no blanket obligations to adopt minimum measures: the choice is left case by case to the controller, in relation to the specific risks. One fixed point remains, though: defending software abandoned by its maker as adequate is close to impossible.

This is the idea of protection “by design”, set out in Article 25: data protection should be thought about from the start, when a system is designed, not bolted on at the end. And it should be proportionate to the risk: the data of a neighbourhood forum and the health data of a clinic don’t call for the same precautions.

One last practical point. If a data breach occurs that poses a risk to people, the controller must notify the supervisory authority “without undue delay and, where feasible, not later than 72 hours” after becoming aware of it. Having logs, backups, and a minimum of procedure ready in advance makes that deadline manageable instead of an emergency.

In short

On the infrastructure side, the GDPR asks for reasonable things: encrypt data at rest and in motion, collect and keep only what’s necessary, control and trace access, protect backups, and know where the data lives. It isn’t a list to tick once, but a way of designing systems that’s proportionate to the risk and able to account for its own choices. The legal side remains a separate craft: for the obligations in your own case, you need a consultant.