How do you know what personal data you hold and where it lives, and what makes that map wrong within a month?

The document that was accurate on the day it was signed

Every organisation that has been through a privacy programme has an inventory. It is usually a spreadsheet or a purpose-built register, it was compiled by interviewing engineering leads, it lists systems against categories of personal data, and it was substantially correct on the date it was completed. The interesting question is not how to build that artefact. It is why it is wrong a month later, and what you would build so that it is wrong less.

The reason it decays is that it was produced by a process with no relationship to the process that changes the estate. Data moves because somebody shipped a feature, connected a tool, or exported a file. The inventory changes because somebody remembered to update it. Two clocks, one much faster than the other, and no mechanism forcing them to agree. So the design question becomes how to derive the map from the estate's actual behaviour, and where derivation is impossible, how to make the manual step a consequence of the change rather than an afterthought.

The three ways the map goes stale

Naming the mechanisms specifically is what separates an answer with operational experience behind it from a generic one.

The first is a new sink. A team adds an analytics tool, a support platform, a data warehouse table, an AI provider, a queue consumer that writes to its own store. This is the easiest category to catch, because a new destination usually leaves traces — a new outbound egress, a new credential, a new supplier in procurement — and each of those is a place to hang a trigger.

The second is a new field inside an existing flow, and it is far harder. The pipeline between two systems was inventoried a year ago as carrying account identifiers and order history. Nobody re-inventoried it when a date of birth was added to the event payload for an age-gating feature, because no new system appeared and no new connection was made. The topology is unchanged and the contents are not, which is why schema-level change detection matters more than architecture diagrams.

The third is copies made by people. An analyst exports a cohort to a spreadsheet to answer a question from finance. An engineer pulls a production extract into a local environment to reproduce a bug. A support agent pastes a customer record into a chat message. These are the copies your data map will never contain, and the honest position is that you address them with controls on export and with tooling that makes the sanctioned path easier than the unsanctioned one, rather than by pretending the inventory covers them.

How the map goes wrong	What detects it	Where the control belongs
New destination for existing data	Egress and credential inventory, supplier onboarding	Procurement and network boundary
New field in an existing payload	Schema and contract diffing in CI	The pipeline that ships the change
Free-text field filling with sensitive content	Sampling and classification of content, not just column names	The product team that owns the field
Derived copy in a warehouse or model	Lineage from the ingestion layer	The platform that creates the copy
Human export to spreadsheet or laptop	Export logging and data-loss tooling	Access path, plus the reason the export was needed
Retained backup of a decommissioned system	Asset decommissioning checklist	The team that turned the service off

An inventory that did not know where the component was running

In 2017 Equifax was breached through an Apache Struts vulnerability that had a published patch which had not been applied, and personal data on well over one hundred million people was taken. The failure was not exotic. The patching process did not know where the vulnerable component was running.

It belongs in an answer about data mapping because it is the same defect viewed from the other side. Whether you are asking which systems run an unpatched library or which systems hold personal data, you are asking the estate to enumerate itself, and an organisation that cannot do the first will not manage the second. It also shows why the two inventories are worth joining: the question that matters during an incident is not "do we run this component" or "do we hold personal data" but the intersection — which of the systems holding regulated data are currently exposed. Teams that maintain those registers in separate tools, owned by separate functions, answer that question by hand under time pressure.

What the map has to say, beyond which systems hold what

A register at system granularity supports almost none of the work it is supposed to support. Consider what downstream processes actually ask of it. An erasure request needs to know every location a given subject's data reaches, at enough granularity to know which fields go and which stay. A retention decision needs purpose, because the same field held for two purposes has two clocks. A transfer question needs to know which processors touch it and where they run it. A breach assessment needs the categories involved and the affected population, quickly, in the first hours.

Those requirements imply the unit of the inventory is not the system but the field-and-purpose pair, with the lawful basis, the retention rule, the owning team and the processors attached to it. That is more expensive to maintain, which is exactly why it should be derived from artefacts engineers already maintain — schema definitions, event contracts, infrastructure code, data-lineage metadata — and annotated at the point of definition rather than described afterwards in a separate document. Tagging a column in a migration is a habit a team can keep; updating a register in another tool is not.

Classification's two errors are not symmetrical

Automated discovery is how you cover ground, and it is worth being precise about its limits rather than presenting it as a solution. Pattern matching finds structured identifiers well and finds sensitive content inside free text badly, and free text is where the awkward categories accumulate — health information typed into a support ticket, biometric or political detail mentioned in a complaint, a child's details in a note field nobody designed for it.

The two failure directions have very different costs. A false positive wastes an engineer's afternoon arguing about a column. A false negative leaves a store outside every control that depends on classification, so it is excluded from your erasure tooling, from your retention schedule and from your breach assessment simultaneously. That asymmetry is the argument for tuning towards over-flagging and for a lightweight route by which an owning team can dispute a classification with a recorded decision, which incidentally produces the evidence that the process is being operated rather than ignored.

The map you can prove and the map you assert

The last distinction is the one a compliance reader will press on. There is a version of your inventory you can evidence — derived from schemas, lineage and configuration, regenerated on a schedule, with a timestamp — and a version somebody asserted in an interview a year ago. Presenting the second as the first is the defect this whole exercise exists to remove, because every obligation built on top of it inherits the error. Where regulators require a record of processing activities, the obligation's shape is that you can account for what you process and why; the specific form, the level of detail expected and the review cadence differ between regimes and are questions for your privacy function rather than assumptions to bake into a design. What is not jurisdiction-specific is that an inventory nobody can regenerate is an inventory nobody should rely on.

Do not ask whether you have a data inventory. Ask when it was last regenerated, whether it knows about fields rather than systems, and which of the three staleness routes — new sink, new field, human copy — you currently have no mechanism to catch.