DPDP Data Mapping: How to Discover Every Place Personal Data Lives

Most Indian companies preparing for DPDP have a data map. It is a spreadsheet, filled in from memory, listing the databases the engineering team can remember, the "main" columns that probably contain personal data, and the vendors the founder recalls signing up for. It was last updated six months ago.

That is not a data map. It is a document, and it will not survive contact with a Data Protection Board inquiry. The same pattern shows up across the visible layer of DPDP work that companies mistake for compliance: policies and checklists look complete while the infrastructure underneath is unmapped.

A real data map is a continuously updated inventory of every location where personal data lives across your infrastructure, tied to every purpose it was collected for, every processor it flows to, and every retention rule that applies. It is the foundation that Sections 5, 6, 8, 11, and 12 of the DPDP Act all depend on. If you cannot answer "where does User X's personal data currently sit and where has it flowed?", you cannot satisfy notice obligations, prove valid consent, fulfil erasure requests, or respond to a breach.

This guide walks through how to build one that actually works. Not the version that ticks a compliance checkbox. The version an engineering team can operate.

Why data mapping is the layer everything else depends on

Under DPDP, five separate legal obligations require you to know where personal data lives:

Section 5 (Notice). You must tell users what personal data you are collecting and for what purpose. You cannot describe what you do not know you have.

Section 6 (Consent). Consent must be specific to a defined purpose. You cannot bind consent to a purpose you have not mapped.

Section 8(3) (Accuracy). You must ensure personal data is accurate and complete. Only possible if you know every location holding it.

Section 8(7) and Section 12 (Erasure). When consent is withdrawn or the purpose is fulfilled, you must erase personal data from every system that holds it. Cannot be done without a data map.

Section 8(6) (Breach notification). You must report breaches to the Data Protection Board and affected Data Principals within 72 hours. You cannot describe the scope of a breach without knowing which data stores were affected and what data they held.

Five legal obligations, one prerequisite. Skip the data map, and every downstream layer of your compliance program is built on sand. That is why practical DPDP readiness starts with a data map before policy rewrites.

The scope problem: where personal data actually lives

Ask a founder to list where their users' personal data lives. You will typically get: "the users table in Postgres and maybe some backups."

The reality across 300+ audits we have run:

Personal data in a typical Indian SaaS or fintech company is scattered across 15 to 40 distinct locations. Below is a non-exhaustive list of the places we consistently find PII that was not on the original inventory.

Primary application databases

• User tables, profile tables, session tables
• Foreign keys carrying user IDs across every related table
• JSON columns and unstructured metadata fields

Analytics and product intelligence

• Data warehouses (BigQuery, Snowflake, Redshift)
• Event pipelines (Segment, Mixpanel, Amplitude, PostHog)
• Product analytics with user_id joined to profile attributes

Communications infrastructure

• Email marketing (Mailchimp, Klaviyo, Sendgrid contact lists)
• Push notification systems (OneSignal, Firebase)
• SMS gateways (MSG91, Kaleyra, Exotel)
• WhatsApp Business API vendors

Payment and financial systems

• Razorpay, Stripe, Cashfree customer records
• Invoicing and billing tools (Chargebee, Zoho Books)

Customer support

• Freshdesk, Intercom, Zendesk tickets containing user data
• Support chat transcripts
• CSAT and NPS survey responses

Storage and files

• S3 buckets holding user uploads (KYC documents, profile photos, PDF exports)
• Cloud storage for reports, receipts, invoices
• Old buckets from migrated products that nobody deleted

Backups

• Nightly database backups (RDS snapshots, Postgres dumps)
• Point-in-time recovery windows
• Long-term archival storage

Logging and observability

• CloudWatch, Datadog, Sentry, Loki logs
• Error tracking that captures request bodies and user context
• API access logs

Internal tools

• Google Sheets exports for analysis
• Retool or Metabase dashboards querying live PII
• CSVs on team members' laptops

Development environments

• Staging and QA environments with production data copies
• Local developer laptops with database snapshots
• Test fixtures with hardcoded real Aadhaar or PAN

Third-party integrations you forgot about

• Old A/B testing tools still receiving user data
• Deprecated CDPs that were never fully disconnected
• Marketing automation pixels on legacy landing pages

Every one of these is a location a Section 12 erasure request must reach. Every one is a location a Section 8(6) breach notification must cover. The scope problem is the compliance problem.

The two-part definition: data discovery vs data mapping

The terms are used interchangeably and shouldn't be.

Data discovery is the technical scanning process. Automated tools scan your infrastructure and identify locations where personal data exists. Output: a list of PII findings tied to specific databases, tables, columns, buckets, and files.

Data mapping is the business context layer on top. It takes discovery output and adds: what purpose is this data collected for, which lawful basis applies, who has access, how long is it retained, what processors receive it, what happens when a user withdraws consent.

Discovery answers "where is the data?" Mapping answers "why is it there and what should happen to it?" You need both. Discovery without mapping is inventory without meaning. Mapping without discovery is a document that is out of date the moment your engineering team ships a new feature.

How to build a data map: the step-by-step engineering process

Step 1: Define the scope of your inventory

Before scanning anything, list every environment where personal data could exist:

• All production databases (primary, read replicas, analytics)
• All object storage (S3 buckets, GCS, Azure Blob, on-prem file shares)
• All third-party SaaS tools your team uses
• All backup systems and archival storage
• Staging, QA, and development environments if they contain production data copies

Assign a single owner per environment. If nobody owns it, nobody will maintain the map for it.

Step 2: Run automated PII discovery

Manual data mapping does not scale and does not stay current. For each environment in your scope, run automated discovery.

For structured databases (Postgres, MySQL, MongoDB, DynamoDB):

Use a scanner that combines three detection methods:

1. Column name heuristics. A column named aadhaar_no, pan, email, mobile, dob is almost certainly PII regardless of what values it currently holds. This catches masked or tokenized data that pattern matching would miss.

2. Regex pattern matching. For India-specific identifiers with validated formats:

   • Aadhaar: 12-digit numeric with Verhoeff checksum
   • PAN: AAAAA0000A (5 letters, 4 digits, 1 letter)
   • GSTIN: 15-character alphanumeric with state code prefix
   • UPI ID: handle@provider format
   • IFSC: 4 letters + 0 + 6 alphanumeric
   • Indian mobile: +91 prefix + 10 digits starting with 6, 7, 8, or 9

3. NER (Named Entity Recognition) for unstructured text. Free-text columns (notes, comments, addresses, descriptions) need ML-based detection that can identify names, addresses, and other PII embedded in prose.

For object storage (S3, GCS):

Sample files from each bucket. CSVs, Parquet files, JSON dumps, PDF exports all commonly contain PII. Extract text from PDFs and DOCXs and apply the same detection pipeline. Verify encryption at rest and lifecycle policies for every bucket that holds PII.

For SaaS tools:

Use vendor APIs where available (Salesforce, HubSpot, Freshdesk, Intercom all expose contact and account data via API). Where APIs don't cover the data, run scheduled exports and scan the exports.

Open-source tooling to get started:

• Microsoft Presidio for NER-based PII detection across text
• The Indic Sentinel's dpdpa-pii-scrubber on GitHub for Bharat-native identifiers (Aadhaar, PAN, UPI validation with checksums)
• AWS Macie for S3 bucket scanning (US-region only, with limits)
• GCP DLP API for GCS and BigQuery

None of these are complete. They are starting points. A production data map for a mid-size company typically requires either a purpose-built platform or a custom integration layer stitching multiple tools together.

Step 3: Add the business-context layer

For every PII location discovered, capture the following metadata. This is what turns discovery output into a real data map:

For a company with 30 PII locations, this is a 30-row document with 11 columns. Nothing more elaborate is needed as a starting artifact. The DPDP-required document that must be produced from this map is called the Record of Processing Activities (RoPA).

Step 4: Map data flows to processors

For every processor identified in Step 3, document the flow:

• What data element flows to them?
• What is the purpose of the flow?
• Under what contract (DPA reference)?
• Do they have sub-processors that also receive it?
• What is the deletion propagation mechanism when consent is withdrawn or the user asks for erasure?

This step is the one most companies get wrong. They know they use Sendgrid. They do not know Sendgrid's sub-processors. Sendgrid uses AWS, so PII flows from your Postgres to Sendgrid's application to AWS S3 US. Under Section 8(1) of DPDP, you are the Data Fiduciary. Sendgrid is the Data Processor. AWS is a sub-processor. You are liable for the entire chain.

Step 5: Establish a change detection mechanism

A data map that is not maintained is worse than no data map, because it creates a false sense of coverage.

Every deployment can introduce new PII locations. A developer adds a new column. A new microservice starts logging user context. A new marketing tool gets connected via Zapier. A backup restore repopulates a deleted table.

Set up continuous scanning at a defined cadence:

• Weekly for production databases and object storage
• On every deployment if you can integrate scanning into CI/CD (this is the highest-leverage version)
• Monthly for third-party SaaS tools via API
• Quarterly for full-scope re-inventory (checking whether new environments have been spun up)

Alert on drift: new columns matching PII patterns, new buckets appearing, new SaaS integrations detected via network egress or SSO logs.

Step 6: Produce the RoPA document

The Record of Processing Activities is the compliance artifact your data map produces. Under Rule 8 of the DPDP Rules 2025 and international best practice (aligned with GDPR Article 30 structure that DPDP is expected to reference operationally), a RoPA typically includes:

• Name and contact of the Data Fiduciary
• Purposes of processing
• Categories of Data Principals
• Categories of personal data processed
• Categories of recipients (including processors)
• Cross-border transfer details, if any
• Retention periods per data category
• Security safeguards in place

Your data map is the input. The RoPA is the output. If your map is accurate, your RoPA is defensible.

The three most common data mapping failures we see

Failure 1: The one-time exercise.

A consultant runs a discovery scan, hands over a spreadsheet, and leaves. Six months later the map is 40% wrong because the product changed. This is the most common pattern and the most dangerous, because leadership believes they have a map.

Failure 2: The lawyer-drafted map.

The privacy policy claims certain data practices. A lawyer wrote a "data flow diagram" based on interviews with the founder. Neither reflects what the code actually does. When an audit compares the two, the gap becomes the finding.

Failure 3: Missing the invisible data.

Discovery covers the databases the team named. It misses the S3 bucket from a deprecated feature, the CSVs in shared drives, the developer laptops with prod snapshots, the CloudWatch logs capturing request bodies, and the analytics pipeline that hoovers up everything. Invisible data is the biggest breach exposure most companies have.

The self-test: are you actually mapped?

Pick a real user in your production database. Not a test account. A real one.

Now answer, without your engineering team having to investigate:

1. Which databases contain any of their personal data?
2. Which object storage buckets contain any of their files?
3. Which third-party vendors have received any of their personal data in the last 12 months?
4. Which of those vendors have sub-processors that also received it?
5. If they submit a Section 12 erasure request right now, what is the exact list of systems your team needs to touch to fulfil it?
6. What is your expected time-to-completion?

If you cannot answer these in under 30 minutes, you do not have a data map. You have documentation of what you hope is true.

Where Privra fits

Privra runs continuous data discovery and mapping across your infrastructure, purpose-built for the DPDP Act. Our discovery engine combines column-name heuristics, India-specific regex validators (Aadhaar with Verhoeff checksum, PAN, UPI, GSTIN), and NER for unstructured text. Findings are mapped against 28 DPDP checkpoints and structured into an audit-ready RoPA that updates as your infrastructure changes.

If you want to know where your personal data actually lives (not where you think it does), talk to us — that is the starting point of every engagement.