Data Inventory, Mapping & RoPA

A recap of the Pyxos masterclass with Richard Chudzynsky and Aben Pagar.

You do not have a privacy program without a record of what data you hold, which is why this masterclass treated the Record of Processing Activities as the backbone of everything else. Led by Richard Chudzynsky and Aben Pagar of Konexo (Eversheds Sutherland), the session made the case that an organization simply cannot manage, protect, or govern personal data it has never inventoried, and that the RoPA is the artifact a regulator asks for first.

The framing that distinguished the session was that the RoPA is a living system, not a compliance document filed once. Chudzynsky and Pagar pushed back on the instinct to map at a high functional level, arguing that each business process, each distinct recruitment or onboarding stage, should be treated as its own processing activity, because that granularity is what makes the record usable. They also widened the definition of processing in a way that catches people out: it is not limited to active use. Any exposure to personal data, shared access, an email thread, can constitute processing that belongs in the record.

On contents, the session was specific about the floor and the ceiling. A compliant record has to capture, for each activity, the purpose, the categories of data and of data subjects, the systems involved, the recipients, the lawful basis, the retention period, and any cross-border transfer. Mature organizations then go beyond that statutory minimum, adding fields such as risk level, AI usage, data volumes, and hosting location, because those extra columns are what let the RoPA trigger downstream work rather than just describe the present.

The practical centrepiece was how to actually build one. Pagar described the combination that works: a bottom-up approach where you sit with the business functions and document what they do, supported but never replaced by a top-down data-discovery scan that surfaces where personal data physically sits. The scan gives you a starting point to validate against; the bottom-up documentation is what produces a defensible record that meets the law. One without the other is incomplete.

What gives the RoPA its leverage is everything downstream that depends on it. It is the trigger mechanism that surfaces which activities need a DPIA, a legitimate interest assessment, or a transfer assessment; it is the map that makes a DSAR answerable and a breach assessable; and it is where retention schedules and cross-border visibility live. The required contents and the build methodology are best taken from the recording and the takeaways.

The session was honest about cost. Building a RoPA in a large organization can span hundreds of processes and months of effort, and the exercise routinely exposes broader gaps, a missing vendor register, incomplete data governance, that were invisible until someone went looking. That discovery is uncomfortable but valuable, because the gaps were always there; the RoPA simply made them visible.

The closing point was that ownership has to be shared: the business owns its processing activities, IT custodies the systems, and the privacy function provides oversight and methodological consistency, but none of it survives without executive buy-in to keep the record current. A RoPA accurate at build time and never revisited is, within months, a liability rather than an asset.