Beyond Legal #28: The business analyst who mapped what no one else could see
I mapped the processing activities. She mapped the risk. Together, we actually fixed it. — Lena H., Business Analyst
The record of processing activities (RoPA) is one of the most consistently neglected repositories in data protection practice. Most companies have one. Most of those records are incomplete, out of date, or built from self-reported information that nobody has ever verified against what the systems actually do. The gap between what a company thinks it processes and what it actually processes is where the Supervisory Authority tends to find what it is looking for.
Lena’s story #
Lena is a Business Analyst at a European healthcare services company with operations across four member states. Her work sits at the intersection of process design and systems analysis — she maps how data moves through the organisation, identifies inefficiencies, and documents requirements for system changes. She is methodical, precise, and comfortable working with technical and operational stakeholders in ways that many compliance professionals are not.
She had no formal data protection training when the Data Protection Leader — let’s call her Mira — approached her about a specific problem. The company’s RoPA had been built two years earlier from departmental surveys. Nobody had verified the information against the actual systems. Mira suspected the records were materially incomplete but lacked the technical access and analytical tools to find out how incomplete.
Lena had both. She agreed to help.
Over three months, Lena conducted a systematic mapping exercise — tracing data flows through the company’s core systems, identifying where personal data was collected, stored, shared, and retained. She used the same process she would apply to any business analysis task: source documentation, system interrogation, process observation, and structured output.
What she found was not a minor gap.
What the mapping revealed #
The RoPA had captured approximately 60% of the company’s actual processing activities. The missing 40% included several processing activities that carried significant compliance risk: a legacy system retaining patient-adjacent data beyond the documented retention period, an integration with a third-party analytics platform that had not been registered as a processor, a cross-border data flow to a group entity in a country without an adequacy decision and without standard contractual clauses, and a staff scheduling system that was processing health-related absence data without a documented lawful basis or Article 9 exemption.
Mira had not known any of this existed. She could not have known — the RoPA had never been verified against the systems it was supposed to describe.
Lena’s mapping gave Mira the visibility to remediate. The third-party analytics platform was brought under an Article 28 agreement. The cross-border flow was suspended pending a transfer impact assessment. The legacy retention issue was resolved. The absence data processing was assessed and documented under the appropriate Article 9 exemption.
Both were fast-tracked in the next performance cycle. Mira cited Lena’s contribution directly in her board report.
What does Article 30 actually require from a company’s records of processing activities? #
Under Article 30 of the GDPR, controllers must maintain records of processing activities that cover, for each processing activity: the name and contact details of the controller (and, where applicable, the joint controller, the controller’s representative, and the DPO), the purposes of the processing, a description of the categories of data subjects and personal data, the categories of recipients, details of any transfers to third countries, envisaged retention periods, and a general description of technical and organisational security measures. The records must be stored and made available to the Supervisory Authority on request. Critically, Article 30 does not use the word ‘accurate’ — but the obligation to maintain records that genuinely describe the listed elements, combined with the accountability principle under Article 5(2), means that records which do not reflect the company’s actual processing activities are not evidence of compliance. They are evidence of a governance process that never connected to operational reality.
Two enforcement decisions show what regulators find when they look behind a company’s disclosures. In October 2024, the Irish Data Protection Commission fined LinkedIn €310 million after an investigation found that LinkedIn lacked a valid lawful basis under Article 6 for behavioural analysis and targeted advertising, and breached the transparency obligations under Articles 13 and 14 — the company’s disclosures to users did not reflect the actual scope of its processing. In September 2021, the Irish DPC fined WhatsApp €225 million — following a binding EDPB decision under Article 65 that significantly increased the DPC’s original draft fine — for transparency failures under Articles 12, 13 and 14 that were rooted in the same underlying problem: the gap between what the company said it was doing with personal data and what it was actually doing. In both cases, the fine was not primarily about a single unlawful act — it was about the accumulated failure to maintain accurate, complete documentation of processing activities and to give data subjects information that reflected operational reality.
Lena’s mapping prevented exactly that gap from persisting.
Why does a Business Analyst matter to a data protection programme? #
A Business Analyst brings three capabilities that many data protection functions lack: access to operational systems, credibility with technical stakeholders, and a methodology for turning complex processes into structured, verifiable documentation. The RoPA is, at its core, a business analysis problem — it requires someone who can trace how data actually moves through a company, not just how the company says it moves. A Data Protection Leader working without this capability is building compliance on top of an unverified foundation. That foundation is precisely what a Supervisory Authority examines first.
The challenge for today: Take three processing activities from your RoPA and verify them against the actual systems — check the retention periods against what the system is configured to retain, check the processor entries against your contract register, check the lawful basis against what the system actually collects. If any of the three do not match, your records are incomplete.
For more on how data flows and system architecture connect to compliance accountability, see Beyond Legal #22, and Beyond Legal #24 on what unverified processor relationships look like in practice.
Article references: Article 5(2) (accountability), Article 6 (lawful basis), Article 9 (special categories), Article 13 (transparency), Article 28 (processor obligations), Article 30 (records of processing activities), Article 44–46 (international transfers).
Series: This is post 28 in the Beyond Legal series — 20 roles, 20 days, real consequences. Mira, Lena and the story are fictitious; the two cases are real.
