What should I do in the first 6 hours after a data breach?
Key takeaways
- CERT-In's 6-hour reporting window starts when you notice the incident or are brought to notice of it, not when you finish investigating it.
- An initial filing at hour four with the affected system, the closest Annexure I category and both timestamps is compliant; certainty is not required.
- CERT-In directions require 180 days of logs, so clock synchronisation on domain controllers, firewalls and servers decides whether you can prove when you knew.
- Log out compromised accounts and revoke sessions in the first hour, because a live attacker session will destroy the evidence you need.
- DPDP Rule 7 notification obligations commence from May 2027, and 83% of Indian organisations have not begun comprehensive DPDP implementation, so prepare the breach register now.
As of 24 October 2026: the service descriptions, prices and turnaround figures on this page are current.
How does the six-hour CERT-In rule actually work?
The rule is a hard deadline with a single trigger. Once you notice a listed incident, or you are brought to notice of one, six hours start running, and the report goes to incident@cert-in.org.in or on 1800-11-4949. Listed incidents include ransomware, data breaches, data leaks, and attacks on digital assets. Two consequences follow. First, the obligation is to report, not to complete an investigation, so a preliminary filing that states what is known is compliant and an accurate later update is expected. Second, because the clock is tied to notice rather than to certainty, the trigger is often earlier and vaguer than teams assume: a third-party supplier telling you that your data was exposed is a notice, and so is a researcher emailing you a copy of your customer table.
What should I include in the hour-four report?
Six elements, and nothing speculative. The date and time of the occurrence, or the best estimate of the breach window. The date and time of detection, and the date and time you were first notified if that is different. The affected system, named precisely, including the application, the host and the data category. The closest category in CERT-In's Annexure I, chosen as best fit rather than a perfect one. A description of the incident in plain terms, with the suspected cause where known. And a point of contact with a working phone number, because CERT-In calls back and an unreachable contact is a compliance failure. Keep the report short and factual. The 180-day log retention requirement means your own logs may be the evidence that supports or contradicts this filing.
Why does clock synchronisation decide whether you were in time?
Because the timestamps in your report are only credible if the systems that produced them agree. If a domain controller, a firewall and a database server are minutes apart, then the detection time you certify is a guess, and in a dispute the discrepancy is the argument. Time synchronisation across domain controllers, servers, firewalls and endpoints has to be configured and monitored, and the offset recorded, well before an incident. It is also what makes the 180-day log requirement usable: a log with wrong timestamps is evidence of nothing. This is a small control with a disproportionate effect on how defensible your 6-hour filing is, and it is the control most often missing when a filing is challenged.
What is the second clock, and what should you do about it now?
The second clock is the Digital Personal Data Protection Act 2023 and its Digital Personal Data Protection Rules. Rule 7 notification obligations commence from May 2027, and once in force they will require notification to the Data Protection Board and to affected data principals in addition to the CERT-In report. The two clocks are different in scope and will not align neatly, so build a single breach register now: a log of every incident with its occurrence, detection, notification and report timestamps, the data categories involved, and the containment steps. 83% of Indian organisations have not begun comprehensive DPDP implementation, so the organisations that build this register early will be ready to file both reports without reconstructing a timeline under pressure.
| Hour | Action | Why it is at that point |
|---|---|---|
| 0-1 | Isolate affected systems, revoke sessions, log out compromised accounts | Stops ongoing loss and preserves the access trail |
| 1-2 | Preserve logs and volatile evidence, freeze logs and clock sources | 180-day logs are what prove your detection time |
| 2-3 | Assess data categories and systems affected, identify the Annexure I category | The report needs a category, not a conclusion |
| 3-4 | File the CERT-In report to incident@cert-in.org.in or 1800-11-4949 | An hour-four filing is compliant; hour thirty is late |
| 4-5 | Involve legal, insurer and CERT-In empanelled incident responder | Notification and insurance deadlines run in parallel |
| 5-6 | Prepare affected-individual notification text and contact list | DPDP Rule 7 applies from May 2027 |
What are the frequently asked questions?
Get a straight answer on this
Call +91 98473 40580 and we will run the 6-hour CERT-In reporting checklist with you, starting with the affected system and timestamp.
Send us the details See pricing