A spreadsheet of tables with PII flagged is discovery. Knowing exactly whose data it is, under which purpose, is mapping — and only mapping answers a rights request.
June 2026 · 8 min read
"We did a data discovery exercise last year" comes up constantly in DPDPA readiness conversations. It is almost always followed by a spreadsheet — a list of database tables with a column flagged here and there as containing personal data. What is missing, more often than not, is anything that actually ties a column to a person, a purpose, or a consent record.
That exercise is discovery. It is a necessary first step. On its own, it is not compliance.
Discovery answers one question: what personal data do we hold, and where does it physically sit? The output is a list of locations — database X has tables A, B and C with personal-data columns; system Y has a user-profiles table with an email, a phone number, a date of birth. That is genuinely useful for understanding the shape of your data footprint. It is not useful when someone actually asks you for their data.
When a Data Principal files an access request, "we have your data somewhere across fourteen tables in six systems" is not a response. "Here is everything we hold about you, organised by the purpose we hold it for" is.
Mapping answers a harder question: whose data is this, under which purpose do we hold it, and can we trace a straight line from every data point back to one specific Data Principal?
A properly built data map, for any given individual, looks less like a table list and more like a structured tree — a named person, with each piece of their data nested under the specific purpose it was collected for: an email and phone number under "marketing communications," a full name and date of birth under "service delivery," an account number under the same. That structure is what lets you answer a Section 11 access request properly, execute a Section 12(3) deletion request across every table that actually holds that person's data, and demonstrate to the Data Protection Board that when someone withdrew consent for marketing, processing genuinely stopped and the relevant data was removed.
The database gets scanned and columns get flagged as likely personal data. Automated tools, AI included, can suggest categories — name, email, phone, financial detail, location — but a human has to review the results. Automated classification misses context and throws up false positives, and nothing built on top of this list is reliable until it has been checked.
You need one table that holds the master list of Data Principals, and one column in it that uniquely identifies each person. This becomes the anchor for the entire map — every other column holding personal data eventually has to connect back to a user through this single point.
This is the part that data-discovery exercises skip almost without exception, and it is the actual backbone of a usable map. Every table carrying personal data has to be traceably connected back to the primary table — usually through foreign-key relationships. Without that lineage, you know email addresses exist in a dozen tables, but not which one belongs to which person. With it, any column can be traced back to a specific user ID.
Once columns are linked to users through lineage, they get mapped to standardised data elements — "Email Address," "Phone Number" and so on — and those elements are grouped under the purposes consent was actually given for. This is the step that connects the database map to the consent record itself.
Data maps go stale fast. New tables get added, schemas change, and a map built once is often out of date within a single sprint. Maintaining it has to be an ongoing activity, not a project with an end date.
Line up each right against what discovery gives you versus what mapping gives you, and the gap is stark. For the right to access, discovery hands you a list of tables that might hold the person's data; mapping hands you every specific data point, by purpose, with its source. For correction, discovery tells you a column type exists somewhere; mapping tells you which exact record holds this person's value. For deletion, discovery tells you which tables generally contain personal data; mapping gives you every record to delete, scoped precisely to the purpose in question. For withdrawal enforcement, discovery only confirms personal data exists; mapping tells you exactly which data, under which purpose, has to stop being processed.
When a rights request lands and there is no data map behind it, an engineer ends up manually querying several databases to reconstruct that person's footprint by hand. It takes days, it is easy to get wrong, and there is no way to audit it afterwards.
Under the DPDPA, the Board's scrutiny does not stop at whether you responded to a request — it extends to how, and how completely. That is a mapping question, not a discovery question.
Getting from a spreadsheet of flagged columns to an actual purpose-linked map is exactly what our DPDP gap assessment starts with.
30 minutes to talk through your specific data footprint — no obligation.
Book a Consultation