# DPDP data mapping: find every record in four weeks, paper and WhatsApp included

> The DPDP Act does not name a data map, but its duties assume one: itemised notices (Rule 3), telling a person every fiduciary and processor her data went to (s. 11(1)(b)), erasure when the purpose ends (s. 8(7)) and scoping a breach for the Board (Rule 7). This guide gives a four-week method, interview questions for each team, a downloadable inventory template and a sweep for WhatsApp, personal phones, shared drives and exports, so the map is ready well before 13 May 2027.

Source: https://dpdp.commons.inc/dpdp-data-mapping · Updated 25 October 2026 · By the Commons Trust team (commons.inc)

A data map is a list of every place your organisation holds personal data, with the purpose, basis, recipients and retention for each. The DPDP Act never uses the phrase, yet you cannot itemise the data in a notice (Rule 3(b)(i)), tell a person every fiduciary and processor you shared her data with (s. 11(1)(b)), erase it when the purpose ends (s. 8(7)) or describe a breach's extent to the Board (Rule 7(2)(a)) for a system you do not know you have. In our estimate an organisation of 50 to 1,000 people can build a usable first map in four weeks; smaller teams need less, larger groups more. We recommend finishing it well before most duties start on **13 May 2027**.

Like the Act (s. 2(y)), we say "she" and "her" for every person.

**Jump to what you need:**

- **DPOs and programme leads running the exercise:** [The four-week plan](#the-four-week-plan-and-how-it-scales), [Interview questions by team](#questions-to-ask-each-team), [The inventory template](#an-inventory-template-you-can-download).
- **IT and security:** [Finding shadow data](#finding-shadow-data-whatsapp-phones-drives-and-exports), [Breach scoping](#scoping-a-breach-in-the-first-hour).
- **SaaS companies and other processors:** [Mapping as a processor](#if-you-are-a-processor-map-per-client).
- **NGOs with field teams:** [A composite example](#an-ngo-maps-a-livelihoods-programme).
- **Legal:** [What the map feeds](#what-the-map-feeds), [Where the law is unclear](#where-the-law-is-unclear-on-mapping).

## The four-week plan, and how it scales

The scope is wide. The Act covers personal data collected digitally or on paper and digitised later (s. 3(a)); personal data is any data about an individual identifiable by or in relation to it (s. 2(t)); and storage is itself processing (s. 2(x)), so an old export nobody opens is in scope. Our view is that the notice and basis follow the data from the moment it was collected, so record paper origins in the source column. Until 13 May 2027 the SPDI Rules still bind body corporates, so flag sensitive personal data (financial details, health, biometrics) now. A register that stays on paper is outside the Act, but a photo of it is not; the [NGO guide](/dpdp-for-nonprofits) covers getting such data off phones and WhatsApp.

The plan below assumes one accountable lead with two to four days a week, and an hour from each team head. The weeks overlap; the order matters more than the dates.

| Week | Goal | Outputs |
|---|---|---|
| 1. Systems | List every system, vendor and channel that could hold personal data | System list; vendor list from the payments ledger; channel list (WhatsApp, SMS, IVR, email, forms) |
| 2. Teams | Interview each team about what it collects, why, from whom and where it goes | Draft inventory rows; a list of shadow stores to check |
| 3. Shadow data | Sweep drives, mailboxes, phones, WhatsApp and exports | Confirmed shadow stores, each with an owner and a decision: keep, move or erase |
| 4. Decisions | Assign basis, retention, owner and children flag to each row; validate with owners | A signed-off map; gap list for notices, contracts, security and retention |

**How it scales.** These are our estimates, not requirements.

- **Under 50 people, one or two programmes:** about two weeks. One person runs the interviews in a day or two; the shadow-data sweep is most of the work.
- **50 to 1,000 people:** four weeks, as above.
- **Over 1,000 people, several entities, or a network of programmes and sub-grantees:** run the four weeks per business unit or programme cluster, in parallel where you have leads, with one central keeper merging the results. Expect six to ten weeks for the whole organisation, which is the range our [NGO guide](/dpdp-for-nonprofits) gives for larger NGOs and networks. Partners' and vendors' answers usually set the pace.

### Week 1: build the system list from four sources

Do not start from the IT asset register alone. It lists what IT bought.

- **The payments ledger.** Ask finance for every vendor paid in the last 24 months, including card spend and reimbursements. SaaS tools bought on a manager's card, SMS gateways, survey tools, payroll bureaux, background-verification agencies, event platforms and freelance data-entry operators appear here and nowhere else. Every vendor that touches personal data is a likely processor. Section 8(2) requires a valid contract for processing related to offering goods or services; we recommend one for every processor, because s. 8(5) and s. 8(7)(b) reach all of them and Rule 6(1)(f) asks for security terms "wherever applicable".
- **Sign-in logs.** If staff use single sign-on, list the apps connected to it. Do the same for apps authorised against your email domain ("Sign in with Google" or Microsoft).
- **Channels.** List every SMS sender ID, WhatsApp Business number, IVR number, toll-free line, website form, chatbot and social media page.
- **Integrations.** For each core system (CRM, HRMS, MIS, ERP, LMS), list what it sends data to and receives from.

### Week 2: interview every team

Hold 45-minute interviews with each team head and one person who does the daily work; the second person knows where the spreadsheets are. Use the questions in the next section. Write rows during the interview, in the template, and send them back the same day for correction.

### Week 3: sweep for shadow data

Use the leads from the interviews and the methods in [Finding shadow data](#finding-shadow-data-whatsapp-phones-drives-and-exports). Every store found gets one of three outcomes: it becomes a row (with an owner), it is moved into an approved system, or it is erased with a record of the erasure.

### Week 4: decide, validate, hand over

For each row, the owner confirms the purpose, the basis and the retention period. The privacy lead checks that each basis is defensible and flags gaps: rows needing a notice, a contract, a security fix, a children check or an erasure job. End the week with a signed-off version and a dated copy kept as the baseline.

## Questions to ask each team

Ask every team the same opening questions, then the team-specific ones.

**For everyone:**

1. What information about individuals does your team collect, receive or create?
2. Why do you need each item? What would break if you stopped collecting it?
3. Where does it live? Include spreadsheets, shared folders, email, WhatsApp and phones.
4. Who outside the team gets it: other teams, vendors, partners, funders, government?
5. When do you stop needing it, and what happens to it then?

| Team | Questions that surface what the opening questions miss |
|---|---|
| HR | What do you collect from candidates who are not hired? Which vendors run background checks, payroll, insurance, attendance? Do you hold dependants' and emergency contacts' details? Medical certificates? Where do exit files go? |
| Finance | Which payments carry personal data (salaries, reimbursements, donor receipts, refunds)? Which bank, payment gateway and tax filings receive it? What does the law require you to keep, and for how long? |
| Sales and marketing | Where did each contact list come from? Which tools send email, SMS or WhatsApp campaigns? Do you buy, rent or swap lists? What runs on the website: forms, chat, analytics, pixels? |
| Customer support | Do call recordings, chat transcripts or tickets contain identity documents or payment details? Which outsourced centre handles calls, and from where? |
| Product and engineering | Which production databases hold user data? What copies exist in staging, analytics warehouses, logs and backups? Which third-party SDKs are in the app? Does any feature use AI services? |
| Programmes and field (NGOs) | What do field staff collect, on what device, and in which language is the notice? Do volunteers or community workers collect for you? Are any beneficiaries under eighteen? Do you share lists with a funder or a government department? |
| Fundraising and communications | Where are donor records? Do you use beneficiary photos and stories? Where are the consents for them? |
| Admin and facilities | Is there CCTV, a visitor register, biometric or card access? Who can view the footage and for how long is it kept? |
| IT | Who has admin rights to each system? Are laptops encrypted? Which systems keep access logs, and for how long? Do you keep the 180 days of ICT logs the CERT-In Directions ask for? Where are backups, and in which country? |
| Legal and compliance | Which records do laws or regulators require you to keep? Which contracts already have data terms? Have there been incidents or complaints? |
| Procurement | Which vendor contracts mention personal data? Which vendors use their own subcontractors? |

We recommend two follow-up questions in every interview: "Show me the last file you exported" and "What would you do if your laptop died today?" The answers lead to the spreadsheets and personal-drive copies that no system list shows.

## An inventory template you can download

One row is one processing activity: a purpose served by a set of data in a system. A CRM used for both sales follow-up and newsletters is two rows, because the purposes, and possibly the bases, differ. The template is ours; the law does not prescribe a format. Download it as a spreadsheet: [dpdp-data-map-template.csv](/downloads/dpdp-data-map-template.csv).

| Field | What to record | Why it matters |
|---|---|---|
| 1. System or store | Name, type (SaaS, database, spreadsheet, WhatsApp group, phone gallery), and who administers it | Security and breach scope (Rule 6(1)(b), Rule 7(2)(a)) |
| 2. Role | Fiduciary, processor (name the client) or joint fiduciary (name the other party) | Who carries the duties (s. 2(i), s. 2(k), s. 8(1)) |
| 3. Data items | Itemised fields, grouped into categories a person would recognise; flag health, financial, biometric, caste, religion, precise location | Notice content (Rule 3(b)(i)); penalty factor (s. 33(2)(b)) |
| 4. People | Whose data: customers, beneficiaries, donors, staff, candidates, visitors; approximate number | Breach extent; access requests |
| 5. Purpose | The specific purpose, in the words of the notice | Specified purpose (s. 2(za)); notice (Rule 3(b)(ii)) |
| 6. Basis | Consent, or the clause of section 7 (for example 7(a) or 7(i)), with one line on why it applies | Lawful processing (s. 4); rights coverage (s. 11(1), s. 12(1)) |
| 7. Source | Collected from her directly, from a parent, from a partner, a purchased list, digitised from paper; channel and notice version | Proof of notice and consent (s. 6(10)); legacy triage (s. 5(2)) |
| 8. Recipients and processors | Every other fiduciary and processor that receives it, what it receives, and whether a contract exists | Access right (s. 11(1)(b)); contracts (s. 8(2)); withdrawal and erasure (s. 6(6), s. 8(7)(b)) |
| 9. Location and transfers | Country of storage and of any remote access; sector localisation rules that apply | Transfers (s. 16, Rule 15); sector rules (s. 16(2)) |
| 10. Retention | Period, trigger (for example "12 months after decision"), legal reason for keeping longer, what happens at the end | Erasure (s. 8(7)); one-year floor (Rule 8(3)); 180 days of ICT logs under the CERT-In Directions |
| 11. Security | Access control, encryption or masking, logging, backup | Rule 6(1)(a)–(e) |
| 12. Owner | Named business owner who decides the purpose | Accountability (s. 8(4)) |
| 13. Children? | Yes, no or possibly; how age is known; how parental consent is verified | Verifiable consent (s. 9(1), Rule 10); tracking ban (s. 9(3)) |
| 14. Lookup identifier | The identifier that finds one person in this system: mobile number, enrolment ID, employee code, email | You must publish which identifier you need (Rule 14(1)(b), Rule 14(5)) |
| 15. Evidence location | Where the notice versions, consent records, contract and erasure logs for this row are kept | Burden of proof (s. 6(10)); reasonable safeguards (s. 8(5)) |
| 16. Last reviewed | Date and reviewer; link to a DPIA if you have run one | Keeps the map current; DPIA for a Significant Data Fiduciary (s. 10(2)(c)(i)) |

Add two working columns, "gaps" and "decision", to carry the actions out of the map.

**One filled row, illustrative:**

| Field | Entry |
|---|---|
| System | Google Sheet "Scholarship applicants 2026–27", owned by the programme account; editors: 4 named staff |
| Role | Joint fiduciary with the funding foundation |
| Data items | Applicant name, date of birth, school, class, marks; parent name, mobile, annual income band; Aadhaar last four digits |
| People | About 2,400 applicants, all under 18, and one parent each |
| Purpose | Assess scholarship eligibility and send status updates |
| Basis | Consent of the parent, verified (s. 9(1), Rule 10(1)(a)) |
| Source | Field visits, tablet app, notice v2.1 in Hindi; paper forms from 2025 digitised by data-entry vendor |
| Recipients and processors | Data-entry vendor (contract pending); funder receives awardee list only (joint-fiduciary agreement in draft); SMS gateway (contract signed) |
| Location | Google Workspace, data region not configured; vendor staff in Jaipur |
| Retention | Awardees: 3 years after final disbursement. Rejected: 12 months after decision. Then erase; keep anonymised counts |
| Security | Named-person sharing; 2-step verification on; no export restrictions; version history on |
| Owner | Head of Programmes |
| Children? | Yes; parent verified against ID document held for eligibility |
| Lookup identifier | Application number; parent's mobile |
| Evidence location | Consent records in the tablet app; notice v2.1 in the programme drive; vendor contract folder |
| Last reviewed | 30 Nov 2026, privacy lead |
| Gaps | Vendor contract; set export restrictions; erase 2025 paper-form photos from the vendor's laptops |

Keep the map in a spreadsheet or a simple database with version history. A dedicated privacy tool helps once there are hundreds of rows and frequent changes; until then it can hide the map from the people who need to update it.

**Flow diagrams.** A table records what is held; a data flow diagram shows how it moves. Draw one per major process (enrolment, payroll, a donation, a customer sign-up): boxes for each system, partner and processor, arrows for each transfer, labelled with the data items and the channel (API, email, WhatsApp, file upload, paper). Mark where data crosses into another organisation or leaves India. Flow diagrams find the gaps tables miss, such as a nightly export to a funder that nobody listed as a recipient, and they are the fastest way to brief someone during an incident. Keep the diagrams with the map and date them.

## Finding shadow data: WhatsApp, phones, drives and exports

Shadow data is personal data held outside the systems you know about. In our view it carries most of the risk, because it has no access control, no retention period and no owner. Look in these places.

**Shared drives and cloud storage.**

- Search drives and mailboxes for patterns: Aadhaar (12 digits, often in groups of four; check the Verhoeff check digit to cut false matches), PAN (five letters, four digits, one letter), Indian mobile numbers, and words like "beneficiary", "salary", "KYC", "medical", "donor list".
- List every file shared by "anyone with the link" and every file shared with personal email addresses.
- Find the largest spreadsheets by row count; mass exports look like that.

**WhatsApp.**

- Run a census: every group used for work, its admins, its members, and what is posted in it. Ask each team head to list groups; ask field staff separately.
- Check for photos of forms, registers, ID cards and medical documents. These usually also sit in phone galleries and in personal cloud backups.
- Find ex-staff and ex-volunteers still in groups.
- Map WhatsApp Business accounts and any vendor that sends messages for you; the vendor is a processor.

**Personal phones and laptops.**

- Ask staff, in a no-blame survey, what work data they hold on personal devices: contact lists, galleries, downloaded files, call recordings, notes apps. The personal-use exclusion (s. 3(c)(i)) does not cover your organisation's data on her phone.
- Check the exit process. If phones and laptops leave without a data check, every leaver is a possible shadow store.

**Exports and copies.**

- Exports from the CRM, MIS or HRMS sent by email or saved to desktops.
- Copies of production databases in test, staging or a developer's machine.
- Analytics warehouses, BI dashboards and log stores that hold identifiers.
- Old systems: the previous CRM that was "switched off" but not erased, and the vendor that still holds data after the contract ended (s. 8(7)(b) requires you to cause erasure).

**Vendors' own subcontractors.** Ask each processor to list who it passes your data to. Our position on whether they belong in an access answer is in [Where the law is unclear](#where-the-law-is-unclear-on-mapping).

We recommend an amnesty week: staff report what they hold, and nobody is disciplined for what they declare. You will find more that way than by scanning, and the declarations become evidence of the measures you took (s. 8(4)).

## If you are a processor, map per client

A SaaS company, call centre, payroll bureau or implementing partner holds much of its data for others. For that data the client is the Data Fiduciary (s. 2(i)) and you process on its behalf (s. 2(k)). Map it differently:

- **One row per client and service**, with the client named in the role field. In a multi-tenant product, keep a tenant register rather than thousands of rows: client, data categories, region, sub-processors, contract and its breach-notice window.
- **The client's instructions are the purpose.** Record the contract or order form that sets them.
- **Per-tenant scoping.** Your logs and the map together should let you say, for one client, which records and fields a given system or sub-processor holds. Clients will need this for their own access answers (s. 11(1)(b)) and breach reports (Rule 7).
- **Export and erasure route.** Record how you would return or erase one client's data on instruction (s. 8(7)(b)) and stop processing after a withdrawal (s. 6(6)).
- **Separate your own rows.** Billing contacts, leads, product analytics, support quality reviews and any model training are purposes you decide, so you are the fiduciary for them. Keep them in the fiduciary part of the map with their own basis.

The [SaaS guide](/dpdp-for-startups) covers how customers will test this, and [processor contracts](/dpdp-processor-contracts) covers the terms.

## What the map feeds

| Output | What you take from the map | Provision |
|---|---|---|
| Notices | Itemised data and specified purpose for each consent-based row | s. 5(1), Rule 3(b) |
| Legacy notices | Rows based on consent given before commencement | s. 5(2) |
| Basis register | The section 7 clause or consent for each purpose | s. 4, s. 7 |
| Access answers | Systems to search (filter by people); recipients (filter by recipients) | s. 11(1)(a)–(b) |
| Correction and erasure | Every copy, including at processors | s. 12, s. 8(7)(b) |
| Withdrawal | Which processors must stop | s. 6(6) |
| Accuracy checks | Rows that feed a decision about her or go to another fiduciary | s. 8(3) |
| Security plan | Which systems hold what, who can reach them | s. 8(5), Rule 6(1) |
| Retention schedule | Period, trigger and the one-year floor | s. 8(7), Rule 8(3) |
| Children | Rows needing verified parental consent and a tracking check | s. 9, Rule 10 |
| Transfers | Data leaving India, and to where | s. 16, Rule 15 |
| Contracts list | Processors without a contract (required by s. 8(2) for goods-or-services processing; recommended for all) | s. 8(2), Rule 6(1)(f) |

**Notices.** Rows with the same people and channel can share a notice, but each purpose must be itemised in it and consented to specifically (s. 6(1), Rule 3(b)(ii)); we recommend a separate tick-box for each purpose. Our [notice guide](/dpdp-consent-notice) has sample texts, and [The data you already hold](/dpdp-existing-data) covers legacy triage.

**Rights.** The access right covers data she gave by consent or under section 7(a) (s. 11(1)). For her, you owe a summary of the data and processing and "the identities of all other Data Fiduciaries and Data Processors" with whom it was shared (s. 11(1)(b)). Sharing with another fiduciary authorised by law to obtain it, on its written request for preventing, detecting or investigating offences or cyber incidents, or prosecuting or punishing offences, is excluded from that answer (s. 11(2)), so flag such disclosures in the recipients column. The lookup-identifier column tells your team how to find her in each system.

**Retention.** Personal data must be erased when consent is withdrawn or when it is reasonable to assume the purpose is no longer served, whichever is earlier, unless a law requires you to keep it (s. 8(7)). Separately, Rule 8(3) requires you to keep personal data, associated traffic data and logs of processing for at least one year from the processing, for the Seventh Schedule purposes, and then to erase them unless another law requires longer. The one-year floor does not cut short data you still need for its purpose. Record both in the retention column, along with the 180 days of ICT logs the [CERT-In Directions](https://www.cert-in.org.in/PDF/CERT-In_Directions_70B_28.04.2022.pdf) require. Direction (iv) of the CERT-In Directions requires these logs to be kept within Indian jurisdiction; CERT-In's FAQs of 18 May 2022 (Q35) suggest a copy may be held abroad if it can be produced in reasonable time, and financial-transaction records must stay in India (Q36). The FAQs are guidance, not binding law; the Directions govern. Commentators differ, so we recommend keeping a copy in India. For data held under a legitimate use rather than consent, when the purpose "is no longer being served" under s. 8(7)(a) is unsettled; set a trigger per row and record why.

## Scoping a breach in the first hour

When something goes wrong, the Board wants the nature, extent, timing and location of the breach and its likely impact, without delay (Rule 7(2)(a)). Each affected person must be told what happened and the consequences relevant to her (Rule 7(1)). With a current map, the first hour of an incident can answer:

- Which system is affected, and which rows sit on it?
- Which people and data items are involved, and roughly how many?
- Are children's records, health, financial or identity data among them?
- Which processors hold copies, and who must be called?
- Which channel do we have to reach each affected person?

Without the map, those answers take days, and the detailed report is due within 72 hours of becoming aware (Rule 7(2)(b)). The [breach response guide](/dpdp-breach-response) has the full playbook.

## An NGO maps a livelihoods programme

This illustration is a composite, not a client story.

A 120-person NGO runs a women's livelihoods programme across four districts. Its MIS vendor, an SMS gateway and Google Workspace are known. Week 1's payments ledger adds a survey tool bought on a manager's card, a freelance data-entry operator paid by bank transfer, and a printing firm that receives names for ID cards.

The interviews in week 2 find that cluster coordinators collect loan-group registers on paper, photograph them, and post them to a WhatsApp group of 31 members, eight of whom have left. The fundraising team keeps beneficiary photos and stories in a personal drive. HR uses a background-verification agency that nobody had listed.

In week 3 the sweep finds 14 spreadsheets shared by open link, one with 9,000 members' mobile numbers and bank account details, exported from the MIS for a bank linkage drive two years earlier.

In week 4 the owners decide. The WhatsApp group is closed and replaced by in-app capture; the photos on coordinators' phones are erased, with a short record signed by each. The open spreadsheets are restricted; the bank export is erased because the drive ended. The survey tool, the data-entry operator and the printing firm go on the contracts list. The photos and stories need separate consents, so they go into the re-consent campaign. The map has 46 rows, nine flagged for children (adolescent girls in a skilling component), and a gap list the director reviews every fortnight until May 2027.

## Where the law is unclear on mapping

We hold these positions until the Board or the courts say otherwise; each gives its reason so you can test it.

**Must the map be written down?** The Act does not require a register by name. We treat a written, dated map as close to essential. *Why:* section 8(4) asks for organisational measures to ensure observance, section 11(1)(b) needs a list of recipients, and showing that your safeguards were reasonable (s. 8(5)) is difficult if you cannot show what you knew you held. *Would change if:* rules or Board guidance prescribe a register, which would make a format mandatory. *Confidence:* high that you need one in practice; the format is open.

**Does section 11(1)(b) include sub-processors?** We list them. *Why:* the text covers processors "with whom the personal data has been shared by such Data Fiduciary". A sub-processor receives data through your processor, so a narrow reading leaves it out, but the fiduciary answers for processing done on its behalf (s. 8(1)), and a person asking who has her data is poorly served by "our vendor's vendor". *Would change if:* the Board accepts a fiduciary-level list only. *Confidence:* medium.

**How much does the map need to cover data processed under section 7(i) or other legitimate uses without consent?** All of it. *Why:* the access and erasure rights apply only to data given by consent or under section 7(a) (s. 11(1), s. 12(1)), but security, breach notice and retention apply to everything (s. 8(5)–(7)). *Would change if:* nothing foreseeable. *Confidence:* high.

**When does the Rule 8(3) one-year period start?** From the processing, which we read as the last active use for the purpose. *Why:* storage is itself processing (s. 2(x)), so a literal reading would restart the clock every day the data sits in storage and never end. *Would change if:* guidance defines the trigger. *Confidence:* low.

**Is pseudonymised data out of scope?** Not if anyone can re-identify it. *Why:* personal data is data about an individual "identifiable by or in relation to" it (s. 2(t)), and the Act has no anonymisation standard. Map pseudonymised analytics data with its key holder. *Would change if:* a standard for anonymisation is published. *Confidence:* medium.

## Your first two weeks, starting now

Starting on Monday 2 November 2026 leaves six months of slack before 13 May 2027.

1. Name the lead and give her two days a week for four weeks.
2. Ask finance for the 24-month vendor list and IT for the sign-on app list this week.
3. Book 45-minute interviews with every team head and one practitioner per team.
4. Set up the template with version history, and enter rows during interviews.
5. Announce an amnesty for personal-device and WhatsApp data, with a reporting form.
6. Freeze new tools: no new vendor touches personal data without a row in the map and a contract.
7. At the end of week 4, send the gap list to the board or trustees, with owners and dates.

Then keep it alive. A map that is right on 13 May 2027 and wrong by August is the version the Board will see after a breach.

**How we wrote this guide.** We worked from the Digital Personal Data Protection Act, 2023, the Digital Personal Data Protection Rules, 2025 (G.S.R. 846(E), as corrected by G.S.R. 892(E)) and the commencement notification G.S.R. 843(E), last checked 25 October 2026. The four-week plan, the scaling estimates, the template, the interview questions and the timings are our method and estimates, not requirements of the law. Statements marked as our view or recommendation are judgement. This guide explains the law; it is not legal advice.
{: .note }

## Questions people ask

### Is a data map the same as a GDPR record of processing activities?

It covers similar ground, but the DPDP Act does not require a written record of processing in the way GDPR Article 30 does. What the Act requires are outputs the map makes possible: itemised notices (Rule 3(b)), the access summary and list of recipients (s. 11(1)), erasure across processors (s. 8(7)) and breach details (Rule 7). If you already keep a GDPR record, extend it with the DPDP basis (consent or a clause of section 7), a children flag, Scheduled-language notice versions and the Rule 8(3) one-year floor.

### Should we buy a data discovery tool before we start?

Not first. Scanning tools find files in systems you already know about, such as cloud drives, mailboxes and databases, and they are good at spotting Aadhaar numbers, PAN and phone numbers. They do not find a WhatsApp group on a field officer's phone, a register photographed into a personal gallery or a vendor nobody listed. Our recommendation is to run the interviews and the payments-ledger check first, then point a scanner at the drives and mailboxes the interviews identified. The search built into common office suites is often enough for a first pass.

### How detailed should the data items be?

Detailed enough to write the notice and answer an access request. Rule 3(b)(i) asks for an itemised description of the personal data, so 'contact details' is too coarse; 'name, mobile number, village, Aadhaar number (last four digits kept)' is about right. List fields, not every column: group a hundred CRM columns into the ten categories a person would recognise, and flag any field that reveals health, finances, caste, religion, biometrics or a child's age.

### How do we map data we hold as a processor for clients?

Keep it in a separate part of the map, one row per client and service, with the client named as the Data Fiduciary (s. 2(i)). Record what you hold for it, where, which sub-processors receive it, the contract and its breach-notice window, and how you would export or erase that client's data on instruction (s. 8(7)(b)). Data you use for your own purposes, such as billing, product analytics or your own marketing, goes in your fiduciary rows, because there the duties are yours.

### Can our ISO 27001 asset register or GDPR record be the map?

It can be the starting point, not the finished map. An ISO/IEC 27001 asset register lists information assets and owners for security; it usually has no purpose, legal basis, retention trigger or recipients per person. ISO/IEC 27701 adds privacy controls and has been a standalone certifiable standard since its 2025 edition, but no certificate is required by the Act. A GDPR record is closer. Either way, add the DPDP columns: section 7 clause or consent, children flag, lookup identifier (Rule 14(1)(b)), notice version and the Rule 8(3) floor.

## About Commons Trust

Commons Trust is a DPDP compliance programme and consent management platform from commons.inc that takes nonprofits, foundations, startups and corporates from wherever they are to fully compliant with India's Digital Personal Data Protection Act. Contact: hello@commons.inc · https://dpdp.commons.inc/#start