CERT-In gives regulated entities six hours to report a cyber incident once it is detected. For SEBI-regulated firms, that clock starts the moment an alert turns into a confirmed event, and incident response under SEBI CSCRF is what determines whether those six hours are spent actually executing a plan or struggling to build one.
The average data breach in India now costs millions and takes an average of 263 days to identify and contain, according to the IBM Cost of a Data Breach Report 2025. Incident response under SEBI CSCRF exists to close that gap between detection and control. This guide breaks down what the framework requires, how the response process works and what a compliant incident response under SEBI CSCRF example looks like in practice.
What is incident response under SEBI CSCRF?
The Cybersecurity and Cyber Resilience Framework (CSCRF), issued by the Securities and Exchange Board of India (SEBI) in August 2024, organises cybersecurity into five resilience goals: Anticipate, Withstand, Contain, Recover and Evolve. Incident response under SEBI CSCRF primarily supports the Contain and Recover goals by helping regulated entities detect cyber incidents, limit their impact, notify the authorities and restore normal operations.
The system applies to stock exchanges, depositories, clearing corporations, mutual funds, brokers and other market infrastructure institutions. Each entity is classified into a tier, and the depth of incident response controls expected scales with that tier.
Why incident response under SEBI CSCRF matters
A documented plan on paper does not satisfy SEBI. The regulator wants proof like escalation paths, tested recovery timelines or completed drills. If you fail to give these – you face daily penalties, potential trading restrictions and mandatory disclosure to SEBI and the exchanges.
Reportable cyber incidents affecting trading systems, client data or market integrity must reach SEBI within six hours of detection, in line with CERT-In’s incident reporting directions. A root cause analysis usually follows within a defined window after that.
Core components of incident response under SEBI CSCRF
Meeting these expectations means building a response capability with clearly defined parts. The components below map directly to what auditors check during a CSCRF review.
- Incident response plan: A documented, board-approved plan naming owners for detection, containment, communication and recovery.
- Security Operations Centre (SOC): Continuous monitoring that generates the evidence auditors expect to see, whether run in-house or through a managed provider.
- CERT-In and SEBI reporting workflow: A clear internal process for meeting the six-hour reporting timeline without last-minute confusion.
- Tabletop exercises and drills: Regular simulation exercises to validate the incident response plan, with testing conducted at the frequency applicable to regulated entity under SEBI CSCRF and supported by documented evidence.
- Recovery and business continuity testing: Documented recovery time objectives, backup validation and disaster recovery drills tied to critical systems.
Incident response under SEBI CSCRF example
Consider a mid-sized brokerage that detects unusual login activity on its trading application at 10 AM. Its SOC flags the anomaly, confirms unauthorised access within 40 minutes and isolates the affected servers. The CISO is notified, the incident response plan is activated, and the SEBI/CERT-In notification is filed within the six-hour window. A forensic review follows, client-facing systems are restored within the entity’s defined recovery time objective, and a root cause report is submitted to SEBI along with corrective actions.
This incident response under SEBI CSCRF example shows why each component works together. Detection without a tested plan delays containment. A plan without a SOC has nothing to trigger it. Reporting without evidence leaves auditors unconvinced during the next CSCRF review.
Conclusion
Incident response under SEBI CSCRF should be treated like a tested, evidenced capability that includes detection, containment, reporting and recovery, and it is what regulators, auditors and customers now expect from every market infrastructure institution. Building that capability early avoids the daily penalties and reputational damage that come with a delayed or undocumented response.
CyberNX’s compliance services help you set up a plan for successfully implementing and maintaining SEBI CSCRF requirements by understanding your needs, developing a compliance roadmap for you, doing periodic assessments and measuring its effectiveness. Connect with our team to check out our SEBI CSCRF consulting services and test your current readiness against the framework.
Incident Response under SEBI CSCRF FAQs
What is the reporting timeline for incident response under SEBI CSCRF?
Reportable cyber incidents must be notified to SEBI within six hours of detection, in line with CERT-In’s reporting directions, followed by a detailed root cause analysis.
Is a Security Operations Centre mandatory for SEBI CSCRF compliance?
Higher-tier regulated entities need a functioning SOC, whether operated in-house, through a market SOC or via a managed service provider. The requirement is the capability and its evidence, not who runs it.
How often should incident response plans be tested?
SEBI CSCRF expects tabletop exercises and simulation drills at least once a year, with more frequent testing recommended for higher-tier entities handling critical trading infrastructure.
What happens if an entity misses the CERT-In reporting window?
Missing the window is treated as a compliance failure. It can trigger daily penalties, adverse reporting to SEBI and closer scrutiny during the next audit cycle.
