Data Mapping Under DPDPA: How to Know Where Every Byte of Personal Data Lives

You cannot protect what you can't find. That's the uncomfortable truth sitting at the centre of most DPDPA compliance conversations right now. Everyone wants to talk about consent banners and cookie pop-ups, but almost nobody wants to talk about the unglamorous groundwork that actually makes those things meaningful — data mapping. And here's the kicker: most organisations, if they're honest with themselves, are starting this exercise from somewhere close to zero.

So What Actually Is a Data Map?

Strip away the jargon and a data map is really just an honest inventory. It's the answer to a deceptively simple question: what personal data do we actually hold, and where does it live?

In practice, this means documenting things like:

• Every category of personal data your business collects

• Where that data comes from in the first place

• The systems and databases it ends up sitting in

• Why you're processing it — the actual business purpose

• The legal basis you're relying on (consent, or a Section 7 legitimate use)

• Who can access it, both inside your company and outside it

• How long you're keeping it around

• Who you're sharing it with

Some people call this a Record of Processing Activities, or RoPA, if they want to sound official about it. Whatever you call it, it's the same idea: a living, breathing map of your organisation's relationship with personal data.

Without this, you're not really building a consent framework. You can't accurately respond to a DSAR request if you don't know which systems hold a person's data. And you certainly can't assess how exposed you are to penalties if you don't know what you're exposed for.

Why Almost Nobody Has One

This isn't really anyone's fault, if we're being fair. Data doesn't arrive in an organisation neatly labelled and filed away. It accumulates over years across systems that were never built with privacy in mind because, frankly, nobody was thinking about it at the time.

Take a fairly ordinary mid-sized company. Personal data is probably scattered across a CRM, an email marketing tool, a data warehouse, a customer support ticketing system, an e-commerce platform, a mobile app backend, a payment processor, some backup storage nobody's looked at in years, and let's be honest a few spreadsheets sitting on individual laptops that IT doesn't even know exist.

Mapping all of that isn't a job you knock out in an afternoon with a coffee and a spreadsheet template. It takes interviews, system audits, a bit of technical digging and usually a fair amount of patience, because people don't always remember or want to admit where the data actually went.

A Methodology That Actually Works

If you're starting from scratch, here's a sequence that tends to hold up in practice.

Step 1 — Map the business functions. Start broad. Marketing, sales, customer support, HR, finance, operations — list down anywhere personal data touches the business.

Step 2 — Talk to the people who actually use the systems. For each function, sit down with the team responsible and get them to list every system that touches personal data. You'll be surprised how often this surfaces a tool nobody flagged before.

Step 3 — Get specific per system. For each one, document what categories of data live there, where it came from, why it's being processed, the legal basis being relied on, and how long it's retained.

Step 4 — Trace the flows. Data rarely stays in one place. Follow it from the point of collection, through storage, into analytics, and out to any third parties it eventually reaches.

Step 5 — Look for the gaps. This is where the real value shows up. You'll find processing activities with no documented legal basis at all. Data retained well past its stated window. Systems quietly holding personal information the business didn't even realise counted.

Choosing the Right Approach

Not necessarily. If your organisation is smaller and your tech stack is relatively contained, a well-built spreadsheet will get you further than you'd expect. It's not elegant, but it works.

Once things get more complex multiple databases, sprawling integrations, data spread across regions then automated discovery tools start to earn their keep. They can scan systems and flag personal data fields far faster than a human ever could. But treat them as a supplement, not a substitute. Software can tell you what is in a database. It can't tell you why someone in the sales team is exporting it into a third-party tool every Friday afternoon. That still takes a conversation.

Make Data Mapping an Ongoing Process

Here's the part people tend to forget: a data map isn't something you build once and file away. It's a living document. Every new system, every new integration, every process change that touches personal data should trigger an update.

The organisations that get this right tend to assign clear ownership — usually Legal, Compliance, or IT and set a defined review cadence, rather than leaving it to whoever remembers.

Why This Is the Real Foundation of Consent Management

Here's the connection that often gets missed. Your data map isn't a side document sitting next to your consent framework. It's what your consent framework is actually built on. Every processing activity your map uncovers needs a legal basis behind it: either consent, or a legitimate use under Section 7. Anything without one is a gap and those gaps are exactly what your consent management platform needs to close.

Closing Thoughts

Nobody’s going to pretend data mapping is exciting work. It’s detailed, time-consuming, and often uncovers gaps that are easy to overlook. But organisations that put in the effort gain something valuable: a clear understanding of how their data is collected, used, stored and shared.

Everyone else risks building a compliance programme that looks good on paper, but doesn’t reflect how data actually moves through the organisation.

OneConsent helps organisations build DPDPA-ready data governance, from data mapping to consent management.

Schedule a Demo