Beyond Legal #22: The data architect who made the invisible visible

Once Ines understood how data actually flows, the whole programme changed. — Maria C., Data Architect, 2025

Some data protection programmes are built on an invalid assumption: that the people running them know where the personal data is. They know where they think it is. Those are not the same thing.

Maria’s story #

Maria is a senior data architect at a mid-sized financial services company. Her job is to understand how data moves — where it originates, how it is transformed, where it lands, and what happens to it along the way. She thinks in pipelines, schemas, and dependencies. She can look at a business process and immediately start asking questions about the data structures underneath it.

The Data Protection Leader — let’s call her Ines — had been running the programme for three years. She was experienced and capable, but her understanding of personal data was mainly based on what appeared in the records of processing activities (RoPA). Lots of rows. Named systems. Declared purposes. All very linear. What the RoPA did not show her was the reality underneath: the API calls between systems, the staging tables that held personal data longer than anyone had intended, the third-party analytics tool that had been integrated eighteen months ago and never added to the register.

Ines knew the RoPA version. Maria knew the actual one.

The conversation that changed things #

It started with a DPIA for a new customer onboarding journey. Ines had drafted it based on the product specification and the system list provided by IT. Maria was brought in late, as architects often are, to review the technical assumptions.

Within thirty minutes, Maria had identified three data flows that were not in the spec. Personal data was passing through an intermediate processing layer that introduced a sub-processor nobody had documented. Retention in one of the downstream systems was indefinite because no deletion logic had ever been built. A field containing health-related data was being written to a reporting database that twelve people across two departments could query without restriction.

None of this was in the DPIA. None of it was in the RoPA. None of it was known to Ines.

That conversation, uncomfortable as it was, became the foundation of something useful. Rather than treating it as a one-off problem to fix, Ines asked Maria if they could work together systematically, and Maria agreed.

What they built together #

Over the following six months, Maria led a structured data flow mapping exercise across the company’s core processing activities. Not a paper exercise, a technical one. She traced actual data movements through source systems, integration layers, and downstream consumers. She documented what was processed, where it moved, how long it was retained, and who could access it.

Ines translated that technical picture into the language of the GDPR: identifying lawful bases, flagging gaps in data subject rights fulfilment, updating the RoPA to reflect reality rather than intention, and prioritising DPIAs for the processing activities that carried the highest risk.

The result was a data protection programme that was grounded in what the company actually did with personal data — not what it thought it did. It was presented to the board. It was used to respond to a Supervisory Authority inquiry with a level of technical detail and accuracy that impressed the investigating officer. It became the foundation for a data protection by design process that Maria presented to the company’s architecture review board.

Ines was promoted to Chief Privacy Officer twelve months later. Maria was appointed Head of Data Architecture in the same round. Both credited the collaboration as the thing that made the difference.

What this means for your programme #

A RoPA built from interviews and system lists is a starting point. It is not a picture of reality. Personal data has a habit of travelling further, staying longer, and being accessed more widely than any processing activity entry in a typical RoPA might suggest.

A data architect sees that reality. They understand the difference between what a system is supposed to do and what it actually does. They can identify where personal data accumulates in ways nobody planned, where deletion is technically impossible because of how the schema was designed, and where a new integration has created a sub-processor relationship that legal has never reviewed.

Remember, under GDPR Art. 5(2), the controller must be able to demonstrate compliance. You cannot demonstrate what you cannot see. And you cannot see what you have never mapped.

If you are a Data Protection Leader reading this #

When did you last sit with a data architect and trace a single personal data record from collection to deletion? Not in a workshop. Not in a process diagram. In the actual systems.

If the answer is never, your RoPA is a best guess. And a best guess is not accountability.

Find your Maria. The programme you build together will be unrecognisable from the one you have now.

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.

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