Twelve things, each tied to a provision
16 September 2026
Twelve things to have in place before the DPDP Act commences on 13 May 2027, each tied to the provision that requires it.
Checklists flatten things. This one is ordered roughly by dependency rather than importance: the later items are difficult or impossible until the earlier ones exist.
The single most common sequencing mistake is building consent capture before completing the data inventory. Purpose-scoped consent requires knowing the purposes, and organisations that skip the inventory end up with a well-built consent flow collecting consent for categories that do not match what the business actually does with the data.
The second is treating withdrawal as a user-interface task. Sec. 6(4) is satisfied by a control the Data Principal can reach; it is discharged only when the withdrawal reaches every system that received the data. The control is a week of work. The propagation is the project.
The twelve, in dependency order
| Provision | The control | Evidence to keep |
|---|---|---|
| Sec. 6(1) | An inventory of personal data and the purpose each item is held for. Sec. 6(1) makes consent specific to a purpose, which is impossible to express without knowing the purposes. | The register itself, with an owner named against every purpose and the date it was last reconciled against what the systems hold. |
| Sec. 5(1) | A notice that meets Sec. 5, per purpose. Itemised data, itemised purpose, plus how to withdraw, how to exercise rights, and how to complain to the Board. | Every published version of every notice, kept after it is superseded — the one that matters is the one a particular person saw. |
| Sec. 5(3), Sec. 6(3) | Notice delivery in the Eighth Schedule languages. The choice of language belongs to the Data Principal, across all 22 scheduled languages. | Which language each notice was served in, recorded against the consent, and who approved the translation. |
| Sec. 6(1) | Purpose-scoped consent capture, not a single bundled tick. One consent covering four purposes cannot be selectively withdrawn. | A decision recorded per purpose rather than per form, so a later withdrawal has something specific to act on. |
| Sec. 6(4), Rule 3 | Withdrawal at parity with the consent flow. Sec. 6(4) requires withdrawal to be as easy as giving consent was. | The two routes described side by side. Rule 3 makes the notice carry the withdrawal link itself, with the ease of withdrawing comparable to the ease of consenting. |
| Sec. 6(6) | Downstream propagation of withdrawal. A withdrawal that stops at your database has not been honoured by the processors that already hold the data. | Per withdrawal, the systems that had to act and a timed acknowledgement from each. Sec. 6(6) requires the Fiduciary to cease and to cause its processors to cease. |
| Sec. 6(10) | A tamper-evident consent record. Notice version, language, timestamp and outcome, in a form that can be shown to the Board. | The record is the discharge of Sec. 6(10), which puts the burden of proving that notice was given and consent obtained on the Data Fiduciary. |
| Sec. 11, Sec. 12 | Access and correction routes under Sec. 11 and Sec. 12. Including a summary of the personal data held and who it was shared with. | Each request and what was disclosed. Sec. 11 extends to the identities of other Fiduciaries and processors the data went to, with a description of what was shared. |
| Sec. 13, Rule 14(3) | A named grievance route under Sec. 13. Reachable, answered within a defined window, and recorded. | The clock, per grievance. Rule 14(3) fixes the outer limit of the response at a reasonable period not exceeding ninety days. |
| Sec. 14, Rule 14(4) | Nomination handling under Sec. 14. A Data Principal may nominate someone to exercise their rights on death or incapacity. | The nomination, the identifier it was made against, and the route by which it arrived. |
| Sec. 8(7) | Retention limits, with legal holds carved out narrowly. Other law may require retention of specific records. It does not license retaining everything alongside them. | A retention period per purpose, expressed as a number, and for each hold the provision of law relied on. |
| Sec. 8(6), Rule 7 | Breach detection and reporting under Sec. 8(6). Reporting duties run to the Board and to affected Data Principals. | When it was detected, what each affected person was told, and the report made to the Board. Rule 7 sets what both have to contain. |
Twelve items, in the order they have to be built. The third column is what survives the project and answers a question later.
What the Rules add beyond the Act
The twelve above are the Act's. The DPDP Rules, 2025 — G.S.R. 846(E), notified on 13 November 2025 — say what several of them mean in practice, which is where a checklist item stops being a policy and becomes a specification.
Rule 6 — the safeguards, itemised
Rule 6 sets a minimum for reasonable security safeguards: measures such as encryption, obfuscation, masking or virtual tokens; access control for the computer resources involved; visibility on access through logs, monitoring and review, sufficient to detect, investigate and remediate unauthorised access; measures such as backups so that processing can continue; retention of those logs and of the personal data for one year unless another law requires otherwise; security obligations in the contract with a Data Processor, wherever applicable; and appropriate technical and organisational measures.
Two of those are projects rather than settings. The one-year floor applies to logs a security team may rotate far sooner, and the contractual flow-down moves at the speed of renewal cycles.
Rule 7 — two clocks, not one
To each affected Data Principal, without delay, in concise and plain language, through her user account or a mode of communication she registered: the nature, extent and timing of the breach, the consequences relevant to her, the mitigation measures taken or under way, the safety measures she can take herself, and business contact information for someone who can respond.
To the Board, without delay, a description covering nature, extent, timing, location and likely impact. Then, within 72 hours of becoming aware — or longer, if the Board allows it on a written request — a detailed update: the broad facts and reasons, the mitigation measures, findings on who caused it, remedial measures to prevent recurrence, and a report on the intimations given to affected Data Principals.
The 72 hours governs the second report to the Board, not the first. An incident process built around a single deadline will be late on one of the two.
Rule 8 — erasure classes, a 48-hour warning, and a one-year floor
Rule 8 and the Third Schedule name three classes: an e-commerce entity with two crore or more registered users in India, an online gaming intermediary with fifty lakh or more, and a social media intermediary with two crore or more. For every purpose except enabling access to her user account and to a virtual token on the platform usable for money, goods or services, personal data is erased three years after she last approached the Fiduciary for the purpose or exercised her rights, or three years from the commencement of the Rules, whichever is latest — unless the law requires it to be kept.
Rule 8(2) puts a warning in front of that: at least 48 hours before the erasure, she is told it will happen unless she logs in, makes contact or exercises her rights. Rule 8(3) runs the other way, and it is not confined to those three classes. In respect of any processing it undertakes, or that a processor undertakes on its behalf, a Data Fiduciary keeps the personal data, the associated traffic data and the logs of that processing for at least one year from the date of the processing, so they stay available for the purposes in the Seventh Schedule, and erases them after that unless another law requires them for longer.
Outside the three classes, Sec. 8(7) still applies: erase on withdrawal or when the purpose is no longer served, whichever is earlier, and cause your processors to erase too, unless retention is necessary for compliance with law.
Rule 9 and Rule 14 — a contact, and ninety days
Rule 9 requires the business contact information of the Data Protection Officer, where there is one, or of a person who can answer questions about the processing, to be published prominently and mentioned in every response to a communication exercising rights. Rule 14 requires the means of making a request, and any identifier needed to make one, to be published just as prominently. Rule 14(3) caps the grievance response at a reasonable period not exceeding ninety days. That is a ceiling rather than a target, and a grievance under Sec. 13 has to be exhausted before the Data Principal can approach the Board.
Rule 10 — how parental consent gets verified
Sec. 9 requires verifiable parental consent before a child's personal data is processed. Rule 10 requires due diligence that the person identifying herself as the parent is an identifiable adult, by reference to reliable identity and age details already held, or to details provided voluntarily — directly, or through a virtual token issued by an authorised entity, Digital Locker service providers among them. An organisation that cannot tell which accounts belong to children cannot apply this at all, which makes age a data-model question first.
Rule 13 — only if you are notified
None of Rule 13 applies until the Central Government notifies you as a Significant Data Fiduciary, weighing factors that include the volume and sensitivity of the personal data and the risk to Data Principals' rights. Once notified, Rule 13 requires, every twelve months from notification, a Data Protection Impact Assessment and an audit, with a report of significant observations furnished to the Board; due diligence that technical measures, algorithmic software included, are not likely to pose a risk to Data Principals' rights; and that personal data specified by the Central Government on a committee's recommendation, with its traffic data, is not transferred outside India. Sec. 10(2) adds a Data Protection Officer based in India and an independent data auditor.
The two commencement dates, and the one that might move
Rule 1(2) brought Rules 1, 2 and 17 to 21 into force on publication. Rule 1(3) brings Rule 4 into force one year later — 13 November 2026, when Consent Manager registration opens. Rule 1(4) brings Rules 3, 5 to 16, 22 and 23 into force eighteen months later — 13 May 2027, when everything in the table above has to be working rather than planned.
One caveat on the later date. In January 2026 MeitY proposed compressing the eighteen-month window to twelve, in a stakeholder consultation with comments invited by 4 February 2026. The reporting puts the proposal on Significant Data Fiduciaries rather than on the duty set as a whole — a Data Protection Officer based in India, impact assessments for high-risk processing, and third-party audits, by November 2026. As of this update it stands as a proposal: Business Standard reported it in January 2026, and the Gazette is what settles it. Check there before planning to the later date.