DPDP Act 2023: 150-point implementation checklist

What the DPDP Act actually asks of you

The Digital Personal Data Protection Act 2023 is short by the standards of privacy law, which misleads people into thinking compliance is light. It is not. The Act is short because it delegates detail to rules, and because most of its weight sits in four obligations that are easy to state and expensive to implement.

You must have a lawful basis, which in practice for most Indian businesses means consent, and consent under this Act is a higher bar than the tick box most organisations currently rely on. It has to be free, specific, informed, unconditional and unambiguous, given by a clear affirmative action, and accompanied by a notice in plain language. Bundling consent for analytics into consent for service delivery does not survive that test.

You must honour data principal rights: access, correction, erasure, grievance redressal and nomination. Each of those is a workflow with a clock on it, not a mailbox.

You must notify the Data Protection Board and affected data principals of a personal data breach. Note that this obligation is separate from, and triggered differently to, the six hour CERT-In reporting duty. Organisations that build one incident process and assume it covers both discover the gap at the worst possible moment.

And you must not keep personal data past the purpose it was collected for. Retention is where almost every organisation we assess is out of compliance today, because deleting data requires knowing where it is.

Where implementations actually fail

In the assessments we run, the same four gaps appear regardless of sector or size.

The first is inventory. You cannot honour an erasure request against data you have not mapped, and the map is almost never complete: the analytics warehouse, the CRM export somebody keeps on a shared drive, the vendor who holds a copy, the backup that restores deleted records. An erasure workflow that covers the primary database and nothing else creates a documented commitment you are not keeping.

The second is consent architecture. Retrofitting granular consent onto a product built on implied consent is a product change, not a legal one, and it needs engineering time nobody budgeted. Consent also has to be withdrawable as easily as it was given, and the withdrawal has to propagate to processors.

The third is processor contracts. The Act makes you accountable for what your processors do. Most vendor agreements we read predate the Act and say nothing useful about data protection obligations, breach notification timelines, or the right to audit.

The fourth is evidence. Being compliant and being able to demonstrate compliance are different problems, and only the second one is testable by a regulator. Every control needs an artefact behind it.

How to use the 150 checks

The checklist is ordered by obligation rather than by department, which means it will cut across your organisational chart. That is deliberate. The commonest reason a privacy programme stalls is that consent sits with product, retention sits with engineering, grievance sits with support, and nobody owns the join.

Work through it once quickly, marking each check as done, partial or not started, without stopping to fix anything. That pass takes a few hours and produces the only thing you actually need at the start: an honest baseline.

Then assign an owner to each not started item. The owner is a named person, not a team. Where an item has no plausible owner, that is itself the finding.

Then attach an evidence type to each done item. If you cannot name the artefact that proves it, treat it as partial. This step reliably converts a comfortable-looking assessment into an uncomfortable one, which is the point of doing it before somebody external does it for you.

Sequencing, if you cannot do everything at once

Nobody implements 150 checks simultaneously. The order that reduces risk fastest, in our experience, is inventory, then retention, then consent, then rights, then evidence.

Inventory first because everything else depends on knowing where personal data lives. Retention second because deleting data you should not hold is the single largest reduction in breach exposure available to you, and it costs engineering time rather than licence spend.

Consent third, because it is a product change with a lead time and you want it started early even though it will finish late. Rights fourth, because the volume of requests is usually low at first and a manual process is defensible while you build. Evidence last and continuously, because it accumulates rather than being built.

The exception is breach notification. That one is not sequenced, it is done immediately, because the cost of not having it is unbounded and the cost of having it is one page and a named decision maker.

What we would ask if we were assessing you

• Show me every system that holds personal data, and tell me how you know the list is complete
• Walk me through what happens when a data principal asks for erasure, including backups and processors
• Show me a consent record for a specific user, with timestamp, scope and the notice they saw
• Tell me your retention period for one category of data and show me the deletion running
• Who decides a breach is notifiable, who is their deputy, and how are they reached at 02:00
• Show me one processor contract with the data protection obligations in it