Purpose & Means Newsletter — Issue 1, August 2026

I have been working in data protection for long enough to know that most of the problems are not legal problems. They are people problems, communication problems, and organisational problems — in data protection, in security, in AI governance, across the board. That is what this newsletter is about.

Welcome to Issue 1.

Tim

Data Protection Hero: The meeting is not over #

The meeting is not over.

This is the moment that separates a DPIA that protects people from a DPIA that protects a project timeline. Risk acceptance is not a feeling. It is not the most senior person in the room pointing at a colour. It is a documented, defined threshold, agreed in advance, not invented in the moment to close a meeting. Today’s hero asked the question nobody wanted to hear. The answer mattered more than the schedule.

The DPIA nobody wanted to write #

Why conventional DPIA practice is organisation-centric — and what the EU Charter says instead.

Part one of a short series.

Spend any time on LinkedIn and you’ll see them. DPIAs shared proudly — completed, signed off, filed. And I understand the impulse. Getting one done is genuinely hard work.

But when I look closely, I see a pattern. A generic risk heat map. Pages dedicated to repeating and reciting articles from the law itself, as if citation were analysis. A conclusion with some high level mitigation statements and often that the risks are acceptable.

In my view, anything with a generic risk heat map deserves further scrutiny. A document that spends more pages reciting the GDPR than engaging with the people it’s supposed to protect fuels sceptism.

Here’s an example of a typical heat map structure. This one is provided by one of the Scandinavian supervisory authorities:

I do not believe these kind of heatmap representations help. They raise more questions than answers but unfortunately they are common in many companies despite being discredited in some risk management circles.

To me, risk management must be at the heart of any change project or programme and when it involves data protection we need to be mindful of the risks that require primary focus. Over the years, I’ve read quite a few books that emphasise the importance of understanding risks to the rights and freedoms of individuals. I’ve followed the repeated attempts by regulators to provide guidance in the spirit the law was intended, guidance that, in practice, tends to get rehashed into an ever more legal-oriented framework, edging further from the person and closer to the organisation.

Earlier this year, the penny really dropped.

I attended a design thinking workshop at the Data and Analytics Lab at the University of Lisbon. I came away inspired — not just by design thinking itself, but by the whole philosophy of the lab: the idea that how you frame a problem determines what solutions become visible, and that starting with the human experience changes everything downstream. I’ve since applied many of the concepts I encountered there in my own work and, perhaps unexpectedly, in my own homelab setup, particularly in my transition to self-hosting my own infrastructure.

That shift in thinking made something obvious I hadn’t been able to name before. The current DPIA approach, even in its recently revamped form, leaves an enormous amount on the table. Not because the people doing the work aren’t skilled or diligent. But because the framework itself starts in the wrong place.

What “rights and freedoms” actually means #

Before we get to what a better approach looks like, it’s worth pausing on terminology because a surprising amount of expensive certification training content uses PIA and DPIA almost interchangeably. They are not the same thing, and the difference is not administrative.

A Privacy Impact Assessment is a concept with roots in US federal practice. A Data Protection Impact Assessment is a specific legal instrument under the GDPR, and the distinction that matters most is what it is assessing risk to. Not to the organisation. Not to the project. To the rights and freedoms of individuals, and in a European context, that means primarily the Charter of Fundamental Rights of the European Union. In other words: human rights.

That is not a minor difference in framing. It is the entire point. The moment you treat a DPIA as a European version of a PIA, you’ve already narrowed the lens in a way the law never intended.

The old WP29 guidance makes this explicit: “rights and freedoms” reaches far beyond data protection. Freedom of speech. Freedom of movement. Freedom of thought. Non-discrimination. Dignity. Liberty. These aren’t abstract values to be noted and moved past. They are what is inherently at stake when personal data is processed at scale, in ways that profile, predict, or decide.

And we’re talking concrete harms to individuals, groups and sometimes society as a whole: erroneous profiling leading to discrimination, reduced dignity, impact on vulnerable groups, effects on freedom of expression. The AI Act’s Fundamental Rights Impact Assessment requirement moves in the same direction. So does the Council of Europe’s guidance on national digital identity systems.

The regulatory framework is already pointing toward something more human-centred. Practice hasn’t caught up.

The data subject problem #

There is a second issue that gets less attention: the data subject category itself. A lot of DPIAs treat it as a single generic entry: employees, patients, online consumers, etc. But a marketer would never accept that level of granularity when trying to understand an audience. The vulnerabilities, and therefore the real risks to rights and freedoms, live in the detail.

A new starter and an employee on a performance improvement plan are both “employees.” Their risk profiles are completely different. An adult online consumer and a teenager using the same platform are both “users.” What is routine data processing for one may constitute a serious risk to dignity, autonomy, or freedom for the other.

My view is that we need to disaggregate data subject categories with the same rigour we would apply to any audience we were genuinely trying to understand. Once you do that, once you identify the granular profiles where vulnerability is concentrated, you can perform a meaningful risk assessment on those specific groups, rather than producing a generic assessment that misses precisely the people who needed protecting most.

A different starting point #

Design thinking starts with empathy, structured engagement with the actual experience of the people affected by a decision. Value sensitive design, developed by the great Batya Friedman and colleagues over three decades, asks us to identify not just direct stakeholders but indirect ones, to work with explicit definitions of values rather than generic references to “privacy,” and to treat value tensions as design constraints rather than trade-offs to be scored and filed.

Applied to a DPIA, this changes the starting point entirely. Instead of beginning solely with the processing activity you must also place greater focus on the data subject — their specific context, their vulnerabilities, their values — and ask: what could this do to this person?

That’s a different question. It produces different answers. And it makes a DPIA that a regulator, a board, and a data subject can each read and get something honest out of.

In Part 2: how I think a DPIA should look in practice, the four-layer approach, why declaring risk appetite before you start is the step most organisations skip, and a first look at a different way to visualise risk to the rights and freedoms of individuals. (See below for a preview.)

In relation to the main piece, I am also currently working on visualising risk in a different way to the traditional heat map. Below are a couple of rough mock-ups I am working on. I aim to share a developed representation in a future issue (click to enlarge):

Field Talk — November 2026 #

Field Talk is a free, practitioner-led online conference for data protection professionals - no sponsors (or their influence), no sales pitches, just practitioners talking to practitioners. This November (17–19), 15 speakers will share how they actually work: how they build programmes, manage stakeholders, navigate ambiguity, and make the role effective inside real organisations. The speaker line up is confirmed, and the topics are emerging. Registration opens soon. It’s free.

Visit the Field Talk website (tracker free and hosted in the EU): https://fieldtalk.eu

In my self-hosted lab #

I build data protection tools using n8n for workflow automation, local AI models on my own EU-based infrastructure, and live public data from sources like EUR-Lex and the EDPB - practitioner-defined, AI-coded, self-hosted, and fully under my control.

Here’s one simple example, a self-hosted horizon scan of EU data and digital law. Ten regulations tracked across five time horizons, updated daily from official sources.

It’s a tool I built for my own practice, tracking EU regulatory timelines so I’m not caught out by enforcement dates. It runs on my own infrastructure, alongside the other tools and trackers I use to support my work.

I’m curious whether something like this would be useful to you. What are you currently using to keep track? What would actually help? Feel free to mail me — I read everything.

Know a practitioner who’d appreciate this newsletter? Forward it. They can subscribe at purposeandmeans.io/newsletter.