DPDPA Compliance Checklist: A Step-by-Step Self-Assessment Guide

I have sat through a fair number of these conversations over the years, first as the internal auditor asking the awkward questions, later as the person on the other side of the table trying to answer them. The pattern with DPDPA readiness is always the same. Someone forwards the Act, thirty-odd pages of a Chartered Accountant's least favourite kind of reading, and three weeks later nobody in the room can tell you whether the company is compliant or just has a PDF sitting in a shared drive. So before the checklist, the plain version: DPDPA cares about four things. Who is the Data Fiduciary deciding the purpose of processing, is there a valid basis (usually consent, sometimes a "legitimate use") for touching that person's data, has the person been given clear notice in an understandable language, and can you produce evidence of all of the above on demand.

That last part, the evidence, is where most of the self-assessments I have reviewed fall apart. Companies are reasonably good at the policy layer, a privacy policy exists, a cookie banner exists, and reasonably weak at the operational layer underneath it, who actually owns the consent records, where do deletion requests go, who signs off when a new vendor gets access to a customer database. A checklist forces you to walk that operational layer end to end instead of just checking that the policy PDF is up to date.

Here is the checklist I actually work through with clients, grouped the way I think about risk rather than the way the Act is numbered.

Governance and documentation: • a data inventory listing what personal data you hold, where it lives, and why • a documented lawful basis for every processing activity, not a blanket "we have consent" • a Data Protection Officer or a named grievance contact if you are not yet an SDF • a record of processor and vendor contracts that flow DPDPA obligations downstream.

Consent and notice: • a consent capture flow that is specific, itemised and as easy to withdraw as it was to give • a notice, in plain language and, where relevant, in the language the data principal used to interact with you, listing what is collected, why, and for how long • no pre-ticked boxes, no bundled consent for unrelated purposes.

Security safeguards and data principal rights: • reasonable technical and organisational measures, encryption at rest and in transit, access controls, logging • a working process to handle access, correction and erasure requests inside a reasonable timeline, which I cover in more detail in the DSAR piece linked below • a retention schedule that actually deletes data once the purpose is served, not just a policy that says it should.

Breach readiness sits last on this particular list only because it is the one companies most often skip during self-assessment, not because it matters less. I have written a separate, longer piece on the 72-hour notification mechanics because it deserves its own space, but at minimum your self-assessment should confirm you know who internally gets paged the moment a breach is suspected, and that the clock starts from suspicion, not from confirmation.

Under Rule 13 of the DPDP Rules 2025, a Significant Data Fiduciary carries a heavier checklist on top of the base one. Once every twelve months from notification, an SDF has to run a Data Protection Impact Assessment and get an independent audit done, and then has to make sure whoever carried out both submits a report of significant observations to the Data Protection Board. On top of that there is an ongoing duty of algorithmic due diligence, meaning you need to verify that any algorithmic or technical system you use to process personal data is not creating risk for the people whose data it touches, and a possible data localisation requirement if the central government specifies that a category of data your organisation handles cannot leave Indian territory.

I would not spend energy trying to self-determine whether you qualify as an SDF from first principles. The classification depends on factors the government sets, like the volume and sensitivity of personal data processed and the potential risk to India's sovereignty, electoral integrity or public order, and it gets notified, not inferred. What I would do instead is build your base checklist assuming you might be notified tomorrow, because retrofitting a DPIA and an independent audit process under a deadline is a much worse exercise than building it in from the start.

I want to be honest about how much precision I can offer here, because a lot of the compliance content I have read online states these dates with more confidence than the primary sources actually support. What is solid: the DPDP Rules 2025 were notified by the Ministry of Electronics and Information Technology on 14 November 2025, after roughly two years of the Act sitting un-operationalised following its 2023 passage. What is directionally right but worth double-checking against the Board's own notifications closer to the date: a phased rollout of around eighteen months, with the consent manager framework becoming operational sometime around November 2026, and Significant Data Fiduciaries facing their first mandatory DPIA and audit cycle in early 2027.

So, practically, I would not wait for a deadline to start. Build the base checklist now, treat the SDF items as "when, not if" if your data volumes suggest you are a candidate, and revisit the exact dates every quarter rather than pinning your entire programme to a single calendar entry that a future notification could move.

The Schedule to Section 33 sets out a tiered structure. Administrative gaps, no DPO appointed, no published contact information, sit at the lower end, up to roughly ten crore rupees. Security failures and delayed breach notification sit meaningfully higher, up to roughly two hundred crore rupees. Core data principal rights violations, and this includes anything involving a child's data, sit at the top of the ordinary scale, and the Board has discretion under Section 33(2) to enhance or reduce the penalty based on factors like the nature of the breach, how sensitive the data was, whether the violation was repeated, and what the organisation did to remediate.

I think the number that should actually worry a founder or a CFO is not the maximum penalty, it is the discretion built into that multiplier. A Board that sees a company running an honest, documented self-assessment programme and fixing what it finds is going to treat a slip very differently to a Board that finds no programme at all. That, more than any single fine amount, is the argument for running this checklist properly rather than performing it for a slide deck.