DPDP readiness
What India's DPDP Act and Rules ask of a Data Fiduciary, which duties PIEDAP Consent covers, and what stays with your organisation.
For decision makers and Data Protection Officers planning for India's Digital Personal Data Protection Act, 2023 and its Rules of 2025. It shows how far this product takes you.
Summary#
The main duties under the DPDP Rules apply from 13 May 2027. PIEDAP Consent covers the duties that turn on notice, consent and proof. It serves an itemised notice in English and the 22 scheduled languages, and enforces opt-in for India. It records each answer as sealed evidence and keeps withdrawal within reach. It tracks rights requests against a deadline of at most 90 days, keeps a breach register with the 72-hour clock, and can erase people after inactivity.
It does not do your organisation's part. It sends no email or SMS, does not verify a parent and has no DPIA module. Your systems stop their own processing: they ask the consent check before they act, or act on its webhooks. It serves the Data Fiduciary and is not a Consent Manager. Storage, backups and encryption at rest depend on the deployment; this paper is not legal advice.
How to read this paper#
The paper takes the duties of a Data Fiduciary in groups. For each group it says what the product does and what stays with you. Each duty is our short version of the section or rule named beside it.
This is not legal advice
The paper leaves out detail and exceptions, and the law may change after it was written. Read the Act and the Rules, and ask your own counsel how they apply to your business.
In this paper, "a DPDP rule" means an enabled region rule under the DPDP law, which is the preset for India. A region rule decides which form a place sees, and under which law.
The dates that matter#
The Rules were published in the Gazette of India on 13 November 2025. They start in three stages (Rule 1).
| From | What applies |
|---|---|
| 13 November 2025 | Rules 1, 2 and 17 to 21: definitions and the Data Protection Board |
| 13 November 2026 | Rule 4: registration and obligations of Consent Managers |
| 13 May 2027 | Rules 3, 5 to 16, 22 and 23: notice, security, breach, erasure and retention, contact, children, Significant Data Fiduciaries, rights and transfers |
The Act's own sections start on the same three dates, by G.S.R. 843(E) under section 1(2). Two points about the dates are not settled. They are listed under Where the law is not settled.
Who carries the duty#
| Term in the Act | Who it is |
|---|---|
| Data Fiduciary | Your business. It decides why and how personal data is processed |
| Data Principal | The person the data is about. For a child, this includes the parent or lawful guardian |
| Data Processor | Whoever processes data on your behalf. When the product is run for you, its operator is your Data Processor for the consent records |
| Consent Manager | A company registered with the Board that lets people manage consent across many businesses |
| Significant Data Fiduciary | A Data Fiduciary the Government notifies as significant. It has extra duties |
The duties in this paper are yours as the Data Fiduciary. You remain responsible when a processor acts for you (section 8(1)).
PIEDAP Consent is the tool your business uses for its own notices, consents and records. It does not act as a Consent Manager. That is a separate role under section 6(7) to (9) and Rule 4, and it opens for registration on 13 November 2026. The product's consent portal lets a person review and withdraw the consents they gave you, as part of your own duties.
Notice and consent#
| Duty | What the product does | What stays with you |
|---|---|---|
| A notice with every request for consent, readable on its own, in plain language (s5(1); Rule 3) | Under a DPDP rule, the first layer of the banner lists every purpose with its description and data items | Wording that is plain and true. The product does not check reading level |
| Itemised personal data and a specified purpose (Rule 3(b)) | Each purpose has a description and Data used items. Publishing is refused while a purpose based on consent lacks either | Listing the data you really process |
| How to withdraw, use rights and complain to the Board (Rule 3(c)) | The banner carries a Your rights link, the complaint link and the privacy contact. Publishing is refused without the complaint link or the contact | Keeping the link and the contact current, and answering the mail |
| English or any Eighth Schedule language (s5(3)) | A language chooser, with built-in labels and starter wording for all 22 languages. A language other than the form's default is published only after a person approves it | Reviewing each language. The built-in Indian-language text has not been reviewed by native speakers |
| A lawful purpose, on consent or a section 7 use (s4(1), s7) | Each purpose names its basis. A purpose not based on consent names the clause of section 7 it relies on | Choosing the right clause and being able to defend it |
| Free, specific, informed and unambiguous consent by a clear affirmative action (s6(1)) | A DPDP rule is always opt-in. Nothing optional runs before a choice, and pre-ticked defaults are ignored | Not making a service conditional on consent it does not need |
| Proof of notice and consent, if questioned (s6(10)) | Every decision is sealed with the exact form version shown, anchored daily and exportable as a signed receipt | Keeping the link from your identifier to the person, and your copy of the daily anchors |
Three things are enforced, not only supported. Publishing a form served under a DPDP rule is refused with DPDP_NOTICE_INCOMPLETE while a required part of the notice is missing. A DPDP rule cannot be saved as opt-out or notice-only. A form that hides Reject all cannot be published while an opt-in rule serves it.
Proving consent sets out what the evidence shows and where it stops.
Withdrawal and earlier consents#
A person may withdraw at any time, with ease comparable to giving consent (section 6(4)). You must then stop processing within a reasonable time, and make your Data Processors stop (section 6(6)).
The product covers the first part. People withdraw with the privacy button, the consent portal or the hosted request form, and your server can withdraw everything a person agreed to. Each withdrawal is a sealed event.
The second part is yours. The runtime holds a withdrawn purpose's tags and deletes its known first-party cookies; a script that already ran keeps running until the page closes. A consent.withdrawn webhook tells your servers, and the consent check answers withdrawn from the moment the withdrawal is recorded.
For each registered Data Processor the webhook lists a stop task with a due date, and the console tracks what was reported. Passing them on is your step.
Section 5(2) covers people who consented before the Act commenced. You give them the notice as soon as reasonably practicable, and may keep processing until they withdraw. Re-consent on a new form version reaches returning visitors. Others can get single-use notice links your own mailer or SMS gateway sends; the product records who was sent which version and who answered. You can import earlier consents, marked as given before the Act.
Children and guardians#
Before processing a child's data you need the verifiable consent of a parent (section 9(1), Rule 10). A child is anyone under 18. You must not track children, monitor their behaviour or direct targeted advertising at them (section 9(2) and 9(3)).
| Duty | What the product does | What stays with you |
|---|---|---|
| Verifiable parental consent | Your server records the consent with the relationship and the method of verification. Both are sealed into the record. A browser cannot record guardian consent | Finding out that the person is a child, and checking that the person consenting is an identifiable adult parent |
| No tracking or targeted advertising | For a child under the Act, analytics, marketing, personalisation, sale-or-sharing and sensitive-data purposes are stored as refused, unless a Fourth Schedule entry covers the purpose. Marketing and sale-or-sharing are always refused | Putting each purpose in the right category |
| Fourth Schedule exemptions (Rule 12) | A purpose can name the entry it relies on. An entry releases analytics and personalisation, and sensitive data only under the health and location entries | Meeting the entry's conditions |
| A guardian's consent for a person with disability (Rule 11) | The record requires a guardianship order as the method | Checking that the guardian was properly appointed |
The product records your result. It does not check a person's age or a parent's identity.
Rights and grievances#
| Duty | What the product does | What stays with you |
|---|---|---|
| Publish how to make a request (Rule 14(1)) | A hosted privacy notice and request form. Under a DPDP rule the banner links to the form | Publishing the same means in your app and privacy policy |
| A summary of the data, the processing and who it was shared with (s11) | An access request produces a signed receipt for each record, a summary of each purpose, and every partner | Adding the personal data held in your other systems |
| Correction and erasure (s12) | Each request type is tracked with a deadline. Erasing the consent records is one action | Correcting and erasing the data in your own systems |
| Grievance redressal and nomination (s13, s14) | Grievance and Nomination request types, with a timeline. The nominee is stored against the person | Resolving the grievance |
| An answer within a published period of at most 90 days (Rule 14(3)) | Requests from India are due within the project's Response deadline, capped at 90 days. A webhook goes out daily for each request due within five days or overdue | Answering in time |
The hosted request form emails nobody: your systems get a webhook with a confirmation link, and you send it. The request waits until the person follows it.
Retention, erasure and breach#
Erasure on withdrawal or when the purpose is over (section 8(7)). Erasing a person withdraws any consent still in force, then removes the identifying details from each record. A subject.erased webhook asks you to erase your own copy, and lists an erase task for each registered Data Processor. Deciding when a purpose is no longer served is yours.
Erasure after inactivity (Rule 8, Third Schedule). For large e-commerce, social media and online gaming businesses. With Erase after inactivity on, a webhook goes out 72 hours before the period ends, and you send the person the notice the Rules require 48 hours ahead. Without a subscriber, nothing is erased.
One year of logs (Rules 6(1)(e) and 8(3)). Keep evidence for cannot be set below one year, and no record is deleted within a calendar year of its last processing. A record past retention is deleted only when the operator has turned enforcement on.
Breach (section 8(6), Rule 7). The Breach register records each incident and counts down the 72 hours from awareness. It warns your systems 12 hours before the report is due, and drafts the Board report and the notice to people. Detecting the breach, and sending both, is yours.
Security and the remaining duties#
| Duty | What the product does | What stays with you |
|---|---|---|
| Encryption, obfuscation or masking (Rule 6(1)(a)) | Identifiers are stored as keyed hashes. The optional readable copy and stored secrets are encrypted | Encryption in transit and of the database at rest, by whoever runs the deployment |
| Access control (Rule 6(1)(b)) | The console needs an IAM session and is scoped to one project. Keys are bound to origins and scopes | Deciding who gets access, and turning roles on so each person has only what their work needs |
| Logs and monitoring (Rule 6(1)(c)) | An audit log of console changes, reads of personal data in the console, and calls on a person with a secret key. Append-only, downloadable, and readable by your SIEM | Reviewing the logs and keeping the SIEM copy |
| Backups (Rule 6(1)(d)) | None in the product | Database backups and restore tests, by whoever runs the deployment |
| A valid contract with each Data Processor (s8(2)) | None in the product | Your contract with the operator of the deployment |
| A Data Protection Officer, an auditor, a DPIA and a yearly audit, for a Significant Data Fiduciary (s10; Rule 13) | Project settings publishes the officer's contact. Receipts, anchors and the audit log are evidence an auditor can check | The appointments, the assessment, the audit and the report |
| Transfers outside India (s16; Rule 15) | No transfer of its own beyond the webhooks, scans and translation calls you set up. The operator states where the deployment keeps data | Where the deployment runs, where your endpoints are, and which translation service you choose |
Security and data protection covers the first four rows in depth.
What the product does not do#
Every table above assumes this list.
- It sends no email or SMS. Confirmation links, breach notices, the notice before inactivity erasure and replies to requests reach your systems. You send them to the person.
- It has no DPIA module. It neither runs nor stores an assessment, nor performs a Significant Data Fiduciary's audit.
- Data discovery covers websites only. The scanner finds cookies, storage keys and third-party hosts on web pages. It does not look inside mobile apps, databases, servers or files.
- It does not verify a parent or guardian. Your systems do the checking and tell the product which method was used.
- It does not correct your business data. A correction request is tracked here and carried out by your team.
- It does not stop your processing by itself. It holds tags in the browser, tells your servers by webhook and answers the consent check your systems call before they process. Your systems make the call and act on the answer.
- It gives no legal advice. The checks in the product cover only what it can see.
Where the law is not settled#
Plan around these points with your counsel.
- 13 or 14 November. The Gazette issue is dated 13 November 2025. The Government's explainer says the Rules were notified on 14 November. This paper follows the Gazette.
- A shorter timeline was proposed. In January 2026 the Ministry was reported to have proposed cutting the 18 months to 12. We found no Gazette notification making this change by late September 2026.
- The notice for earlier consents. "As soon as reasonably practicable" is not defined. We found no official guidance on timing or channel.
- The start of the inactivity clock. As we read the Third Schedule, its three years cannot start before the Rules commenced. The product starts the clock no earlier than 13 November 2025, the earliest date, so erasure is never later than required.
- The 90 days. Rule 14(3) sets the period for grievances. The Government's explainer describes the same period for access, correction and erasure requests. The product applies the cap to every request type.
- A changed notice. Neither the Act nor the Rules has a separate rule on changing a notice. The product asks returning visitors again after a new purpose, a new partner or a changed legal basis. Adding to the data a purpose uses is not detected.
What to settle before the main duties apply#
The product gives you the mechanism. These decisions are yours.
| Decision | Why it cannot wait |
|---|---|
| The purposes, and the basis for each | Every notice, record and receipt is built on them |
| Who reviews each Indian language | A language other than the default is published only after a person approves it |
| Which identifier you record consent under | It decides whether a rights request finds the record |
Which systems act on consent.withdrawn and subject.erased |
Stopping and erasing in your systems is your duty |
| Who answers requests | The contact is shown in every request for consent |
| How you verify a parent or guardian | The product records the method and does not perform it |
| How a breach reaches the register | The 72 hours run from when you became aware |
| Where the deployment runs, and under what contract | Data location and backups are set by the deployment |
| Whether evidence is deleted after its retention period | Deletion happens only when the operator turns it on |
| Who stores the daily anchors | Your copy is what makes the evidence independent |
How to check your set-up#
The DPDP Act check has its own page in the top bar. It combines what the scanner saw on the site, visiting as someone in India, with the project's set-up and open work. Each check has a status, what was found, the fix and the provision it rests on.
The checks fall into three areas: the site, the set-up, and operations such as overdue requests and breach reports that are due. The check covers what the product can see: a website and this project. It is not an audit of your organisation.
What is at stake#
The Board may impose a penalty after an inquiry. The Schedule to the Act sets the most it may impose for each kind of failure.
| Failure | Up to |
|---|---|
| Not taking reasonable security safeguards to prevent a personal data breach | ₹250 crore |
| Not telling the Board or the affected people about a breach | ₹200 crore |
| Not meeting the duties about children | ₹200 crore |
| Not meeting the extra duties of a Significant Data Fiduciary | ₹150 crore |
| Any other breach of the Act or the Rules | ₹50 crore |
The Schedule has no separate line for notice, rights requests or retention. As we read it, a failure there falls under "any other breach".
Sources and further reading#
The duties are taken from the Gazette texts of the Act and of the Rules (G.S.R. 846(E), dated 13 November 2025), and from the Government's explainer of November 2025.