Resources / Checklist

DPDP Act Compliance Checklist

What the notified DPDP Rules actually require, which dates bind, and the order to do the work in. Read from the Gazette text, with every rule number checked.

Checklist22 min read Updated 7 Nov 2026 For founders, compliance leads, engineering managers and counsel

The Digital Personal Data Protection Act, 2023 has been law for years, but until November 2025 there were no rules under it, so most of its duties had no operative detail. The Digital Personal Data Protection Rules, 2025 supplied that detail, and they commence in stages. The rules that tell a business what to actually do take effect on 13 May 2027.

This checklist is built from two primary sources: the notified Rules as published in the Gazette of India, G.S.R. 846(E), and the Act itself. Every rule number, section number, figure and deadline below was read in one of those two texts rather than taken from commentary, and we say which of the two an obligation comes from, because they are routinely run together and several widely repeated claims are attached to the wrong one. It is not legal advice.

Does this apply to you?

Almost certainly yes. The Act covers any organisation that decides why and how personal data is processed in digital form, and personal data means anything by which a person can be identified. A customer list is personal data. So is a recruitment inbox, a support ticket queue, and the spreadsheet of visitor names at reception once somebody types it up.

There is no revenue threshold and no employee-count exemption. A fifteen-person company processing customer emails carries the same core obligations as a bank, differing in scale and in whether the government later names it a Significant Data Fiduciary.

Work out which role you hold, because the obligations follow from it.

RoleWho it isWhat it means
Data FiduciaryYou decide why and how the data is processedNearly every obligation is yours
Data ProcessorYou process data on someone else's instructionsYour duties flow from your contract with the fiduciary
Data PrincipalThe person the data is aboutHolds the rights you must be able to answer
Note. Most businesses are a fiduciary for their own customers and staff and a processor for their clients at the same time. A SaaS company is a fiduciary for its signup data and a processor for whatever its customers put into the product. Getting this wrong at the start is the most common reason a DPDP programme has to be redone.

The dates that bind

The Rules did not all start on one day. Rule 1 sets three dates, each counted from the date of publication in the Gazette. That date is 13 November 2025: the Gazette issue line reads Thursday, 13 November 2025 and the notification carries the same date. Commentary often says 14 November, which is the date inside the electronic Gazette reference CG-DL-E-14112025 and records when the electronic copy was posted, not when the issue was dated.

ProvisionsRule 1 saysWhich falls on
Rules 1, 2 and 17 to 21: short title, definitions, and the constitution and running of the Data Protection BoardOn the date of publication13 November 2025
Rule 4: registration and obligations of Consent ManagersOne year after publication13 November 2026
Rules 3, 5 to 16, 22 and 23: notice, security safeguards, breach intimation, retention, children's data, rights, transfers and appealsEighteen months after publication13 May 2027
Note. Rule 1 gives the intervals, not the resulting dates. Converting them is arithmetic rather than interpretation, but if a date goes into a policy document, cite Rule 1 and the Gazette date alongside it.

What this means for you today

This is where most published guidance goes wrong. Articles describe the seventy-two-hour breach report and the notice requirements as obligations that apply now. They do not yet. Rule 7 is among the rules deferred by Rule 1(4) and commences on 13 May 2027 with the rest of the substantive set.

So you are not in breach today for having no Rule 7 process. You will be in about eighteen months, and the work takes longer than eighteen months if your personal data is spread across systems nobody has mapped. Treating the date as distant is the mistake; treating the obligation as current is merely inaccurate.

The one earlier date is 13 November 2026, when Rule 4 brings Consent Manager registration into force. That binds entities that want to operate as Consent Managers, which is a narrow group. If you are not registering as one, it does not apply to you.

The consent standard itself is in section 6 of the Act rather than the Rules: consent must be free, specific, informed, unconditional and unambiguous, given by a clear affirmative action, and limited to the purpose stated. Pre-ticked boxes do not meet it, and neither does bundling consent for processing the service does not need into access to the service.

What the Rules add is the notice, in Rule 3. It must be presented and understandable independently of any other information you make available, which means it cannot be a clause inside your terms of service. It must give, in clear and plain language, a fair account of the details necessary for specific and informed consent, including at minimum an itemised description of the personal data and the specified purposes, with a specific description of the goods or services to be provided or the uses to be enabled.

Rule 3(c) then requires the notice to carry the particular communication link for your website or app, and a description of any other means, by which the person can withdraw consent, exercise their rights under the Act, and complain to the Board. The withdrawal requirement has a standard attached: the ease of withdrawing must be comparable to the ease with which consent was given. If signing up takes one click and withdrawing takes an email to support, that test fails. It is the most common gap in Indian consent flows today.

Consent is not the only lawful basis. The Act also permits certain legitimate uses, among them processing where a person has voluntarily provided data for a purpose and has not objected, and employment-related purposes. Mapping which of your processing rests on consent and which on a legitimate use is worth doing early, because it determines how much consent machinery you have to build at all.

Consent you already hold does not automatically carry over in the form you hold it. If your records do not show what was consented to, when, and how it can be withdrawn, assume you will need to collect it again.

There is a language requirement, and it is in the Act rather than the Rules, which is why summaries of the Rules leave it out. Section 5(3) requires the Data Fiduciary to give the person the option to access the contents of the notice in English or any language specified in the Eighth Schedule to the Constitution. Section 6(3) extends the same option to every request for consent, which must also be presented in clear and plain language and carry the contact details of the Data Protection Officer, where applicable, or of another person authorised to answer on your behalf.

Read that carefully before costing it. The duty is to offer the option, not to publish a wall of translations by default, and the Eighth Schedule currently lists twenty-two languages. But the option has to be real when someone takes it, which means notice and consent text is content to be translated, reviewed and version-controlled rather than a string in a template. Of everything in this article it is the requirement with the longest lead time for an engineering team, and the one least often budgeted for.

Note. Rule 3 itself says nothing about language beyond requiring clear and plain language, so working from a summary of the Rules alone will cause you to miss this. Working from a summary of the Act, you may instead see it overstated as a duty to make the notice available in all twenty-two languages on request. The duty is to offer the option of English or an Eighth Schedule language.

The requests you must be able to answer

The rights themselves are in sections 11 to 14 of the Act. Rule 14 says what you have to put in place to serve them, and each one is an operational process rather than a paragraph in a privacy policy.

Rule 14(1) requires you to publish prominently, on your website or app or both, the means by which a person makes a request, and the particulars you need in order to identify them. Rule 14(5) defines that identifier broadly: a customer identification file number, a customer acquisition form number, an application reference number, an enrolment ID, an email address, a mobile number or a licence number.

RightWhat a person can askWhat you need in place
AccessA summary of their data and who it was shared withA way to find every copy across your systems
Correction and erasureFix what is wrong, erase what you no longer needDeletion that reaches backups, warehouses and processors
Grievance redressalA complaint route, answered within your published periodA named channel and a tracked queue
NominationName someone to act for them if they die or are incapacitatedA field, and a process that honours it
Note. Access is the right that exposes bad data hygiene. Answering what do you hold about me, and who did you give it to requires knowing where personal data lives. Most organisations discover at this point that it is in a CRM, a support tool, three spreadsheets, an analytics platform and a vendor nobody has a contract with. The data map is the prerequisite and it takes the longest.

Two small rules that are easy to miss

Rule 14(3) requires every Data Fiduciary and Consent Manager to publish a grievance redressal response period not exceeding ninety days, and to implement appropriate technical and organisational measures to actually respond within it. Ninety days is a ceiling, not a target. Publishing ninety days tells a reader that complaints are not a priority, and because a person must exhaust your process before approaching the Board, a slow published period mostly delays your own escalations.

Rule 9 requires you to publish the business contact information of your Data Protection Officer, if you have one, or of a person who can answer questions about your processing, and to mention it in every response to a communication exercising a right. Not only on a page: in each reply.

Erasure has a floor as well as a ceiling

This is the part that contradicts the way erasure is usually described, and it is worth reading the rule rather than a summary of it.

Rule 8(3) requires a Data Fiduciary to retain the personal data, the associated traffic data and the other logs of any processing for a minimum of one year from the date of that processing, for the purposes set out in the Seventh Schedule, and then to erase them, unless some other law requires longer retention. The Seventh Schedule purposes are State access: use by the State in the interest of the sovereignty, integrity or security of India, and disclosure under applicable law.

The illustration in Rule 8 is blunt about the consequence. An e-book platform must keep the order details, the personal data and the processing logs for at least a year from the transaction even if the customer deletes her account, and it must ensure its cloud processor does the same.

So erasure is not simply delete on request. You have a duty to be able to erase and a duty not to erase too early, and the two have to be reconciled in one retention design. A deletion pipeline that purges immediately and completely on request fails the second duty as surely as having none fails the first.

Rule 8(1) and the Third Schedule add a separate clock, and it reaches three classes only: an e-commerce entity with at least two crore registered users in India, an online gaming intermediary with at least fifty lakh, and a social media intermediary with at least two crore. For those, personal data must be erased three years after the person last approached them for the specified purpose or exercised their rights, or three years after the Rules commence, whichever is latest, with account access and stored virtual tokens carved out. Below those thresholds this clock does not apply to you, which is not what most checklists imply.

Note. Rule 8(2) adds a courtesy with teeth. At least forty-eight hours before erasing under that clock you must tell the person it is about to happen, so they can log in or make contact and keep the account alive.

Security safeguards: seven minimums, not a principle

Rule 6 does not say take reasonable measures and leave it there. It lists seven minimums, and they are worth treating as an audit checklist, because that is how they will be used.

  • Data security measures such as encryption, obfuscation, masking, or virtual tokens mapped to the personal data
  • Measures to control access to the computer resources used by you or by your Data Processor
  • Visibility on the accessing of personal data, through logs, monitoring and review, sufficient to detect unauthorised access, investigate it and prevent recurrence
  • Reasonable measures for continued processing if confidentiality, integrity or availability is compromised, such as data backups
  • Retention of those logs and that personal data for one year, unless a law in force requires otherwise
  • A term in the contract with each Data Processor providing for reasonable security safeguards
  • Appropriate technical and organisational measures to ensure the safeguards are effectively observed
Note. Two things follow. You cannot report a breach you cannot detect, so clause (c) is the precondition for Rule 7 rather than a separate nicety. And the one-year log retention in clause (e) is an obligation in its own right, which teams running thirty or ninety day log retention for cost reasons tend to miss entirely.

Breach reporting

Rule 7 runs two clocks and both start at the same moment: becoming aware of the breach.

The affected person must be told without delay, through her user account or a mode of communication she registered with you, in a concise, clear and plain manner. The intimation has to cover the nature, extent and timing of the breach, the consequences likely to arise for her, the measures you have taken and are taking to mitigate risk, the safety measures she can take herself, and business contact information for someone who can answer her questions.

The Board gets a description without delay, covering nature, extent, timing, location and likely impact. Then, within seventy-two hours of your becoming aware, or within a longer period if the Board allows it on a written request, it gets a detailed report: updated detail, the broad facts and reasons leading to the breach, measures implemented or proposed, any findings about who caused it, remedial measures to prevent recurrence, and a report on the intimations you gave to affected people.

There is no materiality threshold. The rule attaches to any personal data breach and says so in both sub-rules. On the text, a single misdirected email containing personal data is reportable. That is a stronger obligation than most incident processes assume, and it argues for a low-friction reporting path rather than a committee that meets on Tuesdays.

The last element of the detailed report is the one that shapes the runbook. You have to tell the Board what you told the affected people, which puts drafting the customer notification on the seventy-two-hour path rather than after it. Write the template now, while nothing is on fire.

Note. This concerns the Rules only. Other obligations are in force today and impose their own, shorter reporting deadlines, including the CERT-In directions of 28 April 2022.

Children's data

Processing the personal data of anyone under eighteen requires verifiable parental consent. Rule 10(2) defines an adult as someone who has completed eighteen years, which is higher than the thirteen-to-sixteen thresholds many global products are built around. A platform designed for a sixteen-year-old minimum age in other markets is not compliant here without change.

Rule 10(1) is more specific than get parental consent. You must adopt technical and organisational measures to ensure the parent's verifiable consent is obtained before any processing of the child's personal data, and observe due diligence to check that the person identifying as the parent is an identifiable adult: by reference to reliable identity and age details you already hold, or details voluntarily provided, or a virtual token mapped to such details issued by an authorised entity, which the rule says includes details made available and verified by a Digital Locker service provider.

The four illustrations in Rule 10 read as test cases, and the distinction they draw is the one to build to: where the parent is already a registered user you check the details you hold, and where she is not you need details issued by an entity entrusted with them by law or by government, or a token mapped to them. If your product can be used by under-eighteens, and most consumer products can whatever the terms say, this needs a design decision rather than an assumption.

If you might be named a Significant Data Fiduciary

Significant Data Fiduciary is a designation, not a size. The government names them under the Act, taking into account the volume and sensitivity of the personal data processed and the risk to data principals, among other factors. You do not opt in and you may not know in advance.

It is worth being precise about which obligations come from where, because they are routinely run together. Most of them are section 10(2) of the Act, not the Rules. The Act requires a Data Protection Officer who represents you under the Act, is based in India, is responsible to your board of directors or similar governing body, and is the point of contact for grievance redressal; an independent data auditor to evaluate your compliance; and periodic Data Protection Impact Assessments and periodic audits.

Rule 13 does not repeat any of that. What it adds is the period the Act left open, a reporting duty, and two further obligations that are rarely mentioned at all.

  • The period the Act leaves unspecified: the assessment and the audit must be undertaken once in every twelve months from the date you are notified as significant
  • A report to the Board containing the significant observations from that assessment and audit
  • Due diligence to verify that technical measures, including algorithmic software, used for hosting, display, uploading, modification, publishing, transmission, storage, updating or sharing of personal data are not likely to pose a risk to the rights of data principals
  • Measures ensuring that personal data specified by the Central Government is processed subject to the restriction that it, and the traffic data about its flow, is not transferred outside India
Note. The last two rarely appear in summaries. Rule 13(3) makes a recommendation or ranking engine a compliance surface and not just a product feature. Rule 13(4) is a localisation power whose categories are to be specified by the Central Government on a committee's recommendation and are not in the Rules, so no Significant Data Fiduciary can finish its data-residency design from the Rules alone.

Sending personal data outside India

Rule 15 is short and often read as a liberalisation. Personal data may be transferred outside India subject to the restriction that the Data Fiduciary meets whatever requirements the Central Government specifies, by general or special order, in respect of making that data available to a foreign State, or to a person or entity under the control of or an agency of such a State.

There is no whitelist in the Rules, no adequacy mechanism and no standard contractual clause regime. There is a reserved power. Plan on the basis that transfers are permitted today and that conditions can be added by order, and keep a record of where personal data actually goes, so that a future order can be answered without a discovery project.

Checklist: find out what you hold

In order. Each block depends on the ones above it, which is why programmes that start at the consent banner stall: you cannot write an accurate notice before you know what you collect.

  • List every system that touches personal data, including spreadsheets and SaaS tools nobody formally approved
  • For each, record what is collected, why, where it is stored, how long it is kept, and who it is shared with
  • Identify where you are a Data Fiduciary and where you are a Data Processor
  • Flag any processing of the personal data of under-eighteens
  • Note which personal data leaves India, and to whom
  • Decide, for each purpose, whether you rely on consent or on a legitimate use
  • Rewrite the notice so it stands alone: itemised data, specified purposes, the goods or services provided, how to exercise rights, how to complain to the Board
  • Put withdrawal in the same place as consent, at comparable ease
  • Check whether the consent you already hold meets the standard, and collect it again if it does not

Checklist: build the processes

  • A route for access, correction, erasure and nomination requests, with an owner and a tracked queue
  • The request means and the identifier you require, published prominently
  • A published grievance response period below the ninety-day ceiling, with the measures to actually meet it
  • Contact information for questions about processing, published and repeated in every rights response
  • Retention that erases on time without erasing before the one-year floor
  • Verifiable parental consent where children's data is in scope

Checklist: secure it, and be able to prove you did

  • Encryption, masking, obfuscation or virtual tokens for personal data
  • Access controls on every system from the first block, reviewed
  • Logs, monitoring and review sufficient to detect unauthorised access
  • Log and personal data retention set to at least one year
  • Backups, and a restore you have actually tested
  • A security clause in the contract with every Data Processor

Checklist: prepare for the bad day

  • A breach runbook naming who decides it is a breach, who intimates the Board, and who tells affected people
  • A drafted notification template for data principals, so the seventy-two-hour window is not spent writing
  • A drafted Board report template covering all six elements of Rule 7(2)(b)
  • One rehearsal before 13 May 2027
Note. If you do only one thing this quarter, do the first block. Every other item is guesswork until the data map exists, and the data map is the part that cannot be bought in a hurry.

Does the DPDP Act apply to a small business?

Yes. There is no turnover or headcount exemption. A company of any size that decides why and how personal data is processed is a Data Fiduciary and carries the core obligations. Only the Significant Data Fiduciary designation, which brings the extra duties in Rule 13, depends on scale and risk.

When is the DPDP compliance deadline?

13 May 2027 for the substantive rules, being eighteen months after the Rules were published in the Gazette on 13 November 2025. Consent Manager registration under Rule 4 starts a year after publication, on 13 November 2026, but that binds only entities registering as Consent Managers.

Do we have to report every breach within seventy-two hours?

Every breach, yes, once Rule 7 commences; within seventy-two hours, not quite. The Board gets an initial description without delay and the detailed report within seventy-two hours, extendable if the Board allows it on a written request. Affected people must be told without delay. There is no materiality threshold in the text, so the obligation covers every personal data breach rather than only the serious ones.

Is DPDP the same as GDPR?

No. The structures rhyme, but DPDP has no legitimate-interest basis of the GDPR kind, sets the child threshold at eighteen rather than thirteen to sixteen, relies more heavily on consent, and adds a minimum retention floor that the GDPR has no equivalent of. A GDPR programme is a useful head start, not a substitute, and the retention design is the part most likely to need rework.

What happens if we do nothing?

Penalties are imposed by the Data Protection Board after an inquiry, and the maxima are in the Schedule to the Act, read with section 33. Two of the figures circulate widely and both are correct. The rest of the Schedule is quoted far less often and is worth seeing whole, because the catch-all in the last entry is what most breaches of the Rules would actually be charged under.

BreachPenalty may extend to
Failing in the obligation to take reasonable security safeguards to prevent a personal data breach, section 8(5)250 crore rupees
Failing to give the Board or the affected person notice of a personal data breach, section 8(6)200 crore rupees
Breach of the additional obligations in relation to children, section 9200 crore rupees
Breach of the additional obligations of a Significant Data Fiduciary, section 10150 crore rupees
Breach of the duties of a Data Principal, section 1510 thousand rupees
Breach of any other provision of the Act or the Rules made under it50 crore rupees
Note. The penalty on the Data Principal is the entry that surprises people: the Act places duties on the individual too, and a breach of them can draw up to ten thousand rupees. It is a small number attached to a real deterrent against false or frivolous complaints. Note also that the practical risk arrives well before enforcement does, because enterprise customers have already begun asking about DPDP readiness in procurement, and an answer of not yet started loses deals long before a regulator calls.

References

Keep reading