CIRCIA's 72-Hour Reporting Clock Is Statutory, and It's Coming for Financial Institutions. What Your Incident Response Plan Is Missing.

TL;DR

• CISA’s CIRCIA final rule is expected September 2026, but the 72-hour cyber incident reporting clock and 24-hour ransomware payment deadline are written into the statute — they won’t change no matter when the rule lands
• Financial institutions are covered entities under CIRCIA as part of designated critical infrastructure; banks, credit unions, payment processors, and fintechs all fall in scope
• CIRCIA reports go to CISA, separately from the banking regulators’ 36-hour rule, SEC’s 4-day 8-K, DORA, and state breach notification laws — you can’t satisfy one by filing another
• Most financial institution incident response plans don’t have a CIRCIA reporting lane, a tested CISA portal account, or a ransomware payment reporting protocol that will meet the 24-hour clock

The Deadline That Won’t Move

CISA has slipped the CIRCIA final rule twice. The original target was May 2026. That moved to a fall 2026 timeline — the agency is now pointing to September 2026, with the delay attributed in part to a DHS funding disruption that interrupted planned stakeholder outreach.

Every time the rule slips, institutions exhale. This is the wrong response.

The 72-hour cyber incident reporting deadline and the 24-hour ransomware payment deadline are not regulatory choices CISA makes in its rulemaking. They are statutory requirements — written into the Cyber Incident Reporting for Critical Infrastructure Act of 2022 by Congress. No amount of rulemaking delay changes the underlying statutory obligation. When the final rule eventually takes effect, these two clocks will be the same clocks they were designed to be four years ago.

What the delay buys is lead time — time to build detection and escalation workflows, register for the CISA reporting portal, test the reporting path, and update incident response plans before enforcement starts. Institutions that treat each deadline slip as an invitation to defer that work are running down a runway that ends with the same required infrastructure, on a compressed timeline, after enforcement begins.

Financial institution incident response teams have spent the last three years adding reporting lanes for the banking regulators’ 36-hour rule, SEC’s 4-day materiality clock, and DORA’s 4-hour ICT incident requirement for EU-connected entities. CIRCIA is another lane. The question isn’t whether to build it — it’s whether you build it now or under pressure.

Who CIRCIA Covers in Financial Services

CISA’s proposed rule defines “covered entity” to include any organization that owns or operates within or in support of a designated critical infrastructure sector. Financial services is one of 16 designated sectors. This means the scope in financial services is broad: banks, credit unions, insurance companies, investment managers, payment processors, money service businesses, and — importantly — fintechs providing financial products or services.

The estimated 300,000 covered entities across all sectors includes a significant concentration in financial services. CISA’s proposed rule does include a size threshold — very small businesses below a defined revenue and employee threshold may be excluded — but the threshold is set low enough that most established financial institutions and fintechs will be within scope.

For the common fintech question of “does CIRCIA apply to us?”: if you hold or transmit customer funds, process payments, provide lending products, or are licensed as a financial services provider, CIRCIA almost certainly applies to your organization. The better question is which incidents would qualify as “covered cyber incidents” under the rule’s criteria — and how your current detection and classification capabilities map to those criteria.

The 72-Hour Clock: When Does It Start?

The CIRCIA statute triggers the 72-hour clock when the covered entity “reasonably believes” a covered cyber incident has occurred. This phrase is doing significant compliance work.

“Reasonably believes” is not the same as “has determined” or “has confirmed.” The clock doesn’t start when your incident response team closes the investigation and confirms that a covered cyber incident occurred. It starts when a reasonable assessment of the available information would lead you to conclude that a covered cyber incident has likely occurred.

For financial institutions with mature security operations centers and incident classification frameworks, this distinction matters in how detection and escalation workflows are designed. If your current workflow waits for a complete post-incident investigation before triggering regulatory notification assessments, you have a CIRCIA timing problem. The determination to notify CISA needs to be embedded early in the detection workflow — at the point where the available information reasonably suggests a covered cyber incident, not at the point where you’ve finished determining exactly what happened.

The practical implication: incident response playbooks need a CIRCIA assessment checkpoint — a defined decision point, early in the incident timeline, where the response team evaluates whether available information meets the “reasonably believes” standard for a covered cyber incident. That checkpoint should be triggered at or before the 24-hour mark, so the reporting decision can be made and the report prepared within the 72-hour window even if investigation continues.

Waiting until you “know what happened” is not a viable strategy for a 72-hour statutory deadline.

Ransomware Payment Reporting: The 24-Hour Problem

The ransomware payment reporting requirement is the one most likely to catch financial institutions off guard, because it operates on a separate trigger and a shorter clock.

Under CIRCIA, any covered entity that makes a ransom payment — to any extent, through any mechanism — must report that payment to CISA within 24 hours of making it. The obligation is categorical: if you pay, you report. It does not depend on whether the underlying ransomware attack independently qualifies as a covered cyber incident.

For financial institutions, this creates a specific gap in most current incident response plans: the ransomware payment decision and the CIRCIA reporting obligation are typically handled by different teams on different timelines. The decision to pay ransom — if it’s made at all — typically runs through executive leadership, legal counsel, insurance carriers, and potentially law enforcement consultation. By the time that decision is made, a 24-hour reporting clock has limited room for error.

Ransomware response playbooks need to explicitly address CIRCIA: the moment a ransom payment is authorized, a parallel 24-hour clock to CISA starts. The person who authorizes payment needs to know this. The person responsible for regulatory reporting needs to be in the room or notified immediately. The CISA reporting workflow needs to be pre-staged so that filing a report within 24 hours is a matter of execution, not of figuring out the process under time pressure.

The incident response decision log and notification clock documentation framework needs a CIRCIA row — including separate entries for “covered cyber incident 72-hour” and “ransom payment 24-hour.”

Why CIRCIA Creates a New Layer, Not a Substitute

Financial institutions are not new to cyber incident reporting. Most have already built infrastructure for multiple overlapping obligations. CIRCIA adds a new lane to a reporting matrix that already includes:

The critical point: these obligations report to different agencies with different mandates, and filing one does not satisfy another. A report to the OCC is not a report to CISA. A CISA report does not satisfy SEC 8-K disclosure requirements. An SEC 8-K does not satisfy state breach notification laws.

Post-CIRCIA, a significant cyber incident at a public financial institution could trigger all six reporting obligations simultaneously, with different clocks, different filing formats, different information requirements, and different agency relationships. Incident response plans that don’t have this matrix explicitly mapped — with a clear owner for each lane — will fail one or more of them in the chaos of an actual incident.

The SEC 8-K cybersecurity materiality framework and the DORA ICT incident reporting requirements are now table stakes for public companies and US banks with EU operations respectively. CIRCIA adds the CISA obligation across the board for financial sector covered entities.

What to Have in Place Before the Final Rule Drops

Register for the CISA reporting portal now. CISA operates an online reporting portal for cyber incident reports. Financial institutions should register organizational accounts, designate reporting officers, and test the submission process before the final rule takes effect. Having an untested reporting pathway is a version of not having a reporting pathway — when you’re 60 hours into an active incident, discovering that your CISA portal account doesn’t work is a solvable problem you should have solved earlier.

Define your organization’s covered cyber incident threshold. CISA’s “substantial” standard will be interpreted by reference to your operations. Compliance teams should work with security operations, legal, and executive leadership to define — in advance — what level of operational disruption, unauthorized access, or data impact would reasonably constitute a covered cyber incident for your organization. That definition becomes the trigger for the 72-hour clock assessment.

Add CIRCIA to your incident severity matrix. Most financial institution incident response plans have a severity or priority matrix that triggers different escalation paths and regulatory reporting assessments. CIRCIA needs a dedicated row in that matrix: what incident characteristics trigger a CIRCIA covered cyber incident assessment, who makes the assessment, and by what point in the incident timeline.

Embed a CIRCIA checkpoint in your ransomware playbook. Every ransomware response playbook needs an explicit step: “If ransom payment is authorized, CISA report is due within 24 hours of payment. Notify compliance/legal immediately upon authorization.” This should be at the decision-point stage of the playbook, not at the post-incident review stage.

Build the notification obligation matrix for your organization. Using the framework above, create a complete, organization-specific version of which incidents trigger which reporting obligations, to which agencies, on what timelines. Assign a designated owner for each lane. Review it with legal counsel and update it after CIRCIA’s final rule publishes.

So What?

CISA’s September 2026 target for the CIRCIA final rule gives financial institutions a window — a compressed one, but a real one — to build the infrastructure before enforcement starts.

The institutions that will have problems after the rule takes effect are the ones that treated each rulemaking delay as a reason to delay internal preparation. They’ll have a 72-hour clock, a 24-hour ransomware payment clock, a new CISA reporting portal they’ve never used, and an incident response plan that doesn’t have a CIRCIA lane.

The statutory obligations are fixed. The 72 hours is 72 hours. The 24 hours is 24 hours. Build the detection checkpoints, register the portal account, update the ransomware playbook, and map the full notification matrix now — while the window is open and the pressure is low. That’s a fraction of the effort of doing it during an active incident with a clock running.

The Incident Response & Breach Notification Kit includes step-by-step incident response playbooks, a regulatory notification matrix covering federal and state obligations, and breach notification templates — the infrastructure CIRCIA compliance requires your organization to have in place before the 72-hour clock starts.