It’s 2:47 AM on a Tuesday. Your PagerDuty wakes you up. A customer has tweeted a screenshot of what looks like your production database on a Telegram channel. Your heart rate spikes. You have approximately 72 hours before the Data Protection Board of India expects to hear from you.
This module is about what happens between that 2:47 AM page and the Board notification filed 65 hours later. It is the most operationally consequential module of the DPDP Practitioner path. By the end, you will have:
- A role-by-role map of who does what in the first 2 hours, 24 hours, and 72 hours
- The exact contents the Board will expect in your notification
- A tabletop scenario you can run with your team next week
- A checklist of the 12 pre-breach controls that reduce both the probability of a breach and the penalty range if one occurs
Why tabletop exercises matter
Every organisation has an incident-response plan on paper. Very few have tested it. The first time a team runs their plan for real — at 2:47 AM, with stakeholders panicking, with partial information, with evidence being destroyed in real-time — is the worst possible moment to discover that the plan has holes.
Tabletop exercises are the discipline of rehearsing the plan in a low-stakes setting: a conference room, a fictional scenario, a few hours, your actual team. They reliably surface three classes of gap:
- Gaps in the plan itself — steps that are under-specified, decisions without owners, escalation paths that dead-end
- Gaps in capabilities — “we’d need to pull X from Sentry” — but can we actually? Who has access? What if Sentry is down?
- Gaps in alignment — different team members have different assumptions about what “notify the Board” means, or who signs off on customer communication
A 3-hour tabletop surfaces gaps that would take weeks to discover during a real incident. For an SDF, regular tabletops are essentially required — for a smaller organisation, they are the single best investment in compliance readiness.
What counts as a breach under DPDP
Section 2(u) defines “personal data breach” as unauthorised processing of personal data, accidental disclosure, acquisition, sharing, use, alteration, destruction, or loss of access to personal data that compromises the confidentiality, integrity, or availability of the data. In practical terms:
- External attacker exfiltrates your user database — breach
- Insider (employee or vendor) downloads customer data without authorisation — breach
- S3 bucket is misconfigured and personal data becomes publicly accessible — breach (even if you don’t know anyone actually accessed it)
- Laptop with unencrypted exports is lost — breach
- Accidental mass email CC leak — breach
- Ransomware encrypts your database (availability compromised) — breach even without exfiltration
- Support agent emails a different customer’s data to the wrong person — breach (small-scale but still reportable)
- A third-party SaaS you use has a breach affecting your data — breach (cascading)
What is NOT a breach: a security incident that was contained before any personal data was accessed (e.g. an attempted SQL injection that your WAF blocked); a deliberate data-sharing flow the user consented to; a routine system outage with no confidentiality/integrity/availability impact on personal data.
The timeline — who does what, when
T+0 to T+30 minutes — detect and contain
The clock starts when the breach is detected, not when it occurred. But if you detect late, that delay will count against you in the Board’s assessment.
- Whoever detects (engineer, support, customer tweet) — escalate within 10 minutes to the Incident Commander on-call. Don’t wait to confirm; false positives are cheap compared to delays.
- Incident Commander (usually engineering lead or CTO) — acknowledge within 5 minutes of escalation. Open an incident channel (Slack / Teams). Begin the runbook.
- First action — contain without destroying evidence. If a compromised account is active, rotate credentials or revoke sessions. If data is being exfiltrated, block the egress path. DO NOT immediately delete attacker artefacts — they are forensic evidence. DO preserve logs by export before they roll.
T+30 min to T+2 hours — assess scope
- Incident Commander declares preliminary severity (Low / Medium / High / Critical). Anything with confirmed exfiltration is High minimum.
- Forensic lead begins timeline reconstruction — how did the attacker get in, how long were they present, what did they access.
- Data Protection Officer (or delegated lead) is notified and joins the incident channel.
- CEO/Founder is notified for any High or Critical incident. They will ask questions you cannot yet answer — set expectations: “We’ll have initial scope within 4 hours.”
- Legal is notified. If you have external counsel, loop them in now.
- Preserve: snapshot the affected systems, export relevant logs, take hashes of evidence artefacts. Evidence integrity matters for later investigations.
T+2 to T+24 hours — investigate and plan communications
- Forensics completes a preliminary incident report: attack vector, systems accessed, data categories likely exposed, rough count of affected Data Principals.
- DPO drafts the preliminary Board notification based on the information available.
- Legal reviews notification drafts and advises on public communication risk.
- Communications drafts two parallel tracks: Data Principal notification (per-user email) and public statement (blog post / press release if the breach is likely to become public).
- Engineering continues remediation: close the vulnerability, rotate credentials, patch systems, add detective controls so you’d catch the same attack earlier next time.
- CEO signs off on scope of internal and external communication.
T+24 to T+72 hours — notify
- Board notification submitted via the official channel (portal or designated email) before the 72-hour window closes.
- Affected Data Principals notified individually with clear language about what happened, what data of theirs was involved, what you’re doing, and what they can do (change passwords, monitor accounts, request a data export).
- Public statement published if warranted. Proactive disclosure is generally better than reactive.
- Business continuity — continue serving customers while investigation is ongoing. Don’t shut down the service unless absolutely necessary for containment.
T+72 hours onwards — remediate and report
- Continue the investigation until root cause is confirmed and remediated
- Provide periodic updates to the Board until the investigation closes
- Publish a post-incident report (at least internally; ideally publicly for serious incidents) documenting root cause, response, and improvements made
- Run a retrospective with the incident-response team — what worked, what didn’t, update the playbook
What the Board expects in the notification
Based on the draft DPDP Rules, the breach notification to the Board should cover:
- Organisation details — name, point of contact (DPO if applicable), role under DPDP
- Nature of the breach — how it happened, when detected, when it actually occurred (if different)
- Categories of personal data affected — email, phone, financial, health, children, etc.
- Approximate number of Data Principals affected
- Likely consequences — what the attacker could do with the exposed data
- Measures taken to contain the breach — what you’ve done in the first 24-72 hours
- Measures taken to prevent recurrence — patches, controls, process changes
- Communication with affected Data Principals — what you’ve told them, when, through which channel
- Point of contact for the Board’s investigation
If the 72-hour window closes before you have complete information (which is almost always the case), you file with what you have and update as the investigation progresses. Do not delay the initial notification because information is incomplete — the Board prefers early notification with updates over late notification with “complete” information.
🔐 Intermediate Module · Basic Tier
Continue reading with Basic tier (₹499/month)
You've read 27% of this module. Unlock the remaining deep-dive, quiz, and every other Intermediate module.
99+ modulesAll levels up to this tier
20-question quizzesUnlimited retries with explanations
Completion certificatesShareable on LinkedIn
16 more sections locked below
