Under India's Digital Personal Data Protection Act 2023, any business that processes personal data (a "Data Fiduciary") must intimate both the Data Protection Board of India and every affected individual (a "Data Principal") as soon as it becomes aware of a personal data breach — regardless of the breach's size or severity. The DPDP Rules 2025, notified by MeitY in November 2025, set out a two-stage notification: an initial "without delay" alert followed by a detailed report to the Board within 72 hours. There is no minimum-harm threshold and no exemption for small businesses. These obligations become fully effective 18 months after the Rules were notified, but if you store, collect, or process personal data of Indian residents, you need a documented, testable breach-notification process well before that deadline, not after an incident forces you to build one under pressure.
What Counts as a "Personal Data Breach" Under DPDP
The DPDP Act defines a personal data breach broadly: any unauthorised processing of personal data, or any accidental disclosure, acquisition, sharing, use, alteration, destruction, or loss of access to personal data that compromises its confidentiality, integrity, or availability. This is a deliberately wide net — far more incidents qualify than most founders assume.
It is not limited to a hacker exfiltrating a customer database. Under this definition, a reportable breach includes:
- A misconfigured cloud storage bucket that briefly exposed customer records, even if no one is confirmed to have accessed them.
- An employee emailing a spreadsheet of user data to the wrong external address.
- A third-party vendor or SaaS tool you use suffering a breach that exposes data you gave them.
- Ransomware that encrypts (not steals) a database, because it compromises availability.
- A lost or stolen laptop, phone, or backup drive containing unencrypted personal data.
- An API endpoint returning more user data than intended due to a broken authorisation check (an IDOR-class bug).
Who You Must Notify, and When
The DPDP Act (Section 8(6)) requires Data Fiduciaries to notify both the Data Protection Board of India and each affected Data Principal in the event of a personal data breach. The Digital Personal Data Protection Rules 2025, notified by the Ministry of Electronics and Information Technology (MeitY) in November 2025, spell out the mechanics in more detail than the parent Act.
Notifying the Data Protection Board
Under Rule 7 of the DPDP Rules 2025, Board notification happens in two stages:
- Immediate intimation — as soon as the Data Fiduciary becomes aware of the breach, it must inform the Board without delay, describing the nature, extent, and timing of the breach and, where known, the likely impact.
- Detailed follow-up report — within 72 hours of becoming aware (extendable in specific circumstances on written request), the Data Fiduciary must submit a fuller report covering the facts and circumstances of the breach, the categories and approximate number of affected Data Principals, mitigation and remedial measures already taken or planned, findings regarding the person responsible where identified, and steps taken to prevent recurrence.
Notifying Affected Data Principals
The same framework requires the Data Fiduciary to notify affected individuals directly, in clear and plain language, describing:
- The nature and extent of the breach.
- The likely consequences for the individual.
- The measures being taken to mitigate the risk.
- A point of contact where the individual can seek further information.
Documentation the Board Will Expect
A notification is only as credible as the evidence behind it. Businesses that treat documentation as an afterthought consistently miss the 72-hour follow-up deadline. At minimum, your incident record should capture:
| Documentation item | Why it matters |
|---|---|
| Timeline of detection, containment, and escalation | Establishes when "awareness" began, which starts the notification clock |
| Systems and data categories affected | Required for both Board and Data Principal notifications |
| Approximate number of Data Principals impacted | Explicitly required in the detailed Board report |
| Root cause and responsible vector (if known) | Required field in the detailed follow-up report |
| Mitigation steps already taken | Demonstrates active response, not passive disclosure |
| Preventive measures planned | Signals the Board that recurrence risk is being addressed |
| Internal sign-off trail (who approved what, when) | Evidence of governance if the Board asks follow-up questions |
Know your vulnerabilities before attackers do
Run a free VAPT scan — takes 5 minutes, no signup required.
Book Your Free ScanCommon Root Causes You Should Be Monitoring For
Most reportable breaches trace back to a small number of recurring failure modes. Knowing where your exposure concentrates helps you prioritise detection and prevention effort instead of spreading it evenly across every theoretical risk.
Note that DPDP breach notification and CERT-In's separate 6-hour cyber-incident reporting mandate are not the same obligation — a single incident can trigger both, and your process needs to satisfy each on its own timeline.
Building a Notification-Ready Incident Response Process
You cannot assemble a compliant breach response after the breach has already happened. Organisations that meet DPDP timelines comfortably treat notification readiness as a standing capability, not a one-time compliance project.
1. Define "awareness" internally, in writing
Decide in advance what counts as your organisation becoming "aware" of a breach — a confirmed alert, a credible customer report, a vendor's disclosure — and write it down. This single decision determines when your regulatory clock starts, and it should not be improvised mid-incident.
2. Pre-build your notification templates
Draft the initial Board intimation and the Data Principal notice as templates now, with every required field mapped to a data source in your systems (logs, asset inventory, customer database schema). This is the single highest-leverage step, since it turns a 72-hour scramble into a fill-in-the-blanks exercise.
3. Maintain a current data inventory
You cannot describe "the categories and approximate number of affected Data Principals" if you do not already know what personal data you hold, where it lives, and which systems process it. A living data-flow map is a prerequisite for fast, accurate notification — not a nice-to-have.
4. Assign clear incident-response roles
Name who declares an incident, who leads containment, who owns regulator communication, and who owns customer communication. Ambiguity about ownership is one of the most common reasons notification deadlines slip.
5. Test the process before you need it
Run a tabletop exercise simulating a realistic breach scenario — a leaked API key, a phished admin account, a vendor incident — and time how long it actually takes your team to produce a Board-ready notification. If it takes longer than 72 hours in a drill with no real pressure, it will take even longer during an actual incident.
6. Close the loop with vendor and third-party breaches
Your DPDP obligations do not stop at your own infrastructure. If a vendor processing personal data on your behalf suffers a breach, you as the Data Fiduciary remain responsible for notifying the Board and your Data Principals. Contractual clauses requiring vendors to notify you immediately are essential, not boilerplate.
Bachao.AI, built by Dhisattva AI Pvt Ltd, runs continuous automated VAPT scans specifically to catch the misconfigurations, exposed endpoints, and vulnerable dependencies that most commonly turn into reportable personal data breaches — before an attacker or a regulator finds them first. Where CERT-In empanelment is a formal requirement for a specific engagement, that work is delivered with a CERT-In empanelled partner.
DPDP Compliance Beyond Breach Notification
Breach notification is a downstream obligation — it only becomes relevant once a breach has already happened. The upstream work covers consent management, data minimisation, purpose limitation, data principal rights (access, correction, erasure), and reasonable security safeguards under Section 8(5), which is what keeps you off the safeguard-failure penalty track in the first place. If you need a structured way to assess and close these gaps, see Bachao.AI's DPDP compliance offering.
Frequently Asked Questions
Frequently Asked Questions
Does the DPDP Act apply to a small business with only a handful of customers?
What is the deadline to notify the Data Protection Board after a breach?
Is a ransomware attack that encrypts data but does not steal it a reportable breach?
Do we need to notify customers even if we believe the risk of harm is low?
How is DPDP breach notification different from CERT-In's 6-hour reporting requirement?
What happens if we fail to notify on time?
Get Ahead of Your Next Incident
The gap between "we have a written policy" and "we can produce a Board-ready notification inside 72 hours" is where most Indian businesses lose. Close it before an incident forces the question. Start with a free VAPT scan to find the exposures most likely to become a reportable breach, and browse the Bachao.AI blog for more DPDP guidance.