A DPDP data inventory should answer a practical question: what digital personal data does the organisation process, for what purpose, through which systems and people, and what happens next? A list of databases cannot answer that. Neither can a privacy policy copied into a spreadsheet.
Build from primary sources. The Digital Personal Data Protection Act, 2023 supplies the statutory framework and definitions. MeitY’s final Rules collection includes the Rules, corrigendum, and enforcement timeline. Because commencement is phased, record the date and source used for each operational conclusion. This guide describes an inventory method, not a legal determination that every field is required in every situation.
What is a DPDP data inventory meant to achieve?
The inventory connects legal and privacy decisions to operational reality. It helps teams find collection points, understand purposes, trace recipients, coordinate requests, investigate incidents, apply retention, and review providers. It should be detailed enough to drive those tasks without becoming an uncontrolled duplicate of the underlying personal data.
The unit of work is usually a processing activity or data journey, not a server. “Customer support” is more useful than “CRM database” because the activity captures collection, agents, ticketing, attachments, analytics, exports, providers, retention, and deletion together. One system may support several purposes, and one purpose may cross many systems.
The NIST Privacy Framework treats inventory and mapping as part of understanding privacy risk. It is voluntary guidance, not an Indian legal source, but its system, product, service, owner, and data-flow perspective can improve discovery.
Which fields belong in a usable inventory?
Start with fields that support a decision or workflow. Avoid collecting details simply because a template has a column.
| Field | Why it matters | Verification source |
|---|---|---|
| Activity and owner | Gives the record a business context | Owner interview and process map |
| Data-principal context | Distinguishes customer, worker, applicant, user, or other context | Live journey and policy |
| Personal-data categories | Supports notices, requests, security, and minimisation | Forms, schemas, samples |
| Source and collection point | Shows how data enters | Interface, API, import, provider |
| Purpose and approved analysis | Explains why processing occurs | Decision record from responsible reviewers |
| Systems and recipients | Traces internal and external movement | Architecture and access evidence |
| Retention trigger and action | Connects policy to deletion | Configuration, job, and test |
| Notice or consent record | Links experience to approved communication | Version and deployment record |
| Security and access | Identifies control owners and exposure | IAM, logging, encryption evidence |
| Change and review date | Prevents silent staleness | Release, renewal, or scheduled review |
Use controlled vocabularies for recurring values such as business function, data category, environment, and record status. Keep a notes field, but do not allow free text to replace structured facts.
How do you discover data that teams have forgotten?
Begin with business journeys and follow the data. Watch a user create an account, open a support case, apply for a job, receive marketing, or close a service. Ask what happens before and after each visible step. Inspect interfaces, API documentation, event streams, warehouse tables, file shares, ticket attachments, email exports, spreadsheets, backups, and service-provider consoles.
Interview questions should invite examples:
- What information do you need to complete this task?
- Where does it arrive, and can it arrive another way?
- Which tools receive a copy or derived value?
- Who can view, export, correct, or delete it?
- What happens when the account, employment, or contract ends?
- Which reports, logs, models, or analytics use the information?
- What breaks if the information is removed?
- Which recent product or vendor change altered this flow?
Compare answers with technical evidence. Interviews reveal context, while system evidence reveals forgotten transfers and implementation gaps. Neither is sufficient alone.
How should a team map providers and onward movement?
Do not stop at the first external vendor. Record the service, business owner, contract owner, categories handled, access method, relevant locations, subprocessors where applicable, integration, retention, deletion or return process, security review, and change triggers. Link rather than duplicate the underlying contract and diligence evidence.
A practical workflow is:
New or changed provider → business intake → data-flow update → privacy and security review → contract review → approval → access configuration → reassessment date → exit verification
At renewal, confirm actual usage. A provider may have been approved for one purpose and later integrated into another workflow. At exit, verify accounts, keys, exports, scheduled jobs, retained copies, and deletion or return evidence according to the approved plan.
When evaluating Gotham as one component, use its security information, privacy information, and current contractual materials as diligence inputs. They do not replace the organisation’s own provider assessment.
How can an inventory support notices and individual requests?
Link every material collection point to the approved notice version, language, deployment location, purpose record, and owner. MeitY’s explanatory note describes the notice approach in accessible terms, while also warning that the note is not part of the Rules and is not for legal interpretation. Use the final legal text and advice for the actual design.
For requests, the inventory becomes a search plan. It tells the case owner which systems, providers, teams, and archives may hold relevant records. Add system contacts and supported actions such as search, correction, export, restriction by policy, or deletion. Do not store full request results inside the inventory.
Test with synthetic cases. Choose a representative user journey, then ask system owners to locate relevant records. Compare actual findings to the inventory. Record missed systems, ambiguous identifiers, and manual dependencies as remediation work.
How do you connect retention rules to technical deletion?
“Retain for X years” is not operational until a trigger and system action are defined. A trigger might be account closure, contract end, ticket resolution, recruitment decision, or another approved event. Document when the clock starts, what pauses or overrides it, which copies are included, who approves exceptions, and how deletion is verified.
Use a retention test record:
- Rule and decision owner are linked.
- Trigger is available and reliable in the system.
- Production records are selected correctly.
- Holds and approved exceptions are respected.
- Derived data, exports, and providers are addressed.
- Backup treatment is documented.
- The action produces reviewable evidence.
- A sample confirms the expected outcome.
Avoid inserting personal values into the compliance record. Keep case identifiers and links where feasible, with access limited to people who need them.
How often should inventory records be reviewed?
Use both scheduled and event-driven review. High-change or high-impact activities may need frequent checks. Stable activities may use a longer cycle, provided releases, incidents, provider changes, and new purposes trigger review immediately.
Useful status values are draft, owner-verified, privacy-reviewed, awaiting decision, change detected, and retired. “Complete” ages badly because it hides freshness. Display the last evidence date and next review date instead.
Trigger review when:
- a product feature or collection field changes;
- an integration, provider, or subprocessor changes;
- a new purpose or audience is introduced;
- access expands to a new team or location;
- an incident reveals an unknown copy;
- a request search misses a system;
- retention testing fails; or
- an official source, interpretation, or sector requirement changes.
What quality checks expose a weak inventory?
Sample records against reality. Select an activity and walk from collection through deletion. Select a provider and trace every connected purpose. Select a notice version and identify all live collection points. Select a data category and find systems, recipients, access roles, and retention. Select a departed user or employee scenario and test the approved lifecycle.
Measure verified coverage, freshness, unresolved owner conflicts, orphan systems, unlinked collection points, provider records past review, and failed deletion tests. Do not turn these into an unsupported “compliance score.” They are operational indicators with known populations and definitions.
Good governance also protects the inventory. Use role-based access, change history, backup, export, retention, and periodic permission review. Record decisions without turning the tool into a warehouse of sensitive source data.
For the workflow layer behind this work, see the related DPDP compliance software guide. Explore Gotham’s workflows, examine security and compliance information, or contact Gotham about connecting inventory records to accountable tasks and evidence. Qualified advisers should determine applicable requirements and statutory roles for the organisation’s facts.
