Twenty-Four Hours to Report: Preparing for Overlapping Incident Clocks
Tomorrow, September 11, 2026, the reporting obligations of the EU Cyber Resilience Act (CRA) begin to apply. Manufacturers of products with digital elements sold in the EU must report actively exploited vulnerabilities and severe incidents affecting the security of their products, with an early warning within 24 hours of becoming aware.
In the United States, CISA has indicated it intends to finalize the rule implementing the Cyber Incident Reporting for Critical Infrastructure Act (CIRCIA). The proposed rule would require covered critical infrastructure entities to report covered cyber incidents within 72 hours and ransom payments within 24 hours. The timing of the final rule remains uncertain.
These requirements join an already crowded field. A single incident at a multinational organization can trigger several notification duties at once, each with its own clock, threshold, recipient and content.
The current landscape
The table below summarizes common incident reporting regimes. It’s a planning aid. Thresholds, definitions and exceptions matter a great deal, and each organization needs its own legal analysis of which regimes apply.
| Regime | Who | Trigger | First deadline | Follow-up |
|---|---|---|---|---|
| EU CRA (from Sept 11, 2026) | Manufacturers of products with digital elements | Actively exploited vulnerability or severe incident affecting product security | Early warning within 24 hours | Notification within 72 hours; final report later (14 days after a corrective measure for vulnerabilities; one month for incidents) |
| EU NIS2 | Essential and important entities in the EU | Significant incident | Early warning within 24 hours | Notification within 72 hours; final report within one month |
| EU DORA | EU financial entities | Major ICT-related incident | Initial notification within hours of classification (within 24 hours of detection at most) | Intermediate and final reports |
| U.S. SEC (Form 8-K Item 1.05) | Public companies | Cybersecurity incident determined to be material | Four business days after the materiality determination | Amendments as information becomes available |
| U.S. CIRCIA (proposed) | Covered critical infrastructure entities | Covered cyber incident; ransom payment | 72 hours (incident); 24 hours (ransom payment) | Supplemental reports |
| New York DFS Part 500 | Regulated financial services entities | Cybersecurity incident meeting the rule’s criteria | 72 hours | Ransom payment notice within 24 hours, with explanation within 30 days |
Sector regulators, state breach notification laws, contractual obligations to customers and partners, and cyber insurance policies add further duties.
Figure 1. Overlapping reporting clocks in the first days of an incident. Exact triggers differ: some clocks start at awareness, some at classification, and the SEC’s at a materiality determination.
Where organizations struggle
Experience with NIS2, DORA and the SEC rules has shown where reporting processes break down. Few of the problems are about writing the report.
Knowing which clocks have started
Each regime defines its trigger differently: awareness, classification as significant or major, determination of materiality. Organizations that haven’t defined who decides each of those things, and how, lose hours establishing whether a clock is running.
Having facts to report in 24 hours
Early warnings require limited information, but they still require some: what happened, whether it’s suspected to be malicious, whether it may have cross-border impact. At 24 hours, many investigations have barely begun. Teams that collect the right facts from the start, rather than reconstructing them later, find early reporting much easier.
Coordinating many recipients
A multinational organization may need to notify several national authorities, a financial regulator, the SEC, customers and an insurer, all with different formats. Without a single coordinating owner, reports go out inconsistent with one another, which creates its own problems.
Product versus enterprise incidents
The CRA is distinctive because it covers the products a manufacturer sells as well as its own systems. A manufacturer must report an actively exploited vulnerability in a product it sells, even if its own network was never touched. That brings product security teams, which often sit in engineering, into regulatory reporting for the first time. Many organizations haven’t connected their product security incident response with their legal and compliance functions.
Building one process for many clocks
The goal is a single incident reporting process that meets every applicable requirement, rather than a separate procedure for each.
1. Map your obligations once
Work with legal counsel to list every regime that applies, with its trigger, threshold, deadline, recipient, required content and follow-up schedule. Include contractual and insurance obligations. Keep this map current, and review it whenever the business enters a new market or sector.
2. Define decision points and owners
For each type of trigger, decide who determines whether it has been met, and how quickly. For example:
- the incident commander confirms awareness of a suspected incident and starts the clock log
- a designated legal lead assesses significance under NIS2 and DORA criteria within a set number of hours
- a defined materiality committee assesses SEC materiality, with a documented process
- the product security lead assesses whether a product vulnerability is actively exploited under the CRA
Write these down, assign deputies, and make sure they’re reachable outside business hours.
3. Collect reportable facts from the first hour
Build a standard incident record that captures, from the start, the facts most reports need: time of detection, systems and products affected, suspected cause, whether data was accessed, jurisdictions involved, customers and services affected, and actions taken. The incident team fills it in as part of normal response, and reports draw from it.
4. Prepare templates and submission paths
For each regime, prepare a template with the required fields and confirm how submission works, including platform accounts, credentials and contacts. Discovering that nobody has access to a reporting portal at hour 20 is avoidable.
For the CRA, reports go through the single reporting platform operated by ENISA, routed to the relevant national CSIRT. Confirm your organization’s registration and access before an incident.
5. Keep one source of truth
Maintain one timeline and one set of facts, owned by the incident lead, from which all reports are drawn. When facts change, every affected report gets updated. Consistency across regulators matters, and inconsistencies are hard to explain later.
6. Exercise against the clock
Tabletop exercises often stop at containment. Run one that continues through reporting: a ransomware incident affecting EU and U.S. operations, with a product vulnerability involved, where the team must produce a 24-hour early warning, a 72-hour notification and a materiality assessment. Time each step. The bottlenecks will be obvious.
For product manufacturers: CRA specifics
Manufacturers within the CRA’s scope should make sure that:
- product security incident response can identify, within hours, whether a vulnerability in a product is being actively exploited
- vulnerability intake channels, such as security contact addresses, bug bounty programs and coordinated disclosure arrangements, route reports quickly to someone who can assess them
- legal and compliance know how to recognize a CRA-reportable event and have access to the reporting platform
- downstream notification to users, required where appropriate, can be issued quickly
The CRA’s broader product obligations, including secure-by-design requirements and vulnerability handling, apply from December 2027. The reporting obligation arriving first means many manufacturers will be reporting under the CRA before the rest of their CRA program is complete.
Keeping the focus on response
Reporting obligations exist to help authorities understand threats and to protect people affected by incidents. A well-designed process supports that goal and doesn’t pull the incident team away from containment and recovery. The best reporting processes are almost invisible during an incident: the right people make the right decisions quickly, the facts are already collected, and reports go out on time while the response team keeps working.
Organizations that invest in this now will find that every new regime adds a row to the obligations map rather than a new process.