⚖️ DPDP Act 2023 — Tabletop
DPDP Act Data Breach Scenario
Customer PII breach mapped to India's Digital Personal Data Protection Act 2023. Notification timelines, penalty exposure up to ₹250 crore, and Data Protection Board response.
📋 Scenario Brief
Organisation
HealthFirst India Pvt Ltd — health insurance portal with 8.2 lakh registered users
Sector
Healthcare / Insurance (IRDAI regulated)
DPDP Classification
Significant Data Fiduciary (likely) — processes health data at scale
Data Affected
8.2 lakh records: name, Aadhaar-linked mobile, email, health policy details, claims history
Breach Type
MongoDB database publicly exposed due to misconfigured cloud access policy
Discovery
Third-party security researcher disclosed via responsible disclosure form
Opening Situation — Read to Participants
It is Monday morning 9:14 AM. You have received an email sent to security@healthfirst.in at 11:53 PM last night. The subject reads: "Responsible Disclosure — Exposed Customer Database." The researcher claims your MongoDB instance has been publicly accessible without authentication for an unknown period. They have attached a sample of 50 records showing customer name, mobile number, policy number, and partial claims history. They say they found it using Shodan. They have given you 72 hours before they publish on their blog. Your CISO is on leave. You are the acting security lead.
⚠️ DPDP Act Penalty Exposure — This Scenario
Breach of personal data (Section 66)
Up to ₹250 crore per instance
Failure to notify Data Protection Board (Section 8(6))
Up to ₹200 crore
Failure to implement security safeguards (Section 8(5))
Up to ₹250 crore
Health data = sensitive category (higher scrutiny)
Aggravating factor in penalty assessment
Aadhaar-linked mobile numbers in dataset
UIDAI notification may be separately required
Estimated total maximum exposure
₹700 crore+ across all violations
⏱️ 72-Hour Incident Timeline
Hour 0 — DiscoveryResponsible Disclosure Received
9:14 AM Monday. Researcher email received. Verify the claim — access the Shodan link provided, confirm the MongoDB instance is live and accessible. Immediately take the database offline. Begin exposure window assessment: when was the MongoDB instance last configured? Check cloud provider access logs.
Inject: Cloud engineer confirms the MongoDB instance has been publicly accessible since a misconfiguration on March 3rd — 47 days ago. The access logs show 12 distinct external IP addresses queried the database in that period. Total records exposed: 8,24,391.
Hour 2Scope Assessment
Classify the data: health insurance policy details + claims history = sensitive personal data under DPDP Act. Aadhaar-linked mobile numbers = special sensitivity. Notify CISO (even on leave — this is a major breach). Engage legal counsel. Begin documenting the timeline for regulatory reporting.
Inject: Legal counsel confirms you are likely classified as a Significant Data Fiduciary under DPDP Act given the volume and sensitivity of data. Section 8(6) requires notification to the Data Protection Board "as soon as possible" for personal data breaches. The exact timeline is not yet defined in rules but industry guidance suggests treating it as 72 hours.
Hour 6CERT-In Mandatory Report
CERT-In Directions 2022 require reporting of data breaches within 6 hours of knowledge. This deadline has been reached. The CERT-In report must go out now regardless of whether the investigation is complete — file what you know, state that investigation is ongoing.
Inject: A health insurance aggregator website has published a thread on X (Twitter): "BREAKING: HealthFirst India database exposed — 8 lakh customers' health data online for 47 days. We have the Shodan URL." The thread has 2,400 retweets in 3 hours. Your PR team is receiving journalist calls.
Hour 24Stakeholder Pressure
IRDAI has called asking for a status report — health insurance data breach affects their regulatory oversight. 3,200 affected customers have sent angry emails. An affected customer has posted on LinkedIn saying their health claim details are "all over the internet."
Inject: A prominent consumer rights lawyer has issued a notice to your company citing the DPDP Act and threatening a ₹500 crore class action on behalf of affected customers. Your board wants a call in 2 hours. The researcher who reported the breach is asking: "Have you notified your customers yet? If not, I will."
Hour 48Customer Notification Decision
Section 8(6) of DPDP Act requires notification to affected data principals "in such manner as may be prescribed." The notification rules are not yet fully notified. But failure to notify proactively creates regulatory and reputational risk.
Inject: CERT-In has acknowledged your report and requested additional information: the complete list of external IPs that accessed the database, evidence of data exfiltration (if any), and your remediation steps. They have also asked whether any government databases or Aadhaar numbers were in the exposed dataset.
Hour 72Researcher Disclosure Deadline
The researcher's 72-hour deadline has arrived. They are asking whether you have notified customers before they publish their full disclosure. Decision: have you notified? Have you offered the researcher a coordinated disclosure timeline?
Inject: Data Protection Board Secretariat (still in setup) has sent a letter stating they are "monitoring" the incident and requesting a written report on your response actions taken, notification status, and remediation measures. They have not formally cited enforcement authority yet — but the tone is regulatory.
⚖️ DPDP Act 2023 — Applicable Provisions
These sections directly apply to this scenario. Participants should discuss which obligations are triggered and what action each requires.
Section 8(5) — Security Safeguards
Every Data Fiduciary shall protect personal data in its possession or under its control by taking reasonable security safeguards to prevent personal data breach.
⚡ This scenario: Applies: The MongoDB misconfiguration is a failure of reasonable security safeguards. Penalty: up to ₹250 crore.
Section 8(6) — Breach Notification
In the event of personal data breach, Data Fiduciary shall notify the Board and each affected Data Principal in such manner as may be prescribed.
⚡ This scenario: Applies: 8.24 lakh customers must be notified. Notification to Data Protection Board required. Timeline: "as soon as possible" — treat as 72 hours.
Section 8(3) — Data Accuracy
Data Fiduciary shall ensure completeness, accuracy, and consistency of personal data.
⚡ This scenario: Applies indirectly — forensic investigation must confirm data integrity during exposure period.
Section 10 — Significant Data Fiduciary
Central Government may notify entities as SDFs based on volume and sensitivity of data processed. SDFs have enhanced obligations.
⚡ This scenario: Likely applies: 8.2 lakh health insurance records likely meets SDF threshold. Await official notification but prepare for SDF obligations.
Section 16 — Special Provision — Children
Data of children requires parental consent and extra protection.
⚡ This scenario: Check if any affected policyholders are minors — dependent children may be in the dataset under family health policies.
Section 25 — Penalties
Schedule I: Various penalties up to ₹250 crore per violation. Multiple violations in same incident can be compounded.
⚡ This scenario: Maximum theoretical exposure for this incident: ₹700 crore+ across Sections 8(5), 8(6), and 10 (if SDF obligations violated).
🤔 Key Decision Points
Hour 0: The researcher has given you 72 hours. Should you ask for more time or use the 72 hours as given?
Best practice: C. Coordinated disclosure (option C) aligns researcher incentives with your response timeline. Option A risks the researcher publishing while you're still investigating — you lose control of the narrative. Option D (immediate notification) is admirable but risky without confirming scope. Option B (7-day extension) is unlikely to be granted and creates a delay that worsens regulatory position.
Hour 6: CERT-In notification is due. Your investigation is only 20% complete. Do you file now?
Best practice: A or C — both are correct. CERT-In Directions 2022 are explicit: report within 6 hours of knowledge. Filing incomplete information is expected and acceptable — CERT-In anticipates this. Failure to file within 6 hours is itself a violation regardless of investigation completeness. Option D (legal delay) is the highest-risk choice — the violation of the 6-hour rule is clear-cut and indefensible.
Hour 48: Should you notify all 8.24 lakh affected customers proactively, before DPB rules on timeline are issued?
Best practice: A. Section 8(6) of DPDP Act requires notification to Data Principals — the obligation exists even if the procedural rules are pending. Proactive notification is also the strongest mitigation factor in penalty assessment. Option C (prioritise high-risk) is a reasonable operational approach but should not delay notification to others. Option D (blog post) is insufficient — it fails the individual notification requirement.
📊 Debrief Guide
Key learning points
→The DPDP Act is not yet fully operationalised — but the obligations in the enacted sections are live NOW. "The rules haven't been notified" is not a defence for failing to notify under Section 8(6).
→Health data is the highest-sensitivity category under DPDP. The Data Protection Board is likely to make an early enforcement example in health data breaches.
→Cloud misconfiguration is not treated as an accident by regulators — it is a failure of reasonable security safeguards under Section 8(5).
→The researcher who reported responsibly is an asset, not a threat. Teams that treat researchers as adversaries lose control of the disclosure timeline.
→Penalty exposure under DPDP can be compounded across multiple violations in the same incident — ₹700 crore exposure is realistic for a major health data breach.
→IRDAI has separate breach notification requirements for health insurance data — two regulators may claim jurisdiction.
DPDP-specific gaps commonly found
⚠No named DPDP Compliance Officer — Section 8 obligations have no clear owner
⚠Data inventory incomplete — organisation cannot confirm what personal data was in scope
⚠No customer notification template pre-drafted for data breach scenarios
⚠DPB contact details unknown — team googles it during the exercise
⚠Cloud access review not part of standard change management process