Mandated cybersecurity incident reporting is coming soon to critical infrastructure, in the form of major regulations like the Cyber Incident Reporting for Critical Infrastructure Act of 2022 (CIRCIA) in the U.S. and Network and Information Systems Directive (NIS2) in the European Union. On both sides of the Atlantic, mandated reporting has been a long time coming, and so-called “covered entities” still have plenty of time to prepare for when it goes into effect in 2025 or 2026.
Still, when executives hear the phrase cybersecurity incident reporting, their first thought is probably how burdensome it will be, followed by vigorous debate over what defines a “reportable” incident. Any incident reporting rule relies heavily on that definition, which in turn can determine its burden.
In this article we’ll compare the incident reporting requirements in these two major regulations and offer guidance on how to (1) define a reportable incident in the context of your operations and (2) put a plan in place that satisfies the applicable regulation’s intent without overburdening your staff.
Note that while CIRCIA pertains exclusively to critical infrastructure incident reporting requirements, NIS2 is much broader in scope. This article focuses only on the incident reporting requirements of each regulation. Also, because NIS2 devote considerable attention to supply chain threats, its geographic reach extends well beyond Europe.
U.S.: CIRCIA Incident Reporting Requirements
In the U.S., CIRCIA will require covered entities across 16 critical infrastructure sectors to report substantial cyber incidents to the Cybersecurity and Infrastructure Security Agency (CISA) within 72 hours and ransomware attacks within 24 hours. More than 300,000 covered entitles are expected to comply, giving CISA and its partners timely incident reports at sufficient scale to identify patterns and provide early warnings to other entities who may be under attack.
CIRCIA Status: Effective in 2026
The statute was passed by Congress in 2022 in the wake of SolarWinds and Executive Order 14208, when there was consensus that it was time to move from voluntary to mandatory incident reporting for critical infrastructure owners and operators. The CIRCIA notice of proposed rulemaking was published in April 2024, followed by a lively comment period that closed in July. The law requires CISA to issue a final rule by October 2025, and it is expected to become effective in 2026. In anticipation, at the end of August the agency rolled out the CISA Services Portal to streamline reporting not just for CIRCIA but for any organization experiencing a cyberattack or incident.
CIRCIA Required Information: Specific and Copious
The deluge of the comments in response to the proposed rule pertained largely to the specificity and number of details expected in the incident reports. Because CISA intends to use the information for widescale threat detection and deterrence, the information is akin to what a private security operations center (SOC) or managed security services provider (MSSP) produces for an investigation. Required details include:
- Vulnerabilities exploited, and in what specific products and versions
- Assets and networks compromised, and indicators of compromise (IOCs)
- Impact on operations
- Effectiveness of response efforts, including security protocols in place and law enforcement responders involved
- Identifying information about the attacker
Additional information required for ransomware reports includes:
- Payment demand, amount and type of assets used to pay
- Recipient identity
- Virtual currency address
- Transaction identifier
- Payment outcome
CIRCIA Definition of Reportable Incident: Room for Interpretation
CIRCIA refers to reportable incidents as “substantial cyber incidents,” defined in terms of their impact. A CISA fact sheet devoted to the definition uses slightly different language than the proposed rule and opens with a disclaimer that the information provided is unofficial pending the final rule.
Per the fact sheet, a substantial cyber incident is one that leads to one or more of these impacts:
- Substantial loss of confidentiality, integrity or availability of a covered entity’s information system or network.
- Serious impact on the safety and resiliency of a covered entity’s operational systems and processes.
- Disruption of a covered entity’s ability to engage in business or industrial operations or deliver goods or services.
- Unauthorized access to a covered entity’s information system or network caused by a compromise of a cloud service provider, managed service provider or other third-party data hosting provider or supply chain compromise.
At first glance these definitions sound prescriptive. Except for “unauthorized access,” however, they all leave room for interpretation by the covered entity.
European Union: NIS2 Incident Reporting Requirements
NIS2 mandates that essential and important entities across 11 critical sectors report significant incidents to their national competent authorities without “undue delay.” In keeping with the directive’s intent to strengthen cyber resilience and present a unified defense in the face of global tensions, the reporting requirement is designed to enable early threat detection and faster cross-border response.
NIS2 Status: Effective in Late 2025 or 2026
The European Union Agency for Cybersecurity (ENISA) published NIS2 (EU 2022/2255) in January 2023. Member states must transpose the directive into national law and adopt implementation measures by October 17, 2024. It may then take most of 2025 for authorities to categorize covered entities as essential or important and notify them. In other words, state-specific enforcement of laws derived from NIS2 is also likely to occur in 2026. Much more will be known soon, as member states begin to publish more detailed implementation measures.
NIS2 Required Information: Phased Based on Discovery
The information that must be provided in NIS2 cyber incident reports is staggered into three (and possibly four) phases, allowing for additional information to be reported based on for further investigation.
Essential and important entities must report to the member state’s Computer Security Incident Response Team (CSIRT) any incident that has a significant impact on the provision of their services, according to this procedure:
- Early warning (within 24 hours): Report whether the event was likely the result of unlawful or malicious activity or could have cross-border ramifications.
- Incident notification (within 72 hours): Update previous information and provide a preliminary evaluation of the incident's severity and effects.
- Intermediate report (as requested): Provide upon request by the CSIRT any relevant status updates on incident and crisis management.
- Final report (1 month): Submit a final report with a thorough description of the incident, including its root cause, any adopted mitigation strategies and any cross-border effects.
NIS2 Definition of Reportable Cyber Incident: Prescriptive
The NIS2 definition of a reportable cyber incident replaces what was deemed too loose a definition in the original NIS Directive. However, its details weren’t known until July 2024 when the EU published a much-anticipated "draft Implementing Regulation” that outlines required cybersecurity risk-management measures and defines what incidents should be considered significant. For both essential and important entities, a significant incident is one that:
- Causes or can cause financial loss where it exceeds EUR 100,000 or 5% of the relevant entity’s annual turnover, whichever is lower
- Causes “considerable reputational damage,” taking into account factors such as whether the incident has been reported in the media and whether the entity is likely to lose a material volume of customers
- Leads to the exfiltration of trade secrets
- Leads to or can lead to the death of an individual or damage to their health
- Involves successful, suspected malicious and unauthorized access to network and information systems.
- Is significant if considered collectively with other incidents that occurred at least twice within six months and have the same apparent root cause
Additional definitions apply to incidents that lead to the complete unavailability of a cloud computing service, content delivery network, DNS service or data center service, as well as interruption of agreed service levels for cloud computing services, managed services or managed security services. These definitions have varying service and affected user thresholds.
Common Incident Reporting Concerns
In reviewing the incident reporting requirements of these two far-reaching regulations, it’s understandable why critical infrastructure entities are less than enthusiastic about looming enforcement dates. That’s not unique to CIRCIA and NIS2. When it comes to reporting mandates in general, two common concerns tend to bubble up.
Resource Strain/Impracticality
Strict reporting timelines and detailed requirements can strain resources — that is, assuming you have the resources to detect cyber incidents in the first place.
For smaller organizations, incident reporting requirements assume that monitoring and investigative tools are in place when they likely are not. Certainly that’s the desired state, and with the right incentives it may become reality. But if you don’t have an in-house SOC or contracted MSSP, meeting the reporting requirements — especially filing three and possibly four reports for each significant incident — is indeed a burden. Even for larger, more sophisticated entities, unless you have an array of sensors strategically placed and tight enforcement of rigorous policies, detecting a cyber incident is the first hurdle; determining its impact is the bigger one.
Compliance Burden/Duplication
Companies operating in multiple jurisdictions face significant hurdles to comply with diverse reporting requirements. NIS2 is a notable exception; as an EU initiative, it should not only consolidate the reporting burden but make the collected information widely actionable.
In the U.S., both the public and private sectors are subject to duplicate, unaligned cyber reporting mandates. The Department of Homeland Security (DHS) is keenly aware of the problem. A year ago, it released a report on “Harmonization of Cyber Incident Reporting to the Federal Government” that documents 45 different cyber incident reporting requirements across the federal government alone. Among the recommendations? Adopt a standard definition of a “reportable cyber incident” and a common form that agencies can use to comply with the different rules.
Cyber Incident Reporting Recommendations
Whether you’re facing compliance with CIRCIA, NIS2 or both, the time to prepare is now.
Define Your Reportable Incidents
With CIRCIA, start by defining what is a reportable incident based on your business. What do you consider to be a “substantial” loss of confidentiality, integrity or availability? What would have a “serious” impact on safety and resiliency? What type or amount of “disruption” would impact your ability to operate? Hopefully you have already defined these parameters as part of a business impact analysis. If not, this is the perfect excuse to do so.
Start to Practice
Using your definitions of what is reportable, begin reporting internally on the incidents that meet the threshold, supplying all the information required by CIRCIA. Then start tracking how long it takes to provide all required information, over how many intervals. Is some information unavailable? Is it available but takes too long to uncover? Document the challenges you encounter now and figure out how to overcome them.
Analyze Your Practice Run
Use the coming year to quantify how many reportable incidents you detect in a quarter, six months, year. Estimate the amount of time it takes you to document those incidents according to the CIRCIA requirements and determine if you have sufficient resources, assuming the same trend continues.
Apply Lessons Learned
Now comes some important decisions. If the incident reporting mandate is going to be burdensome, revisit how you have defined the impact. Were any of the incidents less impactful than originally supposed? The point is not to skimp on reporting information that could prevent another critical infrastructure attack but rather to be pragmatic with your resources. If you’ve already been conservative in your definition, review where your investigations repeatedly hit snags and see if you can address them.
Follow Similar Steps for NIS2
While covered entities have less room to interpret what’s reportable under NIS2, you can still benefit from refining your processes ahead of the effective date. Start reporting internally on all significant incidents as defined in the draft Implementing Regulation (or your member state’s implementation measures, when published). Create an early warning, incident notification and intermediate report template and complete them at the required intervals (24 hours, 72 hours, one month). Are there any common snags at any of these intervals? Is the process too onerous? How can you streamline it?
Final Thoughts
Cyber incident reporting, especially when mandated, can seem like more tedious documentation without any benefit. In critical infrastructure, that’s just not so. These mandates come at a time when the world is getting more digital and more dangerous, and critical infrastructure is a favorite playground for nation-state actors.
Sharing granular details about significant incidents to prevent similar attacks from succeeding across targeted sectors is essential, the timelier the better. As a bonus, you’re likely to be spared an attack at some point, thanks to details reported by other covered entities that can be shared and acted upon quickly.
