A ransomware hits at night. Customers cannot access the service. At 8 AM, the question arrives: "Do we have to notify the authority?" If you work for a company in scope of NIS2, the answer is not "yes" but "how much time has already passed?" The directive does not only look at the damage you suffered. It looks at how quickly you reported it. And the deadlines are not recommendations. They are legal obligations that can hit the people who sign the balance sheet.
We at Meteora Web come from accounting: missing a deadline is a cost, not an excuse. We have spent years handling technical emergencies on the field. NIS2 incident reporting is not a bureaucratic form. It is an operational process that must be built before the emergency happens. This guide walks you through the real deadlines, the three-step notification flow, and what you need to prepare today.
NIS2 incident reporting — why the deadlines actually matter
Before NIS2, incident notification was a good intention. Some sectors did it, others did not, and authorities had few ways to react. NIS2 changes the picture: deadlines are peremptory, company executives become personally liable in certain cases, and incident reporting becomes an indicator of your security posture.
It is not hard to see why the EU focused on this. If an attacker breaks into a digital service provider and nobody reports it, the attack can spread to other companies without warning. The notification protects the whole ecosystem, not just one company. Timelines and reporting processes are the mechanism that lets authorities coordinate response and alert other parties at risk.
From a practical standpoint, the clock starts at a specific moment: when the company becomes aware of the incident, not when the incident occurred. This changes everything. If you discover an unauthorized access three days later, the clock has already been running for three days. And no authority accepts "we did not notice" as a valid excuse.
The penalties for failing to notify are serious: fines up to EUR 10 million or 2% of worldwide turnover, and for company executives, temporary bans from management positions. These are not symbolic numbers. If you need the full picture of compliance, start with our NIS2 and EU cybersecurity regulations pillar guide. Here we go into specifics: what to send, when, and how to organize.
Sponsored Protocol
The first mistake to avoid is waiting until you have all the details before notifying. Authorities know that early moments are confusing. That is why NIS2 provides a lightning alert, then a full notification, then a final report. But if you miss the first deadline, the others become almost irrelevant.
NIS2 incident reporting — what are the real deadlines?
Directive (EU) 2022/2555 defines three mandatory moments. We call them early warning, notification, and final report. Here are the exact timelines.
First notification — early warning within 24 hours. As soon as the company becomes aware of a significant incident, it must send an initial alert. This communication is short: it says "we are under attack, we are investigating". No technical details, no root cause, no exact impact. Just the fact that the incident exists.
Second notification — notification within 72 hours. Here you go deeper. Within three days of becoming aware of the incident, the company must update the authority with an assessment: severity, impact, indicators of compromise if available, and measures already taken. This notification is the core of the NIS2 incident reporting process.
Third notification — final report within one month. The final report closes the loop: full description of the incident, root cause, actual impact, mitigation measures implemented, and lessons learned. Authorities use it to understand whether the company understood what happened and can prevent a recurrence.
There are cases where timelines differ: DNS providers, online marketplaces, and search engines face stricter deadlines under NIS2. And if the incident involves personal data, the GDPR adds a separate obligation to notify the data protection authority within 72 hours. These are two separate channels with different logic.
Sponsored Protocol
A crucial point is the starting moment. The regulation speaks of "without undue delay and in any event within 24 hours" of becoming aware. You cannot wait for formal confirmation before sending the early warning. Even a well-founded suspicion must be communicated. Authorities prefer an imprecise but timely report over a perfect but late one.
How to calculate deadlines without errors
The 24-hour, 72-hour, and 30-day counts start from the detection timestamp, not from the notification time. To avoid mistakes, we built a bash script you can run on your server. Save the file, make it executable, and pass the detection date as an argument.
#!/bin/bash
# Usage: ./deadline_nis2.sh "2026-03-15 10:00:00"
DETECTION=$(date -d "$1" +%s)
EARLY=$(date -d "@$((DETECTION + 86400))" "+%Y-%m-%d %H:%M:%S")
NOTIF=$(date -d "@$((DETECTION + 259200))" "+%Y-%m-%d %H:%M:%S")
FINAL=$(date -d "@$((DETECTION + 2592000))" "+%Y-%m-%d %H:%M:%S")
echo "Early warning (24h): $EARLY"
echo "Notification (72h): $NOTIF"
echo "Final report (30 days): $FINAL"The script uses the GNU date tools available on standard Linux distributions. It is only an operational aid: the responsibility to record the discovery time precisely remains yours.
NIS2 incident reporting — how the three-step process works
Each phase has a minimum content to transmit to the competent authority. In Italy, the national authority is ACN (Agenzia per la Cybersicurezza Nazionale). The official notification portal is the main channel, but having an internal alternative channel to collect data while the emergency is running is essential.
Step 1 — Early warning (within 24h). Minimum content: entity identifier, date and time of discovery, type of incident, known compromise status. Nothing else. The goal is to alert the ecosystem.
Sponsored Protocol
Step 2 — Notification (within 72h). Minimum content: update on the scenario, number of affected users or services, duration of disruption, containment measures activated, and any indicators of compromise. You can also include a first hypothesis about the cause.
Step 3 — Final report (within 30 days). Minimum content: root cause analysis, actual impact, mitigation measures completed or still underway, recommendations, and any digital evidence to preserve. This document is what authorities will use to evaluate your handling of the incident.
To standardize the work, prepare a JSON template like this one. Fill the fields during the emergency with calm but speed.
{
"incident_id": "NIS2-2026-0001",
"entity_name": "Company Name",
"sector": "Digital services",
"incident_date": "2026-03-15T10:00:00Z",
"detection_date": "2026-03-15T10:30:00Z",
"classification": "significant",
"impact": {
"service_disruption": true,
"service_disruption_hours": 8,
"data_breach": true,
"users_affected": 1200
},
"root_cause": "phishing",
"measures_taken": ["credential revocation", "host isolation"],
"contact": "it-security@company.com"
}This template is not an official form. It helps you collect data while the incident is ongoing. The second common mistake is improvising the report structure in the middle of a panic. If you have a ready template, the notification job becomes a matter of filling in the fields.
NIS2 incident reporting — what must be reported and when is an incident serious?
Not every incident must be reported. NIS2 requires notification for significant incidents. But what makes an incident significant? The directive lists criteria: the number of affected users, duration of disruption, geographic scope, and the extent of material or non-material damage. A single infected computer, if isolated immediately, is probably not significant. But if that computer handles the backups for the whole system, it is.
Sponsored Protocol
To avoid wasting time in the first hours, use a triage logic. Answer these three questions:
- Did the incident affect the availability of a service? If so, did the disruption exceed your SLA tolerance limits?
- Did the incident affect the confidentiality of data? If so, how many individuals are involved?
- Did the incident affect the integrity of systems or data? Is there evidence of alteration?
If at least one answer is yes, you are most likely looking at a significant incident and notification is mandatory. If you are not sure, notify anyway. The early warning is designed for this too: better a false alarm than a fine.
The third common mistake is confusing NIS2 notification with a criminal complaint. They are separate channels. NIS2 does not want a judicial investigation: it wants operational information to protect the ecosystem. If your systems contain traces of an attack, preserving that evidence must be done in parallel, but it must not delay communication with the authority.
NIS2 incident reporting — how can you prepare before it happens?
The reporting process should never be improvised. In the middle of a ransomware attack, no team wants to figure out how and where to send the notification. That is why we prepare everything in advance. Here are the essential points.
Designate a notification officer. This person must have the authority to notify the authority even without the owner present. If the decision belongs solely to the CEO, and the CEO is on a plane without connectivity, the 24 hours expire uselessly.
Prepare templates. The templates we showed above should already contain your company data: VAT number, sector, contact person, preferred channel. In an emergency, you will only need to add the incident specifics.
Set up a secure communication channel. The authority will have a portal, but for communications with vendors and consultants, use an encrypted channel. If you use email, enable S/MIME encryption or a PGP-based solution. An incident must not become an opportunity for a second attack through intercepted emails.
Sponsored Protocol
Run drills. Once a year, simulate a fake incident and practice sending test notifications. You will discover that the template was not filled out, a contact is missing, or the portal address has changed. Better to find out in a simulation than during a real attack.
We fix broken SSL certificate renewals on production servers without taking clients offline. The principle is the same: operational preparation makes the difference between a managed problem and a disaster.
To automate deadline calculation and keep it under control, integrate the bash script above into your incident response procedure. If a technician records the discovery time in a log file, the system can automatically calculate the next deadlines and send a reminder to the officer.
What to do now
The NIS2 incident reporting rules are in force. No more waiting. Here are the concrete actions for the next few days:
- Check if you fall within NIS2 scope. Not all sectors are included, but many Italian SMEs are without knowing it. The NIS2 pillar guide helps you run the check.
- Appoint an incident manager. One person, plus a substitute, authorized to send notifications to the authority at any time.
- Download and adapt the notification templates. Fill them now with your company data, so in an emergency you only have to complete the dynamic fields.
- Schedule a drill. Within 60 days, simulate an incident with your team. Involve your technical consultant if you do not have an internal structure.
- Integrate the deadline calculation script into your playbook. Time never stops, and the first deadline is the easiest to meet if everything is ready.
We work every day with companies that need to comply with NIS2. The first step is always the same: admit that an incident can happen. From there, you build an incident reporting procedure that leaves no room for improvisation.
