Data Protection by Design: What It Actually Means When You Ship

The meeting where I realised we were doing it wrong

We were three sprints into a new feature for a digital public service platform. The sprint review was going well — the UX looked clean, the API was fast, and the stakeholders were nodding. Then someone asked: where exactly is this personal data going, and for how long?

Silence. Not because nobody cared, but because everyone had assumed someone else had decided. The data protection officer thought the product team had scoped it. The product team thought the architects had built it in. The architects were waiting for a policy decision that had never been formally made.

That moment is more common than any team likes to admit. And it is precisely what Article 25 of the GDPR was written to prevent. Data protection by design is not a compliance checkbox you fill in at the end. It is a sequence of real decisions that have to land somewhere in your process — or they quietly disappear.

What Article 25 actually requires

The regulation says controllers must implement appropriate technical and organisational measures designed to implement data protection principles effectively and to integrate the necessary safeguards into the processing. It also requires that, by default, only personal data necessary for each specific purpose is processed.

Two obligations, then: design data protection in, and make privacy the default rather than an opt-in.

In practice this translates into a set of concrete questions your team needs to answer before a feature ships, not after:

• What personal data does this feature collect, infer, or derive? Inferred and derived data is often overlooked. A feature that never asks for a user's location can still infer it from their behaviour.
• What is the legal basis for each processing activity? Consent, legitimate interest, legal obligation — each has different implications for how you store, delete, and expose data.
• What is the retention period, and is it enforced in code? A retention policy that lives only in a document is not a retention policy.
• Who can access this data, and under what conditions? Role-based access is not enough if it is not reviewed as the product evolves.
• What happens when a user exercises their rights? Deletion, portability, rectification — these need to work end to end, not just in the UI.

None of these questions are exotic. What makes them hard is that they require decisions, and decisions require someone with the authority to make them to actually show up in the room.

Where teams get stuck in practice

The most common failure mode is not ignorance of the rules. It is a gap between the people who understand the legal requirements and the people who write the tickets.

In larger organisations — and especially in public sector digital programmes — the DPO is often consulted at the start of a project (for the Data Protection Impact Assessment) and then again at the end (to sign off before launch). Everything that happens in between is left to the delivery team, which may or may not have the context to make good privacy decisions on the fly.

This creates a specific problem with LLM-based features, which I have been dealing with directly while building CVChatly. When you introduce an AI component that processes CV data — which is sensitive personal data almost by definition — the surface area for privacy decisions explodes. Does the model log prompts? Are those logs retained? If a user asks the system to delete their data, does that cascade to the vector store, the prompt cache, the fine-tuning dataset? Each of those is a separate engineering decision that has to be made deliberately.

The answer is not to slow down. The answer is to build a lightweight privacy decision record into your definition of done. Before a story closes, someone has to confirm: what personal data does this touch, what is the legal basis, and is the retention enforced. It adds perhaps fifteen minutes to a review. It saves weeks of rework and, in a public sector context, the kind of supervisory authority attention nobody wants.

Data minimisation as a design constraint, not a legal burden

The second obligation — privacy by default — is the one teams tend to find more useful once they reframe it as a design constraint rather than a restriction.

Data minimisation means collecting the least data necessary for the purpose. In product terms, that is actually a forcing function for clarity. If you cannot articulate why you need a specific field, you probably do not need it. If you cannot define a retention period, you have not finished defining the feature.

I have found that applying minimisation early tends to simplify architecture. Fewer data types to store means fewer tables, fewer access control rules, fewer edge cases in deletion flows. In the context of AI features, it also means smaller context windows, lower token costs, and less risk of the model surfacing data it should not. The privacy argument and the engineering argument point in the same direction.

For public sector teams specifically, there is an additional layer: the European Interoperability Framework and, increasingly, the Data Governance Act push for purpose limitation and reuse controls that map almost exactly onto GDPR's data minimisation principle. Designing for one makes compliance with the other significantly easier.

Making it stick in a delivery team

Process matters, but process without ownership does not work. Someone on the product or engineering side needs to be the person who asks the privacy questions in every sprint, not just at the DPIA stage. In small teams that is often the product manager or the tech lead. In larger programmes it might be a dedicated privacy engineer or a security champion with an extended brief.

The artefacts that help most are simple ones:

• A data inventory that is maintained alongside the codebase, not in a separate document nobody reads.
• A standard set of acceptance criteria for any story that introduces new personal data processing.
• A deletion test — literally a test that verifies the full deletion flow works end to end — treated as a first-class feature, not a backlog item that gets deprioritised every sprint.

In my own work, I have started treating the deletion flow as a release blocker in the same way I treat authentication. If you cannot reliably delete a user's data on request, the feature is not done. That framing tends to focus minds in a way that compliance language alone does not.

The practical takeaway

Data protection by design is not about being more bureaucratic. It is about making decisions at the right time, by the right people, and recording them somewhere the team can find. The projects that get this right are not the ones with the longest DPIAs. They are the ones where privacy questions are answered in sprint planning rather than in incident retrospectives.

If you are building digital public services — or AI features that touch personal data — start with one question: is there a human being in every sprint review who has the authority and the context to answer what personal data does this feature touch, and have we handled it correctly? If the answer is no, that is the first thing to fix.