Personal Data Inventory Under the DPDP Act: What It Is and How to Build One
A personal data inventory is the register that makes every other DPDP Act task easier: notices, consent, processors, erasure, rights requests and breach response all start by knowing what you hold. This guide shows what to record, in which fields, with examples, and gives you a free Excel workbook to start with.
A personal data inventory is a living register of the personal data your organisation processes, kept as one row per processing activity. For each row, record the data, whose it is, the specified purpose, the applicable basis (consent or a Section 7 legitimate use), the systems, the recipients and Data Processors, the retention trigger, the erasure route, an owner and a last-verified date. Start with 12 core fields, then add 16 extended fields where risk justifies them.
What the Act says: the DPDP Act does not name an inventory or prescribe its format. The register supports duties the Act does contain.
Where to start: the 12 core fields, for one high-volume process, then widen.
Free tool: the Data Inventory Workbook (Excel) has all 28 fields, drop-down lists, six worked rows and a summary tab.
Phase 1
Design the register
Pick the unit of record and the fields, core first.
Phase 2
Fill and verify
Seed the activities, name owners, fill the rows, check against real systems.
Phase 3
Use and maintain
Run rights, erasure and breach tasks from it and review on change.
What is a personal data inventory under the DPDP Act? A plain-language definition
A personal data inventory is a maintained register that records what personal data an organisation processes, about whom, for what purpose, where it sits, who receives it and when it must end. It is the “what we hold” record behind your notices, consent, vendor contracts, erasure and rights handling.
The Act defines personal data as “any data about an individual who is identifiable by or in relation to such data” (Section 2), and processing broadly, covering collection, storage, use, sharing and erasure. An inventory turns those definitions into rows you can search. It lists activities such as “order fulfilment” or “payroll”, not just databases.
What an inventory is
A register with one row per processing activity.
Owned by named people and dated when last verified.
Searchable: filter by basis, vendor, system or retention.
The input to data flow maps, notices and rights handling.
What it is not
Not a one-off audit that sits in a folder.
Not a list of databases or an IT asset register.
Not a statutory form. The Act prescribes none.
Not proof of compliance on its own. It supports it.
Two scoping points. First, we found no separate “sensitive personal data” category in the Act, so the register treats all personal data under one regime and uses a children’s flag because Section 9 sets distinct duties for a child’s data. Second, the Act covers digital personal data, including personal data collected in non-digital form and digitised later (Section 3), so a paper form that is later keyed into a system belongs in the register.
Several pages in this collection cover neighbouring topics. Use the one that matches your question and avoid reading three guides for one task.
An 8-step method, interview questions and a 30/60/90 plan.
What goes in the register, and how do I build it?
This page
The 28 fields, examples, lists, a quality test and the workbook.
The basics
Does the DPDP Act require a personal data inventory? What the law says and what the register supports
No provision of the DPDP Act or the DPDP Rules, 2025 that we found requires a Data Fiduciary to keep a personal data inventory. But several duties are hard to meet without knowing what you hold, which is why most compliance programmes build one.
Legal position
Treat the inventory as practical compliance infrastructure, not a statutory form. See is data mapping mandatory under the DPDP Act? for the full analysis. The right-hand column below is guidance on how a field helps, not a statutory requirement.
Duties in the Act and Rules, and the inventory fields that help you meet them
Provision
What it requires, in short
Fields that help
Sections 4(1), 5(1), 6
Process only on consent or a legitimate use; give notice describing the personal data and the purpose; consent must be free, specific, informed, unconditional and unambiguous.
Personal data categories; Specified purpose; Applicable basis; Notice reference
Section 6(10)
Where consent is the basis, the Data Fiduciary must be able to prove it if a question arises.
Consent record reference
Section 7
Certain legitimate uses allow processing without consent, for example employment purposes or a specified purpose the person voluntarily provided the data for.
Applicable basis; Section 7 clause
Sections 8(1) and 8(2)
The Data Fiduciary stays responsible for processing, including by a Data Processor, which may be engaged only under a valid contract.
Recipients and Data Processors; Processor contract in place?
Section 8(5) and Rule 6
Reasonable security safeguards for personal data in your possession or control, including with processors.
Systems and storage locations; Roles with access; Security safeguards
Section 8(6) and Rule 7
On a personal data breach, intimate the Board and each affected Data Principal; the Rules require detailed information to the Board within 72 hours or a longer period the Board allows.
Systems; Data Principal group; Personal data categories (to scope who was affected)
Sections 8(7) and 8(8), Rule 8
Erase when consent is withdrawn or the purpose is no longer served, unless law requires retention, and cause processors to erase. Rule 8 and the Third Schedule add time limits for named classes.
Verifiable consent before processing a child’s data; no processing likely to harm a child’s well-being; no tracking, behavioural monitoring or targeted advertising directed at children.
Children’s data?; Data Principal group
Sections 11 and 12
Data Principals can seek a summary of their data and processing, the identities of those it was shared with, and correction or erasure.
Recipients and Data Processors; Rights request route; Systems
Section 16(1)
The Central Government may restrict transfers to notified countries or territories outside India.
Transfer outside India?
The basics
One row per processing activity: choosing the unit of your personal data inventory
Make each row a processing activity, such as “email newsletter” or “payroll”, and list the systems inside the row. A row per system or per data field breaks the link between data and purpose, which the Act cares about.
Three ways to structure the register, compared
Unit of record
Looks like
Strength
Weakness
System
“CRM”, “HRMS”, “Data warehouse”
Easy for IT to list.
One system serves many purposes, so purpose and basis blur. Misses paper, spreadsheets and vendors.
Data set or field
“Customer emails”, “Aadhaar numbers”
Good for data classification.
Hundreds of rows and no purpose, owner or basis.
Processing activity
“Order fulfilment”, “Payroll”, “Newsletter”
Links data, purpose, basis, systems, vendors and retention in one row. Matches how notices and consent are written.
Needs interviews with business owners, not only IT.
Rule of thumb
If the same data is used for two purposes, make two rows. A customer’s email used for order updates and for marketing is two activities with possibly two different bases.
Design the register
The register at a glance: 28 fields in 6 blocks, 12 of them core
The workbook groups the 28 fields into six blocks: identify, data, purpose and basis, systems and flows, lifecycle, and assurance. Twelve are marked core. They are the smallest set that still lets you find, explain and act on an activity.
FAssuranceSecurity, rights route, confidence, date.5 fields, 1 core
Design the register
The 28 fields of a DPDP Act personal data inventory: what to enter, an example and why it matters
Each field below says what to enter, shows an example and names the part of the Act or Rules it helps with. Core fields are marked in saffron. The “why it matters” column is guidance; where it cites a section, that section is the source of the duty.
A
Identify: Who and what
Block A, Identify: 4 fields
Field
Tier
What to enter
Example
Why it matters
Activity ID
Core
Unique code for the row, for example PA-001.
PA-001
Good practice
Processing activity
Core
One line, in plain words: what is done with the data.
Order fulfilment and delivery
Section 2 defines processing broadly
Business function
Extended
The team that runs the activity.
Operations
Good practice
Activity owner
Core
A named person who can answer for the activity.
Head of Operations
Good practice; supports Section 8(1) accountability
B
Data: What data, whose, how much
Block B, Data: 5 fields
Field
Tier
What to enter
Example
Why it matters
Personal data categories
Core
What kinds of personal data are involved.
Contact details; Financial and payment data
Section 5(1) notice describes the personal data
Data Principal group
Core
Whose data it is.
Customers
Section 2 (Data Principal); Section 9 for children
Children’s data?
Extended
Does the activity involve anyone under 18?
No
Section 9(1) to 9(3)
Approx. number of Data Principals
Extended
A band is enough.
10,000 to 1 lakh
Context for size-linked rules such as Rule 8 and the Third Schedule
Collection source
Extended
Where the data enters.
Website form
Notice and consent happen at collection (Sections 5 and 6)
C
Purpose and basis: Why you hold it
Block C, Purpose and basis: 5 fields
Field
Tier
What to enter
Example
Why it matters
Specified purpose
Core
The purpose, in plain language, as the notice states it.
To deliver the order the customer placed
Sections 4(1), 5(1) and 6(1)
Applicable basis
Core
Consent, a Section 7 legitimate use, or not yet determined.
Certain legitimate use (Section 7)
Section 4(1)
Section 7 clause, if used
Extended
Which clause, if the basis is a legitimate use.
7(a) Voluntarily provided for a specified purpose
Section 7
Notice reference
Extended
Where the notice is shown, its version and date.
Checkout notice v3, 1 Oct 2026
Section 5(1)
Consent record reference
Extended
Where proof of consent sits and how it is retrieved. Enter Not applicable for Section 7 uses.
Not applicable
Section 6(10) puts the burden of proof on the Data Fiduciary
D
Systems and flows: Where it lives and who gets it
Block D, Systems and flows: 5 fields
Field
Tier
What to enter
Example
Why it matters
Systems and storage locations
Core
Every system that holds the data, including backups and exports.
Order system; data warehouse; backup
Section 8(5) safeguards cover data in your possession or control
Roles with access
Extended
Roles or teams, not individuals.
Operations; Support; Finance
Rule 6 security safeguards
Recipients and Data Processors
Core
Everyone who receives or processes the data on your behalf.
Logistics partner; payment gateway
Section 8(1) and 8(2)
Processor contract in place?
Extended
Is there a written contract with each Data Processor?
Yes
Section 8(2): only under a valid contract
Transfer outside India?
Extended
Is the data sent or accessible outside India? Name the country.
No
Section 16(1) lets the Central Government restrict transfers to notified places
E
Lifecycle: How long, and how it ends
Block E, Lifecycle: 4 fields
Field
Tier
What to enter
Example
Why it matters
Retention period
Core
How long the data is kept, in time or in an event.
Until the order is closed plus the legal retention period
Section 8(7)
Retention trigger
Extended
What starts the clock or ends the purpose.
Contract ended
Sections 8(7) and 8(8); Rule 8
Erasure route
Core
How deletion happens, who runs it and how processors are told.
Monthly job; processor deletes on written instruction
Section 8(7)(b): cause the Data Processor to erase
Legal retention requirement
Extended
The law that requires you to keep the data, if any. Name it.
Tax records law (name the provision)
Section 8(7): unless retention is necessary for compliance with law
F
Assurance: Controls, rights and proof
Block F, Assurance: 5 fields
Field
Tier
What to enter
Example
Why it matters
Security safeguards
Extended
Encryption, access control, logging, backup, in one line.
Encryption at rest; role-based access; logs kept 1 year
Section 8(5); Rule 6(1)
Rights request route
Extended
How access, correction and erasure requests reach this data.
Support ticket tagged DPDP; Operations updates the order system
Sections 11 and 12
Evidence confidence
Extended
How sure are you that this row is accurate?
Verified in system
Good practice
Last verified (date)
Core
The last date someone checked the row against the real system.
2026-10-01
Good practice
Open gaps
Extended
Anything missing or unknown. Move serious items to the Gaps tab.
None
Good practice
Make the fields filterable
Use drop-down lists for Applicable basis, Section 7 clause, Data Principal group, Children’s data, Transfer outside India and Retention trigger. Free text in those fields makes filtering impossible later. The workbook has them built in.
Design the register
Start small: the 12 core fields that make a minimum viable personal data inventory
If you have only a week, fill these 12 fields for your highest-volume process and stop. A complete core row beats a half-filled 28-field row, and you can add extended fields where risk is highest.
Identify
Activity ID, Processing activity, Activity owner.
Data and people
Personal data categories, Data Principal group.
Purpose and basis
Specified purpose, Applicable basis.
Systems and flows
Systems and storage locations, Recipients and Data Processors.
Lifecycle
Retention period, Erasure route.
Assurance
Last verified (date).
Promote an extended field to required when an activity involves children, a Data Processor outside India, a Section 7 basis you may have to defend, or a large number of Data Principals. For those, add Children’s data, Processor contract, Section 7 clause, Transfer outside India and Evidence confidence first.
Design the register
Worked example: three filled rows (consent, employment and a child’s account)
The same 12 core fields read very differently across a marketing activity, a payroll activity and a children’s product. The table shows how the applicable basis, erasure route and flags change. All values are illustrative, for a fictional retailer, and retention periods are placeholders, not legal advice.
The core fields for three activities, plus the children’s flag and Section 7 clause (illustrative)
Field
PA-002 Email newsletter
PA-003 Payroll and statutory filings
PA-006 Learner accounts for under-18 users
Activity ID
PA-002
PA-003
PA-006
Processing activity
Email newsletter
Payroll and statutory filings
Learner accounts for under-18 users
Activity owner
Marketing Manager
HR Manager
Product Head
Personal data categories
Contact details
Employment and HR records; Financial and payment data; Identity documents and numbers
Contact details; Account and login data; Behavioural and usage data
Data Principal group
Prospects and leads
Employees
Children (under 18)
Children’s data?
No
No
Yes
Specified purpose
To send the monthly product newsletter
To pay salaries and file statutory returns
To provide the learning app and track course progress
Applicable basis
Consent (Section 6)
Certain legitimate use (Section 7)
Consent (Section 6)
Section 7 clause, if used
Not applicable
7(i) Employment, or safeguarding the employer from loss or liability
Not applicable
Systems and storage locations
Email platform; CRM
HRMS; payroll software; finance system
App backend; analytics; support tool
Recipients and Data Processors
Email platform provider
Payroll provider; bank; statutory portals
Cloud host; analytics provider
Retention period
Until consent is withdrawn or the subscriber has been inactive for 24 months (placeholder)
Employment plus the period each law requires (placeholder)
While the account is active; removed after parent withdraws consent (placeholder)
Erasure route
Unsubscribe removes the contact; CRM sync deletes within 7 days
HR closes the record; payroll provider confirms deletion in writing
Parent request triggers account deletion; processors told in writing
Last verified (date)
2026-09-28
2026-09-30
2026-10-02
Notice what the examples show. The newsletter rests on consent, so a withdrawal ends the activity. Payroll rests on a Section 7(i) employment use, so consent withdrawal is the wrong trigger and the end of employment plus legal retention periods governs. The learner account triggers Section 9, so verifiable parental consent and a check against tracking and targeted advertising belong in the row.
Design the register
Controlled lists: Section 7 clauses, data categories and other drop-downs for a searchable inventory
Drop-down lists keep the register consistent, so you can filter it when a rights request or a breach arrives. The most important is the applicable basis, which has three values, and the Section 7 clause list that sits behind it.
Section 7 legitimate uses in plain language, and how to use each in the register
Clause
Covers, in short
Register note
7(a)
The specified purpose for which the Data Principal voluntarily provided the data, where she has not indicated that she does not consent to its use.
Limited to that specified purpose. Do not use it as a blanket for other uses.
7(b)
The State and its instrumentalities providing a subsidy, benefit, service, certificate, licence or permit.
Framed around the State.
7(c)
State functions under law, or the interest of sovereignty, integrity or security of the State.
Framed around the State.
7(d)
Fulfilling an obligation under Indian law to disclose information to the State or its instrumentalities.
Name the law that requires the disclosure.
7(e)
Compliance with a judgment, decree or order under law.
Record the order or the law.
7(f)
Responding to a medical emergency involving a threat to life or immediate threat to health.
Rare for most businesses.
7(g)
Medical treatment or health services during an epidemic, outbreak or threat to public health.
Rare for most businesses.
7(h)
Ensuring safety or providing assistance during a disaster or breakdown of public order.
Rare for most businesses.
7(i)
Employment purposes, or safeguarding the employer from loss or liability.
Typical for payroll and HR records. Keep the purpose specific.
The Act has no separate “legitimate interest” basis like the GDPR. The two bases are consent (Section 6) and the closed list of certain legitimate uses (Section 7). Anything you cannot place in either needs attention before you rely on it. That is why the workbook includes a third value, “Not yet determined”, and counts how many rows still carry it. For the consent side, see the consent management guide.
The other controlled lists in the workbook
List
Values
Personal data categories
Contact details; Identity documents and numbers; Account and login data; Financial and payment data; Employment and HR records; Health data; Location data; Device and online identifiers; Communications and recordings; Images, video and CCTV; Behavioural and usage data; Other
Data Principal groups
Customers; Prospects and leads; Employees; Job applicants; Contractors; Visitors; Vendor and partner staff; Students; Patients; Children (under 18); Other
Retention trigger
Consent withdrawn; Purpose served; Account closed; Contract ended; Employment ended; Statutory period; Fixed period set by policy; Class period under Rule 8
Evidence confidence
Verified in system; Confirmed by owner; Assumed
Build it
How to build a personal data inventory in 6 steps
Fix the unit and fields, seed the list of activities from three sources, name owners, fill the core fields, check them against real systems, then approve and version the register. Each step names who is involved and what you should have at the end. For the cross-team method, see how to conduct a data mapping exercise.
1Fix the designOne row per activity; core fields first.Output: the template
2Seed the activitiesFrom apps, vendors and forms.Output: activity list
3Name ownersOne accountable person each.Output: owner column
4Fill the core fieldsInterviews plus system evidence.Output: draft rows
5VerifyTrace a record; reconcile vendors.Output: confidence marked
6Approve and versionSign off, date and publish internally.Output: approved register
1Fix the design: unit of record, fields and lists
What to do
Adopt one row per processing activity. Choose the 12 core fields, decide which extended fields are required for high-risk activities, and set the drop-down lists. The workbook gives you all of this ready to use.
Who to involve
The privacy or compliance owner, with IT and one business lead to sanity-check the fields.
Watch for
Adding fields nobody can fill. Every field should help a decision, a duty or a request.
Output
An agreed template and field definitions.
2Seed the list of activities from three sources
What to do
Build the list of activities from evidence, not memory. Use three sources, then merge duplicates.
Apps and systems: the IT or single sign-on application list, plus tools teams bought on a card.
Vendors: accounts payable vendor payments, which reveal Data Processors nobody listed.
Collection points: every website form, app screen, call script, paper form and event sign-up.
Who to involve
IT, finance (for vendor payments), marketing and customer support.
Watch for
Spreadsheets, shared mailboxes and personal drives. They hold personal data and rarely appear in system lists.
Output
A deduplicated list of processing activities with IDs.
3Name an owner for every activity
What to do
Assign one named person per activity, ideally the business lead who decides how the data is used. The owner confirms the row and is told when the activity changes.
Who to involve
Department heads, with the privacy owner coordinating.
Watch for
“IT” or “the team” as an owner. Without a person, nobody updates the row.
Output
A complete owner column.
4Fill the core fields with interviews and evidence
What to do
Interview each owner for 30 to 45 minutes with the template open. Ask what data comes in, whose it is, why, where it goes, who else sees it, and when it is deleted. Then attach evidence: the notice text, a system screenshot, a contract reference.
Who to involve
The activity owner and the person who runs the system.
Watch for
Writing the policy answer instead of the real answer. Ask “show me”, not only “tell me”.
Output
Draft rows with a stated source of evidence.
5Verify against real systems and mark confidence
What to do
Run the checks in the quality test below. Search for one test person’s record in every listed system, reconcile vendors against payments, and mark each row Verified in system, Confirmed by owner or Assumed.
Who to involve
Privacy owner and IT.
Watch for
Treating Assumed rows as finished. They are open gaps; log them on the Gaps tab.
Output
Rows with evidence confidence and a Gaps list.
6Approve, version and publish internally
What to do
Have the sponsor approve the register, save it as a dated version, and share it with the people who run notices, rights requests, vendor onboarding and incident response. Set the next review date.
Who to involve
The executive sponsor, privacy owner and function heads.
Watch for
Letting it live on one person’s laptop. It should sit in a controlled, access-limited location, because the register itself describes where your personal data is.
Output
An approved, versioned register with an owner and a review date.
Build it
Filling the retention and erasure fields: periods, triggers and processor deletion
For each activity, record when the data must go, what starts that clock, and how deletion reaches every system and Data Processor. The Act sets the principle, and you set the period and the mechanics unless a Rule or another law fixes them.
Section 8(7) requires a Data Fiduciary, unless retention is necessary for compliance with law, to erase personal data when the Data Principal withdraws consent or as soon as it is reasonable to assume the specified purpose is no longer served, whichever is earlier, and to cause its Data Processor to erase data it made available. Section 8(8) deems the purpose no longer served for a Data Principal who has not approached the Data Fiduciary or exercised rights for a prescribed period. Rule 8 and the Third Schedule set time periods for named classes of Data Fiduciary, such as large e-commerce entities, online gaming and large social media entities, so check whether you fall in one. Rule 6(1)(e) also requires certain logs and personal data to be retained for at least one year. Read the Rule text for its exact scope.
How to write the lifecycle fields for common activities
Situation
Retention trigger
What to write in the register
Consent-based marketing
Consent withdrawn
Period: until withdrawal. Erasure route: unsubscribe removes the contact and syncs to every tool within a set time.
Customer order or account
Account closed or contract ended
Period: until closure plus any period a named law requires. Legal retention requirement: name the law.
Employee records
Employment ended
Period: employment plus the periods each law requires. Name the laws. Do not use consent withdrawal as the trigger.
Job applicants
Fixed period set by policy
Period: a set number of months after the vacancy closes, decided by you and applied consistently.
Named class under Rule 8
Class period under Rule 8
Check the Third Schedule for the period and the notice before erasure, and record both.
Do not skip the processor
Deleting from your own system is only half of erasure. Record how each Data Processor is told to delete and how you know it did. The Processors tab in the workbook has a column for this. Related: what happens when consent is withdrawn.
Build it
Is your personal data inventory any good? A 10-point quality test before you rely on it
An inventory is good when it is complete, owned, traced against real systems and recent. These ten checks take a few hours and catch most problems. The checks are editorial guidance, not a statutory test.
Ten checks for a reliable personal data inventory
#
Check
How to run it
Pass signal
1
Completeness
Open the Summary tab and read average core completeness.
Every row at 100% of core fields.
2
Ownership
Ask each owner to confirm their rows.
A named person on every row.
3
Trace test
Pick a test record and search for it in every system on the row.
Found where the row says, and nowhere else.
4
Vendor reconciliation
Compare recipients with accounts payable and the application list.
Every vendor holding personal data appears in a row.
5
Collection reconciliation
List every live form, app screen and call script.
Each maps to an activity.
6
Basis check
Filter Applicable basis.
No “Not yet determined”; every Section 7 row names a clause.
7
Retention check
Filter rows with no period or erasure route, then test one deletion end to end.
None blank; the test deletion reaches every system.
8
Processor check
Open the Processors tab.
Contract, security review and erasure confirmation recorded.
9
Freshness
Check Last verified dates.
No row older than your review cycle (12 months is a sensible ceiling).
10
Duplicates
Sort by activity name.
No activity listed twice under different names.
Use it and keep it
Put the personal data inventory to work: notices, rights requests, erasure and breach response
A register earns its keep when you filter it to answer a real question. Each task below starts with a filter on one or two fields.
1NoticesCheck purposes and categories match.Filter: purpose
2ConsentFind consent-based rows.Filter: basis
3Rights requestsFind every system holding the data.Filter: group, systems
4ErasureFind processors to instruct.Filter: recipients
5BreachScope who is affected.Filter: system
Real questions the register should answer in minutes
The question
Where to look
What you learn
A customer withdraws consent. What must stop?
Applicable basis = Consent; match the purpose and Data Principal group.
Which activities, systems and processors to stop and erase from (Sections 6 and 8(7)).
A vendor reports an incident. Whose data is involved?
Recipients and Data Processors = that vendor.
The activities, categories and people affected, to scope a breach intimation (Section 8(6), Rule 7).
A Data Principal asks who has received their data.
Data Principal group; Recipients.
A starting list of recipients to answer a Section 11 request.
Are we using children’s data anywhere?
Children’s data? = Yes or Unknown.
Activities to review against Section 9.
Do we have a contract with every processor?
Processor contract in place? = No or In progress.
Contract gaps to close under Section 8(2).
Are we sending data outside India?
Transfer outside India? = Yes or Unknown.
Activities to check against any restriction notified under Section 16.
Keep your personal data inventory current: owners, change triggers and reviews
An inventory goes stale the day a team launches a new form or signs a new vendor. Tie updates to events, give each row an owner, and review everything at least once a year. The cadence below is editorial guidance, not a requirement.
Product and technology
New feature or app release, new form, SDK or analytics tool, new integration, system migration, a new logging practice.
Vendors and data
New vendor or a change of vendor, a vendor’s new sub-processor or location, vendor termination, a new purpose for existing data, a new retention period.
People and events
New business unit or acquisition, a new marketing channel, a security incident or near miss, and a scheduled annual review.
On changeSame week
Owner flags the change
Update the affected rows
Reset Last verified
Log new gaps
Every quarterSample
Spot-check five rows
Reconcile new vendors
Review the Gaps tab
Check the Summary tab
Every yearFull review
Owners re-confirm every row
Re-run the 10-point test
Archive a dated version
Reset the review date
Use it and keep it
10 personal data inventory mistakes and how to fix them
Most failed inventories fail the same way: too wide, too vague, unowned or never updated. Use this table as a checklist before you sign off.
Common mistakes and fixes
#
Mistake
Why it hurts
Fix
1
Building a row per system
Purpose and basis blur; paper and vendors are missed.
One row per processing activity; list systems inside it.
2
Starting with all 28 fields
Rows stay half-filled and nobody trusts them.
Complete the 12 core fields first.
3
Free-text for key fields
You cannot filter by basis, vendor or children’s data.
Use drop-down lists.
4
Using IT only to fill it
IT knows systems, not purposes or vendors bought by teams.
Interview business owners too.
5
Leaving the basis as “legitimate interest”
The Act has no such basis.
Choose consent, a Section 7 clause or flag it as undetermined.
6
Treating 7(a) as a blanket
It covers only the specified purpose the person provided the data for.
Record the specific purpose, and a separate row for each new use.
7
Forgetting processors’ copies
Erasure and breach scoping miss data held by vendors.
Record every Data Processor and how deletion is confirmed.
8
No evidence
Answers are opinions and cannot be defended.
Attach the notice, contract reference or screenshot, and mark confidence.
9
No owner or review date
The register goes stale quietly.
Name a person; set change triggers and a yearly review.
10
Open access to the register
The map of your personal data is itself sensitive.
Limit access and keep it in a controlled location.
Get the workbook
Free DPDP Act Personal Data Inventory Workbook (Excel): what is inside and how to download it
The workbook is a free Excel file with the 28-field register, drop-down lists, six worked example rows, a processor register, a gap log and an automatic summary. It is an internal aid, not legal advice or certification, and you can adapt every tab.
Start here
How to use the workbook, colour key and cautions.
Inventory
28 fields in 6 blocks, 12 core, drop-downs, space for 60 activities, and a core completeness score per row.
Examples
Six illustrative rows, including a consent activity, an employment activity and a children’s product.
Processors
Contract, security review, locations, sub-processors and erasure confirmation for each vendor.
Gaps
A log of unknowns with risk, owner, due date and status.
Summary
Live counts: basis undetermined, children’s data, missing contracts, transfers outside India, stale rows.
FAQ
Frequently asked questions: personal data inventory under the DPDP Act
What is a personal data inventory?
A personal data inventory is a maintained register of the personal data an organisation processes. Each row covers one processing activity and records the data, whose it is, the purpose, the applicable basis, the systems, the recipients and Data Processors, the retention trigger, the erasure route, an owner and a last-verified date.
Is a personal data inventory mandatory under the DPDP Act?
We found no provision in the DPDP Act or the DPDP Rules, 2025 that requires a Data Fiduciary to keep one. It is practical compliance infrastructure that helps with notice, consent, processor control, erasure, rights requests and breach response. See is data mapping mandatory under the DPDP Act for the full analysis.
What should a personal data inventory include?
At minimum: activity ID, processing activity, owner, personal data categories, Data Principal group, specified purpose, applicable basis, systems and storage locations, recipients and Data Processors, retention period, erasure route and last-verified date. Add children’s data, Section 7 clause, notice and consent references, processor contract, transfers outside India, security safeguards, rights request route and open gaps as risk requires.
How do you build a personal data inventory?
Fix one row per processing activity and choose your fields. Seed the activity list from your application list, vendor payments and collection points, name an owner for each, fill the core fields through interviews and evidence, verify against real systems, and approve and version the register with a review date.
What is the difference between a personal data inventory and a data map?
An inventory is the register of what you process. A data map adds how the data moves between systems, people and vendors, often as diagrams. The inventory is usually the first output. See data mapping vs data inventory vs RoPA.
Is a personal data inventory the same as a RoPA?
They overlap but are not identical. A Record of Processing Activities is a GDPR Article 30 requirement with prescribed content. The DPDP Act has no equivalent express duty that we found, so an inventory under the DPDP Act is a practical register you design. If you also handle EU data, you can structure it to satisfy both.
Who should own the personal data inventory?
The privacy or compliance owner should run the register, but each processing activity needs a named business owner who confirms their rows and reports changes. Ownership by a function name instead of a person is a common reason registers go stale.
How often should a personal data inventory be updated?
The Act sets no review cycle. A sensible practice is to update a row whenever its activity, system, vendor or purpose changes, spot-check a sample each quarter and re-confirm every row at least once a year. This cadence is editorial guidance.
Can I build the inventory in Excel or do I need a tool?
Excel or Google Sheets works well for a first inventory and for small and mid-sized organisations. Dedicated tools help when you have many systems, frequent change or need automated discovery. Start in a spreadsheet to learn what you hold, then decide whether a tool is worth it. The free workbook on this page is built for that first phase.
Does the inventory need to include paper records?
The Act applies to digital personal data, including personal data collected in non-digital form and digitised afterwards (Section 3). Paper records that are later digitised belong in the register. Purely paper records that are never digitised are outside the Act’s scope as we read it, but many organisations track them anyway for good practice. Take legal advice on borderline cases.
Is there a free personal data inventory template for the DPDP Act?
Yes. The free Data Inventory Workbook on this page is an Excel file with 28 fields, drop-down lists, six example rows, a processor register, a gap log and a summary tab. It is an internal aid and not legal advice or certification.
Related
Continue the data mapping collection
Go to the full method, the legal text and the practical tools. When you are ready to move from records to working controls, see the DPDP implementation framework.
About this article. Prepared by the DPDPActIndia editorial team under our editorial policy. It explains the Act and Rules in general terms and is not legal advice (disclaimer). The field set, examples, retention wording, quality test and review cadence are editorial guidance, not statutory requirements. Check thresholds and class definitions in the Third Schedule against the Gazette before relying on them. Spotted an error? Tell us.
dpdpactindia
Talk to a DPDP consultant
Consultant-led and partner-backed.
We use your details only to respond to this request.