Erasure

Data mapping

Data mapping for privacy operations

You can't delete what you can't find. A data map is the inventory of where personal data lives—the systems, the tables, the identifier columns, and what you plan to delete versus leave alone.

What a data map contains

Four things, per system:

  • The systems that hold personal data—databases, APIs, anything you connect.
  • The entities or tables within them that store subject data.
  • How a subject is identified—email, phone, external id—and which columns hold it.
  • A decision per table: delete, skip, or keep. Decided on purpose, not in a panic.

Schema discovery vs hand-writing

Writing the map by hand is slow and goes stale. A better path: connect to the database, scan the schema, and get a draft map of tables and candidate personal-data fields. A human confirms and corrects; the machine does the exhaustive part. That is what makes the map actually complete.

Why the map is the bottleneck

Without a map, every deletion request turns into archaeology—asking around, grepping code, guessing. With a map, a request becomes a scoped, predictable job. The map is also what makes a DPIA honest: you can only assess data flows you have actually inventoried.

A map that survives

Maps go stale as schemas change. Re-run discovery, flag drift, and re-confirm before trusting a map for production deletion. Treat the map as living infrastructure, not a one-time spreadsheet.

What this does not solve

Maps cover the systems you connect and configure—Erasure does not automatically discover every SaaS tool holding your data. Deletion only reaches connected systems, so the map is only as complete as your setup.

← All solutions

Invite-only beta

Try it on your own stack

Erasure is invite-only in beta. Request an invite and we will walk you through the parts that matter for your product.

See other solutions