"We did a data discovery exercise last year." This sentence appears in a surprisingly large number of DPDPA readiness assessments. It is usually followed by a spreadsheet listing database tables and flagged columns. Rarely is there anything that connects a column to a person, to a purpose, or to a consent record.
That is discovery. It is necessary. It is not compliance.
What Discovery Gives You
Discovery answers: what personal data do we have, and where is it?
The output is a list of locations: Database X has tables A, B, C with personal data columns. System Y has a user_profiles table with email, phone, and date of birth. This is useful for understanding your data footprint. It is not useful for answering a rights request.
When a Data Principal submits an access request, "we have your data in 14 tables across 6 systems" is not an answer. "Here is every piece of data we hold about you, organised by the purpose for which we hold it" is.
What Mapping Gives You
Mapping answers: whose data is this, under which purpose do we hold it, and can we trace a path from every data point back to a specific Data Principal?
A properly executed data map gives you, for any Data Principal:
User: Priya Sharma (ID: U001)
└── Purpose: Marketing Communications
├── Email Address — users.email
├── Phone Number — users.phone
└── City — user_profiles.city
└── Purpose: Service Delivery
├── Full Name — users.full_name
├── Date of Birth — user_profiles.dob
└── Account Number — accounts.account_no
This is what allows you to respond to a Section 11 access request. This is what allows you to execute a Section 12(3) deletion request across every table that holds the user's data. This is what allows you to prove to the Data Protection Board that when consent for "Marketing Communications" was withdrawn, processing stopped and data was deleted.
The Steps Between Discovery and a Usable Map
1. Scan and classify The database is scanned; columns are flagged as likely PII. AI suggests categories — name, email, phone, financial, location. Human review is mandatory here: AI can miss context and produce false positives. No downstream step is reliable until this list is clean.
2. Set the Primary Table and Primary Column Identify which table holds the master list of Data Principals, and which column is their unique identifier. This is the anchor point for the entire map. Every other PII column will be connected back to a user through this anchor.
3. Lineage mapping This is the structural backbone — and the step most commonly skipped in discovery exercises. Every PII-carrying table must be connected back to the Primary Table through a traceable path, typically via foreign key relationships. Without lineage, you know email addresses exist in 12 tables but cannot say which belongs to which user. With lineage, you can trace every column back to a specific user ID.
4. Map columns to Data Elements and Purposes PII columns, now linked to users via lineage, are mapped to standardised Data Elements (e.g., "Email Address", "Phone Number"). These are grouped under the Purposes for which consent was obtained — connecting the database map to the consent record.
5. Verify and maintain Data maps degrade. New tables are added, schemas evolve. A data map built once is out of date within a sprint cycle. Mapping must be a continuous activity.
Why Rights Fulfilment Depends on Mapping, Not Discovery
| DPDPA Right | What discovery gives you | What mapping gives you |
|---|---|---|
| Right to Access (Sec 11) | Tables that might contain the user's data | Every specific data point, by purpose, with source |
| Right to Correction (Sec 12(1)) | Where a column type exists | Which specific record contains this user's value |
| Right to Deletion (Sec 12(3)) | Which tables have personal data generally | Every record to delete, scoped to the purpose |
| Withdrawal Enforcement (Sec 6(4)) | That personal data exists | Exactly which data under which purpose to stop processing |
The operational reality of unmapped data: When a rights request comes in without a data map, an engineer has to manually query multiple databases to reconstruct the user's footprint. This takes days. It is error-prone. It cannot be audited. Under the DPDPA, the Board can audit your rights fulfilment process — not just whether you responded, but how and with what completeness.