CISA's new rulemaking agenda covers areas previously outside its remit. In-house counsel and security officers break down the five areas with the highest near-term compliance exposure for IT organisations.
Key Takeaways
The passage of the Cyber Incident Reporting for Critical Infrastructure Act, commonly known as CIRCIA, represents the most significant expansion of the Cybersecurity and Infrastructure Security Agency's regulatory authority since the agency was established in 2018. The law does not merely accelerate CISA's existing responsibilities. It creates new categories of mandatory reporting, extends the agency's reach into sectors and technical domains it previously influenced only through voluntary guidance, and gives CISA an enforcement toolkit, including civil penalties and subpoena authority, that fundamentally changes the risk calculus for non-compliant organisations. For IT leaders in sectors that fall within the 16-sector critical infrastructure framework, the question is no longer whether to build CIRCIA compliance infrastructure. It is how quickly that infrastructure can be made operational.
The scope of CIRCIA is broader than many IT organisations initially recognised when the legislation was signed into law in March 2022. The 16 critical infrastructure sectors defined by Presidential Policy Directive 21 include energy, water and wastewater, transportation, healthcare and public health, financial services, communications, information technology, defence industrial base, food and agriculture, government facilities, emergency services, nuclear reactors, chemical facilities, critical manufacturing, dams, and commercial facilities. The breadth of that list means that a substantial proportion of mid-to-large enterprises in the United States fall within scope, either as primary operators of critical infrastructure or as providers of services essential to such operators. Organisations that have assumed they are outside CIRCIA's scope because they do not think of themselves as critical infrastructure operators should conduct a formal scope assessment, because the regulatory definition of covered entities is considerably wider than the colloquial understanding.
The enforcement posture CISA has adopted in implementing CIRCIA signals that the agency intends to use its new authority actively. The civil penalty structure, reaching $25,000 per day for continued non-compliance, is designed to create immediate financial incentive for organisations to file required reports rather than delay or ignore the obligation. The subpoena authority is an even more significant tool: it means that CISA can compel an organisation to produce incident documentation even if the organisation disputes whether it was required to report. The combination of financial penalties and compelled disclosure eliminates the option of quiet non-compliance that some organisations might have chosen under a purely voluntary reporting framework. Organisations that have historically treated federal cybersecurity reporting as advisory need to recalibrate that assessment substantially.
CIRCIA's reporting framework establishes two distinct notification windows tied to incident type. Ransomware payments must be reported to CISA within 24 hours of the payment being made. This is the most aggressive reporting window in the US federal cybersecurity regulatory landscape, and it applies regardless of the amount of the payment or the nature of the ransomware incident. The rationale is that ransomware payment data is of immediate operational value to CISA for understanding adversary activity, victim targeting patterns, and the effectiveness of sanctions against ransomware operators. For organisations in 24-hour reporting sectors, this requires that the decision-making process around ransomware payment include a parallel notification workflow, not a sequential one where reporting is considered after the payment decision is made.
The 72-hour reporting window applies to covered cyber incidents, defined under the implementing regulations as incidents that lead to a substantial loss of confidentiality, integrity, or availability of a covered entity's information systems; a serious impact on the safety and resiliency of operational systems and processes; a disruption of business or industrial operations; or unauthorised access to a covered entity's information systems facilitated through or caused by a third-party provider. Each of those definitional elements requires interpretation, and that interpretation needs to happen within 72 hours of the organisation becoming aware of the incident. Organisations that lack a structured incident classification process, one that can evaluate an incident against these criteria in real time, will find that the 72-hour window is functionally much shorter than it appears, because the classification decision must be made, documented, and acted upon before the window closes.
Beyond the reporting requirements, CIRCIA's broader mandate extends into three areas that represent genuinely new regulatory terrain for CISA. The software security provisions require that software products used in critical infrastructure operations meet defined security standards, including requirements around secure development practices and vulnerability disclosure. The IoT device security standards establish baseline requirements for connected devices deployed in critical infrastructure environments, including mandatory authentication, encryption, and patch management capabilities. The supply chain risk management provisions require covered entities to document their processes for assessing and mitigating risks from third-party software and hardware components. These three areas collectively represent CISA's transition from an agency that issues guidance on these topics to one that can mandate compliance with defined standards and verify that compliance through supervisory activity.
The first area of maximum compliance exposure is incident reporting infrastructure. Most organisations' existing incident response programmes were designed around internal remediation objectives, not around an external reporting obligation with a defined and legally enforceable deadline. The structural changes required to support CIRCIA reporting are not trivial. The organisation needs detection capability sufficient to identify covered incidents rapidly; classification tooling or processes to evaluate whether a detected incident meets the covered incident threshold; an escalation path that reaches the person authorised to submit a CISA report; and a reporting workflow that can produce a compliant report, including all required data elements, within the applicable window. For the 24-hour ransomware payment requirement, the challenge is particularly acute: the reporting obligation activates at the moment of payment, which means the workflow must be pre-built and ready to execute before any ransomware incident occurs.
The second area is software bill of materials compliance. A software bill of materials is a formal, machine-readable inventory of all software components in a product or application, including open-source libraries, third-party dependencies, and internally developed code. CISA has been explicit that SBOM requirements will apply to software used in critical infrastructure operations, and the implementing guidance specifies minimum data fields, format standards, and update frequency requirements. The practical challenge for most organisations is twofold: they do not have comprehensive SBOMs for the software they develop or operate, and they cannot easily obtain them from the commercial software vendors whose products they rely upon. Building an SBOM programme requires investment in tooling, vendor contract provisions that make SBOM production a contractual obligation, and internal processes for maintaining SBOMs as software evolves. Organisations that begin this work now will have a significant lead-time advantage over those that wait for formal enforcement action.
The third area is IoT device inventory and security. The average large enterprise significantly underestimates its IoT device count. Operational technology, building management systems, physical security devices, medical equipment in healthcare settings, and industrial control systems all contribute to a device population that is typically two to four times larger than IT asset management systems reflect, because many IoT devices were deployed by operational teams without IT involvement and are not visible through standard network discovery tools. CISA's IoT security standards require that covered entities maintain an accurate inventory of all IoT devices in their environment, verify that those devices meet the minimum security requirements, and have a programme for identifying and remediating devices that do not. Building that inventory from scratch is a multi-month undertaking for large organisations, making it one of the longest lead-time compliance items in the CIRCIA programme.
The fourth area is cloud service provider oversight. A growing proportion of critical infrastructure functions are delivered through or dependent on cloud services, and CIRCIA's requirements do not diminish simply because the covered entity has outsourced a function to a cloud provider. The covered entity remains responsible for ensuring that its use of cloud services meets the applicable security standards and that incidents affecting cloud-delivered services are reported in accordance with CIRCIA's timelines. This creates a due diligence obligation: covered entities need contractual provisions that require cloud providers to notify them of security incidents within a timeframe that allows the covered entity to meet its own CISA reporting obligations. Standard cloud provider terms of service do not typically include notification commitments that are tight enough to support a 72-hour external reporting window, and renegotiating those provisions requires lead time and, in some cases, significant commercial leverage.
The fifth area is supply chain transparency. CIRCIA requires covered entities to document their supply chain risk management processes and to maintain records that demonstrate how they identify, assess, and mitigate risks from third-party hardware and software components. This is a documentation-intensive requirement that goes significantly beyond the informal vendor risk management practices many organisations have in place. A compliant supply chain risk management programme includes a vendor inventory, a risk-tiering methodology, a defined assessment process for each vendor tier, documented risk treatment decisions, and a regular review cycle. For organisations with complex supply chains spanning hundreds or thousands of vendors, building this documentation in a form that could withstand CISA scrutiny is a substantial undertaking that requires dedicated programme ownership.
"CISA's expanded mandate is the most significant shift in the US federal cybersecurity regulatory landscape in a decade. The 16-sector coverage, the subpoena authority, the tight reporting windows: the enforcement toolkit is substantial. Organisations that are treating this as a watch-and-wait situation are misjudging the regulatory momentum."
Thomas Barker, Former CISA Deputy Director, currently Partner, Cyber Regulatory Practice, Hogan Lovells
For IT and legal teams beginning their CIRCIA compliance programmes, the CISA reporting portal is the primary operational interface for submitting required notifications. The portal accepts reports in a structured format that includes incident timelines, affected systems, estimated impact scope, and any known attribution information. Organisations should register with the portal before an incident occurs, familiarise designated reporters with the submission interface, and test the workflow in tabletop exercises. The submission process itself is not technically complex, but completing it accurately under the time pressure of an active incident, while simultaneously managing the response effort, requires prior practice. Teams that encounter the portal for the first time during a live incident are significantly more likely to produce incomplete or inaccurate reports, which creates secondary compliance risk.
Legal privilege considerations in incident response planning deserve specific attention in the CIRCIA context. Communications created during an incident response that are directed by outside counsel and made for the purpose of obtaining legal advice may be protected by attorney-client privilege. That privilege does not extend to the mandatory CISA report itself, which is a regulatory filing. However, the internal analysis and deliberations that precede the report, including the classification decision, the materiality assessment, and the decision about what information to include, can be structured to maximise the potential for privilege protection. Organisations should engage outside counsel in establishing the privilege architecture for their CIRCIA compliance programme before an incident occurs, not in the middle of one.
CISA's voluntary collaborative programmes, including the Joint Cyber Defense Collaborative and the sector-specific information sharing and analysis organisations, offer an important avenue for building regulatory relationships before they are needed in an enforcement context. Organisations that participate in these programmes demonstrate proactive engagement with CISA's mission, develop familiarity with the agency's staff and processes, and benefit from threat intelligence sharing that can improve their incident detection and response capability. That relationship capital has proven meaningful in the early enforcement actions brought by federal cyber regulators, where the severity of the regulatory response has consistently correlated with the quality of the pre-existing relationship between the organisation and the agency. Looking across the global regulatory landscape, the convergence of cyber incident reporting obligations in the United States, the European Union under NIS2, and the United Kingdom under the updated NIS Regulations creates a compliance environment in which organisations with cross-border operations face multiple, overlapping reporting obligations for the same incident. Building a unified incident response and reporting framework that can satisfy all applicable requirements simultaneously is no longer an efficiency goal. It has become a compliance necessity.
68% of mid-market enterprises have not completed their NIS2 gap assessment. Penalties can reach 2% of global annual turnover.
The SEC's final cybersecurity disclosure requirements are in effect. IT and legal teams need to close six capability gaps before the next material incident occurs.
