SEBI CSCRF incident response: the 75 days after six hours

Six hours opens the incident. Annexure-O sets the next 75 days

Most CSCRF incident guidance stops at the first day: six hours to SEBI and CERT-In, then twenty-four to the portal. Those clocks are real, and the CSCRF overview sets them out. But Annexure-O of the framework keeps going. Table 36 lists six reports, each with its own deadline, counted from the date the incident was reported or brought to notice.

Two details catch firms out. The RCA deadline can be extended, but only on request and case by case, and the framework says the extension is “an exception rather than the rule”. And none of these reports goes straight to SEBI. The RCA, forensic, VAPT and closure reports must first be reviewed by the entity’s IT Committee, and a report of that review goes to SEBI with them. A committee that meets quarterly cannot review a thirty-day RCA in time. Build an out-of-cycle review into its terms of reference before you need one.

Since the FIRE circular of 24 August 2026, HO/(449)2026-ITD-5_DIV1/I/19448/2026, the portal has worked the same way. It takes a report in stages — initial report, intermediate updates, final closure — because some information does not exist when an incident is first noticed. It moved no deadline. The twenty-four-hour filing now opens a record that Annexure-O’s reports keep filling.

Severity decides who reviews it, and whether forensics is optional

Annexure-O grades every incident Low, Medium, High or Critical, and the grade sets the rest of the process. The entity classifies; its IT Committee reviews the classification before anything is submitted.

• Disruption is High or Critical by definition. Any incident that disrupts, stops or varies the normal functioning of the entity’s systems, and so affects service delivery, must be classified High or Critical. Ransomware and exfiltration of market-sensitive data are named as Critical.
• Some Medium incidents look minor. A phishing email an employee clicked, and reported data corruption or deletion, are listed as Medium. Data exfiltration and outbound phishing are High.
• A forensic report is mandatory for High and Critical. For Low and Medium it is owed only if the RCA is inconclusive, or if SEBI or the High Powered Steering Committee on Cybersecurity (HPSC-CS) directs one.
• Who reviews depends on the category. High and Critical incidents at MIIs, Qualified REs and Mid-size REs go to the HPSC-CS, which may change the severity and set time-bound recommendations. SEBI processes everything else internally.

SEBI’s June 2025 FAQ confirms the forensic rule. Forensic auditors are third parties chosen after due diligence, and Indian government forensic labs may be used; CERT-In empanelment is not required. A separate obligation in the Respond standards is easy to conflate with it: every regulated entity must also conduct a compromise assessment, and that one must be done through a CERT-In empanelled IS auditing organisation.

What has to exist before the incident

The Respond standards are mostly about documents that must be ready before anything happens. All of these bind every regulated entity unless noted.

• A Cyber Crisis Management Plan in line with CERT-In’s national CCMP, approved by the Board, partners or proprietor.
• An incident response management plan inside the CCMP, defining what employees and support or outsourced staff each do, plus SOPs for each kind of attack. MIIs also need an SOP for incidents reported to them by the entities they supervise.
• Evidence handling: collect and preserve system logs, network traffic, forensic images and memory dumps in a forensically sound way. Without this, the thirty-day RCA has nothing to stand on.
• A review cycle for the contingency plan, training exercises and response plans: half-yearly for MIIs and Qualified REs, once in two years for Mid-size and Small-size REs. After any incident, every entity updates the plan regardless.
• A quarterly report to SEBI on attacks, threats, incidents and the measures taken, within fifteen days of each quarter ending June, September, December and March. This is owed every quarter, not only after an incident.

One obligation was taken out. The 2024 text told MIIs and Qualified REs to issue a press release after a high-impact, broad-reach attack. The technical clarifications of 28 August 2025, SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2025/119, replaced that with a single instruction: act as your approved CCMP says. So the CCMP, not the framework, now decides when customers and the public are told — and that has to be written in before the incident.

The two-hour RTO was rewritten in August 2025

This is where most published summaries are wrong. The August 2024 framework said: within 30 minutes of a disruption to a critical system, declare a ‘Disaster’; the RTO is two hours; the RPO is 15 minutes for all REs. That wording is widely quoted as current. Even SEBI’s own FAQ of 11 June 2025 repeats it.

Eleven weeks after that FAQ, the technical clarifications replaced the guideline. It “shall now be read as” IOSCO’s formulation:

• Two hours is a design-and-test standard. Entities must design and test systems and processes so critical operations can resume safely within two hours of a disruption, even in extreme but plausible scenarios.
• Judgement is now expected. When a disruption happens, the entity should exercise judgement before resuming, so that resuming does not raise the risk to itself or the market.
• Missing two hours needs a plan. With its IT Committee, the entity must plan for scenarios where resumption within two hours is not achieved.
• RPO is 15 minutes for critical systems, under SEBI’s circular of 22 March 2021, rather than “for all REs” as the 2024 text put it.

The replacement text does not repeat the thirty-minute disaster declaration. Don’t drop the habit, though. The RCA report must still record when a disaster was declared, if one was, so the declaration should be timestamped in the log at the moment it is made.

Drills: live ones, and twice a year for the larger firms

Testing comes in two tiers, and SEBI’s FAQ closes the obvious shortcut.

Three FAQ answers shape how this testing has to be run. A tabletop exercise does not count: the FAQ says live drills are required, because a walkthrough is “theoretical”. Every incident scenario must be covered within one audit period, with the relevant stakeholders taking part. And the resilience testing must include critical third-party service providers, other intermediaries and linked entities, so the plan is tested with the vendors it depends on.

SOC and logs: what the framework fixes and what it leaves to you

SOC coverage is close to universal. Every regulated entity must use SOC services — its own or a group SOC, the Market SOC run by NSE and BSE, or a third-party managed SOC. The framework exempts only client-based stock brokers with fewer than 100 clients. The clarifications of 30 April 2025, SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2025/60, widened that in two different ways. Depository participants and RTAs with fewer than 100 clients are exempt from SOC services altogether. Self-certification portfolio managers, and self-certification AIF or VCF managers, with fewer than 100 clients are exempt only from the mandatory Market SOC.

Small-size and self-certification REs are required to join the Market SOC. The FAQ allows one that already runs its own SOC to keep using it, but it still owes the efficacy report.

• MIIs and Qualified REs measure their SOC’s functional efficacy themselves, half-yearly, using the Annexure-N method.
• Entities using a third-party SOC or the Market SOC obtain the efficacy report from their provider every year.
• MIIs also run a 24×7×365 Cyber Security Operations Centre with dedicated analysts.

Logs have no CSCRF retention period. Search for a CSCRF log-retention period and you will find confident figures. The framework sets none. It requires all log sources to be identified and collected, every log monitored, and a “strong log retention policy” set according to the IT Act, the DPDP Act, CERT-In, NCIIPC and other government requirements.

The binding figure comes from the CERT-In Directions: a rolling 180 days, kept within Indian jurisdiction. Your policy then has to cover the thirty-day RCA and the seventy-five-day forensic window, which can start well after the events they examine.

For an entity that also has another primary regulator — a bank that is also a depository participant, for instance — the August 2025 clarifications put log management under the principle of exclusivity. CSCRF reaches only the systems used exclusively for SEBI-regulated activity, and shared infrastructure falls into SEBI’s audit scope only if the primary regulator’s framework does not already cover it.

To see all of it as dates, the worked stock-broker data-leak case in the incident reporting clock turns the moment you noticed into a deadline for every filing a broker owes, from the six-hour notices to the seventy-five-day forensic report.

Where BitScore fits, and where it does not

Most of this is not ours to do. BitScore is not an incident responder, a SOC or a forensic auditor, and nothing we produce can be filed as an RCA, a forensic report or the compromise assessment. Our tabletop exercise is useful for rehearsing who files what. By SEBI’s own FAQ, it is not the live drill CSCRF requires.

Where we do fit is the outside view. A Bitsight rating shows what your public IP space exposes: open services, expired certificates, compromised systems seen beaconing out. That matters before an incident, because the Evolve standards ask entities to keep reducing their attack surface. It also matters afterwards, because the forty-five-day VAPT and closure reports are stronger with an external view that can show the exposure is gone.

The complimentary Cyber Risk Rating Report shows what that view returns for your organisation. It is evidence for the file — not compliance with CSCRF, and not a substitute for anything Annexure-O asks for.

Every obligation, applicability and deadline here is read from the Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI Regulated Entities, SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113, of 20 August 2024 — the Respond and Recover standards (RS.MA, RS.CO, RS.AN, RS.IM, RC.RP), DE.CM.S3, PR.AA.S8 and Annexure-O. The framework PDF was rendered page by page to read the applicability column, which does not survive text extraction. The rewritten recovery guideline, the press-release change and the exclusivity table are from the technical clarifications of 28 August 2025; the SOC exemptions are from the clarifications of 30 April 2025; the drill, forensic and Market SOC readings are from SEBI’s FAQ of 11 June 2025, read subject to the later circular where the two differ. The staged portal is from Alignment of SEBI's Cyber Incident Reporting Portal with FIRE format, and the 180-day log rule from the CERT-In Directions of 28 April 2022. This page is commentary, not legal advice; confirm how any of it applies to your entity with counsel or your compliance function. External measurement referenced here is a Bitsight capability; BitScore Cybertech LLP is an authorised Bitsight partner. Every instrument cited here was verified against the issuing regulator's own notification on 10 October 2026.

The instrument records on this site: SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113 · SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2025/60 · SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2025/119 · HO/(449)2026-ITD-5_DIV1/I/19448/2026 · No. 20(3)/2022-CERT-In