The Data-Mapping Step Most GDPR Programs Skip

Before writing another policy, walk through your production databases, your logging pipeline, your analytics tools, and your third-party integrations, and list every place personal data lands: names, emails, IP addresses, anything that identifies a person. It's common to find personal data in places nobody expected, application logs that capture full request bodies, an analytics tool receiving email addresses in an event payload, a support tool storing full conversation transcripts indefinitely.

Knowing where data is stored answers half the question; knowing where it flows to answers the other half. A customer's email address might live in your primary database, but it also flows to your email provider, your analytics platform, your support tool, and potentially a data warehouse for internal reporting. Each of those is a separate place a deletion request has to reach, and each vendor receiving that data needs its own data processing agreement on file.

A useful way to trace this without a specialized tool: pick one real record, a specific customer, and physically follow it, checking every system your event pipeline, webhooks and scheduled exports touch. This tends to surface flows nobody remembers setting up, an old export job to a spreadsheet a former employee used, a webhook to a tool the team stopped using but never disconnected, which are exactly the flows most likely to fall through the cracks of a written policy alone.

• List every internal system that stores or processes personal data
• List every third-party vendor that receives personal data, and what specifically they receive
• Note the retention period for each location, even if the honest answer today is "indefinitely"
• Flag anywhere data flows without a clear business reason, since that's often the easiest thing to just stop doing

A data subject access or deletion request under GDPR has a response deadline (generally one month, with limited extensions), and scrambling to figure out where a person's data lives while that clock is running is the wrong time to build your data map for the first time. Once you have the map from the steps above, write an actual runbook: which systems need a delete or export call, in what order, and who owns executing it. Test the runbook on a synthetic record before you need it for a real request, since that's when you'll find the system nobody remembered, the backup that also needs handling, or the vendor whose deletion API doesn't work the way their documentation claims.

Manual retention enforcement (someone remembering to delete old records on a schedule) reliably fails within a year. Wherever possible, build retention into the system itself: a scheduled job that purges records past their retention window, log pipelines configured to redact or drop personal fields after a set period, and analytics events that never capture personally identifying data in the first place rather than capturing and later deleting it. The safest personal data is the data you never collected, so treat "do we need to collect this field at all" as a real question before treating retention as the only lever.

Start the automation with whichever system holds the most data and the least oversight, which is very often the log pipeline. Application logs tend to accumulate personal data as a byproduct of debugging, get written to cheap, high-volume storage, and never get reviewed the way a primary database would. A redaction rule at the point logs are written catches this at the source, rather than trying to scrub years of accumulated logs retroactively once someone notices the gap.