Purpose & Means Newsletter - Issue 4, October 2026

Data Protection Day is 28 January. October is often a busy month for me because clients start thinking about it now - what they want to do, whether it is worth doing, and how to make it land with people who do not spend their days thinking about data protection. That is the right instinct. Leave it to January and you are already too late. I wrote about it this week on the site - making it worth attending requires imagination, and the generic GDPR materials that get pulled out every year are not it. If you want to talk through ideas, get in touch.

Data Protection Hero #

The organisation’s risk appetite, illustrated.

The DPIA everyone writes and no one uses #

Part 4 of a short series. Just joining us? Part 1, Part 2 and Part 3 are here.

The first three parts of this series diagnosed the problem. DPIAs are written to satisfy a process, not to understand a risk. They treat data subjects as categories rather than people. They assess tools instead of processing activities. They skip the people the assessment is supposed to protect. They produce heat maps that cannot be compared, calibrated, or used to make a decision.

This part is about what to do instead.

I want to propose a different way of structuring a DPIA - not a new template, but a different sequence of thinking. Four layers, each with a distinct job, each building on the one before.

Before you open the form #

There is a prior question that almost no DPIA asks, and it is the most important one: what level of risk to the rights and freedoms of individuals is this organisation willing to accept - and how has that been decided?

Most DPIAs arrive at a risk conclusion at the end. Someone looks at the residual risk entries, makes a judgement about whether they are acceptable, and signs off. But that judgement - what counts as acceptable - was never defined in advance. It was invented in the room, often by the most senior person present, often to close the meeting.

That is not risk management. It is retrospective tolerance. And it is indefensible - to a regulator, to a board, and to the people whose rights are at stake.

A few years ago I was delivering CIPM training at the IAPP’s European Data Protection Congress in Brussels. There were around a hundred people in the room, and among them a handful of engineers from Google. We got into a substantial discussion about risk appetite - specifically about what it means to accept that a risk might materialise at a very low probability when you are processing data at the scale Google operates. If you accept a 0.01% likelihood that something could go wrong for an individual, that sounds like a negligible residual risk. At Google’s scale, it is potentially hundreds of thousands of people. The processing context and the volumes involved change everything.

Volume is one dimension. The category of data subjects is another. A processing activity that poses a low risk to the majority of people in scope may pose a significantly higher risk to specific groups within that same population - the elderly, people whose first language is not the dominant language of the service, people in precarious employment, people with particular health conditions. Reducing risk to an acceptable level means reducing it to an acceptable level for those groups, not for the average user. If the residual risk for the most vulnerable categories of data subjects remains high, the overall assessment cannot honestly conclude otherwise.

That conversation in Brussels points to something important about how risk appetite needs to work in this space - and how it currently does not.

Most organisations have a risk policy at board or executive level. Those policies are built around financial risk, operational risk, reputational risk. They deal in probabilities of business impact. But risk to the rights and freedoms of individuals is a categorically different type of risk. It does not accrue to the organisation in the first instance. It accrues to the person, to groups of people, or at a broader level to society - which is, of course, made up of people. The organisation may face secondary consequences - regulatory action, reputational damage, legal liability - but the primary risk lands elsewhere. On people who had no say in the processing decision and who bear the consequences whether or not the organisation ever does.

A standard risk policy cannot simply be extended to cover this without explicitly acknowledging that difference and providing meaningful guidance on how to work with it. In the absence of that acknowledgement, the policy is not useful for this purpose.

What is needed is a risk appetite discussion at the level of the data protection function - a contextual assessment, per processing activity, that takes account of the volumes involved, the categories of data subjects affected, the specific harms at stake, and the particular vulnerabilities of the people in scope. Where a DPO exists, this is precisely the kind of strategic advice the role is positioned to provide under Article 39. It is not a board-level number applied uniformly. It is a considered judgement, grounded in the specifics of the activity being assessed.

There is, it should be said, very little guidance on how to do this well. The regulatory framework - the EDPB, the ICO, the original WP29 guidelines - tells organisations what to assess: risks to the rights and freedoms of natural persons. It says almost nothing about how to calibrate what level of residual risk is acceptable before the assessment begins. That is a significant gap. It leaves every DPIA conclusion floating, anchored to nothing declared in advance. Closing that gap is, in my view, one of the more important undone pieces of work in data protection practice.

Layer 1 - Empathise and frame #

If Part 3 asked who is affected by the processing - who the DPIA forgot - Layer 1 is where you do that work in practice.

Before the legal framework. Before the template. Before the risk table.

Map who is actually affected by this processing. Not the category - the range. Within employees: who has the least power? Who has the most to lose from an error? Who has circumstances that make standard assumptions invalid? Within customers: who is most dependent on this service? Who would be most harmed by a breach? Who is least able to seek redress?

Then run a pre-mortem. Eighteen months from now, this processing has caused serious harm. What happened? To whom? Who did not get to raise a concern? Who was not in the room when the decision was made?

This is not a soft exercise. It is the step that determines whether the rest of the DPIA is calibrated to the real risk population or to an imagined median person who, in most processing contexts, is not the one who needed protecting most.

Layer 2 - Legal necessity and proportionality #

This is where Article 35(7) lives, and it has a clear job: document that what you are doing is lawful, necessary, and proportionate. Identify the processing activity - not the tool, the activity. Establish the lawful basis. Assess necessity and proportionality honestly.

It is worth naming a pattern here. In many DPIAs I have reviewed - particularly those drafted primarily by lawyers - this is by far the largest section. Pages of legal citation, article-by-article recitation of the GDPR, detailed analysis of lawful bases. That work is not without value. But when it dominates the document, it signals that the DPIA has been written to demonstrate legal competence rather than to understand risk. The regulation has been treated as the subject of the assessment rather than the framework within which it operates.

Layer 2 has a job. Do it well, then move on. The analysis that actually matters to the people the DPIA is supposed to protect happens in the next layer.

Layer 3 - Rights and freedoms #

This is the layer that conventional DPIAs either collapse into a risk table or skip entirely. It is also the layer that the law actually requires.

Article 35 does not ask for an assessment of risks to data. It asks for an assessment of risks to the rights and freedoms of natural persons. In a European context, that means the Charter of Fundamental Rights of the European Union - all six titles, fifty-four articles, covering dignity, freedoms, equality, solidarity, citizens’ rights, and justice.

Most DPIAs gesture at this and move on. A few will note that the processing involves personal data and therefore implicates Article 8 of the Charter - the right to the protection of personal data. That is true, but it is also the least interesting observation you can make. Article 8 is the obvious one. The Charter is not only Article 8.

Consider what the processing actually puts at risk:

Freedom of expression and information (Article 11). When people know they are being monitored - their communications, their browsing, their movements - they change their behaviour. They self-censor. They avoid certain searches, certain contacts, certain expressions of opinion. This chilling effect is a concrete harm to a fundamental right, and it does not require the data to be misused for the harm to occur. The surveillance itself is the harm.

The right to non-discrimination (Article 21). Algorithmic systems trained on historical data reproduce historical patterns - including historical patterns of discrimination. A credit scoring system, a recruitment tool, a fraud detection algorithm: each can produce discriminatory outcomes without any discriminatory intent on the part of the controller. If your DPIA does not ask who is systematically disadvantaged by this processing, it has not assessed the risk to this right.

Human dignity (Article 1). Processing that reduces a person to a risk score, a category, a predicted behaviour - without recourse, without transparency, without any mechanism for the person to contest the output - raises a question that Article 1 demands we take seriously. Is this processing treating individuals as ends in themselves, or as data points in someone else’s decision-making process?

Freedom of movement (Article 45). Location data, travel records, mobility patterns: processing that creates a detailed picture of where people go and when has implications that extend far beyond the obvious data protection concern. In the wrong hands, or in a changed political environment, it can constrain where people feel safe to go. That is not a hypothetical. It has happened. A DPIA for a processing activity involving significant location data should ask whether this risk has been considered - not just the breach risk, but the use risk.

These four are not exhaustive. They are illustrations of a point: the Charter was not attached to the GDPR as a formality. It was attached because the processing of personal data at scale puts a wide range of fundamental rights at risk, and the DPIA is the instrument that is supposed to surface which ones.

I have mapped examples of data processing risks across all six Charter titles in a reference document you can download and use alongside your next DPIA. It is not a checklist - it is a prompt, a way of ensuring that the rights assessment in Layer 3 is not limited to the obvious ones.

Download: The EU Charter and Data Processing Risk - a practitioner reference

Layer 4 - Iterate and monitor #

A DPIA is not a document you sign off and file. Processing changes. Systems evolve. The risk picture shifts - sometimes because the technology changes, sometimes because the regulatory environment does, sometimes because something goes wrong.

The WP29 guidance already says this: a DPIA should be treated as a living document, subject to review when there is a change in the processing or when the risk level changes. In practice, this instruction is almost universally ignored. The DPIA gets completed, signed off, and filed. It is retrieved when a regulator asks for it.

This layer is about building in a review cadence. Not a vague commitment to “review annually” - a specific schedule tied to specific triggers: a change in the processing activity, a new technology introduced, a near-miss or incident, a material change in the regulatory environment. The DPIA should be as current as the processing it describes.

The collaborative point #

One more thing that sits underneath all four layers, and without which the structure does not work.

“DPIA tools and questionnaires are repositories for DPIAs. They are not an end-to-end DPIA process.”

A lone data protection practitioner filling in a form is not a DPIA. It is a compliance document produced by one person using their best judgement, without access to the full picture of what the processing actually does, who it actually affects, and what could actually go wrong.

A DPIA requires the people who understand the processing - the engineers, the business owners, the product team, the legal function, the security team - to be in the room. It requires a facilitator who can hold the question open long enough for the analysis to be genuine. And it requires, at Layer 1, someone asking the question that is hardest to answer: who is not in this room who should be?

In Part 5: seeing the risk clearly - why the heat map is the wrong tool, and what an honest visualisation of DPIA risk would actually show.

Field Talk - registration is open #

Field Talk is a free, practitioner-led online conference for data protection professionals - no sponsors, no sales pitches, just practitioners talking to practitioners. This November (17-19), 15 speakers across three days will share how they actually work: how they build programmes, manage stakeholders, navigate ambiguity, and make the role effective inside real organisations.

Registration is free. You can register for individual sessions, whole days, or the entire conference - whatever fits your schedule. Each session comes with an ICS file you can add directly to your calendar, with the session link already included.

Register at fieldtalk.eu →

This issue’s featured speakers:

Katrin Vernik is a Privacy, Data and AI Governance Manager focused on automating privacy at scale through effective data management practices. She specialises in translating regulatory requirements into actionable workflows and embedding privacy as a guiding principle within existing systems - not a bolt-on afterthought. Her work sits at the intersection of privacy and data management, with a conviction that one cannot function effectively without the other.

Shane Patrick McNamee is a legal and policy professional focused on regulatory approaches to data protection, consumer protection, and digital rights - currently working as Legal Counsel at the Appeals Centre Europe. He holds professional qualifications in law (LLB, LLM, BL) and privacy management (CIPP/E, CIPM). His work focuses on how emerging technology trends interact with existing legal structures, and how to communicate complex regulatory issues in plain terms.

What caught my eye #

Automatic Transmission: An Empirical Study of Data Privacy in the Connected Vehicle Ecosystem - Northeastern University researchers tested 21 vehicles from 14 manufacturers. 19 of them sent data to third parties without the driver doing anything. One manufacturer switched from cellular to Wi-Fi when the cellular connection was blocked - apparently to find a different route around the same controls. If you work in automotive, fleet management, or any sector where connected vehicles are part of the picture, this is required reading.

The year of internal tools - geocod.io, 23 September. A practical account of what happens when a small team builds internal tooling with AI assistance - and what that means for data governance. Every AI-generated internal tool is a potential DPIA trigger. Most organisations have not thought about that yet.

Spymarks, not Watermarks - brand.io. Invisible markers embedded in images - not to protect copyright, but to track who viewed them, when, and where. The surveillance capability is real; the consent and disclosure picture is not. This is metadata that bypasses the controls most people think are protecting them.

AI Transparency Starts With the Audience - Tech Policy Press, 29 September. A useful corrective to the idea that publishing a model card or a system card constitutes meaningful transparency. Transparency for whom, in what form, at what point in the process - these are not details. They are the substance.

Europe’s Digital Sovereignty Has a Funding Gap - Tech Policy Press, 24 September. “When confronted with threats to its sovereignty, Europe found the money for glitzy AI gigafactories. It now also needs to find the money for its Democracy Stack that keeps its digital rules accountable to citizens.” The infrastructure argument, made well.

Hire me #

I work with organisations and practitioners on a project basis - consultancy, training design, and workshop facilitation. No long-term lock-in. If you want to talk through a project, a DPIA process, or a Data Protection Day plan, drop me a line or book time directly.

← All issues / Subscribe