NIS2 incident reporting for ISPs:
what the 24-hour clock actually requires

Back to Blog

NIS2 Article 23: The Reporting Timeline

NIS2 (Directive (EU) 2022/2555) establishes mandatory incident reporting obligations for essential and important entities. ISPs, hosting providers, DNS service operators, and TLD registries all fall under the "essential entities" category, which carries the strictest requirements.

Article 23 defines a three-stage reporting timeline for "significant incidents":

Stage 1: Early warning (24 hours)

Within 24 hours of becoming aware of a significant incident, you must submit an early warning to your national CSIRT or competent authority. The early warning must include:

• Whether the incident is suspected to be caused by unlawful or malicious acts
• Whether the incident could have a cross-border impact

This is a triage report. It does not require a complete analysis. The purpose is to alert the authorities early enough that they can coordinate a response if the incident affects other entities or member states.

Stage 2: Incident notification (72 hours)

Within 72 hours of becoming aware of the incident, you must submit a more detailed notification that includes:

• An assessment of the incident, including its severity and impact
• Indicators of compromise (where applicable)
• Initial assessment of the nature of the incident

Stage 3: Final report (1 month)

Within one month of the incident notification (Stage 2), you must submit a final report that includes:

• A detailed description of the incident, including its severity and impact
• The type of threat or root cause that is likely to have triggered the incident
• Applied and ongoing mitigation measures
• The cross-border impact of the incident, where applicable

What ISPs and Hosting Providers Specifically Need to File

The NIS2 text is deliberately broad, and national implementations vary across EU member states. However, based on the directive's text and the emerging consensus among national CSIRTs, here is what ISPs and hosting providers should expect to provide:

For DDoS incidents specifically

DDoS attacks are one of the most common reportable incidents for ISPs. The reporting requirements map to specific data points:

Early Warning (24h):
  - Date and time of detection
  - Nature of incident: DDoS attack
  - Suspected malicious: Yes (DDoS is inherently malicious)
  - Cross-border potential: [Yes/No based on traffic sources]
  - Initial impact assessment: [Number of affected subscribers/services]

Incident Notification (72h):
  - Attack classification (UDP flood, amplification, L7, etc.)
  - Peak volume (Gbps, PPS)
  - Duration
  - Target (IP ranges, services, subscriber segments)
  - Number of affected users/subscribers
  - Service impact (degradation vs. complete outage)
  - Indicators of compromise (source IPs, attack signatures)
  - Initial mitigation actions taken

Final Report (1 month):
  - Complete incident timeline
  - Root cause analysis
  - Full list of mitigation actions with timestamps
  - Effectiveness assessment of each mitigation step
  - Subscriber/service impact quantification
  - Lessons learned and planned improvements
  - Cross-border analysis (attack origin, affected entities)

What Flowtriq Captures Automatically

The challenge with incident reporting is not knowing what to report. It is having the data available to report accurately and on time. When you reconstruct incidents from log files and engineer memories three days after the fact, the reports are incomplete and inaccurate.

Flowtriq's detection engine captures and timestamps every data point you need for NIS2 reporting as the incident unfolds:

Detection timestamp

The exact second the anomaly was first detected. This is your "became aware" timestamp, which starts the 24-hour clock. Because detection is automated, this timestamp is precise and auditable. There is no ambiguity about when you became aware, because awareness is defined by the detection event, not by when a human read a log file.

Attack classification

The detection engine classifies the attack by type (UDP flood, SYN flood, DNS amplification, NTP amplification, HTTP flood, etc.), confidence level, and attack vector. This maps directly to the "nature of incident" field in your reporting.

Volume metrics

Per-second bandwidth (BPS) and packet rate (PPS) measurements throughout the attack duration. Peak volume, average volume, and total volume are all calculated automatically. These are the numbers your CSIRT will want in the incident notification.

Mitigation actions

Every runbook action is logged with a timestamp, action type, parameters, and result. When your report says "FlowSpec rule applied at 14:22:05 UTC targeting UDP port 53 traffic to 203.0.113.0/24, reducing attack traffic from 12.4 Gbps to 0," that is not a reconstruction. That is a direct export from the execution log.

Impact data

The detection engine tracks which IPs, subnets, and services were affected during the incident. For ISPs with subscriber databases, this maps to specific subscriber counts, which is exactly what the "affected users" field requires.

PCAP evidence

Packet captures taken during the incident provide forensic evidence of the attack vector. These are timestamped and stored as incident attachments, available for export to your CSIRT if they request technical evidence.

Flowtriq covers the incident detection, handling, monitoring, and documentation aspects of NIS2 compliance. It does not cover the full directive, which also includes supply chain security, human resources practices, cryptographic policy, access control, and other controls that fall outside the scope of DDoS detection. We are upfront about this: Flowtriq is a required piece of your NIS2 compliance posture, not the whole thing.

Using the Free NIS2 Reporting Tool

We provide a free NIS2 incident reporting tool that generates pre-formatted reports from your Flowtriq incident data. The tool pulls the detection timestamp, classification, volume metrics, mitigation actions, and impact data from the incident record and formats them into the three reporting stages.

For the early warning (Stage 1), the tool can generate a draft report within minutes of detection. You review it, confirm the cross-border assessment, and submit it to your national CSIRT. For the incident notification (Stage 2) and final report (Stage 3), the tool aggregates all incident data and generates a structured report that you can submit as-is or customize with additional context.

Incident report export:
  Format: PDF, JSON, or CSV
  Sections:
    1. Incident summary (auto-populated)
    2. Timeline (auto-populated from detection logs)
    3. Technical details (auto-populated from classification engine)
    4. Mitigation actions (auto-populated from runbook execution logs)
    5. Impact assessment (auto-populated from affected IP/subscriber data)
    6. Cross-border analysis (manual input required)
    7. Lessons learned (manual input required)

Sections 1 through 5 are fully automated. Sections 6 and 7 require human input because they involve judgment calls that cannot be automated: whether the attack had cross-border implications, and what you plan to do differently next time.

Registration Requirements: Where Most Fines Actually Are

The NIS2 provisions that receive the most attention are the incident reporting and security measures requirements. But the provision that is most likely to result in early fines is simpler: registration.

Article 3(3) requires essential and important entities to register with their national competent authority. Many member states have set registration deadlines, and entities that fail to register face administrative fines regardless of their actual security posture. You can have perfect incident handling, comprehensive security measures, and a flawless track record, and still receive a fine for not registering on time.

If you are an ISP or hosting provider operating in the EU and you have not registered with your national competent authority, this should be your first priority. The registration process varies by member state, but it typically involves providing your entity name, contact details, IP ranges, services offered, and the member states in which you operate.

Personal Liability for Management Bodies

One of the most significant changes in NIS2 compared to the original NIS Directive is Article 20, which establishes personal accountability for management bodies. Members of management bodies (board members, C-suite executives, managing directors) can be held personally liable for failures to comply with the cybersecurity risk-management measures in Article 21.

This means that if your ISP experiences a DDoS attack that qualifies as a significant incident and you cannot demonstrate that you had appropriate detection, incident handling, and business continuity measures in place, the management body, not just the company, faces potential sanctions.

The practical implication: management bodies need to be able to demonstrate that they approved and oversaw the implementation of cybersecurity risk-management measures. Having documented, automated DDoS detection and incident handling is a tangible, auditable measure that directly addresses multiple Article 21 requirements (incident handling, business continuity, and effectiveness assessment).

This is not about buying a product to check a compliance box. It is about having evidence that your organization takes cybersecurity obligations seriously and has implemented concrete measures to detect and respond to the most common threat to availability in your industry.

Getting Started

NIS2 compliance is a broad obligation that spans technical measures, organizational processes, governance structures, and reporting procedures. Flowtriq addresses the DDoS detection, incident handling, and monitoring components of that obligation. It is a necessary component, not a complete solution.

If you are an ISP or hosting provider subject to NIS2, start with the fundamentals: register with your national authority (if you have not already), implement automated DDoS detection so your 24-hour clock starts at seconds instead of hours, and ensure your incident data is structured for automated report generation.

Flowtriq starts at $9.99/node/month. The NIS2 reporting tool is free for all customers. Start your free 7-day trial or review pricing for your deployment.

Back to Blog

Related Articles