DDoS attacks under NIS 2
Detection signals, mitigation layers, and the reporting decision under Article 23 NIS 2 and Article 11(6) CIR 2024/2690.
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.
Article 11(6) of Commission Implementing Regulation (EU) 2024/2690 (the CIR) names denial-of-service explicitly as one of the categories that, for digital infrastructure and ICT service providers, counts as a significant incident. 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)
A denial-of-service attack or a distributed denial-of-service attack is considered to be a significant incident for entities providing digital infrastructure services and entities providing ICT service management, where the attack causes a complete unavailability of the service or a significant degradation of the service.
Article 11(6) of Commission Implementing Regulation (EU) 2024/2690. 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, a DoS or DDoS with complete unavailability or significant degradation is, by name, 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, Article 11(6) CIR, 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. The CIR §11(6) test for digital infrastructure entities is even more direct: complete unavailability or significant degradation.
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 under Article 18 NIS 2. 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 Article 11(6) CIR is 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.
The incident module in nisd2.eu carries the Article 23(4) cascade as a structured workflow: early warning at 24h, incident notification at 72h, intermediate report on request, final report at one month, progress variant if the incident is still ongoing. The platform timestamps each step against the moment of awareness rather than the moment of attack, which is what the directive measures.
Asset references on the incident link the affected service to the entries in the asset inventory built under RSK 2.2, so the post-incident review can trace which assets, suppliers, and processes were involved without rebuilding context from scratch.
- 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, Article 11(6) (denial-of-service named as significant incident for digital infrastructure and ICT service providers). 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