Data Mapping: Knowing Where Personal Data Lives Before You Need To

A data map is an inventory of where personal data lives: which systems hold it, which tables and fields contain it, what identifiers link a person to their records, and how deletion should act on each. It sounds administrative. It is actually the most load-bearing piece of privacy infrastructure a company can build, because every deletion request, every breach response, and every regulator inquiry starts with the same question: where is the data?

This post explains what a data map is, why it is the prerequisite for the DPDP Act's erasure right, and how to build one that does not rot within a quarter. It is not legal advice; it is engineering guidance.

Why the map is the bottleneck

Watch a startup handle a deletion request without a data map. The request arrives, the founding engineer opens three tabs, and starts remembering: "the user data is in Postgres, profiles in the cache, there's the old analytics export, and did we ever sync to that CRM?" The request takes days, the answer is incomplete, and nobody is sure.

With a data map, the same request is a lookup: the systems are listed, the identifiers are known, the deletion path for each is defined. The difference between days and minutes is not effort; it is having done the inventory work once, in advance, while calm.

What a data map contains

A useful data map has four layers:

1. Systems. Every place personal data lives: databases, caches, search indexes, SaaS tools, object storage, log pipelines.
2. Entities. The shapes of personal data: users, profiles, orders, support tickets, analytics events.
3. Identifiers. What links records to a person: user ID, email, phone, device ID, and the joins between them.
4. Actions. For each entity, how deletion should work: hard delete, anonymize, exclude certain fields, respect retention.

The fourth layer is where most DIY attempts stop. A list of "we have a users table" is a diagram, not a map. The map earns its keep when it says "users.email is the key, delete rows by user_id, anonymize the orders table, exclude audit fields per policy."

Schema discovery vs hand-writing

Building a map by hand is how it starts, and hand-maintained maps rot. Tables get added, fields get repurposed, services get retired, and the map drifts from reality within months.

The better approach is discovery-assisted: connect to the database, scan the schema, and generate a draft map of tables and candidate personal-data fields for a human to confirm. The human confirms and corrects; the machine does the exhaustive part. This is what Erasure's Data Maps does, with a readiness view so you know when the map is good enough to run deletion against.

The DPDP connection

The DPDP Act's erasure right is only operational if you can find the data. Section 12's erasure, and the Rules' framing around fulfilment, assume the fiduciary can locate and act on personal data across its systems. Without a map:

• Deletion requests are slow and incomplete
• Breach scope assessment is guesswork
• Evidence of fulfilment is retrospective and thin

The map is also the foundation for the Significant Data Fiduciary obligations: DPIAs and audits are built on knowing what you process, where, and why.

Building a map that survives

Five rules for a data map that does not rot:

1. Start narrow. Map the systems that actually hold personal data. A hundred-row spreadsheet of everything is worse than a correct map of the five real systems.
2. Confirm, do not assume. Automated discovery proposes; a human confirms field sensitivity. "Probably an email" is not a mapping decision.
3. Tie identifiers together. The joins matter: which key resolves a person across systems.
4. Define deletion actions per entity. The map is not finished until every entity has a documented action.
5. Refresh on a schedule. Re-scan the schema when the codebase changes. A stale map is a trap with extra steps.

The map and the deletion workflow

A data map is one half of a deletion system; execution is the other. When a verified request arrives, the map tells you the systems and actions; the execution layer runs the deletion jobs and records outcomes. Erasure pairs Data Maps with Systems and durable jobs: the map drives the plan, the worker executes it across Postgres, MySQL, HTTP, and Webhook, and the case records what actually happened.

The deletion workflow guide walks through the full loop, and the right to erasure post covers the legal framing.

The bottom line

A data map is not a compliance artefact to file away; it is operational infrastructure that makes every privacy duty cheaper and more honest. Build it before you need it, because the first deletion request will not wait while you remember where the data lives.

Erasure is built around this loop: Data Maps for inventory, Systems for execution, Evidence for the record. It is invite-only in beta; request access or start with the data maps docs.