What is Data Mapping?

Almost every privacy duty presupposes that you know where the data is. You cannot answer an access request, execute a deletion, write an accurate privacy notice, complete a RoPA, assess a vendor, or scope a breach without a reliable answer to 'which systems hold this person's data, and where does it go from there?' Data mapping produces that answer: an inventory of systems and vendors, the categories of personal data each holds, the purposes served, and the flows between them.

Traditional mapping ran on interviews and spreadsheets — workshops with each department, a diagram, and a document that was stale before it circulated. Modern practice automates discovery: connecting to the systems themselves via APIs, scanning schemas and object stores for personal-data fields, reading the website's trackers, and watching OAuth grants and integrations to catch flows no one mentioned in a workshop. Automation matters because the map's enemy is drift — every new SaaS tool, integration, or marketing tag changes the truth.

The map feeds the compliance stack directly: RoPA entries are generated from it, DPIAs cite it as the processing description, DSAR fulfillment uses it as the checklist of systems to query, vendor management uses it as the list of processors needing DPAs, and breach response uses it to scope what an attacker could have reached. Regulators increasingly ask for flow documentation in investigations; an organization that can produce a current map is having a very different conversation than one that cannot.

Scope discipline keeps it tractable: map personal data flows at the system-and-category level first — perfection at the field level can come later, and usually only where risk justifies it.