Data Mapping and Records of Processing Under the DPDP Act: Why Spreadsheets Aren't Enough

Hero Summary

A data map is a living record of what personal data an organization holds, why, where it is stored, how it flows, and who can access it. A "record of processing activities" (RoPA) is a structured version of that record. The EU's GDPR explicitly requires many organizations to keep a RoPA (Article 30); India's DPDP Act, 2023 does not use that term, but nearly every DPDP obligation — notices, consent, security, breach response, retention, erasure, rights requests, vendor management — depends on knowing what data you have and where it is. A current data map is therefore the foundation of DPDP readiness.

Executive Summary

Most DPDP obligations cannot be met without a data inventory. You cannot notify individuals about purposes you have not listed, respond to an erasure request without knowing where copies are, assess a breach without knowing what was in the affected system, or govern vendors you have not identified. This guide explains the difference between a data inventory, a data flow map, and a RoPA, what DPDP does and does not require, how to build a data map step by step, and why spreadsheets tend to fail and what to do instead.

Data inventory, data map, and RoPA {#terms}

• Data inventory: a list of the personal data assets an organization holds — systems, databases, files, and the categories of data in them.
• Data flow map: a picture of how personal data moves — where it is collected, transferred internally, shared with processors and third parties, and sent abroad.
• RoPA (record of processing activities): a structured register, usually one entry per processing activity, recording the purpose, data categories, data subjects, recipients, transfers, retention period, and security measures.

The three overlap and are usually maintained together.

Does DPDP require a RoPA? {#required}

The DPDP Act does not use the term "record of processing activities" and does not contain a GDPR-style Article 30 obligation to maintain one in that form. That does not make a data map optional in practice. The Act and Rules place obligations on data fiduciaries that can only be met if the organization knows what data it processes, for what purpose, and where. The Government of India's explainer describes the DPDP Act as resting on seven principles — consent and transparency, purpose limitation, data minimisation, accuracy, storage limitation, security safeguards, and accountability — and evidencing these principles requires records. Organizations that also serve people in the EU will already be familiar with the GDPR's RoPA requirement.

What a useful record contains {#contents}

Field	Why it matters for DPDP
Processing activity and owner	Accountability — someone is responsible for it
Purpose	Notices, consent, and purpose limitation
Lawful basis (consent or legitimate use)	Consent management and defensibility
Categories of personal data	Minimisation, security, and breach assessment
Categories of individuals (customers, employees, children)	Special rules, such as for children's data
Systems and locations where data is stored	Security, erasure, and cross-border analysis
Recipients, processors, and third parties	Vendor governance and breach flow-down
Transfers outside India	Cross-border requirements
Retention period and disposal method	Storage limitation and erasure
Security measures	Evidence of reasonable safeguards

How to build a data map {#build}

1. Set scope and owners. Appoint a lead and nominate a contact in each business function — HR, marketing, sales, finance, product, IT, and customer support.
2. List systems and processes. Start with systems of record (CRM, HRMS, ERP, billing, ticketing, marketing tools, website and app analytics) and then find the less obvious: spreadsheets, shared drives, email, and shadow IT.
3. Interview and discover. Ask each function what personal data it collects, why, and where it goes. Supplement interviews with technical discovery, because people forget systems and trackers.
4. Record each processing activity in the fields above.
5. Trace flows between systems, to vendors, and across borders.
6. Identify risks and gaps — data with no purpose, unlimited retention, vendors with no contract, sensitive data with weak controls.
7. Assign remediation owners and track the gaps to closure.
8. Review with the business and legal, and approve the record.

Why spreadsheets fail {#spreadsheets}

A spreadsheet is a reasonable starting point and a poor long-term answer:

• It is out of date almost immediately — new tools, new vendors, and new data fields appear weekly.
• It depends on people remembering to update it, and nobody owns the whole picture.
• It records what people believe is happening, not what systems actually do — for example, tracking scripts added to a website without the privacy team knowing.
• It does not connect to evidence such as scan results, contracts, or decisions.
• It does not scale across many entities, systems, and vendors, or support workflows like rights requests and incident handling.

Keeping the map current {#current}

• Tie updates to change processes: new systems, new vendors, and new features should not go live without an entry or update.
• Use technical discovery to find data and third-party connections that people have not recorded.
• Review on a schedule — at least annually — and after major events such as acquisitions or system migrations.
• Make one function accountable for the record and each business owner accountable for their entries.

How the map supports other DPDP tasks {#uses}

• Notices and consent — you can list real purposes and data categories. See Consent Management Under DPDP.
• Breach response — you can quickly tell what was affected. See Data Breach Response Under DPDP.
• Retention and erasure — you know where copies are. See DPDP Data Retention and Erasure.
• Vendor governance — you know which processors hold what. See Third-Party and Vendor Risk Management Under DPDP.
• Cross-border transfers — you can see what leaves India. See Cross-Border Data Transfers Under DPDP.
• The overall program — see the DPDP Compliance Checklist.

How Threat ResQ fits {#threat-resq-fit}

PrivacyIQ, Threat ResQ's privacy management platform, provides a data inventory covering data assets, processing activities, and data flows, with technical discovery that observes what a website exposes over plain HTTP, explainable findings mapped to DPDP obligations, and evidence. Browser-level (JavaScript-executing) discovery is on its roadmap and is not currently available. PrivacyIQ is a platform that supports a privacy programme: it is not a certifying authority, and it does not grant or imply a "DPDP compliant" status. getTRAC automates evidence collection and control mapping across frameworks, and Threat ResQ's Compliance Consulting service supports regulatory readiness.

FAQ {#faq}

What is a record of processing activities (RoPA)? A structured register of an organization's personal data processing activities, recording purposes, data categories, individuals, recipients, transfers, retention periods, and security measures. GDPR Article 30 requires many organizations to keep one.

Does the DPDP Act require a RoPA? The DPDP Act does not use that term or contain a GDPR-style Article 30 obligation. But most DPDP obligations depend on knowing what personal data you hold and why, so a data map or inventory is a practical necessity.

What is the difference between a data inventory and a data flow map? An inventory lists personal data assets and the systems that hold them. A flow map shows how data moves between systems, to vendors, and across borders.

Why isn't a spreadsheet enough? It goes out of date quickly, depends on manual updates, records beliefs rather than what systems actually do, and does not link to evidence or support workflows like rights requests and incident handling.

How often should a data map be reviewed? Continuously updated through change processes, and formally reviewed at least annually and after major changes such as acquisitions or migrations.