DPDP Rules 2025 Decoded

The Digital Personal Data Protection Rules, 2025 turn the DPDP Act from a principles-based law into a working compliance programme. The Act tells organisations what obligations exist. The Rules explain how several of those obligations must work in practice: what a notice should contain, how breach reporting must happen, what security safeguards are expected, how rights requests should be operationalised, and how children’s data and Significant Data Fiduciary obligations should be handled.

This article decodes the Rules for teams that need to implement them, not just read them.

This article is an operational interpretation, not legal advice. Review the official Rules, the DPDP Act, sector regulations, and counsel guidance before finalising compliance positions.

1. Why the Rules matter

The DPDP Act introduced India’s framework for digital personal data protection. The Rules provide the implementation detail. They matter because they convert broad obligations into system requirements:

• consent notices must be understandable independently of other information;
• withdrawal, rights exercise, and Board complaint routes must be clearly linked;
• breach notifications must go to affected Data Principals without delay;
• breach notifications to the Board have an immediate and a 72-hour component;
• security safeguards now have concrete minimum expectations;
• personal data and processing logs have specific retention and erasure mechanics in defined cases;
• rights workflows need published request channels and identifiers;
• children’s data requires verifiable parental consent;
• Significant Data Fiduciaries face extra governance, audit, DPIA, and data-transfer controls.

2. Commencement and phased implementation

The final Rules were published in the Gazette under notification G.S.R. 846(E) dated November 13, 2025. The PIB explainer describes the DPDP Rules as notified on November 14, 2025 and states that the Rules give full effect to the DPDP Act.

The Rules use a phased start:

• Rules 1, 2, and 17 to 21 commenced from Gazette publication.
• Rule 4 comes into force one year after Gazette publication.
• Rules 3, 5 to 16, 22, and 23 come into force eighteen months after Gazette publication.

What this means

Teams should not treat phased implementation as a reason to wait. Consent, notice, breach, security, and rights workflows touch multiple systems: websites, apps, CRM, data warehouses, support tools, processors, consent stores, incident systems, and audit logs. Eighteen months is implementation time, not strategy time.

3. Consent: what changes in practice

The DPDP Act already required consent to be free, specific, informed, unconditional, unambiguous, based on clear affirmative action, and limited to the specified purpose. The Rules sharpen how that consent must be presented and managed.

Consent is not just a checkbox

Consent must connect to a notice that gives the Data Principal enough detail to make a specific and informed decision. The notice must describe:

• the itemised personal data being processed;
• the specified purpose or purposes;
• the goods, services, or uses enabled by the processing;
• the means to withdraw consent;
• the means to exercise rights;
• the means to complain to the Data Protection Board.

Withdrawal must be designed into the flow

The Rules require the notice to include a specific communication link for accessing the Data Fiduciary’s website or app, and a description of other means, if any, through which the Data Principal may withdraw consent. The withdrawal route should be as easy as the consent route.

Operational interpretation

If consent is captured on a website, in an app, through a campaign, or via a portal, the organisation should be able to prove:

• which notice version was shown;
• what language was shown;
• which specific purpose was selected;
• which personal data categories were covered;
• what affirmative action occurred;
• when consent was given;
• how withdrawal can be performed;
• whether withdrawal propagated to processors and downstream systems.

4. Notice: the new standard is standalone clarity

Rule 3 is one of the most important practical provisions. It says the notice must be understandable independently of any other information that has been, is, or may be made available by the Data Fiduciary.

This means a privacy notice cannot rely on buried terms, scattered FAQs, a generic privacy policy, or vague “we use data to improve services” language.

A compliant notice should answer four questions

1. What personal data is processed?
2. Why is it processed?
3. What can the individual do about it?
4. Where does the individual go to withdraw consent, exercise rights, or complain?

Required notice elements to operationalise

The notice should include:

• itemised personal data;
• specific purpose or purposes;
• the goods, services, or uses enabled by the processing;
• withdrawal route;
• rights exercise route;
• Board complaint route;
• website/app communication link;
• alternate communication means where applicable.

Bad notice patterns

Avoid:

• generic purpose bundles;
• one notice for unrelated data uses;
• privacy policy links without a purpose-specific explanation;
• consent text that is embedded inside unrelated terms;
• no withdrawal link;
• no rights request route;
• no complaint route;
• no record of which notice was shown.

5. Breach reporting: two clocks, two audiences

The Rules make breach reporting concrete. When a Data Fiduciary becomes aware of a personal data breach, there are two notification audiences:

• affected Data Principals;
• the Data Protection Board.

Notification to affected Data Principals

Each affected Data Principal must be informed without delay, in a concise, clear, and plain manner, through her user account or any registered communication mode.

The message should include:

• nature, extent, and timing of the breach;
• consequences likely to arise for the individual;
• mitigation measures implemented or being implemented;
• safety measures the individual may take;
• business contact information for questions.

Notification to the Board

The Board must be informed:

• without delay, with a description of the breach, including nature, extent, timing, location, and likely impact;
• within 72 hours of becoming aware of the breach, with updated and detailed information, unless the Board allows a longer period on written request.

The 72-hour update should include:

• updated breach description;
• broad facts related to events, circumstances, and reasons;
• implemented or proposed mitigation measures;
• findings about the person who caused the breach, if any;
• remedial measures to prevent recurrence;
• report on notifications sent to affected Data Principals.

Operational interpretation

The breach workflow must support:

• awareness-time capture;
• breach classification;
• affected Data Principal identification;
• communication templates;
• Board notification package;
• mitigation tracking;
• root-cause documentation;
• recurrence-prevention controls;
• evidence of individual notifications.

6. Security safeguards: the minimum bar is now explicit

Rule 6 sets out minimum reasonable security safeguards. A Data Fiduciary must protect personal data in its possession or control, including processing undertaken by a Data Processor.

Minimum safeguards include:

• data security measures such as encryption, obfuscation, masking, or virtual tokens;
• access controls for computer resources;
• visibility over access through logs, monitoring, and review;
• measures for continued processing if confidentiality, integrity, or availability is compromised;
• retention of logs and personal data for one year for detection, investigation, remediation, recurrence prevention, and continued processing, unless another law requires otherwise;
• contractual provisions with Data Processors for security safeguards;
• technical and organisational measures to ensure effective observance.

What this means for CISOs

DPDP readiness should be mapped to existing controls:

• IAM and privileged access;
• data encryption and masking;
• logging and SIEM coverage;
• incident response;
• backup and recovery;
• processor security clauses;
• data loss prevention;
• audit evidence.

The important shift is evidence. Security controls must be demonstrable, not merely declared.

7. Retention and erasure: the Rules add mechanics

Rule 8 deals with when a specified purpose is deemed no longer served for certain classes of Data Fiduciaries and purposes listed in the Third Schedule. It also adds a 48-hour pre-erasure notice in those cases.

At least 48 hours before personal data is erased under this rule, the Data Fiduciary must inform the Data Principal that the data will be erased unless the individual logs into her account, otherwise initiates contact for the specified purpose, or exercises rights in relation to the processing.

The Rule also requires retention, in respect of processing undertaken by the Data Fiduciary or on its behalf by a Data Processor, of personal data, associated traffic data, and other processing logs for at least one year for purposes specified in the Seventh Schedule, unless further retention is required by law or government notification.

Operational interpretation

Retention is no longer just a policy table. It needs system behaviour:

• purpose-completion logic;
• last-contact tracking;
• rights-exercise tracking;
• pre-erasure notification;
• processor retention coordination;
• one-year log retention where applicable;
• defensible deletion evidence.

8. Contact information: publish the accountable route

Every Data Fiduciary must prominently publish business contact information on its website or app for the person who can answer questions about processing. If a Data Protection Officer is applicable, the DPO’s business contact information should be used.

This information must also be mentioned in every response to rights-related communication.

Practical impact

Websites, apps, emails, rights portals, and support templates should point to the same accountable privacy contact route. Fragmented contact paths create compliance and SLA risk.

9. Children’s data: verifiable consent is mandatory

Rule 10 requires appropriate technical and organisational measures to ensure verifiable parental consent before processing a child’s personal data.

The Data Fiduciary must also perform due diligence to check that the individual identifying herself as the parent is an adult who can be identified if required under Indian law.

The Rules recognise reliable identity and age details available with the Data Fiduciary, or details voluntarily provided by the individual or through a virtual token issued by an authorised entity.

Operational interpretation

Products that may process children’s data need:

• age detection or declaration;
• guardian flow;
• adult verification mechanism;
• guardian consent record;
• restrictions on tracking, behavioural monitoring, and targeted advertising;
• deletion and rights workflow adapted to child data.

10. Rights handling and grievance response

Rule 13 requires the Data Fiduciary to publish details of the means through which a Data Principal may exercise rights under the Act. It can require identifiers such as username, customer ID, email, mobile number, enrolment ID, application reference number, or licence number to identify the Data Principal under its terms of service.

The Rules also require a system for responding to grievances and appropriate technical and organisational measures to ensure effectiveness.

The PIB explainer states that Data Fiduciaries must address access, correction, updating, or erasure requests within a maximum of 90 days.

Operational interpretation

Rights handling should include:

• request intake;
• identity verification;
• request classification;
• system search;
• processor coordination;
• SLA tracking;
• response approval;
• response delivery;
• audit trail.

Manual email and spreadsheet handling will be difficult to defend at scale.

11. Significant Data Fiduciary obligations

The Rules add operational detail for Significant Data Fiduciaries. They must conduct Data Protection Impact Assessments and audits periodically, and observe due diligence when using algorithmic software for hosting, display, uploading, modification, publishing, transmission, storage, updating, or sharing of personal data to ensure that such software is not likely to pose risk to Data Principal rights.

They must also ensure that certain personal data specified by the Central Government is processed subject to restrictions preventing transfer of that personal data and related traffic data outside India.

Operational interpretation

SDF readiness requires:

• DPIA workflow;
• independent audit workflow;
• board-level privacy reporting;
• DPO accountability;
• high-risk processing register;
• algorithmic system review;
• data localisation controls where notified;
• evidence packs for regulator review.

12. Cross-border transfers

Rule 15 says personal data processed under the Act may be transferred outside India subject to requirements the Central Government may specify by general or special order in respect of making such personal data available to a foreign State, or to any person or entity controlled by or under an agency of such a State.

Operational interpretation

Organisations should maintain:

• data residency map;
• processor and sub-processor list;
• access country map;
• transfer basis;
• contractual safeguards;
• government-order watch process;
• SDF-specific transfer restrictions where applicable.

13. Consent Managers

Rule 4 addresses Consent Manager registration and obligations. It comes into force one year after Gazette publication.

Consent Managers are meant to help Data Principals give, manage, review, and withdraw consent through a transparent and interoperable platform. The Board handles registration and may suspend or cancel registration if conditions or obligations are not met.

Operational interpretation

Even if an organisation is not a Consent Manager, it should design consent systems to interoperate with consent-management patterns:

• consent grant;
• consent review;
• consent withdrawal;
• purpose-level status;
• machine-readable consent state;
• audit trail.

14. What teams should implement first

Consent and notice

• Purpose catalogue.
• Notice template mapped to each purpose.
• Language-ready notice content.
• Consent records linked to notice version.
• Withdrawal flow with downstream propagation.

Breach readiness

• Breach runbook.
• Data inventory tied to affected-person identification.
• Templates for Data Principal notification.
• Board notification package.
• 72-hour update workflow.
• Evidence of mitigation and recurrence prevention.

Security safeguards

• Encryption, masking, tokenisation where appropriate.
• Access control.
• Logging and monitoring.
• Backup and resilience.
• Processor security clauses.
• One-year logs where applicable.

Rights and grievance

• Published request path.
• Identifier model.
• SLA tracking.
• Processor coordination.
• Response evidence.

Children and SDF readiness

• Age and guardian flow.
• Verifiable parental consent.
• DPIA and audit workflow.
• Algorithmic risk review.
• Data transfer controls.

15. Common mistakes after reading the Rules

Mistake 1: Treating notice as a legal page

Rule 3 expects the notice to be independently understandable and directly useful for consent, withdrawal, rights, and complaint routing.

Mistake 2: Treating breach reporting as a security-only task

Breach reporting requires legal, privacy, customer communication, support, engineering, and processor coordination.

Mistake 3: Treating consent as static

Consent must be reviewable, withdrawable, and provable. It must survive scrutiny after the event.

Mistake 4: Ignoring processors

The Rules repeatedly make Data Fiduciaries accountable for processing done on their behalf. Processor contracts and technical controls matter.

Mistake 5: Waiting for the deadline

The work touches product, data architecture, incident response, legal templates, support operations, and vendor management. Waiting compresses implementation risk.

16. How Vishwaas AI maps to the Rules

Vishwaas AI helps operationalise the Rules through:

• notice authoring and versioning;
• multilingual notice readiness;
• purpose-specific consent capture;
• cryptographic consent proof;
• consent withdrawal and downstream propagation;
• Data Principal rights workflow;
• grievance workflow;
• breach response and notification evidence;
• DPIA and SDF governance;
• processor and data-transfer tracking;
• audit-ready evidence packages.

The Rules make one thing clear: DPDP compliance is not a document repository. It is an operating system for personal data decisions.

17. Executive summary

The DPDP Rules 2025 provide the operational detail that organisations were waiting for. The most urgent implementation areas are consent, notices, breach reporting, security safeguards, rights handling, children’s data, retention, and Significant Data Fiduciary readiness.

The organisations that will be ready are the ones that build evidence into daily workflows: every notice version, consent decision, withdrawal, rights request, breach action, processor handoff, and deletion should be traceable.

Sources

• Ministry of Electronics and Information Technology, Government of India: Digital Personal Data Protection Rules, 2025
• Press Information Bureau, Government of India: DPDP Rules, 2025 Notified
• Ministry of Electronics and Information Technology, Government of India: Digital Personal Data Protection Act, 2023