DPDP data inventory: map purpose, systems and owners

Map decisions, not just databases

A list of systems cannot explain why data is processed or what should happen when consent is withdrawn. Use one row or record per meaningful processing purpose and connect it to the data, people, source, destination and responsible owner.

Begin with customer, workforce, applicant, vendor and prospect journeys. Interview the teams that run them and validate the answers against forms, event schemas, integrations, processor consoles and retention jobs.

• Specified purpose and lawful ground.
• Data Principal group, data categories and collection source.
• Systems, processors, recipients and access owners.
• Notice or consent version, retention trigger and deletion method.

Use the map to test the notice

Rule 3 expects a standalone notice with an itemised description of personal data and the specified purpose. Compare each public notice with the current inventory to find hidden collection, vague purposes and secondary use that the user journey does not explain.

Where consent is the ground, connect the purpose to the affirmative action and withdrawal control. Where section 7 is relied on, record the exact legitimate use rather than a generic label such as legal basis or business need.

Keep ownership and evidence current

Assign a business owner who can confirm the purpose and a technical owner who can identify systems and execute change. Review records when a product launches, a processor changes, an incident reveals an unknown flow or the law changes.

Treat completeness as a managed risk rather than a one-time promise. Track unverified systems, stale records and unresolved owner questions, then prioritise the flows with the greatest volume, sensitivity or consequence for Data Principals.