Data inventory / data map
The living map of what personal data you hold, where it enters and lives, why it exists, who receives it, and how it gets deleted.
What it is
A data inventory says what personal data you have and where it lives. A data map adds motion: where each item enters, which services transform it, which vendors receive it, where copies land, and how it leaves. The useful record ties every field or category to a purpose, owner, system, recipient, lawful basis, retention rule, and deletion path.
Reach for it before writing a ROPA, privacy policy, retention schedule, DPIA, or deletion workflow. Start from code, schemas, event calls, network traffic, and vendor contracts, not from the architecture diagram sales uses. That is how the forgotten copies in logs, warehouses, support tools, and CSV exports become visible.
Gotcha: the map rots as soon as nobody owns updates. Connect changes to the release and vendor-onboarding process, and record confidence plus a last-verified date. Backups and subprocessors still count even when deletion is delayed, and a free-text field can collect sensitive data that its innocent column name never mentions.
Ask AI for it
Build a personal-data inventory and flow map for this codebase. Inspect PostgreSQL information_schema, API request and response types, Segment analytics.track calls, Sentry SDK configuration, Stripe Customer objects, log statements, object storage, exports, and backup jobs. For each data element record its source, purpose, owner, lawful basis, classification, systems of record, replicas, recipients and subprocessors, transfer countries, retention rule, and deletion path. Draw the flows as Mermaid, produce a matching table with confidence and last-verified columns, and flag orphaned data, undocumented vendors, free-text fields, and copies that deletion jobs cannot reach.