DPDP Act Compliance Checklist for Indian Businesses (2026)

Most boards I sit in front of think they became DPDP-ready the day their legal team pasted a new privacy policy onto the website. Then I ask one question: show me, right now, every place a customer's phone number lives. Silence. Someone opens a laptop. Twenty minutes later we have a list of four systems, and by the end of the day it is eleven. That gap between what you think you hold and what you actually hold is where every DPDP audit starts to hurt.

The Digital Personal Data Protection Act, 2023 (DPDP Act) is not a documentation exercise. It is an operational one. You can have a flawless notice and consent form and still fail the moment a Data Principal writes in asking you to erase their data and you have no idea where it all sits. This checklist is written the way I actually audit — control by control, artefact by artefact — so you can find your own gaps before a regulator, a breach, or an angry customer does it for you.

Strip away the noise and the Act turns on a few load-bearing ideas. You are a Data Fiduciary if you decide the purpose and means of processing personal data. The individual whose data you process is the Data Principal. Anyone processing on your behalf — your cloud vendor, your call centre, your analytics tool — is a Data Processor, and you remain accountable for them. Consent must be free, specific, informed, unconditional and unambiguous, with a clear affirmative action. That last phrase kills pre-ticked boxes and bundled consent stone dead.

The Act was notified in 2023, and through 2025 the government released the Draft DPDP Rules for consultation, which flesh out consent notices, the Consent Manager framework, breach reporting timelines and Significant Data Fiduciary obligations. Treat the Rules as your operational spec even as the final text settles — the direction of travel is clear, and auditors are already testing against it. Penalties are severe: up to 250 crore rupees for failing to prevent a breach through reasonable security safeguards, up to 200 crore for breach-notification failures, and up to 50 crore for other lapses, adjudicated by the Data Protection Board of India.

Every real DPDP programme begins with a data inventory, and almost every failed one skipped it. Before you touch a consent form, you need a Record of Processing Activities (RoPA): for each category of personal data, what you collect, why, the lawful basis, where it is stored, who it is shared with, and how long you keep it. This is the artefact I ask for first, because it exposes the shadow systems — the marketing spreadsheet, the WhatsApp Business exports, the old CRM nobody decommissioned.

Do this properly and the rest of the checklist gets easier, because every downstream control — consent, rights, retention, breach scope — depends on knowing exactly what you hold and where. Do it badly and you will be guessing during a breach, which is the worst possible time to guess.

Here is where most Indian businesses have quietly been non-compliant for years and never noticed. Under the DPDP Act, consent must be tied to a specific purpose, and the notice you show at the point of collection must be itemised. A single sentence saying we may use your data to improve our services does not survive scrutiny. You must tell the Data Principal what personal data you are collecting, the purpose for each, how they can exercise their rights, and how they can complain to the Board.

Consent notices must also be available in English and the languages listed in the Eighth Schedule to the Constitution — a point many organisations miss until an auditor asks for the Hindi or Tamil version and there isn't one. And withdrawal must be as easy as giving consent. If a customer needed one click to opt in, do not make them call a helpline to opt out.

The record-keeping point is the one that catches people. When the Board or a Data Principal challenges you, you must produce the exact consent that was captured, against the exact notice version shown at that time. If your website has been redesigned three times and you cannot reconstruct which notice a 2024 customer saw, you have a problem. Version your notices. Log consent with a timestamp and a reference to the notice version. Keep it immutable.

Consent forms are theory. Rights fulfilment is practice, and it is where an auditor learns whether your programme is real. The Act gives Data Principals the right to access a summary of their data and processing, the right to correction and erasure, the right to grievance redressal, and the right to nominate someone to act on their behalf if they die or become incapacitated.

Picture the scene that actually plays out. A customer emails: delete all my data. Your support agent forwards it to IT. IT deletes the CRM record. Six months later a marketing email lands in that customer's inbox because their address still sat in the email platform and the analytics warehouse and a backup. Now you have not just failed the erasure request — you have created evidence of it. The fix is not willpower; it is a defined workflow with a system-of-record mapping and an SLA.

Publish a named Grievance Officer with real contact details, not a generic inbox nobody reads. Log every request, its resolution, and the time taken. When I audit rights fulfilment, I pick three closed requests at random and trace them end to end. If the data survived in a system your workflow forgot about, the whole control fails — however good the paperwork looked.

The Act does not hand you a control catalogue. It says you must protect personal data with reasonable security safeguards to prevent a breach — and then attaches the largest penalty in the statute to that single obligation. So the practical question becomes: what will an auditor and the Board treat as reasonable? The honest answer is that they will benchmark you against established frameworks — ISO/IEC 27001, the CERT-In directions, and sector rules from the RBI, SEBI or IRDAI if they apply to you.

Reasonable is not a fixed line; it scales with the sensitivity and volume of what you hold. A fintech processing millions of financial records is held to a far higher bar than a five-person consultancy. But there is a floor everyone must clear, and it maps cleanly onto controls a CERT-In empanelled auditor already tests.

The CERT-In directions of 2022 matter here even though they predate the DPDP Act. They mandate synchronising system clocks to NIC or NPL time, retaining logs for 180 days within India, and reporting specified cyber incidents to CERT-In within six hours of noticing them. That six-hour clock is separate from your DPDP breach obligation, and both can apply to the same incident. Miss either and you have two regulators to answer to.

No breach programme survives first contact with an actual breach unless it was rehearsed. The DPDP Rules require you to notify both the Data Protection Board and every affected Data Principal when a personal data breach occurs — and the draft framing points to prompt, essentially without-delay notification, with a fuller report to follow. This is intentionally aggressive. It means the decision to notify has to be made while you are still firefighting, not after the forensics are complete.

The failure mode is always the same: the incident is spotted by an engineer at 11pm, escalated the next morning, debated by legal for two days, and reported late. By then you have blown the timeline and the notification itself reads like a cover-up. The fix is a pre-approved decision tree and pre-drafted templates so that the on-call responder knows exactly who to wake and what threshold triggers a report.

Your breach notice to affected individuals must describe the nature of the breach, its likely consequences, the measures you have taken, and what the individual can do to protect themselves. Write those templates now. During an incident, nobody has the calm to draft clear language from a blank page.

The government can notify certain organisations as Significant Data Fiduciaries based on the volume and sensitivity of data they process, the risk to Data Principals, and impact on public order or India's sovereignty. If you are named one — and large platforms, big fintechs and health players should assume they will be — additional obligations kick in. You must appoint a Data Protection Officer based in India who reports to the board, appoint an independent data auditor, and conduct a periodic Data Protection Impact Assessment (DPIA).

Even if you are not formally designated, adopting the DPIA discipline is smart. A DPIA forces you to document risk before you launch a new product feature that scoops up personal data — which is exactly the moment most privacy failures are born.

If you do nothing else, work this list in order. It is sequenced the way I would run a remediation programme — inventory first, because everything downstream depends on it, and vendors last only because they take longest to close.

Come back to that boardroom and the eleven systems nobody could name. The privacy policy was fine. The consent form was fine. What was missing was the operational spine — the mapping, the workflows, the logs, the rehearsed response — that turns a legal document into something an auditor can actually verify. DPDP compliance is not a certificate you earn once. It is a set of habits you can prove on any given Tuesday, including the Tuesday you get breached.

If you want a second pair of eyes on where you actually stand, that is the work we do at CyberSigma — senior CERT-In empanelled auditors who sit in the room, trace your data end to end, and tell you plainly what will fail before a regulator does. No dashboards, just the honest findings and a remediation plan you can act on.