Core Concepts
Data Maps
Where subject data lives, identifier bindings, DELETE vs SKIP, discovery and readiness.
Data Maps
What it is
A Data Map is the operator-defined inventory for a System: entities (tables/collections), identifier bindings (email, external id, phone, …), and actions (DELETE or SKIP; anonymize may be reserved).
Why it exists
You cannot delete what you cannot find. Map-backed Systems (Postgres, MySQL, MongoDB, …) do not guess resources. Without a map, start readiness fails for those systems.
Structure
System
└── Data Map
└── Entities (e.g. users, sessions)
├── Identifier mappings → columns / fields
├── Action: DELETE | SKIP
└── Discovery snapshot + suggestions (where supported)| Concept | Meaning |
|---|---|
| Entity | A resource unit (table/collection) + match fields + action |
| Discovery | Enumerate schema (SQL/document modules) |
| Suggestion | Heuristic mapping with confidence (confirm-gated in product) |
| Graph | Relationship view derived from maps + discovery, not a full enterprise ERD |
| Execution preview / dry-run | Match counts without deleting (SQL) |
How Rights uses maps
- Operator configures System + Data Map.
- Start readiness checks DELETE entities and identifiers.
- Worker executes parameterized deletes (SQL) or module handlers using map plans.
- Timeline and Evidence reflect per-system results.
HTTP/Webhook Systems notify or call APIs from connector config; SQL still depends on maps.
What Data Maps are not
- Not automatic discovery of every SaaS without configuration
- Not a legal Record of Processing Activities (RoPA) product
- Not a guarantee that unmapped tables were erased
Related
For the operational context around mapping, see Data mapping: knowing where personal data lives and the data mapping hub.