An incident reporting obligation is a legal duty that requires an organization to notify a designated authority when it suffers a cybersecurity incident that meets defined criteria of severity, and to do so within fixed deadlines and in a prescribed format. In cybersecurity law, such obligations appear in NIS2, DORA, the Cyber Resilience Act and the GDPR in the European Union, and in rules such as the SEC disclosure rule and CIRCIA in the United States.
The purpose is not to punish victims but to give authorities early situational awareness, allow them to warn others and coordinate a response, and build reliable data on threats. Missing a deadline, however, is a separate violation that can lead to fines even when the incident itself was handled well.
How a typical reporting obligation is structured
Modern EU regimes use a staged reporting model. Instead of one complete report, the organization sends a short early warning, then a fuller notification and finally a detailed report once the facts are known. This design accepts that information is incomplete in the first hours while still giving authorities a prompt signal.
Every obligation answers the same four questions: which entities are covered, which events must be reported, to whom, and by when. The answers differ between laws, so an organization in a regulated sector often faces several overlapping regimes for a single event.
| Stage | Deadline | Content |
|---|---|---|
| Early warning | Within 24 hours of becoming aware | Suspected malicious cause, possible cross-border impact |
| Incident notification | Within 72 hours of becoming aware | Initial assessment, severity, impact, indicators of compromise |
| Intermediate report | On request of the CSIRT or authority | Relevant status updates |
| Final report | Within one month of the notification | Root cause, mitigation, cross-border impact |
| Progress report | If the incident is still ongoing at one month | Status, with final report one month after handling ends |
Main reporting regimes compared
The major regimes differ in trigger, deadline and recipient. The table compares the most important ones for organizations operating in Europe and the United States.
| Regime | What must be reported | First deadline | Recipient |
|---|---|---|---|
| NIS2 | Significant incidents at essential and important entities | 24 hours | National CSIRT or competent authority |
| DORA | Major ICT-related incidents at financial entities | 4 hours after classification, at most 24 hours after detection | Financial supervisor |
| Cyber Resilience Act | Actively exploited vulnerabilities and severe incidents in products | 24 hours | CSIRT and ENISA single reporting platform |
| GDPR | Personal data breaches likely to pose a risk | 72 hours | Data protection authority |
| SEC rule | Material cybersecurity incidents at listed companies | Four business days after materiality determination | Public disclosure in Form 8-K |
| CIRCIA | Covered incidents and ransom payments at critical infrastructure | 72 hours, 24 hours for ransom payments | CISA, once the final rule applies |
The EU legislator has recognized the burden of parallel reporting. DORA takes precedence over NIS2 for financial entities, and the single reporting platform for the Cyber Resilience Act is intended to reduce duplicate submissions, but most organizations still need a mapping of all regimes that apply to them.
Deciding whether an incident is reportable
The hardest part is often the classification decision. Under NIS2, an incident is significant if it has caused or can cause severe operational disruption or financial loss, or if it affects others by causing considerable material or non-material damage. Implementing acts set more precise thresholds for digital infrastructure and digital service providers.
DORA uses quantified criteria: clients affected, data losses, critical services affected, duration, geographic spread and economic impact. A financial entity classifies each incident against these criteria, and meeting the thresholds makes it major and reportable.
| Factor | Question to answer | Typical evidence |
|---|---|---|
| Service impact | Were critical services disrupted, and for how long? | Monitoring data and outage logs |
| Affected users | How many clients or recipients were affected? | Customer and transaction records |
| Data impact | Was data lost, altered or exfiltrated? | Forensic analysis |
| Financial loss | What are the direct and indirect costs? | Finance and recovery estimates |
| Cross-border effect | Are other member states affected? | Locations of users and infrastructure |
The clock usually starts at awareness, not at the end of an investigation. Regulators expect organizations to report on the basis of reasonable suspicion and to correct the details later, rather than waiting for certainty.
Building a reporting process that meets deadlines
Meeting a 24-hour or 4-hour deadline requires preparation before any incident occurs. Organizations that improvise typically lose the first day deciding who is responsible.
- Map every applicable regime with its triggers, deadlines, recipients and templates.
- Define decision authority for classification and submission, including deputies for nights and weekends.
- Prepare templates and portal access so that the early warning can be sent within minutes.
- Integrate legal and data protection teams into the incident response plan from the first hour.
- Run exercises that test the reporting path, not only the technical containment.
- Keep a decision log that records why an event was or was not reported.
Consequences and common mistakes
Failure to report can be sanctioned under the general fine regime of each law. Under NIS2, essential entities face fines of up to 10 million euros or 2 percent of worldwide turnover, and management bodies can be held personally responsible for compliance failures.
- Waiting for full facts before the first report, which misses the early warning deadline.
- Reporting to only one authority when NIS2, the GDPR and sector rules all apply.
- Underestimating supplier incidents, which can be reportable when they disrupt the entity’s own services.
- Inconsistent statements between regulatory reports and public communication.
In plain words
Many companies and public bodies must tell the authorities quickly when they are hit by a serious cyberattack or a major IT failure. The law sets a clock that often starts ticking as soon as they notice the problem.
First comes a short alert, often within a day. Then a fuller update follows, and finally a complete report. The goal is to help everyone react faster, for example by warning other organizations about the same attack.
A real-world example
A regional hospital, classified as an essential entity under NIS2, detects ransomware on a Saturday at 06:00. Its imaging systems are encrypted and some patient data may have been copied. The on-call security lead classifies the event as significant at 09:00 and, using a prepared template, sends an early warning to the national CSIRT at 14:00, well inside 24 hours.
Because personal health data may be affected, the data protection officer notifies the data protection authority within 72 hours under the GDPR. The hospital submits the NIS2 incident notification on Monday with initial indicators of compromise, which the CSIRT shares with other hospitals. One month later, the final report identifies a compromised remote-access account as the entry point. The hospital meets every deadline, and the authority closes its review without penalties.