What Is GDPR: A Practitioner’s Refresher

Illustration for: What Is GDPR, A Practitioner’s Refresher

Ask three colleagues what GDPR forbids and you will get three confident, contradictory answers. Eight years after it took effect, the General Data Protection Regulation remains the most quoted and least read law in the average office, blamed for everything from cookie banners to a refusal to share the tea rota. This post is a practitioner’s refresher on what the law actually says, what enforcement actually looks like, and why a security or risk professional should read it as a risk management statute that happens to wear privacy clothing.

The shortest accurate summary

GDPR is Regulation (EU) 2016/679. It applied from 25 May 2018 and it governs the processing of personal data, which means almost anything you do with information about an identifiable living person. When the UK left the EU it kept the text, so British organisations now work under the UK GDPR alongside the Data Protection Act 2018, enforced by the ICO. An organisation trading with Europe usually answers to both regimes at once, and to two sets of regulators.

Personal data is broader than people expect

Names and email addresses, obviously, but also IP addresses, device identifiers, location traces, staff records and pseudonymised data that could be re-linked. If your logs can be tied to a person, they are in scope.

The controller and processor split matters

The controller decides why and how data is processed. The processor acts on the controller’s instructions, a hosting provider or payroll bureau, for instance. Obligations differ, contracts between the two are mandatory, and a supplier assessment that never asks “controller or processor” has missed the first question. An earlier post in this series on supplier security made the same point from the other direction.

Seven principles, and the one that eats the rest

Everything in the regulation hangs off seven principles. Data must be processed lawfully, fairly and transparently, collected for specified purposes, kept to the minimum needed, kept accurate, kept no longer than necessary, and kept secure. The seventh is accountability, and it is the one that eats the other six, because it requires you to be able to demonstrate compliance, not merely achieve it.

Circular diagram of the seven data protection principles arranged around a centre labelled personal data

The seven principles in plain words, where “minimal”, “Correct” and “Time limits” stand for data minimisation, accuracy and storage limitation. “Prove it” is the formal principle of accountability, and it is the reason the other six generate paperwork.

Accountability is why records of processing activities exist, why data protection impact assessments exist, and why “we thought about it and decided” is only a defence when it comes with a date and a signature. Readers of this series will recognise the shape. The regulation does not demand perfection, it demands that someone weighed the risk, made a deliberate decision and wrote it down. That is simply risk management applied to other people’s information.

Six lawful bases, and why consent is not the default

Every act of processing needs one of six lawful bases. They are consent, contract, legal obligation, vital interests, public task and legitimate interests. The most common mistake I see in practice is treating consent as the default. It is not, and it is usually the worst choice, because consent must be freely given, specific and revocable. If the person cannot realistically say no, the consent is invalid and the processing is unlawful. Employers relying on employee “consent” fail this test almost by definition.

Legitimate interests is the workhorse basis for most private-sector processing, and it has a built-in discipline worth noticing. To rely on it you must balance your interest against the rights of the individual and record the assessment. Once again the law is not asking for a particular answer. It is asking for a documented decision.

The rights, the clock and the breach line

Individuals hold enforceable rights, among them access to their data, rectification, erasure in some circumstances, portability, objection, and protection from purely automated decisions with significant effects. The subject access request is the one that bites operationally, with a one-month deadline that lands on whoever holds the mailbox that day.

For security teams, Article 33 is the sharp edge. A personal data breach must be reported to the ICO within 72 hours of awareness unless it is unlikely to pose a risk to individuals. Two things follow. First, the 72-hour clock is an incident-process design constraint, exactly like the reporting clocks covered elsewhere in this series, and it cannot be met by a process designed mid-incident. Second, the “unlikely to pose a risk” judgement is itself a risk assessment, and if you decide not to report you must record why. The regulator’s first question after a late notification is when you knew and what you decided.

Article 32 deserves more attention from security people than it gets

It requires security measures “appropriate to the risk”, taking into account the state of the art, costs, and the nature of the data. That is not a checklist, it is a legal duty to do proportionate, documented risk assessment on the systems holding personal data. Your risk register is not just good practice here. It is evidence.

What enforcement actually looks like

The headline maxima are real, up to £17.5 million or 4 per cent of global turnover in the UK, 20 million euros or 4 per cent in the EU. Actual practice is more instructive than the maxima.

• British Airways was fined £20 million in 2020 for a payment-page compromise, reduced from a proposed £183 million.
• Marriott paid £18.4 million for a long-running breach inherited through an acquisition, a due-diligence lesson as much as a security one.
• Meta received a 1.2 billion euro fine in 2023 over EU-US data transfers, the largest to date and a reminder that transfers, not breaches, drive the biggest numbers.

International transfers remain the most legally unstable corner of the regime. Standard contractual clauses, the UK’s international data transfer agreement and the EU-US Data Privacy Framework carry the traffic today, and each has been or will be litigated. If your architecture assumes data can move freely to the United States, that assumption sits on legal foundations that have already collapsed twice.

The ICO, meanwhile, has shifted visibly toward reprimands and enforcement notices for the public sector, reserving large fines for serious private-sector cases. Anyone waiting for a fine before taking the law seriously has misread the incentive. The expensive part is rarely the penalty, it is the remediation, the litigation and the lost trust.

The UK is drifting, slowly

The Data (Use and Access) Act 2025 made the first substantial UK amendments since exit. It introduced a list of recognised legitimate interests that skip the balancing test, eased rules on some automated decision-making, allowed subject access clocks to pause while identity or scope is clarified, and began restructuring the ICO into an Information Commission. None of this rips up the framework, and the EU extended the UK’s adequacy decisions while it assessed the changes. At the time of writing adequacy has survived, but every future divergence re-runs that test, and a UK business serving EU customers should treat continued adequacy as an assumption to monitor, not a fact to rely on.

Where the critics have a point

An honest refresher should admit what the sceptics get right. Much of the visible compliance is theatre, and the cookie banner is its monument, a ritual that annoys everyone and protects no one. The cost falls disproportionately on small organisations that process little and risk less. And “appropriate” measures is vague enough that two competent professionals can disagree about the same control. All true. None of it changes the practitioner’s position, because the law’s core demands, know what data you hold, decide why you hold it, protect it in proportion to the harm it could do, are things a competent organisation should be doing anyway.

That framing is also the reason to hold your data protection records close. A record of processing activities is a map of every system that holds personal data and every purpose you put it to, which makes it another entry in the target map this series keeps returning to. Treat it accordingly.

GDPR did not invent any of this. It took ordinary risk discipline, applied it to personal information and attached penalties for organisations that could not show their working. The organisations that struggle with it are, almost without exception, the ones that never made deliberate decisions about data in the first place. Decide, document, defend. A written decision about why you process what you process will satisfy a regulator far more often than an accidental default ever will.