Under SEBI's Cyber Security and Cyber Resilience Framework (CSCRF), what you do in the hours after a cyber incident is not just good practice, it is a regulatory obligation. CSCRF expects a tested incident response capability and prompt reporting to SEBI and CERT-In, and a late or missing report is a compliance failure in its own right, separate from the incident that triggered it. This guide covers what CSCRF expects for incident response, exactly who you have to notify and how fast, the cyber-crisis drills regulators want to see, and how to prove the whole process worked. It builds on the detection capability in our logging and SOC guide, because you can only respond to what you detect.
What SEBI CSCRF expects for incident response
CSCRF treats incident response as a governed capability, not an ad hoc scramble. Regulators want to see that you can move from detection to containment to recovery in a coordinated, documented way, with the right people empowered to make decisions under pressure.
- A documented, board-approved incident response plan with clear roles and escalation paths.
- Playbooks for the incident types most likely to hit you (ransomware, data breach, DDoS, insider misuse).
- A defined severity classification that drives who is notified and how fast.
- Named decision-makers and a cyber crisis management team with the authority to act.
- Integration with your SOC, so a detected alert flows straight into the response process.
Incident reporting: who to tell, and how fast
The reporting obligation is where teams most often slip, usually because the clock is faster than they expect. Two regimes apply in parallel: SEBI's own reporting expectations for regulated entities, and CERT-In's national directions. Map both before an incident, not during one.
| Report to | When | What |
|---|---|---|
| CERT-In | Within 6 hours of noticing | Cyber incidents of the types specified in the CERT-In directions |
| SEBI | Within the timeline SEBI specifies | Cyber incidents and attacks, plus periodic (for example quarterly) reports |
| Board / senior management | Per your escalation policy | Severity-based internal notification and decisions |
| Affected stakeholders | As required by law and contract | Customers or counterparties where notification obligations apply |
The incident response lifecycle
A CSCRF-aligned response follows a repeatable lifecycle, with reporting running alongside containment rather than after it.
Detect
SOC or alert flags it
Triage
Classify severity
Contain
Limit the blast radius
Report
SEBI & CERT-In on time
Recover
Restore critical services
Review
Root cause & lessons
Cyber-crisis drills and tabletop exercises
CSCRF does not just want a plan on paper, it wants evidence that you have exercised it. Cyber-crisis drills and tabletop exercises are how you prove the plan works and find its gaps before a real incident does. Run them on a regular cadence, involve the actual decision-makers rather than stand-ins, simulate realistic scenarios (including a reporting deadline), and capture what you learned and what you changed as a result. That record is exactly what an inspection will ask to see.
Common incident-reporting gaps at audit time
- A plan that exists but has never been tested, so nobody knows their role under pressure.
- Missing the CERT-In six-hour window because detection or escalation was too slow.
- No evidence trail: the incident was handled, but there is nothing to show an auditor.
- Reporting to one regulator and forgetting the other, or missing periodic SEBI reports.
- No post-incident review, so the same weakness recurs.
Reporting failures also carry consequences. For how SEBI treats non-compliance, see our guide to SEBI CSCRF penalties.
Putting it together
Incident response under CSCRF is judged on speed, coordination and proof. Build a tested plan, wire it to your SOC so detection triggers response, know exactly who you report to and how fast, drill it regularly, and keep the evidence. Do that and an incident becomes a controlled event you can demonstrate you handled, rather than a compliance failure layered on top of a security one. Start from the compliance checklist and confirm your category in the applicability guide.
Frequently asked questions
What are the incident reporting timelines under SEBI CSCRF?+
Two regimes run in parallel. CERT-In's directions require reporting specified cyber incidents within six hours of noticing them, and SEBI expects regulated entities to report cyber incidents and attacks within the timelines it specifies, plus periodic reports. Confirm the current timelines for your entity category against the latest SEBI and CERT-In documents.
Do I report a cyber incident to both SEBI and CERT-In?+
Generally yes. CERT-In is the national computer emergency response team with its own reporting directions, and SEBI has its own reporting expectations for the entities it regulates. Map both obligations in advance so you are not deciding who to notify during a live incident.
What is a cyber-crisis drill under SEBI CSCRF?+
It is a rehearsal of your incident response and crisis management plan, through a tabletop or simulation exercise, involving the real decision-makers. CSCRF expects you to run these regularly and keep evidence of what you tested, what you found and what you changed as a result.
What happens if I report a cyber incident late?+
Late or missing reporting is treated as a compliance failure in its own right, separate from the incident, and can attract enforcement. That is why fast detection and a rehearsed reporting process matter. See our guide to SEBI CSCRF penalties for how non-compliance is handled.
About the author
Nilesh Wagh
Co-Founder, Pelta Technologies
Former CISO · 10+ years in information security & GRC
Nilesh Wagh is Co-Founder of Pelta Technologies, where he leads its information security, privacy, AI governance and GRC advisory. With over a decade in cyber and information security (including years as a Chief Information Security Officer) he helps regulated organisations move from fragmented compliance to connected, evidence-driven assurance.
Connect on LinkedIn →