Data Mapping Under DPDP: A Practical Guide for Indian Businesses (2026)

Written by: Prakhar Rai, Founder, My Legal Pal | Bar Council of India | LL.B, NLSIU Bangalore | Master of Business Laws | Advises on DPDP, GDPR, and CCPA compliance for businesses operating in and outside India

Table of Contents

Quick answer

Data mapping is the exercise of finding out, in specific and current terms, what personal data your business actually holds: what it is, where it came from, why you have it, who inside and outside your company touches it, and how long you’re keeping it. Nothing in the DPDP Act or its Rules uses the phrase “data mapping” as a named, numbered obligation the way GDPR’s Article 30 names a Record of Processing Activities. But almost every obligation the Rules do impose, itemised notice, purpose-limited consent, timely erasure, breach notification within hours, is impossible to do honestly without a data map already in place. You cannot write an accurate notice about data you haven’t inventoried. You cannot erase data on schedule if you don’t know which systems hold it. This guide walks through what to actually map, how the DPDP Rules notified on 14 November 2025 shape what that map needs to contain, and a working process for building one, whether you’re a three-person startup or a company approaching Significant Data Fiduciary scale.

Why data mapping isn’t optional in practice

The DPDP Act, 2023 and the Rules notified in November 2025 don’t contain a section called “data mapping” or “records of processing.” What they contain is a set of obligations that only work if you’ve already done the mapping exercise, whether you called it that or not.

Section 5 requires an itemised notice at the point of collection, stating what categories of personal data you’re collecting and why, for each purpose separately. You cannot itemise what you haven’t inventoried. A privacy policy that says “we collect data to improve our services” is exactly the kind of vague notice the Act was written to make non-compliant, and the only way to avoid writing one is to already know, specifically, what you collect and why.

Section 4 makes consent the primary lawful basis for processing, and unlike GDPR, the DPDP Act doesn’t recognise “legitimate interest” as a fallback. Every processing activity needs a specific, traceable ground, consent for most of it, one of the narrow exceptions (a legal obligation, a medical emergency, employment purposes under certain conditions) for the rest. Knowing which ground applies to which data point is, again, a mapping exercise before it’s a compliance one.

Rule 8 requires erasure of personal data once the specified purpose is no longer served, unless retention is required by another law or falls under the Third Schedule’s inactivity-based retention windows (more on the exact figures below). You cannot erase data you cannot locate. If customer data collected during a 2023 checkout flow is still sitting in a marketing tool nobody remembers connecting, that’s not a hypothetical, it’s the single most common finding when a business does its first real data inventory.

And if a breach happens, the Rules require notifying the Data Protection Board within a fixed window and affected individuals without delay. That timeline only survives contact with reality if you already know which systems hold what data, so your incident response team isn’t spending the first six hours of a breach figuring out what was actually exposed.

So: data mapping isn’t a named legal requirement you can point to in a section number. It’s the operational precondition for every named legal requirement that is.

The core elements of a DPDP-ready data map

A data map that’s actually useful for compliance, not just a spreadsheet that looks thorough, needs to answer the same handful of questions for every category of personal data your business touches.

What the data is, and how sensitive it is. Not just “customer data” as a category, but the actual fields: name, phone number, email, address, payment details, health information, biometric data, government ID numbers like Aadhaar or PAN. Some of these carry heavier practical risk than others even though the DPDP Act, unlike some other data protection regimes, doesn’t formally create a separate “sensitive personal data” category with distinct rules. Financial and health data still deserve tighter access controls and faster remediation attention if something goes wrong, because that’s where actual harm to a person concentrates.

Why you’re collecting it. Every data point needs a specific, statable purpose, account creation, KYC verification, order fulfilment, marketing communications, fraud prevention. “Business operations” is not a purpose a regulator or a court will treat as itemised. If you can’t finish the sentence “we collect this because ___” with something specific, that’s a flag to either define the purpose properly or stop collecting it.

Where it comes from. Website forms, mobile app sign-ups, a CRM your sales team fills in manually, a third-party vendor, a physical form later scanned into a system. Each source is a separate point where consent needs to be captured and a separate point where an error can enter your systems.

Who it’s shared with. This is where most maps fall apart, because the honest answer usually includes more systems than anyone expected: the payment gateway, the email marketing platform, the analytics tool, the cloud hosting provider, an outsourced customer support vendor, an HR platform if it’s employee data. Each of these is a Data Processor under Section 2 of the Act if they’re handling the data strictly on your instructions, and each one needs a contract that reflects that.

Which data principals it belongs to. Customers, employees, job applicants, website visitors, vendors’ contact persons. The category matters because the rights and notice obligations attach to specific people, and a data point that seems generic (“email address”) means something different depending on whose it is and what role they play with your business.

What the legal ground for processing is. Consent, in most cases. A legal obligation (tax records, statutory filings). A medical emergency. Employment-related processing under the specific conditions the Act allows. Each data point needs one of these attached, not assumed.

How long you’re keeping it, and when it gets deleted. This is where Rule 8 gets specific, and it’s worth getting exactly right rather than working from a general sense of “we’ll delete it eventually.”

What Rule 8 actually requires on retention, in specific figures

Rule 8 of the DPDP Rules, 2025 requires a Data Fiduciary to erase personal data once the specified purpose is no longer being served and retention isn’t otherwise required by law, or, for certain categories of large platforms, once a fixed inactivity period under the Third Schedule has passed.

Before erasure under an inactivity trigger, the Data Fiduciary must notify the data principal at least 48 hours before the erasure completes, so they have a real chance to log back in or re-engage if they want to retain the account or the relationship.

Separately, Rule 8 requires retaining personal data, associated traffic data, and processing logs for a minimum of one year from the date of that processing, a baseline that exists specifically so the Data Protection Board has something to examine if a complaint or breach investigation happens after the fact.

The Third Schedule sets a uniform rule for three categories of large platforms specifically:

E-commerce entities with at least 2 crore registered users in India
Online gaming intermediaries with at least 50 lakh registered users in India
Social media intermediaries with at least 2 crore registered users in India

For all three, the retention and erasure window is three years from the date the data principal last approached the entity to use the service or exercise a right, or from the date the Rules came into force, whichever is later. There’s a specific carve-out: none of the three categories has to erase data needed to let a user access their own account or redeem virtual tokens with monetary or transactional value, so a gaming wallet balance or an e-commerce loyalty point balance doesn’t get wiped out from under an inactive user.

If your business doesn’t meet these user thresholds, the Third Schedule’s specific windows don’t apply to you directly, but the underlying discipline does: define a retention period for every category of data you hold, tied to when the purpose actually ends, and build deletion into your systems rather than leaving it to memory.

A working process for building your data map

Step 1: List every point where data enters your business. Signup forms, checkout flows, cookie banners, a contact form, a CRM your team fills in by hand, a recruitment portal, a physical form later digitised. Most businesses are surprised by the length of this list once they actually walk through it system by system rather than trying to recall it from memory.

Step 2: For each entry point, record what’s collected and why. This is where the itemised-notice requirement and the data map become the same document, effectively. If your privacy policy already does this accurately, you’re partway there. Most don’t, which is usually the fastest and highest-value fix available.

Step 3: Trace where the data goes after collection. Which internal team or system touches it, and which external vendor receives it. This step is what usually reveals shadow processing, a marketing tool connected two years ago that nobody remembers, a spreadsheet export that gets emailed to an outsourced accountant every month, a support ticketing system holding customer PII indefinitely by default.

Step 4: Assign a legal ground to each processing activity. Consent for most of it. Flag anything relying on a claimed exception (legal obligation, employment necessity, emergency) and confirm the exception genuinely applies rather than being assumed.

Step 5: Set a retention period for every category, and confirm your systems actually delete on schedule. A retention policy that exists in a document but isn’t enforced in the actual database is not a retention policy a regulator will find persuasive during an audit.

Step 6: Identify your Data Processors and check their contracts. Every vendor handling data on your instructions needs a Data Processing Agreement covering security standards, breach-cooperation obligations, sub-processing restrictions, and what happens to the data when the vendor relationship ends. Our Data Processing Agreement template is built around exactly these DPDP-specific terms.

Step 7: Revisit the map when anything changes, not on a fixed annual date. A new vendor, a new product feature that collects a new data field, a new marketing channel, each of these should trigger an update to the map rather than waiting for a scheduled review to catch up months later.

For a business that’s already scaling toward meaningful volume or handling sensitive categories like health or financial data, this same exercise is also the direct groundwork for a future Data Protection Impact Assessment if you’re eventually designated a Significant Data Fiduciary, and for DPDP-compliant consent architecture as the Consent Manager framework opens for registration in November 2026.

Data mapping, DPIA, and consent management aren’t the same exercise, but they share a foundation

It’s worth being precise about how these three pieces relate, because businesses often conflate them.

Data mapping is the inventory: what you have, where it is, why you have it. It’s something every Data Fiduciary needs in practical terms, regardless of size, because it’s what makes accurate notices and honest consent possible.

A Data Protection Impact Assessment is a formal, documented risk assessment under Rule 13, and it only becomes a mandatory obligation once your organisation is formally notified as a Significant Data Fiduciary, a designation nobody has received yet as of this writing, with the obligation itself becoming operative on 13 May 2027. Our complete guide to what a DPIA requires covers this designation and its specific requirements in full. A DPIA without an underlying data map is not a real DPIA, it’s a document describing risks the author hasn’t actually traced through the systems that create them.

Consent management is the mechanism that captures and records the lawful basis your data map says you’re relying on, purpose by purpose, and, once the Consent Manager framework opens, lets a data principal manage that consent across multiple businesses from one interface. A data map tells you what consent you need to be collecting; consent management is how you actually collect and record it.

Get the mapping right first. Everything downstream, notices, consent flows, retention schedules, DPIA readiness, is easier and more accurate once it’s built on an inventory that’s actually current.

If your business also has to think about GDPR or CCPA

A meaningful number of Indian businesses processing data under DPDP are simultaneously subject to GDPR, because they have EU users or an EU entity, or CCPA, because they have California customers. If that’s your situation, the good news is that the underlying mapping exercise, what data, from where, why, shared with whom, for how long, is largely the same discipline across all three frameworks. The differences are in what each framework demands you do with that map once it exists.

GDPR’s Article 30 names the output of this exercise directly: a Record of Processing Activities, a formal document most controllers and processors of a certain size are required to maintain and produce on request. DPDP doesn’t have an equivalently named, universally mandatory document, but a business already maintaining a GDPR RoPA is most of the way to a DPDP-ready data map, with the caveat that the two frameworks part ways on lawful basis: GDPR recognises “legitimate interest” as a standalone ground, and DPDP does not, so a mapping exercise built for GDPR needs every “legitimate interest” entry re-examined against DPDP’s narrower list of grounds before you can rely on it here.

CCPA works differently again, it’s opt-out rather than consent-first for most processing, and its core mapping obligation centres on being able to answer a consumer’s “what do you know about me, and who have you sold or shared it with” request accurately, within a defined timeframe. A data map built to answer a CCPA access request and one built to satisfy DPDP’s itemised-notice requirement are asking close to the same underlying question from different regulatory angles, which is why one well-maintained map, kept current and cross-referenced against each framework’s specific requirements, generally serves a multi-jurisdiction business better than three separate, drifting spreadsheets.

For the fuller comparison of how DPDP sits alongside these and other regimes, our guide on data protection laws around the world and our piece on how data protection law in Argentina compares to GDPR and CCPA go through the specific differences jurisdiction by jurisdiction.

Mistakes that show up most often once a business actually maps its data

Treating the privacy policy as the map. A privacy policy is a public-facing summary written for readability. A data map is an internal, granular, working document that the privacy policy gets written from, not the other way around. Businesses that skip straight to writing the policy without doing the underlying inventory almost always end up with a policy that’s vague in exactly the places a regulator would look first.

Losing track of data inside internal tools, not just customer-facing ones. The CRM, the HR system, the analytics dashboard, the support ticketing tool. These get mapped far less often than signup forms and checkout flows, and they routinely hold more sensitive data for longer than anyone realises, because nobody owns the job of reviewing them.

Assuming a vendor is compliant because they say they are. A Data Processor’s own DPDP or GDPR compliance doesn’t automatically extend to you. Your Data Processing Agreement with that vendor is what actually establishes your legal position, and a data map that lists “uses a compliant vendor” without a corresponding contract in place is recording an assumption, not a fact.

Mapping once and never touching it again. A data map built during a compliance push and then filed away is accurate for exactly as long as nothing changes, which in a growing business is rarely more than a few months. The businesses that stay genuinely compliant are the ones that treat an update to the data map as a normal part of adding a new tool or launching a new feature, not a separate annual project.

Confusing “we don’t sell data” with “we’re compliant.” DPDP, unlike CCPA in its original framing, isn’t built around the sale of data as the trigger for obligations. Every instance of collection, storage, and sharing, sold or not, needs a documented basis and an itemised notice. Businesses that have never sold a data point can still be substantially out of compliance if their internal mapping and notices are incomplete.

Frequently asked questions

Is data mapping legally mandatory under the DPDP Act? Not as a separately named obligation with its own section or rule number. But the obligations that are mandatory, itemised notice under Section 5, purpose-specific consent under Section 4, timely erasure under Rule 8, and breach notification within a fixed window, are not realistically achievable without an accurate, current data map behind them. In practice, it functions as a mandatory precondition even without being named directly.

How is data mapping different from a Data Protection Impact Assessment? A data map is the inventory: what data you hold, where it is, and why. A DPIA is a formal risk assessment under Rule 13 that only becomes a mandatory obligation once your organisation is designated a Significant Data Fiduciary, an obligation that becomes operative on 13 May 2027. A data map is something every Data Fiduciary should build regardless of size; a DPIA applies to a narrow, formally designated category of larger organisations.

Does a data map built for GDPR’s Record of Processing Activities satisfy DPDP? It’s a strong starting point, since the core inventory questions largely overlap, but it needs review before you rely on it. GDPR recognises “legitimate interest” as a lawful basis for processing; DPDP does not. Any entry in a GDPR-based map relying on legitimate interest needs to be re-examined against DPDP’s narrower list of permitted grounds, principally consent, before the map can be treated as DPDP-ready.

How often should a business update its data map? Whenever something changes, not on a fixed annual schedule. A new vendor, a new product feature that collects a new data field, or a new marketing integration should each trigger an update at the time it happens. A map that’s only reviewed once a year is typically already out of date by the time the next review comes around.

Do the Third Schedule’s three-year retention windows apply to every business? No. The Third Schedule’s specific inactivity-based retention period applies only to e-commerce entities with at least 2 crore registered users in India, online gaming intermediaries with at least 50 lakh registered users, and social media intermediaries with at least 2 crore registered users. Businesses below these thresholds still need to set and enforce their own retention periods under the general erasure duty in Rule 8, tied to when the purpose for holding the data actually ends.

Where to start

If you’re building this for the first time, start with Step 1 above and walk through every point where your business actually collects data, not the ones you remember off the top of your head. Once the map exists, the notice, consent, and retention work that follows from it gets significantly faster to get right.

If you’d rather have this done and reviewed properly rather than assembled from templates, our DPDP-compliant privacy policy drafting service starts with exactly this data mapping exercise before a single clause gets drafted, and our contract lawyers in India can review your vendor agreements and Data Processing Agreements against what the map turns up. For the complete picture of every other obligation the DPDP Act creates, our complete DPDP Act guide covers the full framework this sits inside, and our free DPDP compliance checker is a quick way to see where the gaps likely are before you start.

Related reading:

This article is general information, not legal advice. DPDP compliance requirements, including retention thresholds and Significant Data Fiduciary criteria, are subject to further notifications and clarification. For advice on your organisation’s specific data mapping and compliance obligations, speak to a qualified data protection lawyer. Authored and reviewed by Prakhar Rai, Advocate, founder of My Legal Pal, enrolled with the Bar Council of India, advising businesses on DPDP, GDPR, and CCPA compliance in India and across borders.