The Aadhaar leak threshold under DPDPA §8(6)

Sample post — full content pending. This is a regulation- analysis post. Tone is practitioner-explainer, not legal advice. Final draft routes through external counsel before publication.

Why this matters

The Digital Personal Data Protection Act, 2023, and its 2025 notified rules created an operational obligation around personal data breaches that India had not previously had at this scale. Layered on top is the Aadhaar Act (and its 2019 regulations) and the CERT-In 2022 directions’ six-hour incident-reporting window. The three regimes do not collide cleanly. This post is a practitioner’s read of where they meet and where they don’t.

What this analysis will cover

1. The text — §8(6) of DPDPA, read carefully
2. The trigger — what counts as a “personal data breach” for notification purposes, and how that differs from a security incident
3. The clock — when 72 hours starts (and the trap most organisations fall into)
4. The Aadhaar overlay — when Aadhaar numbers are involved, what additional obligations attach
5. The CERT-In overlay — how the six-hour window relates to the DPDPA 72-hour window — they are not the same clock
6. The Data Protection Board — what reporting looks like in practice, what the Board has signalled in early enforcement actions
7. A practitioner checklist — five questions to answer before publishing any incident communication

Section 1 — the text

[Verbatim §8(6), then read sentence-by-sentence with annotation.]

Section 2 — what is a breach?

[Five worked examples — a phishing-derived account compromise, a misconfigured S3 bucket, a stolen laptop, a database export sent to the wrong recipient, an insider exfiltration. For each: is it a breach under DPDPA, and if so, when did it become one.]

Section 3 — when the 72 hours starts

[The single most contested operational question. Is it from the incident, from the detection, from the confirmation? What the Act says, what the rules say, and what the Data Protection Board has indicated through early enforcement.]

Section 4 — Aadhaar-involving breaches

[The Aadhaar Act, 2019 regulations, the masked-Aadhaar regime, biometric-locking, Virtual ID, and the additional notification obligation when an Aadhaar number is in the breached dataset.]

Section 5 — CERT-In vs. DPDPA

[Two clocks, two regulators, two scopes. When you must do both. When CERT-In alone applies. When the DPDPA alone applies. Where the two notifications overlap and where they diverge in scope and detail.]

Section 6 — Data Protection Board signals

[Summary of the publicly known enforcement actions to date, with the pattern that emerges from them. What the Board appears to value, what it appears to penalise, and what counsel are advising organisations to plan against.]

Section 7 — checklist

1. Have you confirmed the breach (vs. suspected the breach)?
2. Have you confirmed Aadhaar involvement?
3. Have you logged the start of your 72-hour clock with a timestamp and a named owner?
4. Has your CERT-In six-hour notification gone out, or is it not applicable here?
5. Has your customer communication been reviewed by counsel against the safe-harbour language the Board has accepted?

What we recommend

[Three practical changes for organisations that handle Aadhaar data — and three things that are not recommended despite being asked about regularly.]

Authoring notes — this is an analysis post, not legal advice. External counsel reviews the final draft. We do not publish names of organisations involved in the cited enforcement actions; we work from the public record only.