GDPR has been enforceable since May 2018. That is eight years. And yet it still shows up the same way in too many projects: as a checklist item, somewhere near the end, after the architecture is set, the pipelines are running, and the data is already flowing where it was never supposed to go.
By that point, fixing it is expensive. Not just in time — in rework, delayed go-live, and conversations nobody wants to have with legal, or worse, with a supervisory authority.
The pattern
The problem is not that organisations ignore GDPR. Most take it seriously, at least in principle. The problem is timing and ownership.
Compliance gets handed to a lawyer or a DPO after the platform is built. They come in, ask the right questions, and the answers are uncomfortable: personal data sitting in a storage account with no retention policy, access controls that were meant to be temporary and became permanent, logs kept indefinitely because nobody decided otherwise, data flowing through a third-party tool hosted outside the EU because it was the fastest integration at the time.
Every one of those is a rework conversation. Some are a procurement conversation — the tool that was already integrated needs to be replaced. A few are a legal conversation.
None of them needed to happen. The questions that surfaced them are not hard questions. They just were not asked at the right moment.
What by design actually means
Privacy by design is not a methodology or a framework you layer on top of your architecture. It is a sequencing decision. You ask the compliance questions before anything else is decided.
Where will this data live, and does that satisfy our obligations on residency? Who needs access, and what is the minimum they need to function? How long do we keep this, and what triggers deletion? What happens if this system is breached — who needs to know, and in what timeframe?
These are not legal questions. They are architecture inputs. The answers determine which tools you can use, how you structure access, where you store data, and what your logging looks like. If you make those decisions without the answers, you make them wrong — and you find out later, at the worst possible time.
The cost difference
Asking these questions in week one costs a few hours of careful thinking and one conversation with whoever owns compliance in the organisation.
Asking them in week twelve, after the build, costs a partial redesign. Sometimes a full one. It costs the delay to go-live the business was counting on. It costs the re-procurement of a tool that was the wrong choice from the start.
The late discovery does not make the organisation more compliant. It makes the project more expensive and the team less confident in what they have built.
2026
NIS2 is now in scope for a significant portion of the organisations we work with. The EU AI Act is introducing new obligations around automated decision-making and data governance. The regulatory surface is expanding, not shrinking.
GDPR by design was good practice in 2018. In 2026, building a data platform without it is a risk that is increasingly hard to justify to a board, let alone a supervisory authority.
We treat compliance as an architecture input, not an audit output. That means the first conversation includes the compliance questions — before a tool is chosen, before a pipeline is designed, before anything is committed to. The cost of that conversation is nothing. The cost of skipping it has a number attached, and it is never a small one.
This is not a compliance post. It is a sequencing post. The organisations that get this right are not more legally cautious — they are better at asking questions in the right order.