How to Build a Record of Processing for DPDP
No rule requires this document by name. Three rules require things you cannot do without it, which amounts to the same thing.
Why build it if no rule names it
Three obligations collapse without it:
- Rule 7(2)(a) requires you to tell the Board the extent of a breach without delay. You cannot describe the extent if nobody knows what was in the affected system.
- Rule 8 requires erasure once the specified purpose is no longer served. Purpose has to be recorded per data set for that to mean anything.
- Rule 14 requires a working route for rights requests. Answering one means finding a single individual across every system.
The fields that earn their place
- Data set — a name a person would recognise, not a table name.
- Fields — the actual personal data in it. This becomes the itemised description Rule 3(b)(i) requires in your notice.
- Specified purpose — in the language you would use to a Data Principal.
- Basis — consent, or a legitimate use under section 7.
- Systems — every place it lives, including warehouses, backups and analytics tools.
- Access — which roles can read it, which supports Rule 6(1)(b).
- Processors — who processes it on your behalf, which drives Rule 6(1)(f) contracts.
- Retention — the period, and the law or purpose that justifies it.
- Leaves India — relevant to Rule 15 and to Rule 13(4) if you are notified as a Significant Data Fiduciary.
The copies are the hard part
Most organisations can list their primary databases. What breaks a rights request is the copies: the analytics warehouse, the CSV someone exported, the support tool that caches customer records, the backup that still holds data erased from production.
Recording where data flows, not just where it originates, is the difference between an inventory that works under pressure and one that looks complete.
The inventory is not a compliance artefact. It is the thing that lets you answer, in the first hour of an incident, which people were affected.
Infosek Team
Keeping it current
- Attach it to an existing process. A new data set added in a design review is captured; a quarterly audit is not.
- Give each entry an owner who would notice if it were wrong.
- Review at a fixed cadence rather than when someone remembers.
- Use it as the source for your notice content, so drift becomes visible.
Common questions
Does the DPDP Act require a record of processing activities?
Not by that name. But Rule 7 requires describing the extent of a breach, Rule 8 requires erasing data once the specified purpose is no longer served, and Rule 14 requires handling Data Principal rights requests. None of those is achievable without an inventory of what personal data is held, where, and for what purpose.
What should a DPDP data inventory contain?
At minimum: the data set, the personal data fields in it, the specified purpose, the lawful basis, the systems it lives in, who can access it, any Data Processor involved, the retention period and the law or purpose justifying it, and whether it leaves India.
Starting your data mapping?
Infosek handles the whole of DPDP: data mapping, consent and notices, security controls, vendor contracts, breach readiness and the audit itself. We do the work, not just the gap report.
Book Free 30-Min Assessment