The CIRCIA final rule is no longer a “someday” item. After more than two years of delays, CISA sent the final text to the White House on October 1, and as of this week it is still sitting in interagency review. When it clears, the clock on 72-hour incident reports and 24-hour ransom payment reports starts for a very large slice of critical infrastructure, including the plants, pipelines, utilities and water systems that run on OT. 

If you own incident response for an industrial environment, the useful question is not whether the rule will land. It is whether your team could make a defensible reporting decision, with evidence, inside three days, while the plant is still trying to run. This article covers where the rule stands today, what is likely to survive from the proposal, how the requirements play out in OT specifically, and what to do before the publication date is announced. 

Key takeaways 

• Status: CISA submitted the final rule to OMB’s Office of Information and Regulatory Affairs (OIRA) on October 1. It is listed as pending and has not been published in the Federal Register. 

• Nothing is mandatory yet. CISA’s own CIRCIA page says covered incident and ransom payment reporting is not required until the final rule takes effect. Voluntary reporting is still encouraged. 

• Timing is uncertain. OIRA review can run up to 90 days and can be extended, so publication could land before year-end or slip into early next year. 

• The proposed core obligations: report a covered cyber incident within 72 hours of reasonably believing it occurred, report a ransom payment within 24 hours of making it, file supplemental reports, and preserve related data for at least two years. 

• The open questions matter most for OT: scope, the exact definition of a reportable incident, how overlap with sector rules is handled, and the effective date. 

  
  

Where the CIRCIA final rule stands right now 

Here is the sequence of events, because the history explains why the delays keep happening. 

The latest developments, in order of importance 

1. The rule is at OIRA, which is the last real hurdle 

OIRA review is the final interagency step before publication. Law firm Covington notes that the review can take up to 90 days, or longer if OIRA extends it, which means publication could come in early next year rather than before December. Some trade press has reported that publication is expected before year-end. Treat both as plausible and plan for either. 

Once published, the rule will not bite on day one. The effective date is set by the rule text itself, not the statute, and Covington expects it will likely be at least 60 days after publication. The NPRM also proposed different applicability dates by category of covered entity, so your start date may differ from a peer’s. 

2. CISA has already revised its incident reporting form 

On November 9, CISA updated the form on its Incident Reporting Portal. The revised questionnaire asks more specific questions about malware, hacking techniques, insider threats and social engineering, removes duplicate questions, and now incorporates MITRE ATT&CK so analysts can compare incidents across organizations. This is not the CIRCIA form, but it is the best available preview of the level of technical detail CISA wants. If your IR team cannot describe an incident in ATT&CK terms today, that is a gap worth closing now. 

3. Harmonization is the political fault line 

A July report from the Government Accountability Office (GAO-26-108606) identified 117 cybersecurity regulations from 37 federal agencies across nine critical infrastructure sectors. Of those, 48 require incident reporting, 52 require cybersecurity plans or technical information, and 25 require audits or assessments. GAO concluded that past harmonization efforts have made limited progress and warned that without harmonization, CIRCIA could make redundancy worse, especially in heavily regulated sectors. 

For energy specifically, an analysis of the GAO findings points out that of the 19 energy regulations GAO counted, only two require incident reporting: DOE’s Form OE-417 and NERC CIP-008-6. That matters because it shows how thin the existing federal incident reporting layer is for some OT-heavy sectors, which is also why CIRCIA could add real new workload there. 

Industry has pushed hard on this point since the NPRM. CISA has acknowledged that the comments asked for reduced scope and burden, better harmonization and more clarity. Whether the final text delivers a workable reciprocity mechanism is the single biggest unknown. 

4. A related deadline: CISA 2015 information-sharing protections expire December 11 

Separate from CIRCIA, the Cybersecurity Information Sharing Act of 2015 is set to expire again on December 11. It lapsed during last year’s government shutdown and has survived since through short-term extensions. A coalition of 35 industry groups has asked Congress to extend it through 2035 in the defense authorization bill, but that bill is stalled. Industry groups have warned that any lapse can make companies more reluctant to share information about intrusions. If you share OT threat data with ISACs or the government, watch this one alongside CIRCIA. 

What the proposed rule says, and what will probably carry over 

The final text may differ, so read this as the baseline from the April 2024 proposal rather than settled law. 

Who is covered. CISA proposed two routes: sector-based criteria and size-based criteria. Under the size-based test, entities in the 16 critical infrastructure sectors that exceed Small Business Administration size standards would be captured. CISA estimated the rule would affect roughly 316,000 entities. The sector-based criteria also reach technology providers, including those who develop software that can control access to operational technology, and providers of OT and OT software components. If you are an OEM, integrator or managed service provider supporting industrial customers, check your own status, not just your customers’. 

What triggers a report. A covered cyber incident is a substantial cyber incident experienced by a covered entity. The proposal lists four impacts: 

1. A substantial loss of confidentiality, integrity or availability of an information system or network. 

2. A serious impact on the safety and resiliency of operational systems and processes. 

3. A disruption of the ability to engage in business or industrial operations, or to deliver goods or services. 

4. Unauthorized access to a system or nonpublic information that was facilitated through or caused by a compromise of a cloud provider, managed service provider or other third-party data host, or by a supply chain compromise. 

The proposal’s definition of operational technology explicitly includes industrial control systems, SCADA, distributed control systems and programmable logic controllers. 

The clocks. Report within 72 hours of reasonably believing a covered incident occurred. Report a ransom payment within 24 hours of making it. If new substantial information emerges, or a ransom is paid after you filed the incident report, file a supplemental report. 

Data preservation. Keep incident and ransom-related data for at least two years from the most recent required report. The obligation starts when you form a reasonable belief that an incident occurred, or when a ransom payment is disbursed, whichever is earlier. The proposed categories include logs, forensic images, network traffic, indicators of compromise, attack vector details and threat actor communications. 

Protections and enforcement. The statute and proposal include legal protections for submitted reports, though information provided in response to a subpoena does not get them. CISA can request more information and, if needed, issue a subpoena. Non-compliance can be referred to the Attorney General, and federal contractors face possible suspension and debarment. 

Why OT changes the CIRCIA conversation 

Most CIRCIA commentary is written from an IT and legal point of view. In an industrial environment the hard parts look different. 

Trigger three will catch more than OT compromises. A ransomware event that stays on the corporate network but pushes you to isolate a plant or halt production because you cannot trust your data feeds can still be a disruption of industrial operations. Under the proposed wording, the question is what the cyber incident did to operations, not whether it reached Level 1 or Level 2. 

“Reasonable belief” is harder to reach in OT. A suspicious engineering workstation, an unexplained controller mode change or a historian gap does not come with a clean verdict. IT teams can triage from EDR telemetry. OT teams often cannot, because the visibility is not there. The rule gives you a 72-hour clock from reasonable belief, but your decision process still needs a documented, defensible point at which belief is formed. Without one, you will either report too early, too often, or too late. 

Safety impact is a trigger of its own. Loss of view, loss of control, a safety instrumented system trip tied to a cyber cause, or a forced move to manual operations are all candidates for trigger two. Your process safety and operations teams, not just security, need a say in how that is judged. 

Third-party access is a reporting event waiting to happen. Vendor remote access, integrator jump hosts and managed service connections are the routes trigger four was written for. If a supplier is compromised and your plant is reached through that connection, you may owe a report even if the supplier owes one too. 

Evidence preservation is the quiet pain point. Two years of retention for network captures, firewall and jump host logs, engineering workstation images, PLC project files and historian data is a storage, chain-of-custody and legal-hold problem. Many plants do not log at the level the proposal assumes. Fixing that takes months, not days. 

Where CIRCIA could overlap with reporting you already do 

These regimes have different triggers, recipients and clocks. The table is a planning aid based on commonly cited requirements. Have counsel confirm applicability and current text for your organization. 

The practical lesson is that one incident can start several clocks at different hours, with different audiences and different definitions of “reportable.” The organizations that cope best are the ones that build one fact base and one decision log, then draw each report from it. 

A practical OT readiness checklist 

You do not need the final text to start. The following steps hold up whether the rule publishes next month or next quarter. 

1. Run a scoping assessment. Test your legal entities against both the sector-based and size-based criteria in the proposal. Include subsidiaries, joint ventures and any OT product or service lines. Do not assume your customers’ status is yours. 

2. Write down what “substantial” means for your plants. Translate the four triggers into plant-specific criteria: what loss of view, loss of control, forced manual operation or production stoppage counts, and who decides. Get operations and process safety to sign off. 

3. Define the moment of “reasonable belief.” Name the role that forms it, the evidence that supports it and how it is logged with a timestamp. This is the start of the 72-hour clock, so it should never be an informal judgment. 

4. Build the 72-hour playbook. Use the sample timeline below as a starting point. Assign a single owner for external reporting. 

5. Plan the 24-hour ransom payment path. Decide in advance who has authority, who involves legal, insurance and law enforcement, and who files. You do not want to design this during an incident. 

6. Close OT visibility gaps. You cannot preserve or report what you cannot see. Asset inventory, passive network monitoring at the IT/OT boundary and logging from jump hosts and remote access are the foundation. 

7. Set up evidence preservation for OT. Decide what gets imaged, where it is stored, how long, and who can place a legal hold. Include PLC and engineering project files and vendor access logs. 

8. Review supplier and MSP contracts. Add notification clocks that let you meet your own deadlines, plus access to logs and forensic support. 

9. Map your data to the report fields. Start with CISA’s updated reporting form and ATT&CK, including ATT&CK for ICS, so analysts describe techniques in a common language. 

10. Exercise it. Run a tabletop where IT, OT, legal, communications and operations work through a ransomware scenario that stops a line. Time the decisions. Most teams find the weak point is not technical; it is who is allowed to decide. 

A sample 72-hour reporting timeline for an OT incident 

Note that in practice the 72 hours run from reasonable belief, not from first alert. The timeline above is deliberately conservative, since a late report is a worse position than an early, accurate one with updates to follow. 

Common mistakes to avoid 

• Waiting for the effective date. Most of the work, such as logging, contracts and decision rights, takes longer than the lead time you will get. 

• Treating CIRCIA as a legal-only project. Legal owns the filing. Operations and security own the facts. 

• Assuming OT visibility exists. Many plants find out during the first tabletop that they cannot answer basic scoping questions. 

• Building a separate process per regulation. Maintain one incident fact base with outputs for each regime. 

• Ignoring suppliers. Your reporting position depends on how fast your integrators and MSPs tell you about their own incidents. 

How Shieldworkz can help 

Shieldworkz is an end-to-end industrial OT cybersecurity company, covering SCADA, OT and IoT with services, platform and solutions under one roof. For teams preparing for CIRCIA, that typically means three things: understanding your regulatory exposure (see our CIRCIA compliance page), getting visibility into your OT networks so you can scope and preserve evidence, and having experienced responders on call through our OT incident response retainer when the clock is running. 

If you would like help with a CIRCIA scoping assessment, an OT tabletop exercise, or a reporting playbook, talk to our team. 

Frequently asked questions 

Is CIRCIA reporting mandatory today? No. CISA states that covered cyber incident and ransom payment reporting is not required until the final rule takes effect. Voluntary reporting of significant incidents is still encouraged. 

When will the CIRCIA final rule be published? No date has been announced. The rule has been under OIRA review since October 1, and that review can take up to 90 days or longer. Publication could come before the end of the year or in early next year. 

When will organizations actually have to comply? The effective date will be set in the final rule. Covington expects it will likely come at least 60 days after publication, and the proposal contemplated different applicability dates for different entity categories. 

Does CIRCIA cover operational technology? Yes. The proposal defines operational technology to include ICS, SCADA, DCS and PLCs, and treats a serious impact on the safety and resiliency of operational systems as a reportable trigger. 

Will a CIRCIA report replace my other reports? Not automatically. The NPRM included a harmonization mechanism for some situations, but GAO and industry have both flagged overlap as unresolved. Whether the final rule provides workable reciprocity is one of the biggest open questions. 

What should we do first? Determine whether you are a covered entity, define what a reportable incident looks like in your plants, and test your ability to make a reporting decision within 72 hours. 

Additional resources  

A downloadable report on the Stryker cyber incident here  
Removable media scan solution vendor evaluation and selection checklist here  
IEC 62443-based OT/ICS risk assessment checklist for the food and beverage manufacturing sector here 
IEC 62443-based remediation guides here