How to Conduct a Data Mapping Exercise Under the DPDP Act: An 8-Step Method for Indian Teams
Most guides to data mapping are about moving fields between databases. This one is about mapping personal data: where it enters, why you hold it, which systems and vendors touch it, and how it leaves. Use it to run a first exercise on one business process, then scale it.
To conduct a data mapping exercise, pick one business process, assemble a cross-functional team, then trace the personal data from collection point to systems, vendors, retention and erasure, and validate the result against real systems. Record, for each processing activity: the data, whose it is, the purpose, the applicable basis (consent or a Section 7 use), the systems, the recipients and processors, the retention trigger and the erasure path. Then keep it current.
What the Act says: the DPDP Act does not name a data mapping exercise or prescribe a method. This is a practical way to meet duties it does contain.
Where to start: one high-volume process, such as customer onboarding, not the whole company.
The real test: can you find one person’s data in every system, including at vendors, and act on it?
Phase 1
Scope and people
Choose the process, name an owner and bring in the teams that know the data.
What is a data mapping exercise? Mapping personal data vs mapping fields between systems
A data mapping exercise is a structured process for finding out what personal data you process, why, where it lives, who receives it and how it leaves. Its output is a personal data inventory plus data flow maps, owned by named people and checked against real systems.
The phrase “data mapping” is used for two different jobs, and search results mix them. Be clear which one you need.
Field mapping (integration and migration)
Matches a field in a source system to a field in a target system.
Defines transformation rules, for example combining two name fields.
Used for data migration, ETL pipelines and system integration.
Success means the data arrives correctly. It does not ask why you hold it.
Personal data mapping (this guide)
Records what personal data you process and whose it is.
Links each activity to a purpose, an applicable basis and an owner.
Traces systems, vendors, retention and erasure.
Success means you can explain and act on your processing. Field mapping can be one input.
The two are related. A data engineer’s field mapping tells you which columns hold email addresses. A personal data map tells you why those emails are held, who may see them, which vendor receives them and when they must go. If you are unsure of the vocabulary, read data mapping vs data inventory vs RoPA first.
Legal position
The DPDP Act does not use “data mapping” as the name of a duty, and we found no provision that prescribes a mapping method. See is data mapping mandatory under the DPDP Act? for the full analysis. Treat this guide as a practical method, not a statutory procedure.
The basics
The 7 elements of a DPDP Act data map
A usable data map answers seven questions for every processing activity. If a row cannot answer one of them, that gap is a finding, not a blank to ignore.
The seven elements of a personal data map and what each records
#
Element
What you record
Why it matters
1
Source
Where the data enters: form, app, call, partner, import.
Notice and consent are given at the point of collection.
2
Data and Data Principal
Which data elements, about which group of people.
Separates employees from customers, and flags children.
3
Purpose and applicable basis
The specified purpose, and whether consent or a Section 7 use applies.
Processing must have a lawful purpose under Section 4.
4
Systems
Where the data is stored, processed and backed up.
Security, rights requests and erasure all start here.
5
Recipients and processors
Who receives or processes it, internally and externally.
The Data Fiduciary stays responsible for processors (Section 8(1)).
6
Retention and erasure
The trigger, the period, the legal hold, and how deletion happens.
Erasure duties under Section 8(7) reach processors too.
7
Owner and review date
A named person and the last time the row was verified.
A map nobody owns goes stale quickly.
Keep the field list short
Start with these seven and add fields only when a real decision needs them. The full field list lives in the minimum inventory fields section of the complete guide. This page teaches the method, not a 40-column spreadsheet.
The basics
The 8-step data mapping method at a glance
Scope, team, collection points, categories, flows, purposes and processors, retention and rights, then validation. Each step produces a deliverable you can review, so the exercise never turns into an open-ended survey.
1Define scopePick the first process and the success test.Deliverable: scope sheet
2Form the teamName an owner and the teams who know the data.Deliverable: owners list
3Find collection pointsEvery place personal data enters.Deliverable: collection register
4List data and peopleCategories, Data Principal groups, children.Deliverable: data categories
5Trace systems and flowsStorage, integrations, backups, exports.Deliverable: flow map
6Map purpose and processorsPurpose, applicable basis, recipients.Deliverable: processor register
7Capture retention and rightsRetention, erasure, withdrawal, requests.Deliverable: retention routes
8Validate and maintainCheck evidence, run a test, set reviews.Deliverable: approved map
Run the exercise
Before you start: scope by business process, run a pilot and assemble the data mapping team
Do not try to map the whole organisation at once. Choose one business process, map it completely, and use what you learn to run the rest.
Scope by business process
Work process by process, because that is how people talk about their own data. Typical first-cycle candidates are customer onboarding, website and marketing, mobile app registration, customer support, HR and recruitment, payments or KYC, and vendor management. Pick the ones that handle the most personal data, involve children, use many vendors, or would be hardest to search if someone asked for erasure.
A scoping sheet for the first mapping cycle (example row)
Scope item
Example
Business process
Customer onboarding
Systems involved
Mobile app, CRM, KYC platform, support desk
Personal data involved
Name, phone, email, KYC documents, device data
Process owner
Head of Customer Operations
Known processors
Cloud host, CRM provider, KYC vendor
Output
Customer account
Target completion
A date set by the sponsor
Pilot first
Map one process end to end before you roll out. A complete pilot shows which questions work, which teams are missing and which fields you actually need. It also gives leadership a concrete example to approve.
Assemble the data mapping team
One person with a spreadsheet cannot reliably map an organisation’s data, because no single function sees everything. Privacy or compliance defines the standard, but the facts sit with the teams below.
Who contributes what to a data mapping exercise
Team
What they contribute
Privacy or compliance owner
Sets the template, reviews purposes and applicable basis, escalates issues.
Business process owner
Explains the real workflow, who uses the data and the exceptions.
IT and architecture
Applications, integrations, databases, environments and endpoints.
Information security
Access control, logging, monitoring, encryption and backups.
Product and engineering
App flows, SDKs, APIs, telemetry and cookies.
Data and analytics
Warehouses, pipelines, dashboards and derived datasets.
Marketing and sales
Forms, lead lists, campaign tools and CRM usage.
HR
Employee, applicant and contractor data and systems.
Procurement and legal
Vendor list, contracts, processor terms and legal retention.
Give each process a data owner, a named person who confirms the rows are accurate and approves changes. Skills you need are practical: an ability to ask clear questions, read system diagrams, and write down what you learn in a consistent format. Deep legal or technical expertise is useful but not a prerequisite for the first pass.
Run the exercise
How to conduct a data mapping exercise: 8 steps with questions, records and deliverables
Each step below says what to do, who to involve, what to ask, what to record and what you should have at the end. Use the same five headings every time so the work stays comparable across processes.
1Define the scope and the success test
What to do
Choose the first-cycle processes and write down what “done” means, for example “we can find and act on one person’s data in this process within a set time”.
Who to involve
An executive sponsor and the privacy or compliance owner.
Questions to ask
Which processes hold the most personal data?
Which involve children, or many vendors?
Which would be hardest to search for a correction or erasure request?
What to record
Process name, owner, systems expected, and a target date.
Deliverable
A scope sheet with a sponsor and a completion date.
2Form the cross-functional team and name owners
What to do
Invite the teams in the table above and agree who owns each process. Share the template and one filled example before the first interview.
Who to involve
Process owners, IT, security, procurement, HR and any product or data leads.
Questions to ask
Who can tell us how this really works, not how the policy says it works?
Who approves changes to this process or system?
What to record
Names, roles and responsibilities for each process.
Deliverable
An owners list with one accountable person per process.
3Identify every collection point
What to do
Start where personal data enters, and look beyond the website. Informal channels are where gaps hide.
Who to involve
Marketing, sales, support, HR and product.
Questions to ask
Is data collected directly, through a partner, or generated by us?
What notice is shown at that moment (Section 5)?
Do we rely on consent, or on a certain legitimate use in Section 7?
Where is the consent record kept, and which notice version does it point to?
Do we collect optional fields we do not need?
What to record
Collection point, channel, notice version, applicable basis and where the evidence sits.
Deliverable
A collection point register linked to each processing activity.
Where to look
Customer-facing: website forms, mobile app screens, account registration, chatbots, cookies and pixels, support email, WhatsApp, call centres.
Internal: HR and recruitment portals, payroll, employee spreadsheets, CCTV and access systems, internal apps.
Third party: partners, marketplaces, lead providers, vendors, acquired or imported lists.
4Document Data Principal groups and data categories
What to do
Replace “customer data” with precise groups and categories. Broad labels cannot support rights, retention or vendor decisions.
Who to involve
Process owners, data and analytics, security.
Questions to ask
Whose data is it: customers, leads, employees, applicants, contractors, visitors, children and their guardians?
Which categories: identity, contact, account, transaction, financial, device and online, behavioural, communications, verification, employment, derived?
Is any of it a child’s data, which needs verifiable parental consent under Section 9?
What to record
Data Principal group, data categories, and a children’s data flag.
Deliverable
A data category list per process, including derived data such as scores and segments.
5Trace systems, storage locations and data flows
What to do
Follow the data, not the org chart. For each activity, trace where data is collected, moved, stored, transformed, accessed, backed up, exported and deleted.
Who to involve
IT, architecture, security, data engineering, product.
Questions to ask
At every hop, ask the five flow questions below.
What to record
System and owner, environment (production, test, development), storage type, integrations (API, file transfer, manual export), transformations, backups and archives, and hosting location where relevant.
Deliverable
A system list and a flow diagram for the process.
1CollectForm, app, call or import.Which notice applies?
5EraseDeletion and anonymisation.What happens afterward?
The five questions to ask at every step of a data flow
#
Question
What it surfaces
1
What data is moving?
Unnecessary fields and hidden categories.
2
Why is it moving?
Purposes that are not in the notice.
3
Who receives it?
Unlisted vendors and onward sharing.
4
Where is it stored?
Shadow copies, exports, backups, test environments.
5
What happens afterward?
Missing retention and erasure steps.
Production is not enough
A map that covers only production systems is incomplete. Test and development copies, backups, archives, data warehouses, shared drives, call recordings and manual CSV exports often hold the data that is hardest to find or erase.
6Map purposes, applicable basis, recipients and processors
What to do
Link each data flow to a clear purpose, the applicable basis, and every party that receives or processes the data.
Who to involve
Privacy or legal, process owners, procurement, vendor owners.
Questions to ask
Is the purpose specific enough to match the notice?
Is it consent, or a named Section 7 legitimate use?
For each vendor: what do they receive, why, and under what contract?
What happens to the data when the vendor relationship ends?
What to record
Purpose, applicable basis, then per vendor: entity and service, role, data received, transfer method, contract status, deletion terms, subprocessors, and business owner.
Deliverable
A processing register with purposes, and a processor register.
A purpose statement test, with a weak and a stronger example
Purpose
Verdict
Why
“To improve our services.”
Too broad
Cannot decide what data is necessary or when to delete it.
“For business operations.”
Too broad
Does not match any specific notice or collection point.
“To verify a customer’s identity during onboarding, set up and manage the account, and deliver the service they requested.”
Workable
Specific, tied to the data collected, and gives a clear end trigger.
The DPDP Act uses its own framework: a lawful purpose with consent, or one of the certain legitimate uses in Section 7. Do not import GDPR’s “lawful basis” or “legitimate interest” wording into the Act’s fields. Write “applicable basis: consent” or “applicable basis: Section 7 use”. The consent management guide explains how notice and consent fit together. Do not rely only on the procurement list for vendors, because a team may have bought a tool that never went through procurement.
7Capture retention, erasure, withdrawal and rights routes
What to do
Extend the map past storage. Record how data leaves, and what happens when someone withdraws consent, asks for correction or erasure, or the purpose ends.
Who to involve
Process owners, IT, finance and legal for statutory retention, and processors.
Questions to ask
When does this data stop being necessary?
Does any other law require us to keep it, and for how long?
Where are the copies: production, backups, vendor systems, spreadsheets, email?
How would a withdrawal or erasure request reach each of them?
What to record
Retention trigger and period, any legal retention, erasure method, backup and archive handling, processor deletion route and evidence, the intake route for rights requests, and the escalation owner.
Deliverable
Retention and erasure routes, and a rights search list, attached to each activity.
What the Act and Rules say
Section 8(7) requires a Data Fiduciary to erase personal data when the Data Principal withdraws consent or as soon as it is reasonable to assume the specified purpose is no longer served, whichever is earlier, and to cause its Data Processor to erase data made available to it. Section 8(8) deems the purpose no longer served if the Data Principal neither approaches the Data Fiduciary nor exercises rights for a period the Rules prescribe. For the classes listed in the Third Schedule (certain large e-commerce entities, online gaming intermediaries and large social media intermediaries), Rule 8 sets a three-year period and requires at least 48 hours’ notice before erasure. Check the Schedule for the thresholds and exclusions that apply to you. Retention required by another law is a separate question, so record the law and period in the map.
8Validate, approve, remediate and schedule reviews
What to do
Treat the first version as a baseline. Check it against evidence, fix gaps, get the owners to approve their rows, and set a review date.
Who to involve
Data owners, IT, security, procurement and the sponsor.
Questions to ask
Does what people told us match what the systems and contracts show?
Which gaps are urgent, and who owns each fix?
What to record
Approval date, next review date, known gaps, remediation status and links to evidence.
Deliverable
An approved map with open actions. Validation is covered in detail below.
Run the exercise
Data mapping interview questions by department
Do not send every team a blank spreadsheet. Run short structured interviews using department-specific questions, fill the template yourself, then ask the owner to confirm it.
Questions to ask each department, and what they usually reveal
Team
Ask
What it often reveals
Marketing
Which forms, landing pages, lead lists and campaign tools do you use? Where do leads go after the form? Who else can see them?
Unlisted email platforms, spreadsheets of leads, event badge scans.
Sales
Where do you keep prospect and customer contact details? Do you export from the CRM? Do you buy or import lists?
Personal exports, third-party lead data with unclear consent.
HR
Which systems hold applicant and employee data? Who processes payroll and background checks? How long do you keep rejected CVs?
What do customers send you? Where are calls, chats and attachments stored? Who can export them?
ID documents in email, call recordings with no retention rule.
Product and engineering
Which SDKs, analytics and crash tools are in the app? What does each log? Which APIs send data out?
Third-party SDKs collecting device data, verbose logs with personal data.
IT and security
Which systems hold personal data? How are access, logging and backups handled? Which environments exist?
Test copies of production data, old backups, unmanaged SaaS.
Finance and legal
What must you retain by law, and for how long? Which vendors receive personal data? Which contracts include processing terms?
Statutory retention periods, vendors with no data terms.
Procurement
Which vendors have access to personal data? Which were bought outside procurement? Which contracts are due for renewal?
Shadow SaaS purchased on cards by individual teams.
Run the exercise
Worked example: mapping digital customer onboarding under the DPDP Act
One customer journey touches many systems, teams and vendors. The example below is illustrative. Replace the systems and vendors with your own.
A prospective customer downloads a mobile app, enters a phone number and email, verifies an OTP, uploads an identity document, completes verification through a third-party provider, and receives an account decision. Data then flows into the core account system, the CRM, the support platform, security logs and an analytics environment.
Mapping digital customer onboarding stage by stage (illustrative)
Stage
Data involved
System or team
Recipient or processor
Key mapping question
Registration
Name, mobile number, email, device data
Mobile app, identity service
OTP service provider
What notice is shown, and what proof is kept?
Identity verification
ID document, selfie, verification result
KYC workflow
KYC provider
What is sent and returned, and how long is it kept?
Account decision
Identity, risk signals, decision output
Core platform, fraud system
Fraud or risk vendor, if used
Is derived scoring recorded and access-controlled?
Customer service
Account ID, queries, call and chat records
Ticketing, call centre tools
Support SaaS, call provider
Can we locate this for a correction or erasure request?
Analytics
User ID, events, device data
Data warehouse, BI tools
Analytics vendor
Is the dataset limited and covered by the stated purpose?
Account closure
Account, transaction, support, KYC data
Core system, CRM, archives
All relevant processors
What is deleted, what must be kept by law, and how is it evidenced?
This is why a single “customer data” line is not enough. One journey creates several collection points, different teams, vendors, derived data, security logs and separate retention rules. The map exposes each of them, and each becomes a question you can answer or a gap you can fix.
Run the exercise
Data mapping template: the fields to capture for each processing activity
Fourteen fields are enough for a first usable inventory. Add more only when a real decision needs them.
A starter data mapping template with example values (illustrative)
Field
Example
Activity ID and business process
CUST-ONB-001, digital customer onboarding
Owner
Head of Customer Operations
Data Principal group
Prospective customers and customers
Data categories
Name, phone, email, KYC document, selfie, device ID
Source or collection point
Mobile app registration and KYC upload
Specified purpose
Verify identity, create and manage the account, deliver the service
Applicable basis and notice reference
Consent, notice v3.2, consent record ID and timestamp
Account closure, then the approved period or legal minimum
Erasure route
Automated deletion plus processor confirmation
Children flag, rights route, review date
No; privacy request queue; next review date set
Start your first personal data inventory
Our free Data Inventory Workbook is an Excel file with a 28-field inventory sheet (12 core fields), drop-down lists, six worked examples, a processor register, a gap log and a summary sheet. Copy the fields above into it and run a pilot. See the full guide to building a personal data inventory.
What the DPDP Act says vs what a data map helps you do
The Act and Rules create duties around notice, consent, processors, security, erasure, rights and breaches. A current data map is how you know where to apply each one. The right column is practical guidance, not a statutory requirement.
Duties in the Act and Rules, and how mapping supports them
Area
What the Act or Rules say
Practical use of the map
Purpose, notice and consent
Section 4(1) allows processing for a lawful purpose with consent or for certain legitimate uses. Section 5(1) requires a notice with or before the consent request.
Record which notice version and consent record apply to each collection point.
Processors
Section 8(1) makes the Data Fiduciary responsible for processing by a Data Processor on its behalf.
Keep a processor register with data shared, contract status and deletion terms.
Security safeguards
Section 8(5) requires reasonable security safeguards. Rule 6(1) sets minimum measures: security measures such as encryption, access control, logs and monitoring, backups for continued processing, retention of logs and related personal data for at least one year, processor contract provisions, and technical and organisational measures.
Record, per system, who has access, what is logged, how it is backed up and where logs are kept.
Erasure
Section 8(7) and 8(8) as above, with Rule 8 and the Third Schedule for specified classes.
Record retention trigger, legal holds and the erasure path, including at processors.
Data Principal rights
Section 11(1) gives a right to a summary of data processed and the identities of Data Fiduciaries and Data Processors it has been shared with. Section 12 covers correction, completion, updating and erasure. Section 13 covers grievance redressal, and Rule 14(3) sets a 90-day resolution period.
Keep a search list of every system and processor to check for a request.
Breach response
Section 8(6) requires intimation to the Board and each affected Data Principal. Rule 7 requires notice without delay and detailed information to the Board within 72 hours, or a longer period the Board allows.
Use the map to go from an affected system to the data, the people and the vendors involved.
Do not overstate
None of these provisions says “keep a data map”. If your policy or a client deck says the DPDP Act requires data mapping, change the wording to “a data map supports compliance with” the duty you mean. Rule text should be read in the Gazette (G.S.R. 846(E)) before you cite it formally.
Prove it and keep it
How to validate your data map: does the spreadsheet match reality?
A map is only evidence if it matches your systems. Validate it against documents and systems, then run three practical tests.
Check the map against evidence
Application and database lists, and architecture diagrams.
Website and app forms against CRM and marketing fields.
Vendor lists, contracts, and SaaS spend and sign-in records.
Privacy notices and consent records.
Security documentation and retention policies.
Interviews with process owners, repeated after the first draft.
Run three tests
Trace a record. Pick one real customer and find their data in every listed system.
Drill a withdrawal. Simulate one withdrawal or erasure request from intake to closure, including processors.
Reconcile vendors. Compare your processor register with finance and sign-in records to find tools nobody mapped.
Record what each test finds. A drill that fails is useful: it shows exactly which system, vendor or owner is missing from the map.
Prove it and keep it
Keep your data map current: change triggers and ownership
A data map is a living record, not a one-off project. Define the events that force an update, and make the data owner responsible for acting on them.
Product and technology
New feature or app release, new form, cookie, SDK or analytics tool, new integration, system migration, new AI model or logging practice.
Vendors and data
New vendor, change of vendor or its subprocessors, vendor termination, new purpose for existing data, change in a retention period.
People and events
New business unit or acquisition, new marketing channel, security incident or near miss, and a scheduled review at least annually.
1Change happensA trigger from the list above.Owner is told
2Update the mapAdjust the affected rows and flows.Reviewed by the owner
3Review impactCheck notices, contracts, retention and security.Related documents updated
The simplest control is to add “update the data map” to the checklists that already exist: new vendor onboarding, product release sign-off and change management.
Prove it and keep it
A 30/60/90-day data mapping plan for your first exercise
Discover in the first month, map in the second, and operate in the third. This is our suggested framework. The DPDP Act does not set a 90-day requirement.
Score your readiness against the Act and Rules, then get matched with an implementation partner who can run the exercise with your teams. Prefer to talk scope first? See data mapping services.
Frequently asked questions: how to conduct a data mapping exercise under the DPDP Act
How do you conduct a data mapping exercise?
Choose one business process and form a cross-functional team. Then identify every collection point, list the data and Data Principal groups, trace the systems and data flows, map purposes, applicable basis and processors, capture retention and erasure routes, and validate the result against real systems. Name an owner and set change triggers so the map stays current.
What is a data mapping exercise?
It is a structured process for documenting what personal data an organisation processes, whose it is, why it is processed, where it is stored, who receives it, how long it is kept and how it is erased. The output is a personal data inventory and data flow maps with named owners.
What are the key elements of a data map?
Seven: the source of the data, the data and Data Principal group, the purpose and applicable basis, the systems, the recipients and processors, the retention and erasure route, and an owner with a review date.
Is a data mapping exercise mandatory under the DPDP Act?
We found no provision in the DPDP Act that names data mapping as a duty or prescribes a method. The Act does impose duties on notice, consent, processors, security, erasure, rights and breaches, and a data map helps you meet and show them.
Who should be involved in a data mapping exercise?
Privacy or compliance should set the framework, but the work needs process owners, IT, security, product and engineering, data teams, marketing, HR, and procurement and legal. No single function sees all the data. The practical skills are asking clear questions, reading system diagrams and documenting consistently.
How long does a data mapping exercise take?
It depends on size and complexity, and the DPDP Act sets no timeline for it. As a planning assumption, a single-process pilot can take a few weeks and a first pass across a mid-sized organisation can take around three months. Treat these as editorial estimates, not benchmarks.
Do small businesses need to do a data mapping exercise?
The Act does not name the exercise, but small businesses still have to meet notice, consent, security, erasure and rights duties. A short version works: list your five or six main processes, the tools and vendors involved, and the retention rule for each, in one spreadsheet.
Can a spreadsheet be enough for data mapping?
Yes, for a first exercise or a smaller organisation. What matters is that every row has an owner, is checked against real systems and vendors, and is reviewed when something changes. Move to a privacy or data discovery tool when the number of systems makes a spreadsheet unreliable.
How often should a data map be updated?
Update it whenever a material change occurs, such as a new vendor, form, app release, integration or retention rule, and review it on a regular schedule. Annual review is a common minimum, with more frequent reviews for fast-changing or high-risk environments.
Related
Continue the data mapping collection
Go to the full method, the legal text and the practical tools. When you are ready to move from records to working controls, see the DPDP implementation framework.
About this article. Prepared by the DPDPActIndia editorial team under our editorial policy. It explains the Act and Rules in general terms and is not legal advice (disclaimer). The mapping method, interview questions, templates, timelines and time estimates are editorial guidance, not statutory requirements. Check thresholds and exclusions in the Third Schedule against the Gazette before relying on them. Spotted an error? Tell us.
dpdpactindia
Talk to a DPDP consultant
Consultant-led and partner-backed.
We use your details only to respond to this request.