India Compliance

DPDPAPenalties&Enforcement:TheLivingTracker

A living tracker of DPDPA penalties and Data Protection Board enforcement: the ₹250 crore tiers, key deadlines to May 2027, and what early actions signal.

Vasim VayaniJune 11, 2026 8 min read read

This is a living post. We update it as DPDPA enforcement evolves — bookmark it and check back. Last updated: June 2026.

The Digital Personal Data Protection Act spent its first two years as a law on paper. That phase is over. The Rules are notified, the Data Protection Board (DPB) has started acting, and the countdown to full enforcement is running. This tracker keeps the moving parts in one place: the penalty structure, the enforcement timeline, what the Board has actually done so far, and what that should change in your compliance plan.

The Timeline at a Glance

DateWhat happens
14 Nov 2025DPDPA Rules notified, starting the phased implementation clock
Q1 2026First publicly known DPB actions (app developers, invalid consent)
Nov 2026Soft enforcement phase ends
13 May 2027Hard enforcement — the full obligation set is enforceable

Read that table the way the regulator intends: the period between now and May 2027 is not a grace period to begin thinking about compliance. It is the runway to finish building it.

The Penalty Structure: Up to ₹250 Crore, Per Category, Stacking

The DPDPA's penalty schedule sets monetary penalties reaching ₹250 crore per breach category. Three features of the structure matter more than the headline number:

1. The highest tier targets security failures. The top of the penalty schedule is reserved for failure to take reasonable security safeguards to prevent a personal data breach. Not paperwork lapses — security failures. The legislature's signal is unambiguous: if you under-invest anywhere, do not let it be the controls that actually protect data.

2. Penalties stack. Categories are assessed separately, and a single incident can implicate several. Picture a breach where the investigation finds inadequate security safeguards, late notification to the Board, and consent records that do not hold up. Those are distinct categories, each carrying its own exposure. The realistic worst case for one bad incident is a multiple of ₹250 crore, not a ceiling of it.

3. The exposure logic rewards systems, not heroics. Because the heaviest tier is "reasonable security safeguards," your best defence is the ability to demonstrate a functioning security programme: risk assessments, implemented controls, tested incident response, evidence trails. The organisations that will fare worst are not those that had an incident — incidents happen — but those that cannot show they had taken security seriously before the incident.

For the full obligation set behind these penalties — consent, notice, data principal rights, breach notification — see the DPDPA framework guide.

Enforcement Watch: What the Board Has Done So Far

Q1 2026 — first actions, aimed at consent. The first publicly known DPB actions hit app developers over invalid consent. The signal in that choice of target is worth dwelling on:

  • The Board started with the visible, testable violation. Consent flows are observable from the outside — anyone can install an app and inspect what it asks for and how. Expect early enforcement to keep favouring violations the Board can verify without deep forensics.
  • App developers, not just giants. The early docket was not limited to household-name platforms. Mid-sized product companies are evidently within the Board's field of view from the start.
  • "Invalid consent" is a quality bar, not a checkbox. Consent that is bundled, pre-ticked, obscured, or broader than the stated purpose is the kind of consent that fails. If your consent UX was designed for the pre-DPDPA era, it is now a regulatory exposure, not just a UX debt.

What we are watching for next (no predictions, just the watchlist): the first security-safeguards penalty following a breach; the first action arising from a breach notification (or a failure to notify); enforcement posture toward Significant Data Fiduciary obligations as designations and audits mature; and how the Board treats organisations that self-report versus those that are caught. We will update this section as each of these materialises.

The Two-Clock Problem: DPDPA Meets CERT-In

A reminder that belongs in every Indian incident response plan: one personal-data breach can trigger two separate notification obligations to two separate recipients — a report to CERT-In within six hours of noticing the cyber incident, and breach notification to the Data Protection Board under the DPDPA regime. Different clocks, different formats, different framings: CERT-In wants the technical incident; the DPB cares about the personal data breach and affected individuals.

Run them as parallel workstreams from a single incident record, each with a named owner and a deadline timer. Teams using Incident Management wire both notification tracks into the incident workflow so neither clock gets discovered mid-crisis; the CERT-In guide covers the 6-hour regime in detail.

If You Are a Significant Data Fiduciary (or Might Be)

Significant Data Fiduciary (SDF) designation brings a heavier duty set:

  • An India-based Data Protection Officer — a named, accountable individual in India, not a shared mailbox routed abroad.
  • Data Protection Impact Assessments — structured DPIAs for processing that warrants them, documented and reviewable.
  • Independent audits — periodic external scrutiny of your data protection programme, which means your evidence needs to withstand someone else's standards, not just your own.

If there is a plausible case that your organisation gets designated, the rational move is to build to SDF level now. The marginal cost of running DPIAs and audit-grade evidence from the start is far lower than retrofitting them under a designation deadline — and every element of the SDF duty set independently strengthens your position on the "reasonable security safeguards" tier. Organisations that manage their audit cycle in Audit Management typically stand up the DPDPA independent audit as one more programme on the existing calendar: same evidence workflows, new framework mapping.

Your Runway Plan: Now to May 2027

A pragmatic sequencing for the enforcement runway:

By Q3 2026 — close the consent gap. Early enforcement is already here and it is about consent. Audit every consent touchpoint against the Act and Rules: granularity, clarity, withdrawal, records. This is the workstream with a live regulator attached.

By Nov 2026 (soft enforcement ends) — have the security programme demonstrable. Risk assessment done, safeguards implemented and mapped, breach response tested against both notification clocks, evidence organised. "Demonstrable" is the operative word — a control without evidence is, from a regulator's chair, indistinguishable from no control.

By 13 May 2027 (hard enforcement) — full obligation set operational. Data principal rights handling at production quality, retention and erasure actually executing, processor contracts updated, SDF duties live if applicable, and the whole programme on an internal audit cycle so it stays true after the launch push fades.

The trap to avoid: treating May 2027 as the date to start operating. Processes need shakedown time. An erasure workflow that has never run at volume, or a breach playbook that has never been drilled, will fail precisely when the penalty regime makes failure expensive.

What to Have on File Before the Board Ever Calls

A short list of artefacts worth assembling now, because each one is cheap to maintain and expensive to reconstruct after an incident:

  • Consent records that show, per data principal, what was consented to, when, through which interface, and whether it was withdrawn — the early enforcement actions make this the first file a regulator will want.
  • A data inventory mapping what personal data you hold, where it lives, why you process it, and who it is shared with.
  • A security safeguards map linking each safeguard to the risks it addresses, with implementation evidence — your primary defence on the highest penalty tier.
  • Breach response records: the playbook itself, drill reports, and for any real incident, the timeline showing when it was noticed and when each notification went out.
  • Training records demonstrating that the people who handle personal data were told how to.

None of these require waiting for further regulatory clarity. All of them compound: the earlier you start the record, the stronger the demonstrable-compliance story it tells.

How We Keep This Tracker Current

Enforcement is where data protection law gets its real meaning, and India's regime is being defined action by action. We update this post as the DPB acts, as deadlines pass, and as practice hardens — the changelog below records what changed. If your DPDPA programme is still a spreadsheet and a hope, book a demo: we will show you how to run consent records, breach clocks, DPIAs, and audit evidence as one system before the runway runs out.

Changelog

  • June 2026 — Initial publication: penalty structure, Rules notification (14 Nov 2025), enforcement phase dates (Nov 2026 soft-end, 13 May 2027 hard), Q1 2026 DPB actions on invalid consent, SDF duty set, two-clock breach guidance.

This is general information, not legal advice. Penalty exposure and obligations depend on your specific facts — consult counsel.

Tagged
DPDPAData ProtectionPenaltiesEnforcementData Protection BoardIndia CompliancePrivacy

Frequently Asked Questions

Put this into practice
on a platform that ships with it.

See how Compliance Enablers turns what you just read into a running program — templates, automation, and AI, on a single data model.