If you are a SEBI-regulated entity, the way you report a cyber incident changed in August 2026 — but not in the way most summaries suggest. The reporting clock did not move. What changed is the shape of the report.
SEBI’s circular of 24 August 2026 (ref. HO/(449)2026-ITD-5_DIV1/I/19448/2026) aligned its Cyber Incident Reporting Portal with the Financial Stability Board’s FIRE format — the Format for Incident Reporting Exchange. Alternative Investment Funds are expressly within scope. If you read one thing into it, read this: SEBI now expects a report that evolves with the incident, rather than a single filing made once the dust settles.
What the FIRE alignment actually changed
The substantive change is staged reporting. Rather than one filing, a regulated entity now files an initial notification and then updates the same report as the investigation develops — through intermediate updates, to a final closure.
That sounds administrative. It is not. It changes what your security operations function has to be able to produce, and when.
Under a single-filing regime, there was an unspoken incentive to wait: the longer you waited, the more complete the picture, the fewer corrections you had to issue. Staged reporting removes that incentive and replaces it with an obligation to be legible early. You are expected to say what you know at hour six, and to keep saying it as you learn more.
The timelines that did not change
Two deadlines survive the FIRE alignment intact:
- Within 6 hours of detecting or being notified of a cyber incident — report to SEBI by email.
- Within 24 hours — file on the Cyber Incident Reporting Portal.
Six hours is the number that matters, and it is worth being blunt about what it implies. Six hours is shorter than a shift handover. It is shorter than the time it takes most mid-sized firms to convene an incident call, confirm what they are looking at, and get a sign-off from someone senior enough to write to a regulator. If the incident starts at 2am on a Saturday, the clock still runs.
Indian regulated entities already live with a parallel six-hour obligation to CERT-In, and the practical lesson from that regime applies here: the firms that meet the deadline are not the ones with better lawyers, they are the ones whose monitoring tells them something happened in the first place. A reporting deadline you cannot see the start of is not a reporting problem. It is a detection problem. We have written separately about what CERT-In compliance requires in India.
What staged reporting demands from your SOC
If the report now has three stages, your security operations function needs to be able to answer three different questions at three different points. Most SOC runbooks we see are built to answer only the last one.
Stage one: the initial notification
At hour six you will rarely know root cause, and you are not expected to. What you should be able to state is narrow and factual: when detection occurred, how it occurred, which systems or services are affected, whether the incident is ongoing or contained, and whether there is any early indication of data exposure.
The common failure here is not ignorance — it is the absence of a defensible detection timestamp. If your first evidence of an incident is a user complaint rather than an alert, you cannot credibly date detection, and every subsequent timeline you file inherits that weakness.
Stage two: intermediate updates
This is where investigation output becomes reporting input: scope refinement as you rule systems in and out, containment actions taken and when, indicators of compromise, and any revision to your earlier assessment. Revising an earlier stage is expected. Staged reporting exists precisely so that an early, partly-wrong report is better than a late, complete one.
Stage three: final closure
Root cause, full impact assessment, remediation completed, and the control changes that stop a recurrence. This is the stage most firms are already equipped for, and it is the least time-critical of the three.
The capability question underneath the compliance question
CSCRF sets security operations obligations that vary by the category a regulated entity falls into, and the framework contemplates more than one route to meeting them — an in-house SOC, a group SOC shared across entities, the Market SOC facilities offered through the exchanges, or a managed third-party SOC. Which route applies to you depends on your category, and that is a question to settle against the framework text and your compliance advisers rather than against a vendor’s blog post, including this one.
What is not category-dependent is the underlying capability. Whatever route you take, staged reporting assumes something is watching continuously, that alerts are triaged by someone who can distinguish a scan from an intrusion, and that the timeline of what happened is reconstructable afterwards from retained logs.
Three things make the six-hour clock achievable in practice, and none of them is a document:
- Monitoring that runs when your office does not. Incidents are disproportionately detected out of hours, because that is when they are launched. 24/7 SOC coverage is the difference between a six-hour clock that starts when you detect and one that starts when an attacker chooses.
- Log retention long enough to reconstruct a timeline. Final-stage reporting asks for root cause. If the relevant logs rolled over four days ago, root cause becomes conjecture.
- A named escalation path with authority attached. The reason firms miss six hours is almost never technical. It is that nobody was sure who was allowed to write to the regulator.
What to do this quarter
A short, honest list — in the order we would do it:
- Read the circular itself, and confirm which obligations attach to your RE category. Do not take a secondary summary as the operative text.
- Run a timed drill. Pick a plausible incident, start a stopwatch, and see whether you could file an initial notification in six hours on a Saturday. The result is usually instructive.
- Rewrite your incident runbook into three stages that mirror the report, so the investigation produces the filing as a by-product rather than as extra work.
- Check your log retention against the question “could we establish root cause for something that started three weeks ago?”
- Name the people who can authorise a regulatory notification, and name their deputies. Put it somewhere that does not require network access to read.
- Re-test detection coverage. A worked risk assessment is a reasonable starting point if you do not have a current one.
Frequently asked questions
Did the FIRE alignment change SEBI’s cyber incident reporting deadlines?
No. The reporting timelines are unchanged — email to SEBI within 6 hours of detecting an incident, and a filing on the Cyber Incident Reporting Portal within 24 hours. What changed is the structure of the report: it is now staged, so an entity files an initial notification and updates it through intermediate stages to a final closure.
What is the FIRE format?
FIRE stands for Format for Incident Reporting Exchange, a reporting structure developed by the Financial Stability Board to make cyber incident reporting consistent across financial-sector regulators internationally. SEBI’s August 2026 circular aligns its own portal with that format, which is why the report is now staged rather than filed once.
Does this apply to Alternative Investment Funds?
Yes. AIFs are expressly covered by the circular. Beyond that, the specific security operations obligations under CSCRF vary by the category a regulated entity falls into, so confirm your own category against the framework text rather than assuming a peer firm’s position applies to you.
Can a third-party managed SOC satisfy CSCRF security operations requirements?
CSCRF contemplates several routes to meeting security operations obligations, including an in-house SOC, a group SOC, the Market SOC facilities offered through the exchanges, and a managed third-party SOC. Which routes are open to you depends on your RE category, so that determination should be made against the framework and with your compliance advisers. What applies regardless of route is the underlying capability: continuous monitoring, competent triage, and log retention sufficient to reconstruct an incident timeline.
Why does the six-hour deadline matter more than the 24-hour one?
Because the six-hour clock starts at detection, and detection is a capability rather than a process. Most entities can complete a portal filing within 24 hours once they know what happened. Far fewer can reliably establish, within six hours and outside business hours, that something happened at all. That is a monitoring question, not a compliance-documentation question.
Is an early report that later turns out to be wrong a problem?
Staged reporting exists precisely to accommodate this. The expectation is that an initial notification reflects what is known at the time and is then revised through intermediate updates as the investigation develops. Withholding a notification until the picture is complete is the greater risk, because it puts you outside the six-hour window.
This article is a summary written for IT and security teams, not legal or compliance advice. Reporting obligations attach to your specific regulated-entity category — verify against SEBI’s circular of 24 August 2026 and the CSCRF text before acting. SEBI’s circulars are published at sebi.gov.in.
Novotron runs managed SOC support and cyber security services for businesses in Noida, Delhi NCR and across India. If you want to know what continuous monitoring costs before you talk to anyone, our SOC-as-a-Service pricing guide gives real India figures.