Every delay in the CIRCIA rulemaking has produced the same reaction in SMB IT departments: relief, followed by another year of not building an incident reporting capability. That reaction misreads where the deadlines come from. The 72-hour reporting window for substantial cyber incidents and the 24-hour window for ransom payments are written into the Cyber Incident Reporting for Critical Infrastructure Act of 2022 itself. The rule CISA is still finalizing settles who is covered, what counts as substantial, and how reports get filed — not how long you have. When the rule lands, the clock does not phase in gently.
Where the Rulemaking Actually Stands
CISA now expects to finalize the CIRCIA regulations in September 2026. The path there has been long: CIRCIA was enacted in March 2022, CISA missed the statutory October 2025 deadline to finalize the rule, then set an internal target of May 2026, citing the volume of comments on the proposed rule and an intent to streamline its requirements. That target moved again to the current September 2026 expectation.
The intervening year explains some of the slip. CISA announced in February 2026 that it would run sector-specific and general town hall sessions; those were originally scheduled for March and April 2026 and were postponed by a lapse in Department of Homeland Security appropriations. They were rescheduled for June 15–18, 2026, with more than 1,200 stakeholders participating across four days.
Two things follow. First, a September 2026 target is an expectation, not a commitment — this rule has moved before, and a fourth slip would surprise nobody. Second, the direction of travel in CISA's own stated intent is toward streamlining the proposed requirements rather than expanding them, which means the reporting burden in the final rule is more likely to be narrower than the proposal than broader. Neither of those observations changes the statutory clocks.
Why the Delay Doesn't Buy You Time on the Part That's Hard
Consider what a 72-hour reporting obligation demands operationally. The clock starts when a covered entity reasonably believes a substantial incident has occurred. Inside three days, someone has to determine that the threshold was met, assemble a factual description of the incident, and file it — while simultaneously running containment, dealing with a possibly degraded environment, and managing whatever business disruption the incident caused. For ransom payments, the window is 24 hours.
The part that takes months to build is not the filing. It is the decision-making apparatus around it: knowing who has authority to declare an incident reportable, having the determination criteria written down before the incident rather than argued during it, knowing where the facts a report requires actually live in your logs and tooling, and having a named person who owns the submission with a backup for the strong possibility that the incident happens during a holiday or a vacation.
Organizations that wait for the final rule will find themselves building that apparatus in the compliance window after publication, which is exactly when their assessors, auditors, and cyber insurers all want attention too. The work does not get easier for having been deferred, and none of it depends on the open questions the rule will settle.
The overlap problem is the real trap
A mid-market company with any regulatory surface probably already has several incident-reporting obligations with different clocks, thresholds, and recipients. Defense contractors report CUI incidents to DIBNet within 72 hours under DFARS. Public companies have SEC cyber disclosure obligations on a materiality trigger. Healthcare organizations have HIPAA breach notification duties. Financial entities may have NY DFS obligations with a 72-hour notice of their own, covered in our NY DFS guide. State breach-notification laws add more.
CIRCIA adds another recipient rather than replacing any of them. The failure mode is not missing CIRCIA specifically — it is an incident response plan that treats "notify regulators" as one undifferentiated step, and a team that discovers mid-incident that three different clocks started at three different moments with three different thresholds. Mapping your actual obligations into a single table, with trigger, clock, recipient, and owner for each, is genuinely useful work that the rulemaking delay has no bearing on.
What to Build Before the Rule Lands
1. Determine your likely covered-entity status now, provisionally
CIRCIA applies to covered entities in critical infrastructure sectors, and the final rule settles the precise applicability criteria. You do not need the final text to form a working view: if you operate in one of the designated critical infrastructure sectors and are above a small-business threshold, or if you meet sector-specific criteria regardless of size, assume you are likely in scope and plan accordingly. Being wrong in the direction of over-preparation costs you a documented process you should have anyway. Being wrong in the other direction costs you a missed statutory deadline.
2. Write the substantiality determination criteria down
Draft the internal standard your team will apply to decide whether an incident is reportable, and get it reviewed by whoever handles your legal exposure. Written criteria produced before an incident are defensible; a judgment call made at 2 a.m. on day two of an outage is not. Expect to revise this once the final rule defines the threshold — a draft you revise beats a blank page you start under pressure.
3. Identify where the reportable facts live
A report needs specifics: what happened, when, which systems, what the suspected vector was, what data was involved. Walk through a hypothetical ransomware event and identify, concretely, which log source or tool would tell you each of those things and how long retrieval takes. This is the exercise that surfaces the uncomfortable answers — retention windows shorter than your detection lag, endpoint telemetry that never reached a central store, cloud audit logs nobody enabled.
4. Name the owner and the backup
One named person accountable for the determination and the filing, plus a documented alternate. If your incident response plan says "IT notifies as required," it has no owner. This is the single cheapest item on the list and the one most often missing.
5. Settle the ransom-payment question before you need to
The 24-hour ransom-payment reporting window is tighter than the incident window, and it lands in the middle of the most chaotic decision an organization ever makes. Decide in advance who authorizes payment, who must be informed, and who files — and understand that a payment decision made without that clarity generates a reporting failure on top of everything else. Our overview of what ransomware recovery actually costs covers the economics of the underlying decision.
6. Read your MSP contract for the reporting gap
If a provider manages your environment, the contract likely obligates them to notify you of incidents — often on a vague timeline like "promptly" or "without undue delay." Under a 72-hour statutory clock measured from your reasonable belief, a provider who takes four days to characterize an incident has consumed your entire window. Push for a specific notification interval measured in hours, a commitment to provide the factual detail a regulatory filing requires, and clarity that the reporting obligation is yours while the underlying facts are in their systems. Our MSP contract negotiation guide covers the clause structure this fits into.
What the Final Rule Will Still Change
Three open items are worth tracking rather than guessing at. Applicability thresholds — the specific size and sector criteria that determine coverage, where CISA's stated streamlining intent may narrow the population from what the proposal contemplated. The substantial-incident definition — the practical threshold separating a reportable incident from a contained nuisance, which drives your internal criteria. Submission mechanics and the supplemental-report cadence — the actual portal, required fields, and the obligation to update as new facts emerge, which determines how much your process needs to accommodate ongoing filings rather than a single report.
None of those affect the six items above. That asymmetry is the whole argument for starting now: roughly everything expensive and slow about CIRCIA readiness is independent of the questions the rule will answer.
The practical takeaway for a covered SMB: treat September 2026 as a date the rule might land rather than a date to begin preparing, and use the interval to build the determination process, the fact-retrieval map, and the named ownership that a 72-hour statutory clock requires regardless of what the final text says. If the rule slips a fourth time, you have an incident response capability you needed anyway. If it does not, you are not building it under a compliance deadline while your assessor is also asking for attention.
Frequently Asked Questions
When is the CIRCIA final rule expected?
CISA currently expects to finalize the rule in September 2026, having missed the statutory October 2025 deadline and an internal May 2026 target. Given that history, treat September 2026 as an expectation rather than a firm date, and verify current status directly with CISA before making compliance decisions.
Does the delay push back the 72-hour reporting deadline?
No. The 72-hour incident reporting window and the 24-hour ransom-payment reporting window come from the statute itself, not the rule. The rulemaking determines who is covered, what counts as a substantial incident, and how reports are submitted — not how long covered entities have to file.
Does CIRCIA replace our other incident reporting obligations?
No. CIRCIA adds a reporting recipient alongside existing sector obligations — DFARS DIBNet reporting for defense contractors, SEC disclosure for public companies, HIPAA breach notification, NY DFS notice, and state breach-notification laws all continue to apply on their own triggers and clocks.
What should we do while the rule is still pending?
Form a provisional view of your covered-entity status, draft written substantiality criteria, map where the facts a report requires actually live, name an accountable owner and a backup, settle ransom-payment authority in advance, and tighten your MSP's incident notification interval to something measured in hours. All six are independent of the rule's open questions.
← CMMC Reform Task Force and MSPs | HIPAA Security Rule Overhaul Delayed to 2027 →