NIS2 penetration testing requirements are not written down anywhere in NIS2. The directive never uses the phrase. What Directive (EU) 2022/2555 requires, in Article 21(2)(f), is "policies and procedures to assess the effectiveness of cybersecurity risk-management measures", and that clause is the hook every national authority, auditor and implementing act hangs security testing on.
The gap between what the text says and what your supervisor asks for is why every article you have read gives a different answer. The binding specifics live in the layers below the directive: in your Member State's transposing act, and, if you provide digital infrastructure or digital services, in a directly applicable EU regulation most people in scope have never opened.
One correction before you budget anything. There is no EU-wide NIS2 deadline in October 2026. The EU-wide deadline was 17 October 2024 and it is long past. What exists in October 2026 are three separate national dates in three separate countries.
The Deadline You Were Given Is Probably the Wrong One
The transposition deadline was 17 October 2024 and the directive applied from 18 October 2024. Both dates have gone, so in every Member State that has transposed, your obligations are live now, not pending.
Most Member States missed that deadline, and that is where the confusion starts. The Commission opened infringement procedures against 23 Member States in November 2024, escalated to reasoned opinions against 19 of them on 7 May 2025, and on 9 July 2026 referred Ireland, Spain, France and the Netherlands to the Court of Justice, asking for a lump sum plus daily penalties until each notifies full transposition. Writers have filled that vacuum with whatever national date they found, and three of those dates fall in October 2026:
- Italy. Entities placed on the national NIS list during 2025 must have the basic security measures fully operational by 31 October 2026, 18 months from notification of listing, under ACN Determination 379907/2025, which replaced the earlier 164179/2025 and has applied since 15 January 2026. It is the hardest, most testing-adjacent deadline in the EU right now.
- Austria. The NISG 2026 was published in the Federal Law Gazette on 23 December 2025 and enters into force on 1 October 2026, bringing roughly 4,000 entities into scope, with registration by 31 December 2026.
- Poland. The amended KSC Act took effect on 8 April 2026, a further amendment applies from 1 September 2026, and registration is due 1 October 2026.
Three countries, three different obligations, one month. None of them is a European deadline.
Why every article gives you a different date
NIS2 is a directive, not a regulation. A directive binds Member States as to the result and leaves them the form and methods, and that single fact generates all the variance you have been reading.
It also produces a trap: a late Member State is not a safe Member State. When Germany transposed, the BSIG changes applied from 6 December 2025 with no transition period at all, and BSI registration was due by 6 March 2026. Roughly 11,500 of an estimated 29,500 in-scope organisations made it.
In Italy, obligations run from the date you were notified of your listing, not the date you read the determination. Waiting for your government does not buy time. It compresses it.
What NIS2 Article 21 Actually Requires (and the Word It Never Uses)
Article 21(1) is deliberately open. Essential and important entities must take "appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems which those entities use for their operations or for the provision of their services".
Article 21(2) then lists ten minimum measures. Three generate testing work:
- 21(2)(a), policies on risk analysis and information system security. You cannot analyse risk in a system whose exposure you have never measured.
- 21(2)(e), security in acquisition, development and maintenance, including vulnerability handling and disclosure. A lifecycle obligation, not an annual event.
- 21(2)(f), policies and procedures to assess the effectiveness of cybersecurity risk-management measures. This is the clause.
The load-bearing word is "proportionate". The test sits in the second subparagraph of Article 21(1), which requires that "when assessing the proportionality of those measures, due account shall be taken of the degree of the entity's exposure to risks, the entity's size and the likelihood of occurrence of incidents and their severity, including their societal and economic impact". (Article 21(3) is a different provision: it governs supply-chain measures under 21(2)(d).) Read that as a buyer, not a lawyer: proportionality is not a discount, it shifts the burden of proof onto you. Nobody tells you in advance how much testing is enough. You are asked afterwards to show your reasoning, and an undocumented decision to test less is indistinguishable, in an evidence request, from never having decided at all.
Article 21(2)(f): the effectiveness clause that creates the testing obligation
Every jurisdiction reaches penetration testing by the same route. Article 21(2)(f) asks for procedures to assess whether your measures work, and assessment implies a method that can return a negative result. A control review, confirming that a control exists and is documented, cannot return "this control does not stop the thing it was bought to stop". A security test can. That asymmetry is why authorities land on testing as the evidence for 21(2)(f), and why "we reviewed our policies annually" reliably fails.
It does not make penetration testing the only acceptable answer. It means you need at least one assessment method capable of falsifying your own control claims, applied to the systems that support your service, on a cadence you can justify.
Essential vs important entities: same measures, different supervision
Essential and important entities carry identical Article 21 obligations. There is no lighter set of measures for important entities. What differs is supervision and penalty ceiling.
| Essential entities | Important entities | |
|---|---|---|
| Article 21 measures | Full set, all ten | Full set, all ten, identical |
| Supervision | Ex ante and ex post: proactive audits and inspections without an incident trigger (Article 32) | Ex post only: follows an incident, complaint or evidence of non-compliance (Article 33) |
| Administrative fines | Member States must set a maximum of at least EUR 10,000,000 or at least 2% of total worldwide annual turnover, whichever is higher (Article 34(4)) | Maximum of at least EUR 7,000,000 or at least 1.4%, whichever is higher (Article 34(5)) |
| Management suspension | Available under Article 32(5), including temporarily prohibiting a CEO or legal representative from exercising managerial functions | Not available under the Article 33 regime |
The practical difference is when the question arrives. An essential entity can be asked for its testing evidence on an ordinary Tuesday. An important entity is usually asked during the worst week of its year, right after an incident, when nobody has time to assemble a file that should already exist.
Where the Binding Specifics Actually Live: Three Layers Below the Directive
If you take one structural idea from this post, take this one. Article 21 sets the outcome. Three layers underneath it set the requirement you are measured against.
Layer 1: your Member State's transposing act
This is the enforceable instrument. NIS2 is minimum harmonisation, so Member States may go further, and several have. Italy's ACN publishes numbered basic security specifications, roughly 87 requirements for important subjects and 116 for essential subjects, with a hard operational deadline. Belgium runs a conformity assessment model instead: essential entities had to complete a first NIS2 conformity assessment by 18 April 2026, performed by a body accredited by BELAC and authorised by the CCB, with about three quarters choosing the CyberFundamentals (CyFun) framework. Same directive, completely different artefact.
Layer 2: CIR (EU) 2024/2690, and if you are a digital entity this is your actual rulebook
Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 is the most useful document in this area and the least read. It is a regulation, so it applies directly in every Member State with no transposition and no national variation.
It covers eleven categories: 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, and trust service providers. Managed IT and managed security providers are on that list, and many read past their own category assuming it describes someone larger. Scope is not unlimited, though: the CIR bites where the entity falls within NIS2 scope in the first place, which for these categories generally means meeting the medium-enterprise threshold under Article 2(1) (50 or more staff, or annual turnover and balance sheet total above EUR 10 million), or being caught by one of the Article 2(2) criteria regardless of size. If you are not established in the Union but offer these services into it, Article 26 requires you to designate a representative in a Member State, and jurisdiction follows from there.
For those entities the CIR converts the ten outcome statements of Article 21(2) into technical and methodological requirements across thirteen thematic points in its Annex, and this is where NIS2 finally gets specific about testing. Annex point 6.5 requires a security testing policy: 6.5.1 obliges relevant entities to establish, implement and apply one, and the sub-points that follow address what that policy must settle, including the type and scope of testing, its frequency, and how results are recorded and acted on. Note what it does not do: the CIR does not publish a closed menu of accepted test types the way DORA does, so the choice of method remains yours to justify. Annex point 6.10 covers vulnerability handling and disclosure, including regular scanning and the treatment of what you find. Annex point 7 carries the dedicated requirements on assessing the effectiveness of cybersecurity risk-management measures, the direct expression of Article 21(2)(f), expecting a defined procedure, defined intervals and documented outcomes.
Layer 3: ENISA technical implementation guidance
ENISA published technical implementation guidance on the CIR's risk-management measures, version 1.0, in June 2025. It is not binding, but it is what supervisors read when deciding whether what you did was adequate, and it maps requirements to ISO/IEC 27001 and NIST CSF. Treat it as the answer key rather than the exam.
See what your external surface exposes, mapped to the controls it touches.
Run a free External Security Check →Your Country, Your Cadence: NIS2 Testing Requirements by Member State
There is no EU-wide testing cadence in NIS2. There are national expectations, and they diverge sharply.
| Member State | Transposition status | Competent authority | Testing and assurance expectation | Key date |
|---|---|---|---|---|
| Italy | Transposed (D.Lgs. 138/2024) | ACN | Numbered basic security specifications, around 87 requirements for important subjects and around 116 for essential, in the annexes to ACN Determination 379907/2025. Effectiveness assessment is an explicit control. | 31 Oct 2026 for entities listed in 2025; 31 Jul 2027 for those first listed in 2026 |
| Austria | Transposed (NISG 2026, BGBl 23 Dec 2025) | Federal authority under NISG 2026 | Risk-management measures plus mandatory reporting for around 4,000 entities | 1 Oct 2026 entry into force; registration by 31 Dec 2026 |
| Poland | Transposed (amended KSC Act) | CERT Polska / CSIRT GOV | Security audit obligations under the KSC framework, with periodic audit expectations for key entities | Further amendment applies 1 Sep 2026; registration by 1 Oct 2026 |
| Belgium | Transposed | CCB | The most prescriptive assurance model in the EU: conformity assessment by a BELAC-accredited body, commonly via CyberFundamentals (CyFun) | First conformity assessment for essential entities was due 18 Apr 2026 |
| Germany | Transposed (NIS2UmsuCG amending BSIG) | BSI | Measures applied immediately with no transition period; BSI can require proof of effectiveness | In force 6 Dec 2025; BSI registration was due 6 Mar 2026 |
| Netherlands | Passed by the Senate 7 Jul 2026 (Cyberbeveiligingswet); still referred to the CJEU, as the referral predates notification of full transposition | NCSC-NL and sectoral supervisors | Duty of care plus reporting duty; supervisory guidance still developing, over 8,000 organisations in scope | Enters into force 15 Aug 2026 |
| France | Not yet fully transposed; referred to the CJEU | ANSSI | Resilience bill combining NIS2 with related directives; tiered requirements expected by entity class | Referred to CJEU 9 Jul 2026, lump sum and daily penalties requested |
| Ireland | Not yet fully transposed; referred to the CJEU | NCSC-IE | Draft national guidance restates the CIR requirements closely, including security testing | Referred to CJEU 9 Jul 2026 |
| Spain | Not yet fully transposed; referred to the CJEU | INCIBE / CCN | Existing RD 43/2021 obligations continue to apply in the interim | Referred to CJEU 9 Jul 2026 |
Read as a calendar rather than a country list, the same table shows how compressed the next eighteen months are:
Last verified: 11 August 2026. National implementation is moving fast and this table will age. If your jurisdiction has moved since this date, tell us and we will correct it and credit the correction.
Two patterns are worth pulling out. Countries that transposed early are now running assurance regimes with named artefacts, and Belgium signals where this is heading: assessment by an accredited third party, not a self-declaration. Countries that transposed late are removing transition periods to catch up, which is the wrong environment in which to be starting from zero. The Netherlands is the clearest case: the Cyberbeveiligingswet entered into force on 15 August 2026 with no general grace period, so if the Netherlands is your supervising state your obligations are already live, see our full breakdown of the Dutch Cbw.
NIS2 vs DORA: Which One Governs Your Testing Programme
If you are a financial entity this is a five-minute question. DORA is lex specialis. NIS2 Recital 28 and Article 4 provide that where a sector-specific Union act requires measures at least equivalent in effect, the corresponding NIS2 provisions do not apply, and DORA Recital 16 confirms the relationship from the other side. You run one programme, under DORA.
The comparison matters for everyone else, because it exposes what is hard about NIS2.
| NIS2 | DORA | |
|---|---|---|
| Instrument | Directive, transposed nationally | Regulation, directly applicable |
| Test types named | None | Twelve, enumerated in Article 25(1) |
| Cadence stated | None in the directive | At least yearly under Article 24(6) |
| Tester independence | Implied via national acts and the CIR | Explicit in Article 24(4), higher bar in Article 27 for TLPT |
| Scoping burden | On you, and you must document the reasoning | Partly resolved by the regulation |
DORA hands you a menu and a clock. NIS2 hands you an outcome and asks you to show your working, which is harder, not easier. So borrow: where NIS2 gives no menu of accepted test types, DORA Article 25(1)'s twelve is a defensible reference to cite in your own scoping rationale, because it is an EU legislative statement of what counts as adequate ICT testing. For the full treatment, including which entities fall into threat-led penetration testing scope, read our DORA penetration testing requirements guide.
Building a Testing Programme That Survives a NIS2 Audit
A supervisor does not audit your penetration test. They audit your programme, and the test report is one exhibit in it. Six components carry the weight.
Frameworks overlap heavily here. If you already run SOC 2 penetration testing, most of this structure exists and needs remapping rather than rebuilding.
Annual is a floor, not a programme
Systems change continuously, so an annual test evidences effectiveness on one day out of 365 and says nothing about the other 364. The defensible pattern is an annual independent test that produces the signed artefact, plus continuous exposure monitoring between tests that produces the timeline. When an auditor asks how you knew about the exposed admin interface that appeared in March, "our annual test is in November" is not an answer. A dated detection record is. That is the case for continuous threat exposure management in regulatory rather than marketing terms.
What you can automate and what you can't
Automation is right for coverage, breadth and recurrence. It is not sufficient for the parts requiring judgement, and the split is clean enough to write into your scoping rationale:
- External surface discovery, run continuously rather than annually
- Configuration and TLS checks against every internet-facing host
- Vulnerability scanning against known signatures, mapping cleanly onto CIR Annex point 6.10
- Drift detection between tests, which produces the dated timeline auditors ask for
- Business logic flaws, which only make sense against your own workflows
- Chained exploitation across several low-severity findings
- Authorisation failures that require understanding your data model
- Deciding whether a finding actually threatens the service, which needs a name on the report
That split is worth naming in your scoping rationale, and it tracks the CIR Annex's own separation of ongoing vulnerability handling at point 6.10 from the deliberate, policy-governed security testing at point 6.5. Automation covers the systematic 80%, the classes that reward breadth and repetition across every in-scope host. Human judgement owns the rest, and owns the verdict.
There is a second axis underneath it that matters more to a supervisor than the first. Whichever side of the automation line the work falls on, the question in an evidence request is who ran it. Coverage is a security question. Independence is the compliance one, and only one of them is settled by better tooling. The honest version of that line is at when automated pentesting is enough.
Article 20: why this report is your board's personal liability file
Article 20(1) requires management bodies to approve the risk-management measures and oversee their implementation, and makes clear they can be held liable for infringements. Article 32(5) sharpens it for essential entities, giving authorities power to temporarily prohibit a person discharging managerial responsibilities at chief executive or legal representative level from exercising managerial functions. That is not a corporate fine. That is a named person losing their role.
Which reframes what you are buying. A programme with dated scope documents, an independent report, tracked remediation and a board minute is what lets a director say "we approved measures, we verified they worked, here is the file" and have it be provable rather than asserted.
Start Where an Auditor Starts: Your Internet-Facing Surface
There is a reason supervisors begin with what is externally observable. It costs them nothing, requires no cooperation from you, and is a good proxy for programme maturity. You can run the same four checks against your own domain in ten minutes, no signup. None of them discharges an Article 21 obligation on its own, but each produces a dated observation relevant to a named measure, which is where a file starts.
None of these is a penetration test. All four are the reconnaissance an assessor performs before deciding what to look at closely, and running them first means you find the embarrassing items before someone with statutory powers does. To go wider than the four in one pass, the free external security check maps your externally observable surface to the controls it touches, and its output is a sensible input to scoping the paid work. It is recon, not a pentest: it sees the front door, and says so on the report.
What This Costs, and the Three Decisions to Take to Your Board
Traditional consultancy testing anchored buyers at figures that make an annual programme look like a capital project, and that anchor is out of date. The full breakdown is in the 2026 penetration testing cost guide, and our tiers are on the pricing page. An independent signed report is a four-figure line item rather than the five-figure consultancy engagement most budgets were built around; what your own programme costs depends on how many in-scope services you carry and the cadence you justify.
Then take three decisions, in order.
The expensive mistake in NIS2 is not underspending. It is buying an annual test scoped so narrowly that it produces a clean report about systems nobody cared about, then discovering at inspection that it evidences nothing about the systems supporting your essential service. The common mistake is simpler and worse: no documented programme at all, and hoping the question arrives late.
It is not arriving late. Italy asks on 31 October 2026. Austria's law switches on the day before that month begins. Belgium already asked in April. So establish the baseline this week, scope an independent test against the systems that carry your service, and insist that what you buy produces evidence a supervisor can consume: methodology, severity ratings, reproduction detail, remediation tracking and retest confirmation, signed by a named certified security professional. A PDF with a logo and a risk score is not that, and the difference is set out in what makes a pentest report auditors trust. Then put the programme in front of your board with a date on it.
Frequently Asked Questions
Does NIS2 require penetration testing?
How often does NIS2 require penetration testing?
What does NIS2 Article 21(2)(f) require?
Is there a NIS2 deadline in October 2026?
How is NIS2 different from DORA for penetration testing?
Does CIR (EU) 2024/2690 require security testing?
Build the File Before Someone With Statutory Powers Asks For It
NIS2 does not give you a menu or a clock. It gives you an outcome and asks you to show your working, which means the deliverable is not a test, it is a file: dated scope, justified method, independent report, tracked remediation, board minute. That file takes weeks to assemble and minutes to be asked for.
CyberOrbit delivers an independent, audit-ready penetration test in 48 hours: you set your own targets, our platform scopes and runs the assessment, and a certified security professional reviews and signs the completed report you select, with real HTTP evidence behind every finding. Start with the free surface checks above to find the obvious gaps, then scope the paid work against the systems that actually carry your essential or important service.