The Digital Personal Data Protection Act, 2023 told organisations what they owed. It was always going to be the Rules that told them what to build. For two years, most Indian compliance programmes were constructed on an educated guess about the operational detail. That guess is now testable.
This note is written for the person who has to translate the framework into work: which systems change, which documents have to exist, and what would have to be produced if the Data Protection Board asked. It is not a clause-by-clause commentary, and it is deliberately not exhaustive.
The shift from principle to evidence
The single most important change is one of posture. Under the Act read alone, an organisation could reasonably describe its obligations in terms of principles: give notice, obtain consent, keep data secure, delete when the purpose ends. With the Rules in force, each of those principles acquires an evidentiary shape. The question is no longer whether you gave notice. It is what the notice said, in what form it was served, in which languages it was made available, and whether you can retrieve the version that a particular Data Principal actually saw on a particular date.
That is a systems problem before it is a legal one, which is why programmes that treated DPDP as a policy exercise are the ones now discovering how much engineering work sits in front of them.
Notice: standalone, plain, and retrievable
A notice under the Act has to be understandable on its own terms. It cannot be a cross-reference to a privacy policy that itself cross-references a cookie table. It must set out the personal data being collected and the purpose for which it will be processed, and it must tell the Data Principal how to exercise their rights, how to withdraw consent, and how to complain to the Board.
Two operational consequences follow, and both are commonly missed:
- Language. The notice has to be made available in English and in the languages specified in the Eighth Schedule to the Constitution. For a consumer product, that is a content-management requirement, not a one-time translation project, because every time the notice changes the translations change with it.
- Versioning. If notices change — and they will — you need to know which version was served to whom. Very few consent management deployments we have reviewed store the notice text alongside the consent record. Storing a timestamp and a boolean is not a record of what the person was told.
Consent: the record is the obligation
Consent under the Act must be free, specific, informed, unconditional and unambiguous, given by a clear affirmative action, and limited to the personal data necessary for the specified purpose. Withdrawal must be as easy as giving.
In practice, the compliance failure is almost never the consent screen. It is everything behind it. A defensible consent record needs, at minimum: the identity of the Data Principal, the purpose consented to expressed in the same terms as the notice, the notice version served, the timestamp, the interface through which it was captured, and the full withdrawal history. If your architecture cannot answer “what did this person agree to, on what date, having been told what?” in a single query, it is not yet a record.
There is a related design point worth stating plainly: bundling. Consent that is conditioned on the provision of a service beyond what is necessary for that service is not valid consent. Product teams routinely bundle marketing permissions into onboarding because it converts better. Under the Act, that is not a growth decision; it is a compliance defect.
Erasure by default
The obligation to erase personal data once the purpose is no longer being served, and consent has been withdrawn, is the requirement that most reliably exposes the gap between a written retention policy and an operating one. Most organisations have the former. Very few have deletion that actually runs — across production databases, analytics warehouses, backups, logs, third-party processors and the spreadsheet on someone’s laptop.
Our practical advice is to treat retention as an engineering deliverable with a legal specification: for each processing activity, a defined retention trigger, a defined period, a defined deletion routine and a defined exception list for data retained under another law. The exception list is important, because the Act preserves retention required by other legal obligations, and organisations frequently either forget those or use them to justify keeping everything.
Breach: two clocks, not one
On becoming aware of a personal data breach, a Data Fiduciary must intimate both the affected Data Principals and the Data Protection Board. The content and timing of those intimations is prescribed, and the two are not the same communication.
The trap is that the DPDP obligation does not displace others. CERT-In directions impose their own reporting timeline for specified cyber incidents, and it is considerably shorter. Sectoral regulators — the RBI in particular — impose further obligations on regulated entities. An incident response plan that maps only to the DPDP Act will miss deadlines that fall first.
The best predictor of how a breach is handled is not the quality of the plan. It is whether anyone has run it before the day it was needed.
Security safeguards, stated as a legal position
The Act requires reasonable security safeguards to prevent a personal data breach, and it is a breach of that obligation — not the breach itself — that attracts the highest penalty ceiling in the Schedule, up to INR 250 crore.
The important word is “reasonable”, which is assessed after the fact, by someone looking at what happened. That makes contemporaneous documentation of the security decisions you took, and why, materially valuable. Encryption, access control, logging, monitoring and a tested restoration capability are the expected baseline; what distinguishes a defensible position is a written record showing that the standard applied was chosen deliberately in light of the data held, and reviewed since.
Where we would start
If a general counsel asked us for the first four things to do, we would say:
- Inventory by purpose, not by system. Systems change; purposes are stable, and the Act attaches obligations to purposes. An inventory organised by database will not survive your next migration.
- Fix the consent record before the consent screen. The screen is a week of work. The record is a quarter, and everything else depends on it.
- Read your processor contracts. Not the new ones. The ones signed in 2019 that nobody has opened since.
- Run a breach exercise. Two hours, on a Tuesday, with the people who would actually be on the call. The gaps it exposes are always the useful ones.
None of this is difficult in the abstract. It is difficult because it is cross-functional, because it has a deadline, and because the parts of it that matter most — the record, the retention routine, the contract chain — are the least visible to anyone looking at the product from the outside.
Disclaimer
This note is published for general information only. It is not legal advice, it does not take account of your particular circumstances, and reading it does not create a lawyer-client relationship with Incept Legal. The law is stated as at the date of publication. Please take advice before acting.