NIS2 DDoS Reporting: Your Outage Threshold Is 30 Minutes, 20 Minutes, or Zero

Distributed denial of service is the most common cyber incident in the European Union, and the overwhelming majority of it is not reportable. ENISA analysed 4 875 incidents between 1 July 2024 and 30 June 2025 and found that DDoS attacks "make up about 76.7% of recorded cases", a category it describes as "overwhelmingly driven by hacktivist groups" whose campaigns it characterises by their "minimal impact and low-advanced attacks" [6]. The operational question is therefore never whether you were hit. It is whether this one crossed the line.

That line is not where most guidance puts it. If you are one of eleven categories of digital provider, your threshold is written as a stopwatch reading in Articles 5 to 14 of Commission Implementing Regulation (EU) 2024/2690 [1] — and depending on what you are, it is 30 minutes, 20 minutes, or no elapsed time whatsoever. If you are anything else, the Implementing Regulation does not bind you at all, and you are working from the Article 23(3) test as your Member State transposed it.

First, Check Whether the CIR Thresholds Bind You at All

Almost every guide to this topic quotes CIR 2024/2690 as though it applied across NIS2. It does not. Article 1 names its addressees exhaustively, and everyone outside that list is bound by Article 21(2) and Article 23 of the Directive directly, not by this Regulation.

Are you one of these eleven?	Then your DDoS threshold is…
DNS service providers; TLD name registries; cloud computing providers; data centre providers; content delivery network providers; managed service providers; managed security service providers; online marketplaces; online search engines; social networking platforms; trust service providers	A specific, numeric criterion in CIR Articles 5–14, incorporated into the significance test by Article 3(1)(g) [1]
Everyone else in scope — energy, health, transport, water, banking, public administration, manufacturing, food, chemicals, waste, postal, research	The qualitative two-limb test in Article 23(3) of the Directive, as transposed into your national law [2]

This split matters more for availability incidents than for any other kind. A ransomware case will usually satisfy several criteria at once. A clean DDoS may satisfy exactly one — a duration measurement — and if that measurement does not exist for your category, you are back to arguing about the word "severe".

Your Outage Threshold, Category by Category

Here is what Articles 5 to 14 actually say about availability. Every figure below is quoted from the Official Journal text [1]. The right-hand column is the one to internalise: it is the shortest complete outage that is automatically significant, with no further assessment required.

Entity category	CIR Article	Complete-outage trigger	Degraded-service trigger
DNS service providers	Art. 5	More than 30 minutes	Average response time above 10 seconds for more than 1 hour
TLD name registries	Art. 6	Any duration — the text has no time qualifier	Average response time above 10 seconds for more than 1 hour
Cloud computing providers	Art. 7	More than 30 minutes	Availability limited for over 5% or 1 million Union users, whichever is smaller, for more than 1 hour
Data centre providers	Art. 8	Any duration — no time qualifier	Availability limited for more than 1 hour — no user threshold at all
CDN providers	Art. 9	More than 30 minutes	Over 5% or 1 million Union users, whichever is smaller, for more than 1 hour
MSPs and MSSPs	Art. 10	More than 30 minutes	Over 5% or 1 million Union users, whichever is smaller, for more than 1 hour
Online marketplaces, search engines, social platforms	Arts. 11–13	Any duration, once over 5% or 1 million Union users, whichever is smaller	Same user test, no duration element in either limb
Trust service providers	Art. 14	More than 20 minutes	More than 1 hour cumulative per calendar week; or over 1% or 200 000 users affected

Read across the rows and the practical consequence is stark. A 25-minute total outage caused by a volumetric flood is below threshold for a cloud provider, a CDN and an MSSP. The identical outage, on the identical infrastructure, is automatically significant for a data centre operator, a TLD registry, and a trust service provider. For an online marketplace, duration is not measured at all — a four-minute outage that reaches 5% of Union users is significant on its face.

One counting rule quietly makes the user-based tests much harder to pass than B2B providers expect. Article 3(3) applies the user count "for the purpose of Articles 7 and 9 to 14" and requires entities to include both contracted customers and "the number of natural and legal persons associated with business customers" [1]. A managed service provider with 180 corporate clients does not count 180 users. It counts everybody behind those 180 contracts. Note also which articles are absent from that list: Articles 5, 6 and 8 are excluded, because DNS providers, TLD registries and data centres have no user-count criterion to apply.

Article 3 Is Not Where Your DDoS Threshold Lives

Ask most compliance tooling where the DDoS threshold sits and it will point at CIR Article 3, usually at the EUR 500 000 figure. That is a misread of how the Regulation is wired. Article 3(1) lists seven alternative criteria, and any one of them is sufficient. Only two of them realistically engage a denial-of-service event, and one of them does not engage it at all.

• Article 3(1)(a) — the money limb. Direct financial loss exceeding EUR 500 000 or 5% of total annual turnover in the preceding financial year, "whichever is lower" [1]. Note the comparator: lower, not higher. For a mid-sized entity the 5% figure usually bites first. (Article 34’s fines use the opposite comparator — whichever is higher. Confusing the two is a common and expensive error.)
• Article 3(1)(g) — the bridge. An incident is significant where it "meets one or more of the criteria set out in Articles 5 to 14" [1]. This is the provision that actually carries the outage thresholds. Article 3 does not contain them; it imports them.
• Article 3(1)(e) — the one that does not apply. This covers "a successful, suspectedly malicious and unauthorised access to network and information systems" capable of causing severe operational disruption [1]. A volumetric flood achieves no access. The attacker never gets in; they simply consume capacity from outside. On the plain wording, a pure DDoS does not trigger (e).

That last point has a sharp operational edge. Where a DDoS coincides with a successful intrusion — whether as deliberate cover or simple coincidence — criterion (e) fires on the access alone, independently of any stopwatch. You would then be reportable even if the flood itself lasted eleven minutes and your threshold was thirty. The first question your responders should answer during a DDoS is not "how long has this been running" but "what else is happening while we are looking at this". Our guide to the Article 23(3) two-limb test and the EUR 500K threshold walks through the criteria in full.

Complete Outage, Degraded Service, Slow Response: Three Different Measurements

The Regulation never uses the words volumetric or application-layer. It does not care how the traffic was generated. It measures outcome, and it measures three distinct outcomes with three distinct tests — which is precisely why the attack type you suffered determines which criterion you have to evidence.

The UK’s NCSC notes that a denial-of-service attack "can target a network’s capacity to send and receive traffic (its bandwidth), or the processor limitations of servers", and that spreading traffic across many sources "makes it harder to distinguish attacker traffic from legitimate traffic" [9]. Those two failure modes land in different places in the CIR:

What the attack does	Typical technique	Which criterion you are measured against
Saturates the pipe; service falls over entirely	Bandwidth-exhausting flood, amplification or reflection	The complete-unavailability limb — Art. 5(a), 6(a), 7(a), 8(a), 9(a), 10(a), 11–13(a), 14(a)
Service stays up but is partly unusable, or unusable for some users	Request-level pressure on application logic, expensive endpoints, or a scrubbing rule dropping good traffic	The limited-availability limb — Art. 7(b), 8(b), 9(b), 10(b), 11–13(b), 14(b)–(c)
Service responds, but slowly	Resolver or CPU exhaustion that degrades rather than denies	The latency limb — only Art. 5(b) and 6(b), and only for DNS providers and TLD registries

The latency limb is worth pausing on because it is unique in the Regulation. For a DNS provider or a TLD registry, an average response time above 10 seconds sustained for more than an hour is significant even though the service never went down [1]. No other category has a performance-based trigger. An application-layer attack calibrated to degrade rather than deny is therefore reportable for a resolver operator and, on availability grounds alone, invisible for almost everyone else. If you run resolvers or a registry, our DNS and TLD security guide covers the wider obligation set.

The consequence for a CISO is concrete: monitoring that only alarms on hard-down will not produce the evidence these criteria require. You need timestamps of complete unavailability, a defensible measure of the share of Union users affected during partial degradation, and — for resolver operators — retained average response-time telemetry at hourly granularity.

Repeated Waves Aggregate by Money, Not by Minutes

Hacktivist DDoS is characteristically repetitive; ENISA records that DDoS made up 91.5% of hacktivist-claimed incidents against EU Member States over the period [6]. So the natural question is whether eight sub-threshold hits add up to a reportable one.

Article 4 is the aggregation rule, and its third condition is the one everybody misses. Incidents that are individually insignificant count collectively as one significant incident only where they (a) occurred at least twice within six months, (b) share the same apparent root cause, and (c) "collectively meet the criteria set out in Article 3(1)(a)" [1].

Article 3(1)(a) is the financial limb. Article 4 therefore aggregates on money only. Ten separate 20-minute outages against a cloud service do not combine into a reportable 200-minute outage, because each falls under Article 7(a)’s 30-minute bar and Article 4 has no mechanism to sum elapsed time. They become reportable only if the accumulated direct financial loss crosses EUR 500 000 or 5% of turnover. This is genuinely counter-intuitive, and it cuts both ways: a long grinding campaign that costs you real money in scrubbing fees, overtime and contractual penalties can become notifiable without any single outage ever having been close to threshold.

There is exactly one exception in the whole Regulation. Trust service providers are measured under Article 14(b) on unavailability "for more than one hour calculated on a calendar week basis" [1] — a cumulative clock. A qualified trust service provider absorbing six ten-minute hits in one week has reached its threshold on time alone. No other category has that.

Outside the CIR: the Article 23(3) Test, and What Germany’s BSI Actually Says

If you are a hospital, a grid operator, a rail company or a manufacturer, none of the numbers above legally bind you. Your test is Article 23(3): an incident is significant where it "has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned", or where it "has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage" [2]. Either limb alone suffices, and the words "capable of causing" mean a contained attack can still qualify.

This is a genuinely soft test, and that softness is documented. Peer-reviewed analysis of the NIS regime found that "most Member States lack further guidance as to the determination of significance", with transposition diverging across the Union [8]. Do not assume that your national reading matches your neighbour’s.

Germany’s competent authority has taken the most useful public position on this. The BSI states that where the Implementing Regulation does not apply directly, it can nonetheless be assumed that a significant incident has occurred where at least one of the criteria of Regulation (EU) 2024/2690 is met — and adds a national rule of its own: a significant incident is always to be assumed where the provision of critical services has failed or been impaired [5]. Two things follow for a German entity, and both are worth testing against your own authority’s guidance:

• The CIR numbers function as a presumption well beyond their binding scope. Meeting one is sufficient; failing to meet one is not a defence, because the Article 23(3) test still sits underneath.
• The critical-services rule has no duration element and no user threshold. For a KRITIS-adjacent operator, a short DDoS that impairs a critical service is reportable on the national rule even where every CIR figure would have said no.

If You Absorbed It Cleanly, You May Have Had a Near Miss

Article 6(6) defines an incident as "an event compromising the availability, authenticity, integrity or confidentiality" of data or services — availability listed first [3]. A DDoS that degrades nothing has compromised nothing. Article 6(5) supplies the companion concept: a near miss is an event that could have compromised those properties "but that was successfully prevented from materialising or that did not materialise" [3].

A flood fully absorbed upstream by scrubbing, with no measurable customer impact, is on that wording a near miss rather than an incident — and near misses carry no mandatory notification. Article 30 lets you report them voluntarily, and protects you for doing so: voluntary reporting "shall not result in the imposition of any additional obligations upon the notifying entity to which it would not have been subject had it not submitted the notification" [4].

Two cautions before anyone files a DDoS under near miss and closes the ticket. First, "we mitigated it" is a conclusion, not a measurement — it holds only if the availability and response-time metrics stayed inside your thresholds throughout. Second, mitigation that works by dropping traffic can itself create the impairment: if you null-route a prefix or a scrubbing rule sheds legitimate requests, users are unserved. Article 3(2) will not rescue you there, because it exempts only "scheduled interruptions of service and planned consequences of scheduled maintenance" [1], which an emergency response plainly is not. That reading follows from the text rather than any published authority guidance, so document your reasoning either way.

The First 24 Hours

The Article 23(4) cascade runs from awareness, not from resolution: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report no later than one month after the notification [2]. Two practical notes that catch teams out. The clock starts on reasonable suspicion, not on confirmation. And the one-month clock runs from your 72-hour filing, so notifying early shortens your own final-report window — a wrinkle covered in our guide to why the 24-hour clock starts at suspicion.

Role	Your job during a DDoS
CISO / IT security	Timestamp the start and end of complete unavailability to the minute. Capture affected-user share and, if you run resolvers, hourly average response time. Sweep for concurrent intrusion — that is the Article 3(1)(e) question.
Compliance / legal	Identify which CIR article applies to your category before the incident, not during it. Record the criterion assessed and the reasoning, including for a decision not to notify.
SME owner or non-technical lead	Ask one question: did customers lose the service, and for how long? If you are outside the eleven categories, ask whether a critical service was impaired at all — under some national guidance, that alone is enough.
Board	Nothing to approve mid-incident. Article 23(1) confirms the mere act of notification does not increase liability, so there is no defensible reason to delay a filing for board sign-off.

When you do file, the portal and required fields differ by Member State — see where to report a NIS2 incident in 24 hours.

Frequently Asked Questions

Is every DDoS attack a NIS2 incident? Any DDoS that compromises availability is an incident under Article 6(6) [3]. Only a fraction are significant incidents requiring notification. One fully absorbed with no measurable impact is arguably a near miss under Article 6(5), reportable only voluntarily [3][4].

Where does the widely quoted 99.9% availability threshold for DNS providers come from? Nowhere in the legislation. Several high-ranking guides state it; no such figure appears anywhere in CIR 2024/2690. The actual Article 5 criteria are complete unavailability for more than 30 minutes, an average response time above 10 seconds sustained for over an hour, or a compromise of integrity, confidentiality or authenticity [1].

What changed from the old NIS1 rule? Digital service providers were previously measured by a single blended metric: unavailability "for more than 5 000 000 user-hours" under Article 4 of Implementing Regulation (EU) 2018/151 [7]. CIR 2024/2690 repealed that instrument outright (Article 15) [1] and replaced one formula with eleven category-specific tests. A small provider that could never accumulate five million user-hours may now cross a 30-minute bar routinely.

Does a ransom demand attached to a DDoS change the analysis? Not the significance test itself, which is outcome-based. It may bring the incident within criminal-reporting expectations and, if the extortion involves any access to your systems, opens the Article 3(1)(e) route independently of duration [1].

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex, Official Journal
2. Directive (EU) 2022/2555, Article 23 — Reporting obligations
3. Directive (EU) 2022/2555, Article 6 — Definitions
4. Directive (EU) 2022/2555, Article 30 — Voluntary notification of relevant information
5. "#nis2know: NIS-2-Meldepflicht" — Bundesamt für Sicherheit in der Informationstechnik (bsi.bund.de)
6. ENISA Threat Landscape 2025 — ENISA, October 2025
7. Commission Implementing Regulation (EU) 2018/151 (repealed) — EUR-Lex
8. Schmitz-Berndt, S., "Defining the reporting threshold for a cybersecurity incident under the NIS Directive and the NIS 2 Directive", Journal of Cybersecurity, Vol. 9, Issue 1, 2023, tyad009 (academic.oup.com)
9. Understanding denial of service (DoS) attacks — NCSC (United Kingdom)