GDPR in 2026: what changed since 2018.

Why the text stayed still and the practice moved

GDPR has not been rewritten. The article numbers you learned in 2018 are the article numbers you apply in 2026. What changed sits one layer down: the case law that interprets the text, the EDPB guidelines that operationalise it, the standard contractual clauses that paper your transfers, and the adequacy machinery that governs where data can legally land. A privacy programme built in 2018 and never touched since is not wrong on paper. It is stale in practice, and stale is what enforcement now finds.

This page is for the person who already understands the regulation and needs to know what to refresh. It assumes you can define personal data, a controller and a lawful basis. It focuses on the four moving parts that actually generate findings in 2026: international transfers, the Transfer Impact Assessment, the AI Act overlap, and the question of whether you are required to appoint a Data Protection Officer at all.

International transfers: the decision tree, not the headline

Most teams know the headlines. Schrems II struck down Privacy Shield in 2020. The EU-US Data Privacy Framework replaced it in 2023. The 2021 SCCs replaced the 2010 versions. The headlines are true and almost useless on their own, because the real work is matching a specific transfer to a specific instrument and then deciding whether a Transfer Impact Assessment is required on top of it. That is a decision tree, and you run it per data flow, not once for the whole company.

Start from the destination. If the importer sits in a country with a current EU adequacy decision, you transfer on the adequacy decision and you do not need SCCs or a TIA for that flow. If the destination is the United States and the importer is self-certified under the Data Privacy Framework for the relevant data categories, that flow rides the DPF as its own adequacy basis: no SCCs, no supplementary measures. The moment you step outside both of those, you are on Article 46 safeguards, which in practice means the 2021 SCCs, and the SCCs come with a TIA obligation that Schrems II made non-optional.

The Transfer Impact Assessment in operations

A TIA is the document that answers one question: does the law and practice of the destination country undermine the protection your SCCs promise on paper? It is not a checkbox. It is a small piece of legal-and-technical analysis you produce per transfer (or per group of materially identical transfers) and keep on file for the day a regulator asks.

In practice a defensible TIA does four things. It describes the transfer concretely: who exports, who imports, what data, what volume, what purpose. It assesses the destination legal regime, with particular attention to government access powers and whether a data subject has any effective redress. It identifies supplementary measures where the legal regime is weak, and the measure that actually moves the needle is encryption you control, where the importer never holds the keys. And it records a reasoned conclusion: proceed, proceed with measures, or do not transfer.

1. Map the flow precisely, including any onward transfers your processor makes to sub-processors. The flows you forget are the ones that surface in a breach.
2. Assess destination law against the EDPB criteria, not your gut feel about the country.
3. Apply supplementary measures where needed, and treat strong, key-managed encryption as the default technical measure rather than contractual promises alone.
4. Document the conclusion and date it, then set a review trigger so it does not silently expire.

Where GDPR meets the AI Act

The AI Act does not replace GDPR and does not relax it. Where an AI system processes personal data, both apply in full and you satisfy both. The cleanest way to see the overlap is by the artefact each regime expects. GDPR wants a Data Protection Impact Assessment when processing is likely to be high risk to individuals. The AI Act wants a conformity assessment, technical documentation and (for some systems) a fundamental rights impact assessment for high-risk AI. These are different documents answering different questions, and a high-risk AI system that touches personal data needs both, consistent with each other.

The friction points are familiar GDPR problems wearing new clothes. Automated decision-making with legal or similarly significant effect already triggered Article 22 obligations; the AI Act layers transparency and human-oversight duties on top. Training data raises lawful-basis and purpose-limitation questions that do not disappear because the output is a model. Profiling and inference were always in scope. The practical rule for 2026: do not run an AI governance workstream that ignores your DPO, and do not run a privacy programme that pretends model training is someone else’s problem. The two assessments should reference each other.

Privacy engineers who have to bridge these regimes in build decisions are exactly the audience for the CDPSE certification, which is structured around governance, architecture and data lifecycle rather than legal text alone. To operationalise privacy as a management system that sits cleanly beside an ISMS, the ISO 27701 Foundation course covers the PIMS model, and the ISO 27701 Lead Implementer course takes you through building and running it.

Enforcement is a signal, not just a risk

Read recent enforcement as a map of where authorities are looking, because they tell you where your own exposure probably is. The pattern across 2023 to 2025 is consistent. International transfers produced the largest single penalties, with the Meta decision (1.2 billion euros) turning on EU-US data flows. Behavioural advertising and the lawful basis for ad targeting drew the LinkedIn decision (310 million euros). Scraped biometric data drove repeated action against Clearview AI across multiple authorities. The active authorities are the ones you would expect: the CNIL in France, the DPC in Ireland for the large platforms, the AEPD in Spain.

The operational takeaway is to stop treating enforcement as someone else’s headline. If transfers, ad-tech consent and biometric or AI-adjacent processing are where the fines land, those are the three files a regulator is statistically most likely to ask you about. A programme that can produce a current TIA, a defensible consent record and a DPIA for its riskiest processing is a programme that survives the questions actually being asked.

Do you actually need a DPO?

The DPO question is the one most often answered by reflex rather than by the text. Article 37 makes a DPO mandatory in three situations: you are a public authority or body; your core activities consist of regular and systematic monitoring of data subjects on a large scale; or your core activities consist of large-scale processing of special category data or data on criminal convictions. If none of those apply, GDPR does not force the appointment, though some national laws add their own triggers and a voluntary DPO is often the sound choice.

The phrase that decides most real cases is "core activities". A hospital monitors health data as its core activity, so it needs a DPO. A manufacturer that runs payroll processes personal data but that is a support function, not a core activity, so payroll alone does not trigger the obligation. The mistakes cluster at the edges: appointing someone who lacks the independence and reporting line Article 38 requires, naming a DPO who has a conflict of interest because they also own the processing they are meant to oversee, or appointing on paper while giving the role no authority. A DPO who cannot reach the board and cannot say no is a finding waiting to be written.

If the role is yours to fill or to oversee, the depth matters. The GDPR Foundation course is the right starting point for the team around the role, and the GDPR Certified Data Protection Officer course is built for the person carrying the title, covering the independence, tasks and accountability the regulation actually demands.

What to refresh before your next audit

Bring the moving parts up to date and the rest of the programme largely takes care of itself. Confirm every transfer is on the 2021 SCCs, not the withdrawn 2010 set, because legacy clauses are an instant finding. Check that each non-adequate transfer has a dated TIA linked from your RoPA. Verify any US vendor you rely on is currently DPF-certified for the data you send, and that you hold an SCC fallback if it is not. Make sure your highest-risk processing has a DPIA, and that anything AI-driven has the AI Act artefacts sitting alongside it. Finally, re-test the DPO question against your actual core activities rather than the answer you gave in 2018.