What the DPDP Rules actually change for consent, breach reporting and children's data

The Digital Personal Data Protection Act, 2023 gave India a data protection statute. The Rules give it teeth — and, more importantly for anyone actually building systems, they convert broad principles into specifications you can hold an engineering team to.

We have now run DPDPA readiness programmes across healthcare, financial services, retail and SaaS. The pattern is consistent: organisations read the Act, conclude it is a lighter GDPR, and are then surprised by three specific requirements that are materially harder than their GDPR equivalents.

Notice is a product surface, not a document#

Under GDPR, most organisations satisfy transparency with a well-structured privacy notice page. Layered, narrative, one language, occasionally translated.

DPDPA works differently. The notice must be itemised — a clear enumeration of the personal data being collected and the specific purpose for each. And it must be available in English or any language in the Eighth Schedule to the Constitution, at the data principal's option.

That phrase does the damage. "At the data principal's option" means the choice is theirs at the point of collection, which means your application has to offer it. You cannot satisfy this with a footer link to a translated PDF.

In practice this means:

• A language selector present wherever consent is captured, not buried in account settings.
• Notice content stored as structured data keyed by purpose and language, rather than as prose in a CMS.
• A release process that prevents a new data field shipping before its notice entry exists in every offered language.
• Version pinning, so you can prove which notice text a specific data principal saw on a specific date.

The last point is the one teams miss. When a regulator or a data principal asks what someone was told, "here is our current privacy notice" is not an answer.

The breach duty has no materiality filter#

This is the single most commonly misread obligation in the Act.

Under GDPR Article 33, you notify the supervisory authority unless the breach is unlikely to result in a risk to rights and freedoms. Under Article 34, you notify individuals only where there is a high risk. Two thresholds, both filtering.

DPDPA's structure is different. The obligation to intimate affected data principals is not conditioned on a risk assessment. In operational terms: a laptop containing a spreadsheet of 400 customer records is lost, the disk is encrypted, and there is no realistic prospect of access — under GDPR you would likely document the assessment and not notify. Under DPDPA, the safe reading is that you notify.

That has consequences well beyond the privacy team:

• Volume. Your notification tooling needs to handle events you would previously have closed internally.
• Communications. Customer support, PR and account management need pre-approved templates, because low-severity notifications will be frequent enough to need a routine.
• Detection. If you must notify on everything, you need to actually know about everything. Incomplete logging becomes a compliance exposure rather than an operational inconvenience.

And this sits on top of CERT-In's six-hour reporting window, which has its own trigger list, its own recipient and its own clock. One incident, several parallel obligations.

Verifiable parental consent under 18#

GDPR sets the digital consent age between 13 and 16 depending on member state. DPDPA sets it at 18, and requires verifiable consent from a parent or lawful guardian below that.

Consider what that means for an Indian consumer platform. A material share of your user base may be under 18. For each of them you need:

1. A reliable determination of age — which itself requires collecting data you would otherwise minimise.
2. Identification of a parent or lawful guardian.
3. A verification mechanism that is genuinely verifiable, not a checkbox asserting parental status.
4. A record of that verification, retained and auditable.

Additionally, tracking, behavioural monitoring and targeted advertising directed at children are prohibited outright. For an ad-funded product this is not a consent question — it is a product architecture question, because you must be able to suppress those systems reliably for a subset of users.

The organisations handling this well are treating age assurance as a first-class platform capability with its own service boundary, rather than a field on the user table. The ones struggling are trying to bolt it onto a signup form.

Withdrawal must actually stop things#

DPDPA requires that consent be as easy to withdraw as to give, and that on withdrawal the fiduciary cease processing and erase the personal data unless retention is legally required.

Read that as an engineering requirement and it becomes demanding. Withdrawal must:

• Propagate to every system that received the data, including analytics warehouses, CRM, marketing automation, ad platforms and partner feeds.
• Trigger erasure, not merely suppression — a marketing_opt_out = true flag is not erasure.
• Reach processors, with evidence that they complied.
• Complete within a defensible period, and be provable afterwards.

Test this with a seeded identity: withdraw consent, then check each downstream system yourself. The results are consistently sobering — a data footprint spread across dozens of systems typically has only a handful actually honouring a withdrawal. That single test is worth running before anyone tells a board the organisation is DPDPA-ready.

Where to start#

If you are early, the sequence that works is:

None of that requires a platform purchase, and all of it produces evidence you will need regardless of which route you take afterwards.

Plan on being a Significant Data Fiduciary#

The Central Government designates Significant Data Fiduciaries based on the volume and sensitivity of personal data processed, the risk to data principals' rights, and potential impact on India's sovereignty and integrity, electoral democracy, security of the State and public order.

That is a discretionary test, not a threshold you can compute. Which means the useful question is not "are we one?" but "what would it cost us to be treated as one, and how much of that should we do anyway?"

Three additional duties attach:

An India-based Data Protection Officer accountable to the board. Not a nominated contact — an appointed officer with a reporting line to the governing body. Getting this wrong is expensive to unwind, because the reporting line is the part that takes months to establish politically.

An independent data auditor. Someone outside the programme, evaluating it. Organisations that have never commissioned an independent privacy audit consistently underestimate how much evidence this requires, because internal reviews tend to test whether documents exist rather than whether controls operate.

Periodic Data Protection Impact Assessments and audits. Not one DPIA for the flagship product — a standing methodology applied on a defined cadence, with the results going somewhere.

Our advice to large consumer platforms, financial institutions, health providers and telecom operators is to assume designation and build accordingly. The marginal cost over a well-run non-designated programme is smaller than most boards expect — perhaps fifteen to twenty per cent — and the alternative is retrofitting a statutory reporting line and an audit trail under a deadline you did not set.

What to put in front of your board#

The board question is rarely "are we compliant?" It is "what is our exposure, and is it going up or down?" Four numbers answer it:

• Coverage — what proportion of systems holding personal data are in the verified inventory. Below 100%, everything else is an estimate.
• Consent propagation — how many downstream systems honour a withdrawal, tested rather than assumed. This is the number that changes conversations.
• Rights fulfilment — median days to close a request, against the statutory window. Trend matters more than the absolute.
• Open high-risk processing — activities running without a completed impact assessment, with named owners and dates.

Report those four every quarter and the board can see direction. Report a maturity score out of five and they cannot.

If you want a scored starting position rather than a blank page, our free Digital Trust assessment(opens the assessment platform in a new tab) covers DPDPA readiness alongside security and AI governance, and takes about fifteen minutes.