What Is a Data Breach Notification?
Key takeaways
- Two clocks run together after an Indian breach: 6 hours to CERT-In for a cyber incident report, and 72 hours to the Data Protection Board and the affected data principals under the DPDP Rules.
- The notification is issued on what is known at the time, and CERT-In has stated that an incomplete first report is acceptable and can be updated, so the first report is never delayed for perfection.
- A useful notification names the incident in plain language, gives the date range, the data categories affected, the approximate number of people, the likely consequences and the concrete steps a person should take.
- The most commonly missed section is the advice to the individual, such as changing a password, watching for OTP fraud, or reporting to cybercrime.gov.in, and for financial data, the helpline and the bank contact.
- Keep a pre-approved template and a pre-approved call tree, because the drafting is not the bottleneck, the six-hour clock is, and the template is what makes the first hour usable.
As of 24 October 2026: the service descriptions, prices and turnaround figures on this page are current.
What must a data breach notification contain?
Under the DPDP Rules the notification to the Board and to the affected data principals carries specified content: the nature of the breach, the categories of personal data affected and the approximate number of data principals concerned, the likely consequences of the breach, and the measures taken or proposed to address it. Add what an auditor and a customer will ask for on top of that: the date range of the incident, the systems involved, what you are doing for each affected population, the contact route for questions, and the specific advice the individual should follow. Keep the language plain, because the affected person decides whether to complain, and a notice written in compliance language loses the reader.
What is the difference between the CERT-In report and the DPDP notification?
They are different obligations with different recipients, different formats and different clocks. The CERT-In report goes to CERT-In within 6 hours of noticing an incident, and it is a technical report of the incident, the affected assets and the mitigation, filed on the CERT-In incident reporting portal. The DPDP notification goes to the Data Protection Board and to the affected data principals within 72 hours, and it is written for a regulator and for a customer, so it is about personal data, the people affected and their consequences. The CERT-In report is where the technical truth lives and the DPDP notification is where the human consequence lives, and neither replaces the other.
How do you write the notification to affected customers?
Write it in the customer's language, not your legal team's. Open with what happened in two sentences, using plain words and no code names, then give the date range, the categories of data, what you have not affected, and what you have done. Then give the individual actions: change a reused password, watch for OTP and payment fraud, contact your bank if a financial identifier was involved, and report suspicious messages on cybercrime.gov.in or on the 1930 helpline for financial fraud. Then say who to contact and over what window. One honest limitation stated clearly protects you far better than a reassuring paragraph, because the person reading it will compare your statement with what they can see.
What goes wrong most often in breach notifications?
Four failures, in order of frequency. First, missing the six-hour clock because the team waited for forensic certainty; the fix is a standing rule that a suspected incident triggers a report, and CERT-In has confirmed that an incomplete report is acceptable. Second, inconsistency between the CERT-In report, the customer notice and the internal timeline, which is the easiest thing for a regulator or a plaintiff's counsel to exploit. Third, omitting the individual advice, which turns an honest notice into a legal notice. Fourth, an absent escalation path, where the person who could approve the send is asleep. Each is cheap to fix in advance with a template, a call tree and a standing approval from the leadership.
| Obligation | Clock | Recipient | Core content |
|---|---|---|---|
| CERT-In incident report | 6 hours from noticing the incident | CERT-In | Incident nature, affected systems, impact, mitigation and contact |
| DPDP breach notification | 72 hours from becoming aware | Data Protection Board | Nature of breach, data categories, numbers affected, likely consequences, measures |
| Customer and data principal notice | With the DPDP notification | Every affected data principal | Plain-language account, date range, individual actions, contact route |
| Public advisory | Where individual notice is impractical | Public | Nature of breach, mitigation and contact, issued through official channels |
| Police and cybercrime report | Immediately for criminal acts and fraud | cybercrime.gov.in and 1930 helpline | Fraud, extortion or misuse of stolen data, with the FIR reference |
| Post-incident review | After containment | Board and regulators as relevant | Root cause, control gaps, remediation plan and owner for each action |
What are the frequently asked questions?
Get a straight answer on this
Send us your current incident runbook, and we will return both templates: the 6-hour CERT-In report and the 72-hour DPDP notification, ready to fill in.
Send us the details See pricing