Find the personal data you hold, classify it, map where it flows, and hold it to a retention schedule that the system can act on. Runs standalone, and shares onboarding data with every other module.
Scans locate personal data across databases, applications and platforms, including the copies nobody documented. The exports on a shared drive, the staging database restored from production two years ago, the spreadsheet a team keeps because the system does not do what they need. Those are the copies that turn a request into a fire drill.
The tool classifies what it finds, so the difference between a marketing list and a set of financial identifiers is visible without a manual review. Classification drives everything downstream: what safeguards apply, how long it may be kept, and whether a flow into a new system is routine or needs a decision.
A visual record of processing activities: what is held, where it lives, how it is used, and which departments and vendors it flows to. Each flow is tied to the purpose it serves, so a purpose that no longer exists is visible as data still moving for a reason nobody can name.
Where a flow relies on consent, it is linked to the purpose in Module 1 rather than described separately. Two systems of record for the same fact will disagree eventually, and the disagreement surfaces at the worst moment: under a request, or under an audit.
Every category carries a retention period and the basis for it. The schedule is a property of the data rather than a paragraph in a policy nobody reads, so the question of whether something should still be held has an answer the system can act on rather than one requiring a meeting.
When consent is withdrawn or the purpose is served, erasure runs across every mapped location, including the copies outside the primary store, and each one acknowledges. An erasure that missed the warehouse copy is not an erasure, and the acknowledgements are what turn the claim into a record.
The DPDP Act contains no Article 30-style obligation to maintain records of processing activities, and we are not going to invent one. Sec 11(1)(a)–(b) gives every Data Principal the right to a summary of their personal data and the identities of everyone it has been shared with, and Sec 10 imposes audits on Significant Data Fiduciaries. Neither is answerable without a maintained record.
So the record exists because two obligations require it in practice, not because a third one names it.
A Data Principal is entitled to a summary of their personal data and the identities of everyone it has been shared with. If the map is current, that is a query. If it is not, it is a fortnight of asking colleagues what they hold.
Significant Data Fiduciaries face audits and Data Protection Impact Assessments. Both start from an accurate picture of processing, which is why the DPIAs in Module 4 sit on these flows rather than on a description of them written from memory.
A rescan that finds personal data in a system the map does not cover raises it. Estates do not stay mapped on their own; the useful property of a record is that it notices when it has stopped being true.
