How prepared are Indian Data Fiduciaries for DPDP, really?

There is a comfortable answer that almost every Indian organisation gives when you ask them how ready they are for the Digital Personal Data Protection Act. It usually sounds like "we have a privacy policy, we've briefed the team, our lawyers are tracking the Rules, we'll be ready when enforcement starts." This answer is reassuring to repeat, easy to put in a board deck, and almost completely disconnected from the operational reality of what DPDP compliance actually requires.

I've spent the last six months in detailed conversations with privacy leads, CISOs, DPOs (where they exist), and CEOs across Indian banking, healthcare, ed-tech, e-commerce, logistics, telecom, and SaaS. The honest readiness picture is more uneven, more sector-dependent, and more time-bound than most boardrooms understand.

Here's the unvarnished version — and the order in which the gaps are best closed.

The five gaps that recur in almost every Indian organisation

If you map the conversations against the actual obligations under the Act, the same five gaps come up in nearly every sector. The relative depth varies — a bank is in a different starting position from a 50-person ed-tech — but the categories don't.

Gap 1 — Consent is still treated as a UX problem, not a data problem

Almost every team I've spoken with has updated their privacy notice and their signup form. Far fewer have updated their data systems to actually honour what the new consent flow promises.

Under DPDP, consent has to be free, specific, informed, unconditional, unambiguous, and itemised by purpose (Section 6). It has to be withdrawable as easily as it was given. And critically — this is where most operations break down — every consent decision has to be evidenced. If the Data Protection Board asks you to prove a particular individual consented to a particular processing purpose on a particular date with a particular notice version shown to them, you need to be able to produce that record.

What "ready" looks like, operationally:

• A consent ledger that records, per individual, every consent decision: the purpose category, the notice version, the timestamp, the IP, the channel, the legal basis, and any subsequent withdrawal.
• A way to retrieve any individual's full consent history in under a minute — because you may have to, on a statutory deadline, when a Data Principal exercises their Section 11 right to access.
• An automated mechanism that enforces the consent state across downstream systems: when someone withdraws consent for marketing, the marketing platform stops emailing them within minutes, not the next sync cycle.

Most organisations have item 1 in a partial form, item 2 not at all, and item 3 only in a single channel. The work to close the gap is real and takes months, not weeks.

Gap 2 — Data Subject Rights have no workflow behind them

Section 11 (right to summary), Section 12 (right to correction and erasure), and Section 13 (right to grievance redressal) are not aspirational. The 2025 Rules pin specific timelines on them. When a Data Principal emails you and says "delete my data," you need a workflow that can:

• Verify the identity of the requester (without exposing them to enumeration attacks)
• Find every system that holds that person's data — including the ones nobody documented
• Perform the requested action across all of them, with audit evidence
• Notify any data processor or sub-processor involved
• Respond to the Data Principal within the statutory window, in a language they can understand

Most teams do not have this workflow today. What they have is a shared mailbox, a vague routing rule, and an engineer who knows how to write a DELETE query. That is not a workflow; that is a hope.

The organisations that close this gap tend to do it by treating DSR fulfilment as a named process: defined SLA, named owner, defined escalation path, audit trail captured automatically, and an evidence pack that can be handed to the Board if a complaint escalates. It is the kind of thing that pays for itself the first time a complaint lands and you can produce a clean evidence trail in 24 hours instead of 24 days.

Gap 3 — Breach response is "we'll figure it out when it happens"

Section 8(6) of the Act requires personal-data breach notification to the Board and to the affected Data Principals. The 2025 Rules pin the Board notification at 72 hours from the moment the Fiduciary becomes aware of the breach. Most Indian organisations I've talked to do not have a 72-hour breach process. They have an incident response process, often built for IT outages, with a privacy escalation bolted on as an afterthought.

The difference matters. A 72-hour clock starts at awareness, not at containment. It runs in parallel with the technical incident response. It requires a discoverable, evidenced decision on whether the incident is a notifiable personal-data breach. It requires drafted notification language for both the Board and the affected Principals, in their language, ready to be sent.

What "ready" looks like:

• A breach intake that captures incident metadata the moment a security team flags it, not after triage
• A 72-hour countdown timer that's visible to the DPO, the CISO, and the legal team simultaneously
• Pre-built notification templates for the DPB and for affected Principals, with the seven mandatory elements from Section 8(6) already present
• An impact analysis worksheet that distinguishes a "security incident" from a "notifiable personal-data breach" with a defensible rationale
• A communication path that can reach the Board and the affected Principals in the right channels and the right languages on a Sunday at 3 am

Almost nobody has all of this in place today. The good news is that closing it is a finite project, measurable in weeks.

Gap 4 — Vendor risk is governed by the lawyer's filing cabinet

DPDP makes the Data Fiduciary fully responsible for the actions of their Data Processors (Section 8). If your CRM vendor mishandles your customers' data, the penalty lands on you, not on the vendor. This is the same principle GDPR established years ago, and it has the same consequence: vendor management is now a privacy operation, not a procurement operation.

What I see today: most Indian organisations have a folder of signed Data Processing Addenda, an outdated vendor inventory, and no automated tracking of which DPA covers which vendor, which version, with which scope, with which expiry. When DPDP penalties start, the first questions from the Board will include "show me your processor inventory" and "show me the DPA on file for vendor X." If the answer is "let me check the filing cabinet," the organisation is exposed.

What "ready" looks like is unglamorous but specific: a vendor inventory with each vendor mapped to (a) the purposes they process for, (b) the categories of personal data they touch, (c) the DPA on file and its expiry, (d) a risk classification, (e) whether they require a DPIA, and (f) the breach-notification SLA they've committed to. Updated quarterly. Owned by the privacy team, not by procurement.

Gap 5 — Training is annual, generic, and forgotten

The Act doesn't explicitly mandate employee training (the EU's GDPR does, via Article 39), but every regulator's enforcement playbook tells you that training is the first line of evidence the Board will ask for. "Show me how your staff is trained on DPDP." "Show me when each person last completed a DPDP module." "Show me the scenarios they practised."

Most Indian organisations have an annual generic privacy training that the workforce clicks through. This is fine as a starting point and almost worthless as a defence. The organisations that are getting ready properly are deploying scenario-based training that puts employees into realistic DPDP situations — what to do when a customer emails asking to delete their data, how to recognise a notifiable breach, how to write a consent prompt that's actually informed — and tracking completion with audit-grade evidence per individual.

This sounds like a lot of work, but it's the single highest-leverage investment if a complaint ever escalates: a clean training record is what turns "your team didn't know" into "your team knew, was trained, and made an unfortunate operational error" — and the penalty math is very different between those two narratives.

Where the sectors actually stand

Painting in broad strokes — every organisation is a snowflake, but the patterns hold:

Banking and large financial services are the furthest along. RBI's existing data governance regime, the long shadow of SEBI cyber-resilience expectations, and the operational habit of regulator-facing reporting mean banks already have most of the plumbing — they just need to re-point it at DPDP obligations. The remaining gaps are usually consent itemisation, vendor risk consolidation, and the 72-hour breach workflow.

Healthcare is bimodal. Large hospital chains and clinical labs have the IT discipline; small to mid-size hospitals often do not, and they're sitting on extraordinarily sensitive data with paper-based grievance processes. The 2025 Rules' children's-data provisions (Section 9) add another layer for paediatric data.

Ed-tech is the most exposed sector by far. They process children's data at scale, often without verifiable parental consent, often with a Western-built consent flow that doesn't map to Section 6, often with vendor stacks rebuilt every six months. The penalty exposure here is real and structural.

E-commerce and consumer internet look better on the surface because they have the engineering muscle, but the gap between engineering capability and privacy programme maturity is enormous. They can build anything; they often don't know what the regulator will ask them to build.

Telecom and logistics sit in the middle. Operational maturity but legacy systems and a vendor sprawl that's hard to inventory.

SaaS for Indian customers — particularly the B2B startups — tends to be in worse shape than they realise. They're often Data Processors and Data Fiduciaries simultaneously, depending on the contract; many haven't drawn that distinction yet.

The order to close the gaps in

If I had a single quarter to close as much exposure as possible, I'd do it in this order:

1. Build the breach workflow first — it's a discrete project, the 72-hour clock is unforgiving, and a publicly-visible breach without a notification process is the single fastest way to attract the Board's attention.
2. Build the DSR workflow second — it's the front door for the most common Data Principal complaint, and it's the only category of failure that compounds (each unanswered request is a separate breach).
3. Consolidate vendor risk third — it's a known unknown and the inventory work is finite.
4. Re-architect consent fourth — it touches engineering, marketing, and product, so it takes the longest, but it's also the one where partial progress is genuinely better than none.
5. Roll out scenario-based training last — the upside is large but only if items 1-4 are real; training people to use systems that don't exist yet is wasted effort.

This is opinionated. Other people will sequence it differently. What matters is that it's sequenced — not done in parallel as a vague "compliance project" with no real timeline.

A closing thought for the CEO

The cost of being early on DPDP is small and front-loaded. The cost of being late is unbounded and reputational.

The organisations that look back in 2028 and say "we did this well" will be the ones whose CEO, in 2026, treated this as an operational programme — owned by a named DPO, funded properly, tracked weekly — and not as a legal review that happens once a quarter. The Act gave you a runway. The runway is closing.

If you want the honest internal readiness score: pick the five gaps above, score each one on a 1–5 scale, multiply, and you'll have an integer somewhere between 1 and 3,125. Most Indian organisations come out under 300. The ones that come out over 1,500 have done real work.

Where would yours score?