The 6-Hour Clock Is Already Running: CERT-In Incident Reporting SOP for BFSI

Why BFSI Organisations Consistently Miss This Window

The CERT-In 2022 Directions introduced mandatory reporting within 6 hours of becoming aware of a cyber incident. For BFSI entities regulated by RBI, SEBI, or IRDAI, this obligation sits on top of — not instead of — sector-specific notification requirements. Yet most Indian financial institutions are not operationally ready to meet this deadline.

The failure modes are almost always the same. Four data points tell the whole story:

The CERT-In Directions use the phrase "as soon as possible and in any case within six hours of becoming aware." This is a critical legal distinction. The clock does not start when you confirm the breach. It starts when the first responder becomes aware of an event that could be a cyber incident. Organisations that wait for forensic confirmation before opening a CERT-In ticket are almost always already late.

This SOP is designed around that reality. Every phase below is timed from the moment your SOC or helpdesk first flags an anomaly — not from the moment the legal team finishes their review.

Hour-by-Hour Response SOP

The following four-phase timeline gives your IR team a concrete sequence of actions. Each phase is designed to be executable without senior management approval — those escalations happen in parallel, not as gates.

BFSI Incident Categories Matrix

CERT-In's Directions enumerate 44 reportable incident types. The 12 categories below are the highest-frequency types for BFSI entities. All are reportable — the priority column indicates response urgency and typical regulator scrutiny level.

Dual Reporting in BFSI: CERT-In Is Not Your Only Obligation

One of the most common compliance gaps we see in BFSI incident reviews is the assumption that filing with CERT-In completes the reporting obligation. It does not. BFSI entities face sector-specific notification requirements that run in parallel and have their own timelines, formats, and escalation paths.

For RBI-regulated entities (scheduled commercial banks, cooperative banks, NBFCs, payment aggregators), the Cyber Security Framework requires reporting to the Chief General Manager, DPSS, Reserve Bank of India, within 2 to 6 hours depending on incident severity. The format is separate from the CERT-In portal and typically involves a structured email or the RBI reporting portal.

For SEBI-regulated entities (stock brokers, depositories, AMCs, RIAs), SEBI's CSCRF requires notification to the relevant Market Infrastructure Institution and to SEBI ISAC within the prescribed timeline. The CSCRF maturity framework also requires post-incident RCA submission within 30 days for Audit Trail (L3) and above entities.

For IRDAI-regulated entities (insurers, insurance intermediaries), the IRDAI Cyber Security Guidelines require notification to the IRDAI within 6 hours, mirroring the CERT-In timeline but through a separate channel.

CERT-In Portal Filing Checklist

The portal at incident.cert-in.org.in requires structured data across four sections. Your IR team should have pre-populated templates for the most likely incident scenarios. The checklist below maps to the portal fields as they appear in the current submission form.

The 6 Most Common CERT-In Reporting Mistakes

These are the six failure patterns that most frequently result in RBI or CERT-In enforcement action, based on observed incident post-mortems across Indian BFSI entities.

Mistake 1 — Delayed detection: Most organisations treat the 6-hour clock as starting when they complete initial triage. It does not. The clock starts the moment any person in your organisation becomes aware of an anomaly that could constitute a cyber incident. Your SIEM alert, your helpdesk ticket, your customer complaint call — any of these is awareness. Your detection-to-declaration pipeline must be measured in minutes, not hours.

Mistake 2 — No pre-built IR contact list: Under incident stress, teams spend the first 30 to 60 minutes finding phone numbers. Your IR contact list must be printed and stored offline, available on an out-of-band channel (not the same infrastructure that may be compromised), and updated quarterly. It must include CERT-In portal credentials, sector regulator emergency contacts, legal counsel, and your MSSP/forensics retainer contacts.

Mistake 3 — Reporting only to CERT-In: As covered above, sector-specific reporting obligations are independent and equally enforceable. RBI's Cyber Security Framework has been the basis for several enforcement actions where institutions reported to CERT-In but failed to notify DPSS within the prescribed window.

Mistake 4 — Waiting for complete forensics: The CERT-In portal is not a forensic submission portal. It is a notification portal. File with what you know. The investigation continues after submission. CERT-In regularly follows up with requests for additional information — that is the intended workflow.

Mistake 5 — Destroying volatile evidence: The instinctive response to a detected compromise is to isolate and reimage the affected system. This destroys running process data, active memory, and network connection state — evidence that is critical to root cause analysis and potentially to law enforcement. Always capture a memory dump and volatile state before isolation.

Mistake 6 — No DPDP triage: CERT-In reporting and DPDP breach notification are parallel obligations with different timelines, different recipients, and different consequences. A data breach that triggers CERT-In in 6 hours also triggers a potential DPDP notification obligation to the Data Protection Board of India within 72 hours. If your IR process does not include a DPDP triage step, you are systematically missing the parallel clock.

The DPDP Act Parallel Clock

The Digital Personal Data Protection Act 2023 and the DPDP Rules 2025 establish a separate notification obligation for Data Fiduciaries when personal data of Data Principals is involved in a security incident. This obligation runs in parallel to the CERT-In 6-hour clock and has a 72-hour notification window to the Data Protection Board of India.

Your incident response process must split into two parallel tracks at the moment a cyber incident is detected:

• Track 1 — CERT-In + Sector Regulator: 6-hour notification to CERT-In, parallel notification to RBI/SEBI/IRDAI within sector-prescribed timeline
• Track 2 — DPDP: Within 72 hours, assess whether personal data was compromised, determine number of Data Principals affected, and notify the Data Protection Board of India using the prescribed format

Track 2 requires your IR team to make a prompt determination: was personal data involved? This means your incident triage must include a data classification check — which systems were affected, what data did those systems hold, and whether any of that data constitutes personal data under the DPDP Act definition.

For banks and NBFCs, almost any customer-facing system compromise will trigger the DPDP parallel clock. Account data, transaction history, KYC documents, and contact information all constitute personal data under the Act. The default assumption should be that DPDP is triggered until proven otherwise.

Pre-Incident Readiness: 10 Things to Do Before the Next Incident

The difference between a 5-hour submission and a missed deadline is almost entirely determined by what your team does before the incident. The following 10 actions, completed before any incident occurs, will make your CERT-In compliance structurally achievable rather than heroically improvised.

1. Register on the CERT-In portal before an incident occurs. The portal registration process involves identity verification and can take several working days. An organisation that attempts to register for the first time during an active incident will miss the 6-hour window. Register now, test your login, and store credentials in an offline location.
2. Maintain an up-to-date IR contact list with off-band access. Every contact your team will need during an incident — CERT-In portal credentials, RBI DPSS emergency number, SEBI ISAC contact, legal counsel, MSSP incident hotline, forensics retainer — must be available on a medium that does not depend on your potentially-compromised infrastructure.
3. Map your likely incident scenarios to CERT-In categories in advance. Ransomware maps to "Malicious Code." A data exfiltration event maps to "Data Breach / Data Theft." A credential stuffing attack maps to "Unauthorised Access." Do this mapping exercise in a tabletop — not during the incident.
4. Pre-draft partial report templates for your top 3 incident scenarios. A pre-populated template with your organisation's name, CERT-In registration ID, sector, and primary contact fields already filled saves 20 to 30 minutes during the 6-hour window. Build one for ransomware, one for data breach, and one for DDoS.
5. Test your logging infrastructure: can you extract 30 days of logs within 2 hours? CERT-In may request historical logs as part of follow-up. CERT-In Directions require 180-day log retention. Validate that your SIEM can actually produce a usable log export for a given IP range or time window within the time pressure of an incident response.
6. Establish a DPDP breach notification workflow that runs separately from your IR workflow. Designate a Data Protection Officer action item for every incident. This person should have a pre-drafted DPBI notification template and know the Board of India submission process independent of the CERT-In process.
7. Conduct a tabletop exercise that simulates a ransomware event at 2 AM on a weekend. Most real incidents are detected outside business hours. Your IR plan must work when your CISO is asleep, your legal counsel is unavailable, and your on-call SOC analyst has never filed a CERT-In report before. Test this scenario explicitly.
8. Ensure vendor and third-party NDAs include a 1-hour notification requirement. Supply chain incidents account for a growing share of significant cyber events. Your MSPs, SaaS vendors, and cloud providers must be contractually required to notify you within 1 hour of detecting an incident affecting your data or systems — giving you time to start your own 6-hour clock.
9. Designate a CERT-In Reporting Officer by name and role, not just by title. "The CISO will file the report" is not an operational assignment. The designated Reporting Officer should be someone available 24/7, empowered to submit without additional approvals, and backed up by a named alternate. This designation should appear in your IRP and be known to your SOC.
10. Integrate CERT-In reporting triggers into your SIEM or SOAR playbooks. When your SIEM fires a high-severity alert, the playbook should automatically: (a) create a draft incident record, (b) alert the Reporting Officer, (c) start a countdown timer, and (d) open the CERT-In portal template. Manual processes fail under incident stress; automated triggers do not.