CIRCIA Is Coming: 72-Hour Incident Reporting, Explained

If your organization operates in one of the 16 critical infrastructure sectors, CIRCIA will require you to report substantial cyber incidents to CISA within 72 hours and ransom payments within 24 hours. The statutory deadline for the final rule was October 4, 2025 and passed without one; as of August 2026 the Unified Agenda entry (RIN 1670-AA04) targets September 2026. Don't read the delay as a reprieve. Those two clocks come from the statute itself, the Cyber Incident Reporting for Critical Infrastructure Act of 2022, and no amount of rulemaking delay will soften them. The delay buys you preparation time. That's all it buys.

We'll say this plainly: most incident response plans we review would fail a CIRCIA tabletop today. Not because the teams are weak, but because the plans were written for a world where notification decisions had days or weeks of runway. State breach laws mostly say "without unreasonable delay." CIRCIA says 72 hours from the moment you reasonably believe a covered incident occurred. That is a different sport, and you don't get good at it by reading the rule when it publishes.

Key takeaways

• If you operate in one of the 16 critical infrastructure sectors, CIRCIA will require reporting substantial cyber incidents to CISA within 72 hours and ransom payments within 24 hours.
• The final rule is projected for September 2026, but both clocks were written by Congress rather than CISA, so no amount of rulemaking delay softens them.
• The 72-hour clock starts at reasonable belief that a covered incident occurred, not at forensic certainty. "We're still investigating" does not pause it.
• Run the covered-entity self-assessment this quarter and write the memo either way. "We're not critical infrastructure" is an intuition, not an analysis.
• A compliant reporting capability has three parts: a decision tree with named roles, evidence capture from the first alert against the preservation window, and a counsel loop that runs in hours rather than days.

Why the delay changes nothing about the clocks

Congress passed CIRCIA in March 2022. CISA published the proposed rule on April 4, 2024, held four public town halls in June 2026, and says it is still reviewing comments and working on the final rule, with multiple funding lapses having affected the schedule (CISA). The reporting obligation only becomes enforceable when the final rule takes effect, so technically nothing is due yet. But the two numbers everyone cares about were written by Congress, not by CISA:

• 72 hours to report a covered cyber incident, measured from when the entity reasonably believes the incident occurred
• 24 hours to report a ransom payment, measured from when the payment is made

The rulemaking decides who is covered, what counts as substantial, what goes in the report, and how long you preserve supporting data. It cannot move those deadlines. So every month the rule slips is a month you can spend building the reporting muscle on your own schedule. Organizations that wait for the final text will be building it under enforcement pressure instead, which is the most expensive way to learn anything.

We track the rule's status on our regulatory radar, and we plan to rewrite this article the same week the final rule lands. Treat everything below as a readiness guide keyed to the proposed rule, not a summary of final requirements.

Are you a covered entity? Run the self-assessment now

CIRCIA's reach is wider than most executives assume. Under the proposed rule, you're a covered entity if you operate in one of the 16 critical infrastructure sectors CISA recognizes and you either exceed the SBA small business size standard for your industry, or you meet one of the sector-based criteria that apply regardless of size.

The 16 sectors: chemical, commercial facilities, communications, critical manufacturing, dams, defense industrial base, emergency services, energy, financial services, food and agriculture, government facilities, healthcare and public health, information technology, nuclear, transportation systems, and water and wastewater.

Read that list again with your own operations in mind. A SaaS company can plausibly sit in the IT sector. A regional hospital group is squarely healthcare and public health. A precision machine shop with Department of Defense contracts is defense industrial base, and probably already sweating CMMC. "We're not critical infrastructure" is an intuition, not an analysis, and intuitions don't hold up when a CISA request for information arrives.

The self-assessment is straightforward and cheap to do now:

1. Map your operations against the sector definitions. CISA publishes sector profiles; use them rather than guessing.

2. Pull your NAICS code and check the SBA size standard (revenue or headcount, depending on industry). Exceeding it in a covered sector likely makes you a covered entity.

3. Check the sector-based criteria in the proposed rule, which pull in certain smaller entities because of what they do rather than how big they are.

4. Document the conclusion either way. Date it, have counsel review it, and revisit it when the final rule publishes. If you conclude you're not covered, write down why. That memo costs a few hours today and is worth a great deal during an incident, when nobody has spare hours.

What counts as a substantial cyber incident

Under the proposed rule, a substantial cyber incident is one that causes any of the following: a substantial loss of confidentiality, integrity, or availability of a covered system; a serious impact on the safety and resiliency of operational systems and processes; a disruption of your ability to engage in business or industrial operations; or unauthorized access enabled by a compromise of a third-party service provider or supply chain.

Notice what isn't there. A blocked phishing campaign is not reportable. A single compromised laptop that's contained in an hour probably isn't either. But a ransomware detonation that halts order fulfillment, a cloud provider compromise that exposes your data, or an attacker with sustained access to production systems all likely qualify.

The hard part isn't the extreme cases. It's the middle: the incident that might be substantial depending on facts you won't have for another 48 hours. The 72-hour clock starts at reasonable belief, not at forensic certainty, so "we're still investigating" doesn't pause it. That tension is exactly why you need structure instead of judgment calls made at 2 a.m.

What a compliant reporting capability looks like

Three components. If your incident response plan has all three, CIRCIA is an update, not a rebuild.

A decision tree, not a debate

Write a flowchart that runs from detection to submission: severity triage, then an explicit question ("does this plausibly meet the substantial incident definition?"), then who makes the reportability call, who drafts the report, who approves it, and who submits it. Name roles, not people, because people take vacations.

Two details matter more than the rest. First, log the moment someone forms a reasonable belief that a covered incident occurred; that timestamp is when your 72 hours start, and you want your own contemporaneous record of it. Second, pre-draft the report skeleton now. CISA's proposed content requirements (affected systems, incident description, indicators, response actions, impact) map cleanly to fields you can template. Filling in a template under pressure works. Composing from a blank page under pressure doesn't.

Evidence capture that starts at detection

The proposed rule includes data preservation obligations, two years in the proposal, covering the records that support your report. Your incident process needs to capture and retain the incident timeline, indicators of compromise, affected asset inventory, response actions taken, and relevant communications, from the first alert onward.

This is where we see the most common real-world gap: logging retention. If your SIEM keeps 30 days and your cloud audit logs keep 90, you cannot preserve what you never had. Check retention against the preservation window now; fixing it is a configuration change today and an impossibility retroactively.

The counsel loop

CIRCIA reports carry statutory liability protections and are exempt from FOIA disclosure, which is genuinely favorable compared to most notification regimes. But what you write to a federal agency still matters, and supplemental reports are required when substantial new information emerges, so early wording constrains later filings.

That means counsel reviews before submission, and the review has to run in hours, not days. If your outside counsel needs a week to return a redline, they're the wrong counsel for this workflow, or you need a pre-negotiated on-call arrangement. Put the counsel step into your tabletop exercises and time it. We've watched well-prepared teams lose a full day of their 72 hours waiting on a legal review that nobody had rehearsed.

What to do between now and September

In order, because sequence matters:

1. Run the covered-entity self-assessment this quarter and get the memo written.

2. Add CIRCIA triggers to your incident response plan: the reasonable-belief timestamp, the reportability decision point, the 24-hour ransom payment path.

3. Run one tabletop against the 72-hour clock, with the counsel loop included and timed.

4. Fix logging and evidence retention gaps against the proposed preservation window.

5. Build a single notification matrix covering CIRCIA alongside your existing obligations: state breach statutes, sector regulators, SEC disclosure if you're public, HIPAA if you handle PHI, and contractual notice clauses. One incident will trigger several of these at once, on different clocks.

An honest note on buying help: if you already have a tested IR plan and a retainer with a firm that runs tabletops, you likely need a few hours of gap analysis, not a new engagement. Where we earn our fee is with organizations starting from a plan that hasn't been exercised, or none at all. Our incident response practice builds and pressure-tests exactly this capability, and our compliance as a service clients get CIRCIA folded into a maintained obligations register rather than tracked in someone's head. Either way, the 24-hour ransom payment clock deserves its own tabletop scenario, because payment decisions involve a different set of people (finance, insurers, sometimes OFAC screening) than the technical response does.

This article has a shelf life, on purpose

The final rule, targeted at September 2026 on the Unified Agenda as of August 2026, may adjust the covered-entity criteria, the substantial-incident definition, report content, and preservation periods. The 72-hour and 24-hour clocks will survive because Congress set them. When the rule publishes, we'll rewrite this article within the week and note what changed. Until then, the regulatory radar entry carries the latest status.

Frequently asked questions

How do we know if we're a covered entity under CIRCIA?

Start with two questions: do you operate in one of the 16 critical infrastructure sectors, and do you exceed the SBA small business size standard for your NAICS code? If both answers are yes, assume you're covered under the proposed rule. Some smaller entities are also pulled in by sector-based criteria tied to what they do rather than their size. Document the analysis either way and have counsel review it, because the conclusion may shift when the final rule publishes.

Does CIRCIA replace state breach notification laws?

No. CIRCIA reporting to CISA sits on top of, not instead of, state breach notification statutes, sector-specific rules like HIPAA, SEC disclosure obligations for public companies, and contractual notice requirements. One incident can trigger several regimes on different clocks, which is why we recommend a single notification matrix. There is a limited exception concept for substantially similar reports already made to another federal agency under an agreement with CISA, but state obligations are untouched.

When does the 72-hour clock actually start?

At the point your organization reasonably believes a covered cyber incident occurred, not when forensics confirms it. That standard is deliberately early, and it's why your incident process should log the moment reasonable belief forms. Waiting for certainty is not a defense; it's how organizations end up explaining a late report.