Beyond Legal #38: The data protection leader who understood system design - and changed everything
She was the first Data Protection Leader I’ve met who understood system design. We built something real. — Matteo O., Enterprise Architect
Maturity assessments I’ve conducted over the years revealed data protection programmes often sit on top of the company’s systems rather than inside them. The data protection framework exists. The legal documentation is largely maintained. But the systems themselves - the platforms, the integrations, the data flows between applications - were not designed with data protection requirements in mind. When a Supervisory Authority asks for evidence of data protection by design, what many companies can produce are a policy documents and perhaps a DPIA. What they cannot produce is architecture that demonstrates the policy is living and breathing.
Matteo’s story #
Matteo is an Enterprise Architect at a multinational professional services company operating across 14 EU member states. His work defines how the company’s technology landscape is structured - which systems are used for which purposes, how data flows between them, where personal data resides, how systems are integrated, and what the design principles are that govern future technology decisions.
He had worked with data protection teams before, and the experience had always been the same: they came at the end of a project, reviewed what had been built, flagged concerns that were expensive to remediate at that stage, and then the company moved on. The data protection team’s involvement was a tick in a box, not a contribution.
That changed when he started working with the Data Protection Leader - we’ll call her Yuna.
Yuna had a different starting point. She did not want to review architecture after the fact. She wanted to define data protection requirements at the point at which architectural decisions were being made - when the cost of changing a design was low, not after deployment when it was prohibitive. She understood the difference between a system that stores personal data in one location and a system that fragments it across six microservices with different access controls and retention configurations. She knew that data minimisation as an architectural principle produces different systems than data minimisation as a policy requirement.
Matteo had never met a data protection leader who thought in those terms.
What they built together #
Over 18 months, Matteo and Yuna developed a data protection architecture framework that embedded four requirements into the company’s technology design process: data minimisation by default in system specifications, documented retention configurations as a system requirement rather than a policy overlay, access controls designed to the principle of least privilege from the point of architecture rather than added post-deployment, and a data flow mapping requirement that produced a verified, system-level records of processing activities entry for every new platform or integration.
The framework changed what the DPIA process produced. Instead of a risk assessment conducted in parallel with system design and then filed separately, the DPIA became an input to architectural decisions - the findings drove design choices, and the design choices were documented as evidence that the findings had been acted on.
When the Supervisory Authority conducted a review of the firm’s data protection programme two years later, the RoPA was verified against the actual system architecture. The DPIA process was evidenced in design documentation. The access controls could be demonstrated, not just described. The review concluded without findings.
Both Matteo and Yuna were elevated to board level, jointly accountable for technology governance and data protection strategy.
What does data protection by design require from an Enterprise Architect? #
Data Protection by Design under Article 25 of the GDPR requires that technical and organisational measures appropriate to the data protection principles are integrated into the processing system at the time of designing it. For an Enterprise Architect, this means that the data protection requirements - minimisation, purpose limitation, storage limitation, integrity, confidentiality, access control, etc., - are system requirements, not compliance overlays. They are specified before development begins, verified in architecture review, and evidenced in the system’s design documentation.
Two enforcement decisions show what happens when this does not occur. In June 2024, Italy’s Garante fined Eni Plenitude €6.4 million after finding that the energy company’s processing of personal data for commercial and contractual purposes had been implemented without the technical and organisational measures required by Article 25 to guarantee data protection from the design stage. The investigation identified violations of Articles 5, 24, 25, and 28 - finding that the company had implemented processing systems that lacked the accuracy and accountability controls that the GDPR requires to be built in from the point of design, and that the absence of those controls had produced real harm to data subjects in the form of unlawful telemarketing and incorrect contract activations. The Garante’s finding was explicit: the obligation under Article 25 is not to retrofit protection onto a working system. It is to ensure protection is embedded when the system is designed.
In January 2025, the Finnish Data Protection Authority fined Sambla Group €950,000 for serious data security issues in its loan comparison services - finding violations of Article 25 (data protection by design), Article 32 (security of processing), and Article 35 (failure to conduct a required DPIA). The authority found that loan application data had been accessible to third parties through insecure URL links, in systems that had been built without the technical measures that Article 25 requires from the point of design. Both cases describe the same architectural failure: systems built for functionality, with data protection added as a consideration afterward - or not at all.
Why does an Enterprise Architect matter to a data protection programme? #
The architecture of a company’s technology systems is the physical manifestation of its data protection programme. Policies describe what the company intends to do with personal data. Systems determine what the company actually does. A Data Protection Leader who can only influence the policies - but not the architecture - is working on the description of compliance, not its substance. An Enterprise Architect who understands what data protection by design requires is the person who can make the programme come alive in the trenches: embedding data minimisation into system specifications, designing access controls that reflect the principle of least privilege, building retention configurations that actually implement the documented retention periods, and creating data flows that can be mapped and verified rather than inferred. The accountability principle under Article 5(2) requires controllers to demonstrate compliance. Demonstration requires evidence. Evidence lives in the architecture.
The challenge for today: Take one processing activity from your RoPA - ideally one involving a platform that was deployed in the last three years - and trace the documented retention period back to the system’s actual configuration. Ask: does the system enforce that retention period automatically, or does it require a manual process that may or may not have happened? If the answer requires investigation, you have found the gap between your policy and your architecture.
For more on how technical architecture shapes the compliance position, see Beyond Legal #22 on mapping data flows, and Beyond Legal #30 on the gap between documented and actual infrastructure.
Article references: Article 5(1) (data protection principles), Article 5(2) (accountability), Article 25 (data protection by design and by default), Article 30 (records of processing activities), Article 32 (security of processing), Article 35 (data protection impact assessment), Article 83(4) (fines for Article 25 violations).
Series: This is post 18 in the Beyond Legal series - 20 roles, 20 days, real consequences. Matteo, Yuna and the story are fictitious - the Italian and Finnish enforcement actions are real.
Purpose and Means is a niche data protection and GRC consultancy based in Copenhagen but operating globally. We work with global corporations providing services with flexibility and a slightly different approach to the larger consultancies. We have the agility to adjust and change as your plans change. Take a look at some of our client cases to get a sense of what we do.
