DDoS attacks under NIS 2
Detection signals, mitigation layers, and the reporting decision under Article 23 NIS 2 and the CIR 2024/2690 thresholds.
Why DDoS sits squarely inside Article 23
A distributed denial-of-service attack saturates a target with traffic from many sources so that legitimate users can no longer reach the service. Under NIS 2 the technical category is less interesting than the effect. Once a DDoS measurably degrades or interrupts a service the entity provides, Article 23 NIS 2 turns it into a reportable event with a fixed cascade.
Commission Implementing Regulation (EU) 2024/2690 (the CIR) does not name denial-of-service as a category. For the digital providers it covers, Articles 5 to 14 set availability thresholds per service type (for cloud: completely unavailable for more than 30 minutes, Article 7). For other essential and important entities the general significance test in Article 23(3) NIS 2 applies. Service availability impact is the dominant trigger in both cases.
An entity that operates a website, an API, an online portal, a payment gateway, a DNS resolver, or any other internet-exposed service typically reaches the reporting threshold faster than it can scale defences. The legal cascade therefore starts running in parallel with mitigation, not after it.
EU directive (binding across the Union)
Member States shall ensure that essential and important entities submit to the CSIRT or, where applicable, the competent authority: (a) without undue delay and in any event within 24 hours of becoming aware of the significant incident, an early warning; (b) without undue delay and in any event within 72 hours of becoming aware of the significant incident, an incident notification; (c) an intermediate report on relevant status updates, upon the request of a CSIRT or, where applicable, the competent authority; (d) a final report not later than one month after the submission of the incident notification under point (b); (e) in the event of an ongoing incident at the time of the submission of the final report referred to in point (d), Member States shall ensure that entities concerned provide a progress report at that time and a final report within one month of their handling of the incident.
Article 23(4) NIS 2. Reporting clock starts at the moment the entity becomes aware of the significant incident, not when mitigation begins or ends. A DDoS that is still ongoing at the one-month mark triggers the progress-report variant in point (e).
EU implementing regulation (binding technical detail)
With regard to cloud computing service providers, an incident shall be considered significant under Article 3(1)(g) where it fulfils one or more of the following criteria: (a) a cloud computing service provided is completely unavailable for more than 30 minutes; (b) the availability of a cloud computing service of a provider is limited for more than 5 % of the cloud computing service’s users in the Union, or for more than 1 million of the cloud computing service’s users in the Union, whichever number is smaller, for a duration of more than one hour; […]
Article 7 of Commission Implementing Regulation (EU) 2024/2690, as an example. The CIR applies directly to DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, providers of online marketplaces, online search engines and social networking services. For these entity types, Articles 5 to 14 set the availability thresholds; a DoS or DDoS that crosses one is significant.
National example (Germany)
Wesentliche und wichtige Einrichtungen melden dem Bundesamt erhebliche Sicherheitsvorfälle. Die Meldung erfolgt unverzüglich, spätestens jedoch innerhalb von 24 Stunden nach Kenntnisnahme als Frühwarnung, innerhalb von 72 Stunden als Meldung mit erster Bewertung und innerhalb eines Monats als Abschlussbericht.
§ 32 BSIG (NIS2UmsuCG). The German transposition mirrors the Article 23(4) cascade verbatim. Reports go to the BSI via the Meldeportal. Other Member States use their own national CSIRT or competent authority routing. The substance is identical.
Detection signals at the SOC level
Typical indicators picked up by network monitoring or a SOC include a sudden spike in inbound traffic volume, a drop in successful request ratios, abnormal connection counts on edge devices, a surge of identical user agents or query patterns, increased latency or packet loss on perimeter links, and saturation alerts from upstream providers. Combined with a measurable service availability drop, these indicators turn an event into an incident in the sense of Article 6(6) NIS 2.
Mitigation layers in common use
Common mitigation patterns include upstream traffic filtering at the internet service provider, scrubbing through a third-party DDoS protection service, rate limiting and connection throttling at the edge, anycast and geographic distribution, blackholing or null-routing of attack sources at the carrier level, and application-layer protections such as bot management. Layered defence is described here, not recommended; the proportionate combination depends on the entity's risk assessment under Article 21 NIS 2.
Reporting decision under Article 23
Once service availability is impacted in a way that meets Article 23(3) NIS 2 or, for digital infrastructure entities, the CIR thresholds (Articles 5 to 14), the cascade begins: early warning within 24 hours, incident notification within 72 hours, intermediate report on request, final report within one month, progress report if the incident is still ongoing at the one-month mark.
Service impact, not attack volume, is the trigger
Article 23(3) NIS 2 defines significance through effect on the service: severe operational disruption, financial loss, or material non-material damage to other natural or legal persons. A 500 Gbps attack that is fully absorbed is not, by itself, a significant incident. A 5 Gbps attack that takes a portal offline for an hour usually is. For the digital providers covered by the CIR, the thresholds are even more direct, for example a cloud service completely unavailable for more than 30 minutes (Article 7 CIR).
DDoS often masks a second-stage event
Volumetric attacks are sometimes used as cover for credential stuffing, data exfiltration, or ransomware deployment. The post-incident review required by Article 23(4)(d) NIS 2 in the final report typically distinguishes between the visible availability event and any secondary access or integrity event detected during or after the flood.
BSI as national CSIRT and reporting endpoint
In Germany the BSI receives Article 23 reports via the Meldeportal under § 32 BSIG. The BSI also publishes incident handling guidance such as the BSI-Standard 200-4 (BCM) and operational technical notes; these are guidance, not additional reporting obligations. Other Member States have parallel structures (NCSC-NL, ANSSI, NCSC-IE, and so on).
ISP cooperation and upstream filtering
Internet service providers can absorb or filter attack traffic before it reaches the customer edge. In Germany, electronic communications providers operate under the TKG and cooperate with BSI on threat response; BSI TR-03103 covers technical interfaces for some categories. The point for the reporting entity is that ISP mitigation does not remove the Article 23 reporting obligation if the service was already impacted.
ENISA technical guidance and threat landscape
ENISA publishes the annual Threat Landscape report and incident response guidance. The Threat Landscape 2024 confirms DDoS as one of the top observed threat categories across EU sectors. ENISA documents are reference material; they do not change the Article 23 cascade.
The ISP handles it, so nothing needs to be reported
ISP-side filtering reduces impact but does not change the legal trigger. If the service was unavailable or significantly degraded between attack onset and ISP mitigation, Article 23(3) NIS 2 or the CIR thresholds (Articles 5 to 14) are engaged. The reporting cascade runs in parallel with carrier-level response.
Treating only the symptom is enough
Rate limiting and scrubbing stop the flood but rarely identify whether the DDoS was a diversion. A post-incident review that does not check authentication logs, outbound traffic anomalies, and configuration changes during the attack window leaves the secondary event undetected. The final report under Article 23(4)(d) is the documented checkpoint for this.
Once traffic normalises, the incident is closed
Article 23(4)(d) NIS 2 requires a final report within one month of the incident notification. That report covers root cause, mitigation taken, and lessons learned. An entity that closes the ticket the moment traffic drops typically has nothing to submit, which is itself a documented non-compliance.
Two operational habits separate entities that handle DDoS cleanly from those that scramble. First, the reporting clock and the mitigation clock are tracked separately. Mitigation can take hours; the 24-hour early warning has its own owner and template ready before the event. Second, the post-incident review is scheduled at the moment of detection, not at the end of the flood. A calendar slot 25 days after detection forces the final report to be written, even on a quiet incident.
DNS and edge configuration matter more than attack-time decisions. Anycast routing, separate authoritative DNS providers, a tested upstream filtering arrangement with the ISP, and a documented contact path to the carrier NOC are typically in place long before the first packet of an attack arrives. The same applies to the report templates: the early warning and notification fields required under § 32 BSIG and the equivalent national portals are static enough to pre-fill.
- Directive (EU) 2022/2555 (NIS 2), Article 6(6) (definition of incident), Article 21 (risk management measures), Article 23 (reporting). EUR-Lex: eur-lex.europa.eu/eli/dir/2022/2555/oj
- Commission Implementing Regulation (EU) 2024/2690, Articles 3 and 5 to 14 (significance thresholds for the digital providers it covers). EUR-Lex: eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- BSIG (NIS2UmsuCG), § 32 (reporting obligations to the BSI). gesetze-im-internet.de
- BSI Meldeportal and operational guidance on incident reporting. bsi.bund.de
- ENISA Threat Landscape 2024, DDoS chapter. enisa.europa.eu
- BSI-Standard 200-4 (Business Continuity Management). bsi.bund.de
- BSI TR-03103 (technical guideline series). bsi.bund.de
In practice
Where this comes up in the walkthrough
The walkthrough turns this into steps you fill in, with the law explained beside each one. Open a step to see its screen, filled in for a made-up company.
Incident Handling
Know how to report an incident
Three reports to your authority, with fixed deadlines.
Been asked to handle NIS2?
In the end you have everything in one document: what is done, what is still open, and your management's approval with name and date. The app writes the texts.
