A personal data map is a living list of every place personal data is stored or sent, with the data class, purpose, owner and recipients for each. Developers can build the first version in a few days by reading database schemas, API specs and outbound integrations, then keep it current through pull request checks.
Start with stores, not with a questionnaire
Asking every team "what personal data do you hold?" gets vague answers. Start from the systems instead. List every database, object store, search index, cache, queue and log sink. For each one, export the schema or a sample of keys.
Then mark each column or field with a data class. A short scale is enough: direct identifier (name, email, phone), indirect identifier (device ID, IP address, account ID), sensitive category (health, biometrics, political opinion), and not personal. GDPR defines personal data as information relating to an identified or identifiable person, which includes identifiers a name alone would not cover, so the indirect class matters.
Follow the flows
A store list is half a map. The other half is movement. Look for:
- Outbound HTTP clients and SDKs that send user fields to another company.
- Message topics and event streams that carry user objects.
- Exports, nightly jobs and data warehouse syncs.
- Backups and replicas, including where they sit geographically.
- Support tools, email senders and analytics libraries.
Your dependency manifests are a fast shortcut here. Every analytics, payments, error reporting and messaging package is a likely recipient of personal data. Read each one's configuration to see which fields it receives.
Record the minimum useful attributes
For each entry, capture:
- System and field names.
- Data class and the people affected (customers, employees, prospects).
- Purpose, in a sentence a lawyer would accept.
- Lawful basis, as decided by whoever owns that call.
- Recipients and transfer destinations.
- Retention period, or a note that none is set yet.
- An owner by role, not by person.
These line up with what Article 30 asks for in a record of processing, so the map becomes the raw material for that record rather than a second document to maintain.
Keep it current
A map done once decays within a quarter. Two habits keep it alive:
- Make schema changes carry a privacy tag. A migration that adds a column without a data class fails review.
- Re-run the inventory when a new outbound integration is added, since a new vendor changes who receives data.
Store the map next to the code, in a YAML or CSV file reviewed like any other change. People will update what they can diff.
What you will find
Expect surprises: email addresses in free text fields, user IDs in URL paths that land in logs, full request bodies in error reports, and forgotten tables from a pilot. Each surprise is a deletion or minimisation task, which is the real value of the exercise.
If you use Safeguard, asset discovery and SBOM and dependency scanning help list the third party packages and services that sit in your estate, which feeds the recipients column. The map itself still needs a human to judge purpose and lawful basis.
Quick check
Do I need to map every field?
Start with fields that identify a person or could be combined to do so. Operational fields with no link to a person can be marked not personal and skipped.
Is a spreadsheet good enough?
Yes, to start. Move it into version control once more than one team edits it, so changes are reviewed and dated.
Sources
Last reviewed: 19 October 2026.
