Consiva takes what discovery found and what consent recorded, and builds the map: which personal data, held in which system, for which declared purpose, shared with which processor, under which retention position. The layer between a list of columns and a register you can defend.
Discovery gives you a list: 214 columns across three databases, classified by type. Useful, and not yet an answer to anything.
The questions that follow are all about purpose. Why do we hold this? Which notice told her we would? If she withdraws consent for marketing, which of these columns is affected and which is not? If the specified purpose has been served, which of these should have been erased already? None of those are answerable from a list of columns.
DPDP is built around purpose in a way that makes this unavoidable. Consent is valid only for the specified purpose, and is limited to the personal data necessary for it. Erasure is triggered when the specified purpose is no longer being served. Notice must state the specified purpose with a specific description of the goods, services or uses enabled. A data inventory with no purpose layer cannot support any of those.
From a raw finding to a versioned, purpose-mapped entry — shown here as a workflow before the detail below.
This is the mapping view. Each system is linked (or not) to the data source that feeds it and the processor that runs it. The rows worth looking at are the ones with a red flag — like Customer CRM here, which holds 214 discovered data assets with no processor mapped and no declared purpose. Selecting a system shows the chain behind it: which data source it draws from, which processor (if any) is involved, and whether a purpose has actually been declared. An unmapped system is both a Section 5 notice problem and a Section 8(7) erasure question waiting to surface.
Purposes are not inferred. They are yours, and the map records where each one is declared:
| Purpose source | What it establishes |
|---|---|
| Consent notice purposes | The purpose as presented to the Data Principal, tied to a notice version |
| Cookie and tracker purpose categories | The purpose a tracker was classified under |
| Manual declaration by a business owner | A purpose asserted by a named person, labelled as manual |
Per mapping: the data category or system · the declared purpose · the notice version that declared it · systems and processors involved · retention position · source of the underlying finding · the person who confirmed the mapping, and when.
Per version: a dated snapshot of the map, so a decision taken in March can be evidenced against March's map rather than today's.
Per gap: unattributed personal data, with an owner and an open date.
An EdTech company declares four purposes in its notices: account and service delivery, learning analytics, parent communication and marketing. Discovery finds personal data in 38 places across two databases.
Mapping reveals that 31 map cleanly to a declared purpose. Of the remaining seven, five are legacy columns from a discontinued tutoring feature and two are a set of guardian contact details written by a support tool into a system that no notice covers. The five legacy columns become an erasure decision under Section 8(7), because the specified purpose is demonstrably no longer being served. The two guardian columns become a notice problem to fix before the next term, since guardian data collected without a covering purpose is not something to leave mapped as a gap indefinitely.
Illustrative. Not based on a named Consiva customer.
Software that connects personal data to the purposes it is held for, the systems it moves through and the processors that receive it. It sits between discovery, which finds the data, and a processing register, which evidences it. The distinguishing feature is the purpose layer: an inventory tells you what you hold, a map tells you why.
Findings from discovery and tracker scans are matched against the processing purposes you have declared in your notices. Each mapping records the purpose, the notice version that declared it, the systems and processors involved and the retention position. Data present in the evidence with no declared purpose is surfaced as a gap with an owner rather than omitted. The map is versioned, so a decision can be evidenced against the map as it stood at the time.
Because DPDP is a purpose-centred statute. Consent is valid only for a specified purpose and only for the personal data necessary for it (s.6(1)). Erasure is triggered when the specified purpose is no longer being served (s.8(7)). Notice must state the purpose with a specific description of what it enables (Rule 3(b)(ii)). Each of those requires a defensible link between a data element and a purpose, which is exactly what a map is.
Most of the saving is in maintenance and in scoping. Manual maps are rebuilt by interview and decay immediately; a generated map updates as discovery and scanning repeat, and tells you which mappings changed. The scoping saving shows up when a withdrawal or erasure request arrives — the map already identifies which data is affected by which purpose, so the request is scoped rather than investigated.
An inventory is the list — what personal data exists and where. A map is the inventory plus purpose, flow and processors. Consiva produces both: discovery generates the inventory, mapping adds the purpose layer, and ROPA generates the register you would hand an auditor. They are sold as one Enterprise capability because in practice none of the three is useful on its own.
Enterprise, alongside Data Discovery and ROPA generation. Pro excludes all three.
Enterprise plan — the purpose layer between an inventory and a register you can defend.