↓Skip to main content

Beyond Legal #21: The engineer who built exactly what he was asked

·4 mins
Beyond Legal Privacy by Design DPIA Accountability Frameworks GDPR Risk Reduction Records of Processing GDPR at 10

Beyond Legal #21: The engineer who built exactly what he was asked

Data protection by design? She wrote the DPIA. I just built what I was asked. — Sam R., software engineer, 2025

There is a sentence I have heard in various forms in a few companies, and it’s not particularly comfortable on the ears. “I just built what I was asked.” It is not said out of spite because it is often said in a sincere way. And that is the problem.

Sam’s story #

Sam is a mid-level software engineer at a fast-growing SaaS company that operates across the EU. He writes clean code, ships on time, and has a reputation for being low-drama during sprint planning. He does not think much about data protection — not because he doesn’t care, but because the data protection team rarely engaged with him.

The Data Protection Leader — Claire — had been appointed two years ago. Thorough, many privacy certifications, and entirely focused on the legal side of her role. Lawful bases, data subject rights procedures, records of processing activities. She was good at that work. But she had made an invalid assumption that would eventually cost her the job: that data protection by design and by default was something she could briefly mention in a paragraph, and that engineering would handle the rest.

The DPIA that nobody finished reading #

When the product team began building a new behavioural analytics feature, Claire did a DPIA. At first glance, it was well-structured. It identified risks, though they seemed quite generic and high level. It made clear recommendations — pseudonymisation of user identifiers, configurable retention periods, granular consent mechanisms built into the user interface.

It was shared with the engineering team as a PDF attachment in a ticket description.

Sam received the ticket. He read the acceptance criteria at the top. He struggled with the DPIA. He had never been involved in any DPIA process, never received contextual education/training, or what the recommendations meant in terms of what he needed to build. The ticket said: “Build analytics event tracking for the onboarding flow.” So he did.

The feature shipped. It tracked broadly and retained indefinitely. The consent mechanism was a single toggle buried in account settings, defaulted to on. Tens of thousands of data subjects were being processed in a way that did not reflect the intended design.

What the Supervisory Authority found #

A data subject complaint triggered an inquiry. Investigators found a huge gap between what the DPIA recommended and what was actually built — enough to constitute a failure of accountability under GDPR. The company could not demonstrate that data protection had been integrated by design and by default, as required under Article 25.

The case caught the attention of the media, and suddenly the company was getting unwanted attention.

Claire was held accountable, not Sam. Claire — because she had signed off the feature as “compliant” without verifying that her recommendations had been implemented.

She was let go within a couple of months of the inquiry outcome. Sam still works there.

The structural failure #

Obviously, this was not a malicious failure. It was a structural one, and this kind of scenario is one I have encountered on a few occasions.

Claire treated data protection by design as a legal exercise — a document that, once produced, discharged her obligation. She had never translated her DPIA recommendations into engineering acceptance criteria. She had never participated in a sprint review. She had never asked Sam what it would actually take to implement pseudonymisation in their data model.

Article 25 is unambiguous. Data protection by design and by default requires that appropriate technical measures are implemented into the processing itself. The DPIA is the beginning of a conversation that has to happen in the various departments in the places where the product actually gets designed and built. Claire never had those conversations.

If you are a Data Protection Leader reading this #

Could you translate your last DPIA into a set of engineering acceptance criteria? Could you explain to a software engineer why pseudonymisation matters at the data model level? Have you ever sat in a sprint review?

If the answer is no to all three, you are not alone. But you are exposed. And so is your company.

The bridge between legal and engineering is not someone else’s job to build. It is yours.

GDPR turns ten - this is a fictitious story part of a series of blog posts reminding us that data protection is not just an issue for the legal team. See Why the backstory of GDPR matters to read about about some of the key dates and events.

Purpose and Means works with organisations on data protection strategy, governance, education and training — going beyond the legal text to focus on how things actually get done. If you’d like to discuss what this means for your company, book a call or explore our services.

Author
Tim Clements
Tim Clements is Business Owner of Purpose and Means, a data protection and GRC consultancy based in Copenhagen, operating globally. He helps data protection and GRC leaders simplify complexity into actionable strategies, providing tools, training, and support to engage and influence across the organisation. Tim is a Chartered Fellow of the BCS (British Computer Society).

Browse by Topic

access controls accountability accountability frameworks ai act ai ethics ai governance ai infrastructure sovereignty ai literacy ai regulation article 12 article 13 article 22 article 25 article 28 article 30 article 32 article 35 article 46 article 5 article 6 article 7 audit and assessment automated decision-making awareness awareness campaigns behaviour change beyond legal board level board reporting case law change management chief people officer cloud infrastructure compliance monitoring consent cookie compliance cross-border transfers customer success dark patterns data accuracy data breach notification data flows data mapping data minimisation data processing agreements data protection data protection by design data protection culture data protection day data protection hero data protection leader data quality data residency data retention data science data sovereignty data subject rights datatilsynet deceptive design direct marketing dora dpia education employee data employee engagement enterprise architecture eprivacy esg executive communication external legal counsel finance and banking gdpr gdpr at 10 generative ai governance grc healthcare horizon scanning hr and data protection hr and employment incident response information security intellectual property internal communications international transfers lawful basis leadership lego serious play machine learning marketing nis2 privacy by design privacy culture product management profiling public sector purpose limitation quantum computing records of processing regulatory guidance risk management risk reduction ropa sales security software development special category data standard contractual clauses strategic planning sub-processors supply chain sustainability system design third-party risk training design transparency trend radar ux design vendor management visual communication weak signals workshop facilitation

Related Posts