GDPR in IT practice: technical security measures
'Appropriate technical measures' — but which exactly? GDPR Article 32 as an IT checklist: encryption, access, logs, backups and testing.
GDPR deliberately contains no list of required technologies — Article 32 speaks of measures “appropriate” to the risk, taking into account the state of the art and costs. That flexibility suits lawyers, but it leaves IT teams with the question: what exactly should we implement? The answer exists — assembled from case law, fines issued by European authorities, EDPB guidance and sound security practice. Below we translate it into a checklist.
How to read Article 32: risk, not ritual
The provision explicitly names four directions: pseudonymisation and encryption, the ability to ensure the confidentiality, integrity, availability and resilience of systems, the ability to restore availability quickly after an incident, and regular testing and evaluation of the measures’ effectiveness. The interpretive key: you match measures to the risk to the data subjects — not to the company. A database of 100,000 customers with financial data demands more than a newsletter mailing list; the same online shop needs different measures for its orders database than for its recruitment system.
The practical consequence: before implementing anything, you need a processing map (the RoPA usually already exists with your DPO) joined to a systems map — which applications, databases and drives hold which categories of data. Without it, the “appropriateness” of measures is guesswork.
The checklist: 8 areas a regulator will ask about
1. Access control. Access to personal data on a need-to-know basis: named accounts, roles instead of access-to-everything, quarterly permission reviews, immediate off-boarding. MFA for access to systems holding data — after a series of European fines for hijacked accounts without MFA, its absence is hard to defend as “state of the art”.
2. Encryption. At rest: full disk encryption on laptops (a lost encrypted laptop is an incident without the duty to notify individuals — an unencrypted one can end in a fine), encryption of databases and backups. In transit: TLS everywhere, including internally. Plus key management — encryption with the key lying next to the data is theatre.
3. Pseudonymisation and minimisation. Test and development environments without production personal data (a frequent point in fines!) — anonymisation or synthetic data. In analytics: identifiers instead of raw data. Retention implemented technically: automatic deletion/anonymisation when periods expire, not “a policy in a binder”.
4. Logging and accountability. Who accessed whose data and when — especially in HR, medical and financial systems. Logs protected from modification, kept with a defined retention and actually reviewed (monitoring) — in an incident, they decide whether you can establish the breach scope within 72 hours.
5. Availability and recoverability. Ransomware encrypting personal data is a breach of its availability — i.e. a GDPR breach, even without a leak. Hence the requirement of backups with restore testing and a continuity plan. Article 32’s “timely restoration of availability” means a properly tested RTO, not a declaration.
6. Regular testing. GDPR explicitly requires “regularly testing, assessing and evaluating the effectiveness” of the measures. In practice: vulnerability scanning on a continuous rhythm, periodic penetration tests for systems holding data, configuration audits. A test report is simultaneously compliance evidence — authorities ask for it after incidents.
7. Processors (Article 28). Every entity processing data on your behalf — hosting, SaaS, an agency, IT support — requires a data processing agreement and verification that it meets Article 32 itself. It’s the same work as TPRM, just with a legal sanction attached.
8. Privacy by design/default. New projects and changes pass through data questions at the design stage: must we collect it, how long do we keep it, who will have access. For high-risk processing — a DPIA before launch (this includes AI deployments).
What the fines teach
The patterns in decisions by European authorities repeat consistently enough to act as an unofficial requirements list: no MFA on remote access to data, unencrypted media, production data in test environments, no security testing despite policies declaring it, overly broad permissions with no reviews, and finally — the inability to demonstrate that measures worked (no logs, documentation or test results). That last point is crucial: the accountability principle means undocumented measures are treated as non-existent.
Putting it together: the minimum plan
- Map the systems processing personal data and classify them by risk (volume, data categories, impact of a breach on individuals).
- For high-risk systems, close the eight areas above first; for the rest — a proportionate version.
- Document the state: policies + technical evidence (configuration snapshots, test reports, permission review logs).
- Rehearse a breach scenario against the 72-hour clock — we described it step by step.
- Repeat tests and reviews on a fixed rhythm; system changes trigger a measures review.
Frequently asked questions (FAQ)
Does GDPR specifically require penetration tests? It doesn’t name them — it requires “regular testing and evaluation of effectiveness”. In practice, for systems processing significant data, that requirement is hard to satisfy without security testing, and authorities ask directly for the results after incidents. A penetration test is the strongest single piece of evidence that your measures work — we run them with reports your DPO can actually use.
We have ISO 27001 — does that settle Article 32? It helps a lot (it covers systematic risk management and most measures), but it doesn’t remove the thinking: ISO protects the organisation’s information, GDPR protects individuals’ rights. Verify that the certification scope covers the systems holding personal data and that the risk analysis includes the data subjects’ perspective.
Is encryption mandatory? Formally it’s an “example” measure; practically it’s the expected standard wherever its absence raises risk: laptops, media, transmission, backups, sensitive data in databases. Bonus: a leak of properly encrypted data (without the key) usually doesn’t require notifying the individuals affected.
Who owns technical measures — the DPO or IT? The controller (i.e. the board). The DPO advises and monitors, IT implements, but the decision on risk level and budget is management’s responsibility — exactly as under NIS2. Good practice: a joint IT + DPO risk map, reviewed with the board twice a year.
Where do we start if today we only have policies on paper? With the four highest-impact items: MFA on access to data, laptop encryption, backups with a restore test, and access logs on key databases. Then a gap audit against the list above. We can run such a technical compliance review and leave you a prioritised remediation plan.
Summary
GDPR Article 32 can be turned into concrete work: access control with MFA, encryption, minimisation, logs, restorable backups, regular testing, processor oversight and documentation that proves it all. It’s the same hygiene that protects against ransomware and breaches — GDPR merely adds a sanction. If you want to know how your technical measures compare with the requirements and regulators’ practice — let’s audit them.
This article is not legal advice. Sources: GDPR (Articles 5, 25, 28, 32–34), EDPB guidelines, supervisory authority decisions.