How relevant are the DPDP Rules in the Indian context, really?

The DPDP Rules 2025 landed with much less drama than the Act they implement. Where the Act was front-page news in 2023, the Rules arrived in a quieter media cycle, mostly read by compliance officers and a handful of journalists on the privacy beat. Most Indian businesses haven't actually read them. The ones who have are still figuring out how literally to take them.

I want to spend this post on a question I keep getting in conversations with Indian DPOs: how well do these Rules actually fit India? Not in the abstract sense of “are they good rules” — that's a debate for academics — but in the practical sense of will an Indian organisation reading them be able to operationalise them without contortion?

The honest answer is: mostly yes, partially no, and the rest we'll only know after the first enforcement actions. Let me unpack what I mean by each piece.

The parts that fit India well

The breach notification window

Section 8(6) of the Act and the corresponding clauses in the Rules give Data Fiduciaries a defined window to notify the Data Protection Board after becoming aware of a personal data breach. The window is calibrated to be tight enough to force operational seriousness but generous enough to give a competent team time to triage and respond.

In the Indian context, this fits well for one specific reason: most Indian organisations have no incident response process today. The 72-hour clock forces them to build one. If the window had been “within a reasonable time”, every organisation would interpret “reasonable” through the lens of their own internal politics, and most would mean “whenever we get around to it”. The hard clock removes the ambiguity, which is exactly what an immature regulatory regime needs.

This part fits.

The grievance redressal mechanism

Section 13 requires every Fiduciary to publish a grievance redressal mechanism with a named Grievance Officer and a defined response window. Indian Data Principals are culturally well-trained on grievance mechanisms — every regulated industry in India (banks, telcos, insurers, regulators) already has a grievance officer because that's how Indian consumer protection works. Indians know how to file a grievance. They know that grievances escalate to the regulator if the first response is unsatisfactory. This is familiar territory in a way that “Data Subject Access Request” is not.

The grievance redressal model in the DPDP Act is essentially borrowed from the Indian banking ombudsman, the IRDAI grievance mechanism, and the SEBI SCORES portal. It works because it's already what people expect.

This part fits very well.

Multi-language notice requirement

Section 5 requires that the notice given to a Data Principal be in their preferred language, drawn from the eighth schedule of the Indian Constitution. The Rules elaborate on what “reasonable” effort means here.

This is the first time an Indian privacy framework has explicitly recognised the linguistic reality of India — that 22 scheduled languages exist for a reason and that a privacy notice in English alone is not actually a notice for the majority of the population. Western privacy frameworks have nothing like this requirement because they were written for jurisdictions with one or two dominant languages. The DPDP Rules take a step that the GDPR has not yet taken.

This is the most India-native provision in the entire framework. It fits perfectly. The operational question is whether organisations will actually do it, or whether they will treat the requirement as performative — which brings us to the parts that don't quite fit.

The parts that don't quite fit (yet)

The Significant Data Fiduciary criteria

Section 10 says the Government can designate any Fiduciary as “significant” based on factors including data volume, sensitivity, processing risk, impact on Indian sovereignty, and risk to electoral democracy. The Rules elaborate on what kind of factors will be weighted.

The fit problem here is that the criteria are still abstract enough to leave most organisations guessing about whether they qualify. This is by design — the Government wants flexibility to designate based on real risk rather than mechanical thresholds — but the practical effect is that most Indian Fiduciaries are sitting in a kind of compliance purgatory. They're not designated, so they don't have to do the SDF obligations (DPO appointment, independent audit, periodic DPIA), but they don't know if they'll be designated next quarter, next year, or never. So they either do the SDF obligations anyway (expensive, possibly unnecessary) or skip them entirely (cheap, possibly catastrophic).

This is uncomfortable for India in particular because Indian organisations are accustomed to clear bright-line thresholds. RBI tells you when you become a Domestic Systemically Important Bank. SEBI tells you when you become a listed entity. The DPDP framework's reluctance to specify SDF criteria is unfamiliar and the natural reaction is to either over-comply or ignore.

My recommendation has been to over-comply quietly — but I recognise that's not financially feasible for everyone. The fit gets better when the Government publishes clearer SDF criteria, and I expect that to happen within the next 18 months as the first sectoral guidance lands.

The cross-border transfer regime

Section 16 gives the Central Government the power to restrict transfers of personal data to specific countries by notification. The default is permissive — you can transfer freely unless the Government has specifically restricted a destination.

The fit problem in the Indian context is that most Indian organisations are already running their primary tech stack on global SaaS vendors that store data abroad — Salesforce in the US, HubSpot in the US, Microsoft 365 in Ireland, Google Workspace in the EU, AWS in Singapore, Slack in the US. The default-permissive regime works fine until the Government issues its first restriction notification, at which point hundreds of Indian organisations will simultaneously discover that their CRM data is sitting in a country that's now off the list.

This is going to be an operational nightmare for the first organisations affected. Most Indian DPOs do not know what country their CRM vendor's primary data centre is in. Most Indian procurement teams have never asked. The Section 16 regime is fine in principle but poorly fitted to a market where the visibility of vendor data residency is currently near zero.

My recommendation: every Indian Fiduciary should build a vendor residency register now, before the first restriction notification, so the discovery work is already done.

The verifiable parental consent for children's data

Section 9 requires verifiable parental consent before processing children's data. The Rules detail what counts as verification.

The fit problem is that India has no national digital identity verification mechanism for parental relationships. We have Aadhaar for individual identity, but Aadhaar does not natively prove that one Aadhaar-holder is the parent of another. You can build a workflow that uses Aadhaar plus a self-attested declaration plus a school ID, but that is not the same as verifiable consent in any robust sense.

The Western privacy frameworks struggle with this too — COPPA in the US has the same problem. But in India, the absence of a national parental verification mechanism means the rule is going to be implemented through a patchwork of organisation-specific workflows, none of which will be very robust. The Data Protection Board will have to choose between accepting weak verification as good-faith compliance or holding Fiduciaries to a standard that does not yet have national infrastructure.

This is a case where the Rule is reasonable in principle but the supporting infrastructure is missing. Expect the Government to publish more specific guidance on verification methods within the next year or two — possibly including a Government-run verification service.

The parts we'll only know after enforcement

This is the most honest section. There are several places in the Rules where the intent is clear but the operational meaning will only become clear after the Data Protection Board takes its first actions.

What “reasonable” security safeguards means

Section 8(5) requires “reasonable security safeguards” to prevent breaches. The Rules elaborate to some extent — encryption, access control, periodic review, breach response — but they don't specify what level of those things is “reasonable”. Reasonable for a 5-person startup is not reasonable for a 5,000-person bank. The Board will have to draw this line case by case, and we don't yet know where the line will be.

My guidance: implement security in proportion to the volume and sensitivity of the data you process, document the rationale, and assume the Board will ask “why this and not more?”.

What counts as “awareness” for the breach notification clock

The 72-hour clock starts when the Fiduciary becomes “aware” of a breach. The Rules don't define awareness operationally. Is it when the SOC analyst opens the alert? When the security team confirms the alert? When the General Counsel reads the email?

The legal interpretation in other jurisdictions has consistently been the earliest of those moments — awareness is a low bar by design. But the Indian Board has not yet stated its position, and that position will be set in stone by the first breach notification case it adjudicates.

My guidance: assume the lowest common denominator. Start the clock at the moment your monitoring system flags the anomaly, not when human analysis confirms it. Better to declare and downgrade than to delay and explain.

How the penalty calculation will weight remediation

Section 33 lets the Board weigh several factors when calculating a penalty, including remediation effort, self-disclosure, and history of compliance. The Rules don't specify the weights.

In my experience, regulators that have to build credibility quickly tend to over-weight good-faith remediation in their early cases — because they want to encourage other Fiduciaries to self-disclose and cooperate. Once the regulator's authority is established, the weights drift back toward a more punitive baseline. But we don't know yet where the Indian Board will start.

My guidance: in the first 24 months of enforcement, expect generous credit for self-disclosure and rapid remediation. Use that window to build a track record of cooperation. Don't be the Fiduciary who tried to hide a violation in 2026 — those will be the cases that get published.

So, are the Rules relevant?

To answer the question I started with: the Rules are highly relevant in the parts that match India's existing regulatory and cultural norms (grievance, multi-language notice, breach clock), partially relevant in the parts that need supporting infrastructure that doesn't yet exist (children's verification, vendor residency tracking), and provisionally relevant in the parts that depend on the Board's still-undefined enforcement posture (security “reasonableness”, awareness, penalty weights).

The honest answer is that the Rules are an excellent first version of what India needs, but they are a first version. They will be refined through enforcement, through sectoral guidance, and through the slow accretion of Board precedent. The Indian organisations that wait for that refinement before engaging with the Rules will have done the worst possible thing — they will have shown up to the test without studying.

The Indian organisations that engage with the Rules now, even where the Rules are imperfect, will discover something useful: the act of trying to comply teaches you what the gaps are, and once you know what the gaps are you can either close them yourself or escalate them to the Government for clarification. The early movers will shape the operational interpretation of the Rules in a way the late movers cannot.

If you've been telling yourself the Rules are too vague to act on, that's the wrong frame. The right frame is: the Rules are a draft of an evolving operational standard, and you can either be a participant in that evolution or a recipient of it. Being a participant is much cheaper.

If you want to start participating right now, our free DPDP assessment maps every question back to a specific section of the Act and the Rules — including the ambiguous ones, where I tell you explicitly what the operational interpretation looks like in 2026 and what's likely to change as the Board makes precedent.