How to Build a Data Inventory for DPDP Compliance

Most data inventories start the same way.

Someone creates a spreadsheet.

Columns:

System
Data type
Owner
Vendor

Then the team fills it in during a workshop.

Privacy has one version.

Engineering has another.

Security has an architecture diagram.

Finance has a vendor list.

Six months later, none of them match production.

That is the problem.

A data inventory is useful only when it reflects the environment that actually exists.

For DPDP, the inventory needs to answer more than:

"What data do we have?"

It needs to answer:

What personal data do we process, why do we process it, where does it go, who can access it, how long should it remain, and what happens when the purpose or legal basis changes?

A RoPA can be a useful output, but the operational inventory comes first.

For discovery, see our DPDP Data Mapping guide.

Data inventory vs data map vs RoPA

These terms are often mixed together.

They are related, but not identical.

Data inventory

The catalogue of data assets and personal-data elements.

Example:

users.email
users.phone
orders.billing_address
s3://exports/customer.csv
analytics.user_id

Data map

The inventory plus relationships.

For example:

User email
   ↓
Application DB
   ↓
CRM
   ↓
Email provider

RoPA

A structured record of processing activities focused on context such as:

• Purpose
• Data categories
• Data Principal categories
• Recipients
• Transfers
• Retention
• Controls

The DPDP framework should not be reduced to:

"Create a RoPA spreadsheet and you are compliant."

A current processing inventory is an operational tool.

The compliance program is the processes and controls built around it.

Step 1: Define what you are inventorying

Do not start with:

Customers.

Start with data elements and processing activities.

Identity

• Name
• Aadhaar-related information
• PAN
• Passport
• Date of birth

Contact

• Email
• Mobile
• Address

Financial

• Bank account information
• Payment references
• Transaction information

Device and technical

• IP address
• Device identifier
• Session identifier

Behavioural

• Product events
• Search history
• Clicks
• Recommendations
• Feature usage

User-generated

• Support messages
• Comments
• Uploaded documents
• Chat transcripts

Then identify the systems where each category appears.

Step 2: Inventory systems before fields

Start broad:

Product
Marketing
Sales
Support
Finance
Security
Engineering
HR
Operations

Then list systems.

Example:

Marketing
├── CRM
├── Marketing automation
└── Advertising

Support
├── Intercom
└── Freshdesk

Engineering
├── PostgreSQL
├── S3
├── BigQuery
├── Sentry
└── CloudWatch

Then determine which systems actually contain personal data.

Step 3: Discover systems from reality, not memory

Workshops are useful.

They should not be your only discovery method.

Combine:

Cloud inventory

Discover resources directly from your cloud account.

Codebase inspection

Search for:

• SDKs
• API endpoints
• Vendor domains
• Event destinations

Network signals

Look for external destinations receiving data.

SaaS and SSO inventory

Find applications connected to company identity systems.

Finance and procurement

Find vendors who were paid but never entered the privacy inventory.

Data discovery

Scan the actual content.

This is how you find the systems nobody remembers.

Step 4: Add purpose to every activity

Do not write:

Email — CRM — Sales

Write:

Email address — CRM — lead management and sales communication

Then ask:

• Why is the purpose needed?
• Is the data necessary?
• Is consent used?
• Is another lawful basis or legitimate use relevant?
• Is the purpose reflected in the notice?
• Which systems receive the data?

For every important processing activity, there should be an owner who can explain why it exists.

Step 5: Record the Data Principal category

Examples:

• Customer
• Trial user
• Employee
• Job applicant
• Parent
• Child
• Merchant
• Borrower
• Vendor contact

This helps separate ordinary workflows from situations involving additional obligations, such as children's data under Section 9.

It also makes rights workflows easier to route.

Step 6: Record the applicable basis

Do not label every processing activity "consent."

Section 4 requires a lawful purpose and permits processing based on consent or certain legitimate uses. DPDP Act 2023

For each activity, record the applicable route.

Examples:

Marketing email
→ Consent

Account operation
→ Relevant legitimate use / applicable basis

KYC required by law
→ Applicable legal requirement

Medical emergency
→ Relevant legitimate use

The exact classification depends on the processing.

The point is to make the reasoning visible.

Step 7: Record recipients

For each processing activity, list:

Internal recipients

• Product
• Engineering
• Support
• Finance

External recipients

• Data Processors
• Other Data Fiduciaries
• Service providers
• Regulators, where applicable

For SaaS:

User email
  ↓
Application
  ├── CRM
  ├── Email provider
  ├── Support platform
  └── Analytics

The inventory should make those relationships explicit.

Step 8: Track location and transfers

For each system, record:

• Country of incorporation
• Data storage location
• Material processing location
• Cross-border status
• Relevant contractual restrictions
• Sector-specific restrictions

Section 16 allows the Central Government to restrict transfers to specified countries or territories, while other Indian laws can impose stronger restrictions in particular contexts. DPDP Act 2023

Do not infer location from the company's headquarters.

Look at the actual service configuration.

Step 9: Define retention by purpose

Do not write:

Customer data — 7 years

That is too broad.

Instead:

The final Rules also include specified retention requirements for particular classes and purposes and a minimum one-year requirement for specified processing data and logs used for listed security purposes. DPDP Rules 2025

The inventory should capture those rules where they apply.

Step 10: Add the deletion mechanism

A retention policy without a deletion mechanism is just a sentence.

For each location, record:

Deletion method:
API / scheduled job / lifecycle policy / manual / retention exception

Owner:
Platform

Trigger:
Erasure request / purpose expiry / account closure

Verification:
System response + re-scan

Evidence:
Timestamp + result

This is where an inventory becomes operational.

Step 11: Add access information

For each material data location:

• Owner
• Team access
• Service accounts
• Privileged users
• External access
• Audit logging

Rule 6 requires appropriate access controls and visibility through logs, monitoring and review. DPDP Rules 2025

You do not need to turn the inventory into an IAM system.

You do need enough context to understand exposure.

Step 12: Track processor relationships

For every external system, ask:

Are they processing on our behalf?

Are they determining their own purposes?

What does the contract say?

What actually happens in production?

Then record:

• Vendor
• Role
• Purpose
• Data categories
• Contract
• Sub-processors
• Location
• Deletion
• Breach pathway

See How to Map Data Flows to Third-Party Processors Under DPDP.

Step 13: Use a simple inventory schema

A practical starting schema:

You do not need 100 columns.

Start with the fields people will actually maintain.

Step 14: Make the inventory change-aware

This is where most inventories fail.

A developer adds:

alter table users add column aadhaar_hash text;

What happens?

The inventory should eventually know:

New field
   ↓
Potential personal data
   ↓
Review
   ↓
Purpose
   ↓
Retention
   ↓
Owner

Likewise:

New SaaS vendor
   ↓
Processor discovery
   ↓
Data categories
   ↓
Contract review
   ↓
Deletion path

You do not need perfect automation on day one.

You need a trigger that stops the inventory going stale.

Step 15: Reconcile technical and legal views

Run a periodic reconciliation.

Engineering says:

23 systems contain customer data.

Procurement says:

31 vendors touch customer data.

Privacy says:

14 processing activities.

These numbers can all be true.

But they need to connect.

The inventory is where they reconcile.

The minimum viable inventory

For a startup, begin with:

System
Data category
Data element
Purpose
Data Principal category
Applicable basis
Processor / recipient
Location
Retention
Deletion method
Owner
Last verified

Then add:

• Sub-processors
• Access
• Risk
• Consent state
• Evidence
• Lineage
• Regulatory references

as maturity increases.

Common mistakes

Mistake 1: Starting with a legal workshop.

You get the documented view, not the technical one.

Mistake 2: Treating systems as data categories.

"CRM" is a system. Email, phone, documents and transaction information are data.

Mistake 3: One retention period for everything.

Different purposes create different retention logic.

Mistake 4: No processor relationship.

A system name without the downstream relationship tells you little.

Mistake 5: No owner.

An inventory nobody owns becomes a dead spreadsheet.

Mistake 6: No verification date.

You do not know whether the row is still true.

Mistake 7: No connection to action.

The inventory should feed consent, rights, erasure, vendor management, security and evidence.

The self-test

Open your current inventory.

Pick one row.

Ask:

1. Is the data actually there?
2. Why is it there?
3. Who can access it?
4. Who receives it?
5. Where else does it flow?
6. How long should it remain?
7. How is it deleted?
8. When was it last verified?
9. What happens if the purpose changes?
10. What happens if the Data Principal exercises a right?

If the row cannot answer these questions, it is not yet an operational inventory.

Where Privra fits

Privra turns infrastructure discovery into a continuously maintained data inventory.

Our AI agents discover personal data across databases, storage, analytics, logs and third-party systems, then connect those findings to purpose, processors, retention, ownership and remediation.

The result is not another spreadsheet.

It is a living map of what your company is actually doing with personal data.

Talk to Privra about continuous data inventory and DPDP compliance.

This article is general information, not legal advice. Legal requirements and Privra's recommended implementation practices are intentionally distinguished.