It is 02:14 on a Tuesday. Your SOC flags anomalous API traffic. By 02:40 you know enough to be worried: a compromised API key belonging to a lending service provider has been used to pull loan records. Names, PANs, sanctioned amounts, repayment history. Maybe 200,000 rows.
You have a policy document. You have a firewall. You have a CISO. You have four hours to file with CERT-In, and you have not yet woken up your legal lead.
In Episode 3 we built the retention register. This episode is about the moment that knowledge is tested under a clock, and it is the episode most likely to save you money.
A single breach at an Indian regulated financial entity does not trigger one notification. It triggers up to four regulatory filings, to different authorities, in different formats, on different clocks, all running from the same detection timestamp. Miss any one and the failure to report is a separate violation from the breach itself.
First, know what counts as a breach
Three properties of the DPDP definition catch BFSI teams off guard, and each one widens your reporting surface considerably.
Unauthorised processing, accidental disclosure, alteration, destruction, or loss of access. Ransomware with no exfiltration is still a personal data breach.
Ten records and ten million both trigger notification. There is no de minimis carve-out in the statutory text today.
KYC vendor, dialler, cloud, LSP, analytics. If they hold your data and are compromised, you carry the filing.
Your triage question is not "was this serious?" It is: did personal data's confidentiality, integrity, or availability get compromised, anywhere in our chain? If yes, the clocks are already running.
The timestamp is the most important artefact you will produce
Every clock in this episode runs from a moment, and that moment must be defensible.
Clock runs from when you noticed the incident: detection, not confirmation, not classification.
Clock runs from when you became aware that a personal data breach occurred, typically confirmation through initial investigation, a detection system, or a processor report.
These are subtly different, and the gap is where teams lose hours they cannot afford. "Sometime Tuesday morning" will not survive scrutiny. The first thing your runbook does, before containment, before escalation, is write down the detection timestamp, NTP-synced, in a tamper-evident record.
The most expensive mistake in Indian incident response is waiting for certainty. Report on reasonable suspicion and refine later. A late first report is a finding. An over-cautious early report is not.
The four clocks
Click each clock. Note clock 3 carefully: the popular framing "you have 72 hours to notify the Board" is wrong. Rule 7 is two-stage.
A correction worth internalising, because much of the Indian commentary gets it wrong. You will see claims that RBI requires a "21-day root-cause analysis report" after a cyber incident. It does not. The 2016 Cyber Security Framework circular requires reporting in the format at Annex-3, whose heading reads "Security Incident Reporting (SIR) to RBI (within two to 6 hours)", and Root Cause Analysis is field 5 inside that very form. Further detail is supplied through subsequent updates, provided "if the earlier reporting was incomplete i.e. investigation underway or new information pertaining to the incident has been discovered or as per request of RBI." There is no fixed 21-day cyber deadline.
The 21-day figure is real, but it belongs to a different regime: fraud reporting. If your incident is also a fraud, the fraud track runs on its own clock. Do not let a blog post put a phantom deadline in your runbook, and do not let it hide a real one.
Clock 1: CERT-In (6 hours). Personal criminal liability.
Under the April 2022 Directions, all entities must report specified cyber incidents within six hours of noticing them. No size or sector exemption. Non-compliance under IT Act §70B(7) can attract imprisonment of up to one year, and/or a fine. Every other penalty in this series is corporate. This one is personal.
The initial report is a notification, not a forensic conclusion. CERT-In wants category, detection timestamp, affected systems, estimated scope, point of contact, and containment so far. Partial is acceptable and expected.
You cannot create a CERT-In account at 03:00 during a live breach.
System, flow, app, auth, email, DNS, cloud audit. No logs, no defensible filing.
time.nic.in or time.nplindia.org. Drift kills correlation and both CERT-In and DPDP reports.
Clock 2: RBI / SEBI (2 to 6 hours)
"RBI-regulated" is not one obligation. The 2 to 6 hour figure comes from a circular addressed to a specific audience, and applying it blindly across entity types is how runbooks go wrong. Check which row you are in:
Two things worth pinning down before you need them:
The banks' framework is explicit, report incidents "whether they were successful or were attempts which did not fructify." Teams that only report successful compromises are under-reporting by design.
Annex-3 asks you to grade the incident: Severity 1, critical systems, customer-facing applications, or a crippled internal network affected; Severity 2, an incident on a system or network that could put critical systems at risk. Know which one you are filing before the call, not during it.
An NBFC with a broking arm, which describes a large slice of Indian financial services , you file to both. Equivalence (Episode 2) may let you reuse controls and evidence across frameworks. It does not let you skip a filing.
Clock 3: Without delay, to the Board and your customers
The moment you become aware, intimate both the Data Protection Board and every affected Data Principal, without delay, on a best-knowledge basis. If you wait 72 hours to tell customers, you have already failed.
Channel matters. Maintain at least one reliable, tested channel per customer. A notification to a bounced email is not a notification. Do not wait for forensic clarity. Concealment attracts worse treatment than the breach itself.
Clock 4: The 72-hour detailed report
Within 72 hours of becoming aware, a comprehensive report goes to the Board only. It becomes a permanent regulatory record. Extension is possible by written request, but assume it will not be granted.
The hour-by-hour runbook
Print this. Put it on a wall. Nobody composes four regulatory filings from scratch at 2 a.m.
Write NTP timestamp. Open incident. Assign owner.
DPDP / CERT-In / sectoral / fraud tracks ON or OFF.
CISO · DPO · Legal · Comms. Preserve volatile evidence first.
Isolate, revoke, rotate. Do not destroy H+72 evidence.
File RBI CSITE (banks, Annex-3) / SEBI via exchange-depository / NHB if HFC. Grade Severity 1 or 2. Report attempts too.
Systems, categories, approximate principals. Cross-check registers.
File CERT-In. Partial report expected. Do not wait.
Notify DPB AND every affected principal. Multi-channel.
Forensics, root cause, findings log, draft history.
Detailed report to the Board.
Forensic readiness: where breach response is actually won
Every filing above is downstream of one capability: can you reconstruct what happened, with evidence that holds up?
Not a Google Doc or Slack thread. Write-once, immutable bucket, or IR system.
Disk images, logs, memory captures tracked end to end. Not optional hygiene, RBI's own incident form asks: "Is chain of custody maintained?", "Has the bank filled the chain of custody form?", and "What tools were used for collecting the evidence?" If you have never filled one, you will be answering "no" to your regulator, in writing, during your worst week.
Every hypothesis tested, every conclusion reached.
All four filings must match. Inconsistency is itself a finding.
If SIEM cannot reconstruct the path, the 72-hour report fails.
Tamper-resistant proof of encryption/tokenisation prices severity down.
The eight failure modes
Survey data from Indian BFSI IR teams points at the same recurring failures. Read these as a pre-mortem on your own programme.
Reporting only to CERT-In and missing parallel RBI/SEBI filings
Waiting for complete forensics before filing
No pre-built contact list at 2 a.m.
Destroying volatile evidence by isolating too early
No DPDP triage alongside the CERT-In track
Portal not pre-registered; burning the six-hour window
Notifying customers at H+72 instead of without delay
Vendor silence until day four, after your clocks expired
Bind every processor to notify you within one hour of a suspected incident. Your vendor does not know your clocks unless you write them into the agreement, and their breach is your filing.
What this costs if you get it wrong
The breach and the failure to report are separate violations. Weak controls plus under-reporting means both heads of liability, before the sectoral regulator has said a word.
Before the next incident: the pre-work checklist
That last item, the 2 a.m. tabletop, is the only one that tells you the truth. Everything else is a claim.
- One detection trigger, four filings from pre-approved templates
- Live regulatory countdown from a single detection timestamp
- Evidence collected continuously: 180-day logs, control state, encryption posture, consent records
- Control-to-framework mapping so Rule 6, CSCRF Detect/Respond, and RBI IR requirements are evidenced once
Next: Episode 5 (finale) on SDF readiness. India-based DPO, annual DPIA, independent data audit, and algorithmic accountability for credit and fraud models.
Sources, verified against primary text: DPDP Rules 2025 (G.S.R. 846(E), 13 Nov 2025), particularly Rule 7; CERT-In Directions No. 20(3)/2022 under IT Act §70B; RBI Cyber Security Framework in Banks, RBI/2015-16/418, DBS.CO/CSITE/BC.11/33.01.001/2015-16, 2 June 2016 , including Annex-3 ("Security Incident Reporting (SIR) to RBI (within two to 6 hours)"), whose Severity 1/2 grading and chain-of-custody fields are quoted above, and which contains no 21-day RCA deadline; RBI Master Direction on IT Governance, Risk, Controls and Assurance Practices, RBI/2023-24/107, 7 Nov 2023 (in force 1 Apr 2024) , applicability per Chapter I and footnote 17 on Housing Finance Companies reporting to NHB; RBI Master Direction on Frauds (source of the 21-day FMR timeline, a separate regime); and SEBI CSCRF (Aug 2024, as amended through Aug 2025).
Reporting timelines, formats and portals vary by entity class and change over time. Verify each against the primary circular applicable to your entity, and confirm portal registration and current formats before an incident, not during one. General information only; not legal advice.