Finding your personal data before you govern it

Data discovery finds where personal data sits. Data mapping records what it is for, where it goes and when it should leave. The DPDP Act never uses either term, but several of its duties cannot be done without the output: the notice, purpose-limited consent, access requests and erasure all depend on knowing what you hold.

What the Act needs from an inventory

Four provisions each need a fact an inventory supplies.

• Sec. 5 and Rule 3 require a notice giving an itemised description of the personal data and the specified purpose. You cannot itemise what you have not found. See consent notice requirements.
• Sec. 6(1) limits consent to the personal data necessary for the specified purpose. That needs a link from each data item to a purpose.
• Sec. 8(7) and Rule 8 require erasure on withdrawal or when the purpose is no longer served, and require you to cause processors to erase too. That needs to know which processors hold which copies.
• Sec. 11 gives the Data Principal a right to a summary of the personal data being processed and the identities of those it was shared with. An inventory is the source of that summary.

The Act stops there. No section prescribes the form of a record of processing, so what follows is practice, not statute.

Discovery and mapping are different jobs

Discovery is technical. A scanner connects to a database, bucket, mailbox or SaaS app and classifies what it finds: names, phone numbers, Aadhaar-format numbers, PAN, addresses, free-text fields. It finds the surprises, such as a CSV export in a shared drive, a debug log with full request bodies, a test database copied from production.

Mapping is organisational. For each processing activity it records:

• the purpose, and the ground for it (consent under Sec. 6 or a Sec. 7 legitimate use);
• the categories of data and of Data Principals;
• the system that holds it and the people with access;
• recipients, including each Data Processor;
• the retention period and the erasure mechanism;
• the international transfers, if any.

Tools can do most of the first job and help with the second. A person who knows the business has to supply purpose and retention, since no scanner can infer why you collect a field.

What to inventory

Start with the places the data enters: web forms, mobile apps and their SDKs, call centres, branches, paper forms, partners, and public sources. Then the places it ends up. The commonly missed ones are:

• application and access logs, which Rule 6(1)(e) and Rule 8(3) require you to keep for one year;
• backups and analytics warehouses;
• email and chat, where staff paste data;
• exports and spreadsheets;
• test and staging environments;
• processor-side copies.

Record children's data separately, since Sec. 9 and Rules 10 to 12 attach extra duties to it. Record the Data Processors too, because the vendor register is a subset of the map.

Criteria for choosing a tool

No ranking is offered here, and be wary of any list that offers one. Ask these questions.

1. Coverage. Does it connect to the stores you have: your databases, your cloud storage, your SaaS tools, your file shares? A tool covering 60 percent of your systems leaves the rest as before.
2. Accuracy on your data. Run it on one real system. Check false positives and misses on Indian identifiers, names in Indic scripts, and free text.
3. Where it processes. Does it read data in place and send only metadata, or copy data to the vendor's cloud? The second makes the vendor a Data Processor under Sec. 8(2) and needs a contract with security terms under Rule 6(1)(f).
4. Its own security. The scanner holds credentials to every store. Ask about access control, logging and how credentials are held.
5. Output you can use. Can findings flow into your records of processing, or only into a report? A one-time scan that goes stale in a quarter is a weak result.
6. Rescans and change detection. New tables and fields appear constantly.
7. Who does the mapping work. If the tool leaves purpose and retention blank, you still own them.

From scan to record

A reasonable sequence: list systems by hand first, scan the highest-risk ones, reconcile what the scan found against the list, and turn each confirmed activity into a row with a purpose, owner and retention. The records-of-processing module in MyConsent+ is built for the second half of that sequence. It holds the map; it does not replace a scanner for finding unknown stores.

Keep the map alive by tying it to change. New vendor, new field, new purpose: each updates a row. Compliance by design covers where in the release process that update belongs.