NIS2 and DDoS: What Essential and Important Entities Must Implement

Directive (EU) 2022/2555 — NIS2 — contains no DDoS product requirement. It does not name a mitigation capacity, an architecture, a detection technique or a response time. Anyone selling you a “NIS2-compliant DDoS solution” is selling you a category error.

What the directive does contain is a set of duties written at the level of risk management, incident reporting, governance and supply chain, and those duties do have specific consequences for how a DDoS defence must be built and operated. The work of compliance is the translation: turning “appropriate and proportionate technical, operational and organisational measures” into decisions about where inspection happens, who is authorised to declare an incident at three in the morning, what telemetry survives the night, and what happens if the supplier holding half of your defence becomes unavailable.

This guide performs that translation. It deliberately stays away from article-by-article recitation, for two reasons. First, the binding text for any given entity is not the directive but its national transposition, which differs between member states in ways that matter operationally. Second, the parts of NIS2 that actually change engineering decisions are thematic rather than clause-level, and reading them clause by clause tends to produce a compliance document that no engineer ever opens.

What NIS2 asks for, in the terms an engineer recognises

Strip the directive down to what bears on availability under deliberate attack and four themes remain.

Risk management on an all-hazards basis. In-scope entities must take appropriate and proportionate technical, operational and organisational measures to manage risks to the security of their network and information systems, and to prevent or minimise the impact of incidents on the recipients of their services and on other services. Proportionality is explicit: measures are judged against the state of the art, relevant standards, the cost of implementation, and the entity’s size, risk exposure and the likelihood and severity of incidents including their societal and economic impact. This is the clause that makes “we considered volumetric attack and accepted the risk” a legitimate position in principle — and an indefensible one in practice for a public-facing service whose unavailability has societal consequences, because the assessment has to be proportionate to that impact.

A minimum set of measures. The directive enumerates the areas those measures must at least cover. Several bear directly on DDoS: policies on risk analysis and information system security; incident handling; business continuity, including backup management, disaster recovery and crisis management; supply chain security, including the security-related aspects of the relationship between the entity and its direct suppliers and service providers; security in the acquisition, development and maintenance of network and information systems, including vulnerability handling and disclosure; and policies and procedures to assess the effectiveness of the measures themselves. That last one is the quiet obligation most organisations underestimate, and it is treated separately below.

Staged incident reporting on a fixed clock. A significant incident triggers an early warning without undue delay and in any event within 24 hours of the entity becoming aware of it; an incident notification within 72 hours, updating the early warning and providing an initial assessment of severity and impact together with, where available, indicators of compromise; and a final report within one month. The early warning must indicate whether the incident is suspected of being caused by unlawful or malicious acts and whether it could have a cross-border impact. The final report must describe the incident and its severity and impact, the type of threat or root cause that likely triggered it, the mitigation measures applied and ongoing, and any cross-border effects. Where an incident is still running at the one-month mark, the process accommodates a progress report followed by a final report once handling is complete.

Management accountability. The directive puts approval and oversight of the cybersecurity risk-management measures on the entity’s management body, holds it accountable for infringements, and requires its members to undergo training. This is what converts the DDoS significance threshold from an engineering preference into a governance artefact: if a threshold determines whether the organisation notifies a regulator, someone at board level owns it.

A fifth structural point sits underneath all of these. NIS2 works largely on self-identification: entities in the listed sectors assess whether they meet the criteria, register with the competent authority, and keep their registration details current. Nobody sends you a letter telling you that you are in scope.

Essential and important entities: same duties, different supervision

The two categories are frequently misread as two compliance tiers. They are not. The risk-management measures and the reporting obligations apply to both. What differs is the supervisory regime: essential entities are subject to proactive, ex ante supervision, while important entities are supervised ex post — broadly, when something indicates that they may not be complying. Enforcement ceilings are also set higher for essential entities, with the directive requiring member states to provide for administrative fines expressed both as a fixed maximum and as a percentage of worldwide annual turnover, whichever is higher.

For DDoS specifically this has one practical consequence worth internalising. An important entity is not entitled to a thinner architecture. It is, however, in a position where its first substantive contact with the supervisory authority is likely to follow an incident — which means the evidence has to be assembled retrospectively, under time pressure, about an event that has already happened. The essential entity at least gets asked in advance.

Which annex your sector sits in — the sectors of high criticality or the other critical sectors — and how the size criteria apply to you are questions for your national transposition and, where necessary, for counsel. They do not change the engineering.

Translating risk management into architecture

Here is where the directive’s abstractions become design decisions. The mapping below is not a compliance checklist in the regulatory sense; it is the set of engineering questions that each theme forces you to answer.

NIS2 theme	The DDoS question it forces	What “done” looks like
Risk analysis	What is the largest attack that could reach us, and where is our ceiling?	A documented comparison of plausible attack volume against access-circuit capacity, with the gap named
Incident handling	How long from first malicious packet to mitigation, and who decides?	A measured detection-to-mitigation figure and a named, always-reachable decision authority
Business continuity	What runs in degraded mode, and how do we fail back?	A written degradation plan and a tested fail-back sequence, not just a diversion trigger
Crisis management	How do we talk to each other when the circuit is full?	An out-of-band escalation path exercised at least as often as the primary one
Supply chain security	What breaks if a supplier stops supplying?	A dependency map with a stated survival time per dependency
Effectiveness assessment	How do we know any of this works?	Exercise records with findings, owners and closure dates

The first row deserves emphasis because it is the one where the directive’s language and the physics of the problem meet most directly. An on-premise appliance cannot filter traffic that has already saturated the circuit delivering it; above that line the only thing that helps is capacity closer to the source. A risk analysis that does not state where that line sits for your organisation has not analysed the risk — it has described a product.

The jurisdiction dimension in that diagram is not a NIS2 requirement and should not be presented as one. It matters because the two regimes apply in parallel: a scrubbing tier cannot classify traffic without processing source addresses, headers and often session identifiers, and where those are personal data the transfer question is answered by data protection law rather than by the cybersecurity directive. Our comparison of cloud, on-premise and hybrid architectures works through that trade-off in detail; the NIS2-relevant point is narrower, and it is about evidence rather than legality. The architecture you choose determines who holds the data you will need in order to file a report.

The clock starts when you become aware

The 24-hour early warning runs from the moment the entity becomes aware of a significant incident. That single word is where DDoS defence and reporting obligations intersect, because awareness is a property of your detection stack, not of the attack.

Two failure modes follow. The first is late awareness. An application-layer campaign engineered to stay below volumetric thresholds — browser-grade requests, realistic session behaviour, traffic aimed at authentication or checkout paths — may degrade a service for hours before anyone characterises it as an attack rather than as a performance problem. The clock does not start when the attack starts; it starts when you notice. But the final report will reconstruct the timeline, and a long gap between onset and awareness is itself a finding about the adequacy of your measures.

The second failure mode is the opposite: a detection stack that produces awareness of everything and significance judgements about nothing, so the 24-hour decision gets made by whoever happens to be on shift.

The diagram carries a compliance implication that is easy to miss. Mitigation that completes in seconds frequently keeps an attack below any plausible significance threshold; mitigation that requires detection, decision, announcement and routing convergence often does not. Two organisations with identical policies and identical attacks can end up with different reporting obligations purely because of where their mitigation sits in the path. That is not an argument for one architecture over another — it is an argument for knowing which side of the line your design puts you on, before an auditor asks.

Significance is a threshold you have to write down

The directive frames significance in terms of severe operational disruption of the services or financial loss for the entity concerned, or considerable material or non-material damage caused to other natural or legal persons. Those are outcome tests, not packet counts. For certain digital-infrastructure and digital-provider categories the Commission has adopted implementing rules that specify significance in more quantified terms, but the general population of in-scope entities has to do the specification itself.

For DDoS, a workable threshold is built from three components, all of them observable during the event rather than after it:

1. A service-level trigger. Availability or latency of named services, measured from outside your network, breaching a defined level for a defined duration. External measurement matters: during a volumetric event your internal monitoring may be as unreachable as the service.
2. A scope trigger. The number or class of affected recipients — a single internal application and a citizen-facing portal are not the same event, and the directive’s second limb is explicitly about damage to others.
3. A duration trigger. A short absorbed burst and a sustained degradation differ in kind, not just in degree, and the threshold should say so. This distinction does most of its work where many short events have to be judged in a short period, which is the pattern in politically motivated campaign activity.

Three properties make this document useful rather than decorative. It must be approved at management level, because the governance limb of the directive puts approval and oversight of the risk-management measures there. It must name a person, reachable at any hour, who applies it. And it must be written so that applying it does not require judgement about the regulation — only about the metrics.

Business continuity, crisis management, and the channel you escalate on

The business continuity and crisis management limb of the risk-management measures is routinely satisfied with a document about data-centre failover, which addresses the wrong failure. A DDoS event does not destroy your data; it removes your reachability, including — and this is the part that surprises people during their first serious incident — the reachability of the tools you would use to respond.

Three concrete requirements follow.

An escalation path that does not traverse the circuit under attack. If the only way to reach your upstream provider runs over the saturated link, you do not have an escalation procedure. The directive’s list of measures explicitly reaches secured communication and emergency communication systems; this is the DDoS-specific reading of that. A separate connection, or a pre-agreed out-of-band channel with the provider, has to exist before the incident and has to be tested.

A documented fail-back, not just a documented diversion. Diverting traffic upstream is the easy half. Returning it to the normal path without a second outage requires defined conditions, a defined owner and a tested sequence. Continuity plans that stop at the diversion trigger describe half a procedure.

A degraded-mode definition. Which functions must survive, which may be shed, and who is allowed to shed them. For an entity whose services have societal impact this is the part the supervisory conversation will actually be about, because it is the part that determines harm to recipients.

Supply-chain security, applied to the security vendor

The supply-chain limb is the most under-implemented part of NIS2 in practice and the most interesting one for DDoS, because DDoS mitigation is unusual among controls: a large share of it is typically delivered as a service by a third party, sitting in the traffic path, holding the telemetry, and reachable by the entity only through the supplier’s own platform.

The directive expects entities to take into account vulnerabilities specific to each direct supplier and service provider and the overall quality of their products and cybersecurity practices, including their secure development procedures. Two consequences deserve to be made explicit.

Your mitigation supplier may itself be in scope. The sectors listed in the directive include managed service providers and managed security service providers. A supplier delivering DDoS mitigation as a managed service may therefore carry its own NIS2 obligations — including its own reporting duties. That is a question with a documentary answer, and it belongs in the vendor questionnaire: are you in scope, in which member state, and under which competent authority?

Concentration and dependency are the assessable properties. The useful supply-chain question is not “is this vendor reputable” but “what continues to work, and for how long, if this relationship is interrupted”. Interruption has many causes and few of them are hypothetical: acquisition and product discontinuation, unilateral licensing changes, export controls or sanctions affecting supply to a given geography, a prolonged quality problem, or a breach at the vendor itself.

Our separate assessment of sourcing the two mitigation layers from different manufacturers develops the concentration argument properly, and it is worth being precise about what NIS2 does and does not contribute to it. The directive lists supply chain security among the risk-management measures and provides for coordinated risk assessments of critical supply chains at Union level. It does not establish a defined concentration-risk and exit-strategy regime of the kind the EU’s financial-sector rules impose on ICT third parties, and claiming that NIS2 mandates a multi-vendor DDoS architecture produces a rationale that will not survive audit. What NIS2 supplies is legitimacy and vocabulary: supplier dependency is a named risk category, so an entity that records “both layers of our availability defence depend on one supplier” in its risk register and acts on it is doing exactly what the directive asks, rather than indulging a preference.

Where this becomes an architecture criterion rather than a paperwork exercise is in the survival question. A mitigation layer that keeps detecting and blocking with no reachback to a vendor cloud, whose telemetry is held on equipment the entity owns, and whose commercial relationship is separate from that of the upstream layer, answers the dependency map differently from one that does not. Appliances built to operate fully on-premise with their own detection engine and full L3–L7 coverage in a single device occupy that position by design. The criteria are vendor-independent and belong in the questionnaire in that form; the point is that they are answerable with documents rather than assurances.

The evidence problem nobody budgets for

Reporting obligations are data obligations. The 72-hour notification asks for an initial assessment of severity and impact and, where available, indicators of compromise. For a DDoS event the indicators are attack vectors, source characteristics, request signatures and volumes over time. The final report asks for the type of threat or root cause. All of it has to come from data that was captured while the event was in progress and retained afterwards.

Three questions determine whether you can actually file:

• Who holds the packet-level or request-level evidence? If mitigation happens entirely in a provider’s scrubbing centres, the forensic detail is in their platform. Ask what is exported, in what format, on what schedule, and whether an incident export can be obtained inside 72 hours — the deadline is yours, not theirs, unless the contract says otherwise.
• How long is it retained, and where? Retention windows on attack telemetry are frequently shorter than the one-month final-report horizon, and the location of that data is a data-protection question in its own right.
• Is the clock synchronised? A reconstructed timeline built from sources with drifting clocks is not a timeline. This is unglamorous and it is the first thing that falls apart under scrutiny.

On root cause, a caution. For a DDoS the tempting answer is “a third party attacked us”, which is true and useless. The analytically honest root cause is usually architectural: the stateful firewall exhausted its session table before the circuit filled; the authentication endpoint had no rate limit; the diversion trigger existed but had never been exercised, so the operator hesitated. Reports that name the external actor and stop there tend to produce supervisory follow-up, because they demonstrate that the entity has not asked why the attack worked.

Assessing effectiveness: the obligation that requires exercises

The requirement to have policies and procedures for assessing the effectiveness of the cybersecurity risk-management measures cannot be satisfied by desk review. For DDoS defence specifically, the properties that decide the outcome — whether the diversion trigger fires, whether the fail-back works, whether the out-of-band channel is reachable, whether the on-call engineer can apply the significance threshold at 03:00 — are only observable when exercised.

A defensible programme has four elements: a planned, controlled test schedule with defined scope; measured outcomes rather than narrative ones (time to detection, time to full mitigation, legitimate traffic lost during mitigation, time to divert and to fail back); a findings register with owners and closure dates; and evidence that findings from the previous cycle were actually closed. The last element is what distinguishes a programme from an annual event, and it is the one a supervisor can check in a single request.

Testing that touches shared infrastructure needs coordination with your provider and, in most jurisdictions, explicit contractual authorisation. That is a scheduling constraint, not a reason to skip it.

The binding text is your member state’s law

NIS2 is a directive, which means it does not apply to entities directly. It obliges member states to bring national measures into force, and it is those national measures that bind you. The transposition deadline passed in 2024; several member states legislated late, and the Commission has pursued infringement proceedings against states that had not notified complete transposition.

Practical consequences for anyone building a programme across more than one member state:

• Scope can differ. Member states may bring additional entities within scope, and the application of the size criteria is settled nationally.
• The recipient of your report differs. Reports go to the CSIRT or, where applicable, the competent authority, and the national arrangements — single entry point, sectoral authority, reporting portal — are set nationally.
• Sectoral reporting duties stack. Financial-sector, telecommunications and payment rules impose their own incident notifications on their own clocks. An entity subject to more than one regime needs one internal trigger that fans out, not three independent processes that discover each other during an incident.
• Timing differs. Where transposition was late, national supervisory practice is younger than the directive, and guidance from the national authority is frequently the most operationally useful document available.

For entities in accession and neighbourhood states, alignment with the EU cybersecurity acquis proceeds on a national timetable, but the requirements usually arrive earlier by contract than by statute: in-scope customers pass supply-chain expectations to their suppliers, so the questions in this article show up in tenders well before any local law compels them.

What you must be able to demonstrate

Compliance is evidentiary. The following is the DDoS-relevant subset of what an entity should be able to put in front of a supervisor, an auditor or a large customer without preparing it first.

1. A risk assessment that names the ceiling. Plausible attack volume against access circuit capacity, with the gap explicitly stated and a decision recorded about it.
2. A written significance threshold, approved at management level, expressed in service metrics rather than in regulatory language.
3. A named decision authority, reachable at any hour, with a documented deputy.
4. A reporting runbook aligned to the 24-hour, 72-hour and one-month stages, with the national recipient identified and templates pre-drafted.
5. Evidence that telemetry exists and is retained — retention period, location, and the export mechanism you would use to produce an incident package inside the deadlines.
6. A tested out-of-band escalation path, with the date of the last test.
7. A fail-back procedure, tested, with its own owner.
8. A supplier dependency map, stating for each dependency what stops immediately, what degrades, and over what period.
9. Vendor documentation, including whether the supplier is itself an in-scope entity, its own incident notification commitments to you, and the jurisdictions in which it processes your traffic.
10. Exercise records with measured outcomes, findings, owners and closure evidence from the previous cycle.
11. Management-body evidence: approval of the measures, and records of the cybersecurity training the directive requires of its members.
12. A post-incident register showing, for each event, what was detected, when awareness was established, whether the threshold was met, and what was reported.

An organisation that holds those twelve artefacts has done the substantive work. One that holds a vendor’s compliance datasheet has not.

What the source material settles, and what it does not

The linked list at the foot of this page gives the primary texts; this section says what each of them is good for, because a reference list without that reading is a list of homework.

The legal texts. Directive (EU) 2022/2555 (NIS2) NIS2 Directive is the primary source and is available in all official languages on EUR-Lex; read it alongside your own member state’s transposing act, which is the text that binds you. Directive (EU) 2022/2557 on the resilience of critical entities is its physical-resilience counterpart and applies to overlapping populations. Regulation (EU) 2022/2554 (DORA) governs ICT risk in the financial sector and imposes its own third-party and incident regime. For entity categories in digital infrastructure and digital services, the Commission has adopted implementing rules setting technical and methodological requirements and specifying when an incident is significant — check EUR-Lex for the current consolidated text rather than a secondary summary.

ENISA materials. The annual ENISA Threat Landscape Enisa Threat Landscape is the standard open reference for European threat context and includes denial-of-service among its tracked categories. ENISA also publishes sector maturity and criticality analysis across the NIS2 sectors, technical implementation guidance supporting the Commission’s implementing rules, and maintains the European vulnerability database established under the directive. ENISA guidance is not law, but national authorities lean on it, which makes it the closest thing to a common baseline across member states.

Incident handling and risk management. NIST SP 800-61 NIST SP 800 61R3, now in its third revision as Incident Response Recommendations and Considerations for Cybersecurity Risk Management, is the most widely used external reference for the incident lifecycle the reporting stages assume; if your procedures still cite the second revision’s Computer Security Incident Handling Guide, that is the document to re-read first. NIST SP 800-34 covers contingency planning; NIST SP 800-53 provides a control catalogue that maps reasonably onto the directive’s measure areas; NIST SP 800-161 addresses cybersecurity supply chain risk management, which is the discipline the supply-chain limb is asking for. The NIST Cybersecurity Framework 2.0 NIST CSF 2 is useful as an organising structure for the evidence set above. ISO/IEC 27001 and ISO 22301 are the management-system standards most national authorities recognise as supporting evidence.

DDoS-specific technical references. RFC 4732 RFC 4732 (Internet Denial-of-Service Considerations) remains the clearest statement of the problem class. BCP 38 (RFC 2827) RFC 2827 and BCP 84 (RFC 3704) cover ingress filtering, which is what stops your own network being part of someone else’s incident. RFC 5635 covers remotely triggered black hole filtering; RFC 8955 RFC 8955 and RFC 8956 cover BGP FlowSpec; RFC 9132 RFC 9132, RFC 8783 and RFC 8811 define DOTS, the standards-based signalling interface between an entity and an upstream mitigator. RFC 7011 RFC 7011 (IPFIX) is the relevant standard for the flow telemetry your reporting will depend on. NIST SP 800-189 covers resilient interdomain routing.

A closing caution. No product, certification or service confers NIS2 compliance, and no vendor can hold it on your behalf. The directive places the obligation on the entity, its management body carries the accountability, and the evidence has to be yours.