NIS2 Penetration Testing: What CIR 2024/2690 Actually Requires — And Why Essential Entities Face Tougher Scrutiny

NIS2 never uses the phrase “penetration testing.” Not once, in any of its 46 articles. That gap is exactly why so much advice on this topic is either too vague to act on or confidently wrong — including guidance that tells essential entities they need Threat-Led Penetration Testing (TLPT) when, in most cases, they legally don’t.

The real obligation sits one layer down, in Commission Implementing Regulation (EU) 2024/2690 — the technical rulebook that turns NIS2 Article 21’s broad language into specific, auditable controls. Get the citation right and the rest of the compliance picture (frequency, scope, evidence, who needs what) follows logically. Get it wrong and you either over-invest in a DORA-grade testing programme you don’t need, or under-document a real Article 21(2)(e) obligation you do.

Does NIS2 Actually Require Penetration Testing?

Yes, indirectly — if you’re an essential or important entity, you’re already inside the scope of a testing obligation, even though the word “mandatory” needs a caveat. NIS2 requires “appropriate and proportionate” technical measures under Article 21, and Commission Implementing Regulation (EU) 2024/2690 (“CIR”) turns that into a concrete security-testing duty at Annex Point 6.5. Penetration testing is the method most entities use to satisfy it, but it isn’t the only one the CIR names.

Your situation	Testing obligation
Essential or important entity under NIS2 Annex I/II	Yes — CIR Point 6.5 security testing applies directly
Direct supplier to an essential/important entity	Indirectly — often required contractually under Article 21(2)(d) supply chain clauses
Financial entity also in scope for DORA	Yes, plus DORA’s separate Article 26 TLPT obligation (see below)
Outside NIS2/DORA scope entirely	No legal obligation — still good practice

If you’re unsure which category applies, our NIS2 scope test walks through the sector and size thresholds before you spend a euro on testing.

What CIR 2024/2690 Actually Requires — Point 6.5, Not “Mandatory Pen Testing”

The legal chain runs like this. Article 21(2)(e) of the NIS2 Directive requires “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure.” The CIR’s Annex — the document competent authorities actually audit against — expands that into Point 6.5, Security Testing. Its three sub-points are specific: entities “shall establish, implement and apply a policy and procedures for security testing” (6.5.1); they must set the test scope from the results of their own risk assessment and “carry out security tests according to a documented test methodology, covering the components identified as relevant,” recording test type, scope, timing, and results with a criticality rating (6.5.2); and they must review and update that testing policy on a regular basis (6.5.3).

Nowhere in that text does the CIR say “you must run a penetration test.” It says you must test, on a documented methodology, and fix what you find. Penetration testing only enters the picture explicitly in the Regulation’s preamble, which names it as one accepted method alongside automated and manual tests, vulnerability scanning, and static/dynamic application security testing. In practice, a pentest is the method most auditors expect to see for anything internet-facing or business-critical — but a pure vulnerability scan can satisfy 6.5 for lower-risk components, provided your risk assessment says so and you can defend that call.

This is also where Point 6.10 (Vulnerability Handling and Disclosure) picks up: once your test finds something, you’re separately obliged to “perform, where appropriate, vulnerability scans,” address critical vulnerabilities without undue delay, and run disclosure through your national coordinated vulnerability disclosure channel. Testing and vulnerability handling are written as two connected but distinct duties — a report full of findings you never patch satisfies neither.

Annual, or Risk-Based? What 6.5.2 Actually Says About Frequency

Neither the NIS2 Directive nor the CIR states a number. Point 6.5.1 says testing happens “on a regular basis”; Point 6.5.2 ties scope and depth to your own risk assessment; Article 21(1) adds the proportionality test — due account of “the entity’s exposure to risks, the entity’s size and the likelihood of occurrence of incidents and their severity.” Read together, the legal requirement is a risk-justified cadence with a documented rationale, not a fixed calendar date.

“Annual” has become the default answer anyway, because it’s a defensible, easy-to-explain baseline — not because any NIS2 text mandates it. Treat the table below as practical guidance, not a quoted legal threshold:

Risk profile	Practical starting cadence	Retest triggers
Internet-facing critical service (essential entity)	Every 6–12 months	Major release, new external integration, confirmed incident
Internal-only systems, moderate exposure	Annually	Significant architecture change, M&A integration
Legacy/OT systems, low change frequency	Every 12–24 months, scoped narrowly	Firmware/PLC change, new remote-access path
Direct supplier under contractual pass-through	Per the contract, usually annual	Contract renewal, scope change

Whatever cadence you pick, the audit-relevant part isn’t the interval — it’s that Point 6.5.2 requires you to show your working: which components you tested, why that scope, and how the interval traces back to your risk assessment.

Essential vs. Important: Why Your Classification Changes the Real-World Stakes

The CIR sets one testing standard for everyone in scope. What differs sharply is how a competent authority checks your work — and that gap is the strongest reason essential entities should treat their own CIR 6.5 test as non-negotiable.

Article 32 governs essential entities: supervision is ex-ante. Authorities may run “on-site inspections and off-site supervision, including random checks,” “regular and targeted security audits,” and “security scans based on objective, non-discriminatory, fair and transparent risk assessment criteria” — without needing any prior trigger. Article 33 governs important entities: supervision is explicitly ex-post — the Directive states authorities act “through ex post supervisory measures,” only once there’s “evidence, indication or information” of a possible breach of Article 21 or 23.

The practical read: an important entity’s testing gap might sit undiscovered until something else draws scrutiny. An essential entity can be handed the same security scan Article 32 authorises, at any time, with no complaint or incident required. Running your own CIR 6.5 test first is how you control the outcome of that scan instead of finding out about your gaps from the regulator. See our breakdown of essential vs. important classification and the full supervisory measures both entity types face.

Defining Scope: Perimeter, Internal, OT, and Social Engineering

Point 6.5.2’s phrase — “the components identified as relevant” — is deliberately open. A scope that only covers your public website will satisfy the paperwork and miss the actual risk almost every regulator cares about. Four scope categories cover what “relevant” tends to mean in practice:

Scope type	What it tests	Who typically needs it
Perimeter / external	Internet-facing services, VPN gateways, exposed APIs, cloud edge	Every in-scope entity with any external footprint
Internal	Lateral movement, privilege escalation, segmentation between business units	Entities with flat or legacy internal networks; post-breach validation
OT / ICS	PLCs, SCADA, HMI panels, IT/OT boundary controls — tested against safety constraints, rarely live-fired the way IT is	Manufacturing, energy, water, transport essential entities
Social engineering	Phishing simulations, pretexting, physical access attempts	Any entity, as validation of Article 21(2)(g) cyber-hygiene training

The OT row is where most generic testing programmes fail Point 6.5.2’s own logic. A 20-year-old PLC that can’t absorb a standard IT-style scan without risking a shutdown is still a “component identified as relevant” if it drives a critical process — the CIR doesn’t exempt it, it just requires your methodology to account for it (reduced-intensity scanning, passive network monitoring, or an offline test-bench replica, with the residual risk formally accepted and documented under 6.6’s patch-management derogation logic). Our vulnerability and patch management guide covers that same acceptance mechanism for systems you can’t patch on schedule.

TLPT and NIS2: The DORA Overlap Most Guides Get Wrong

Threat-Led Penetration Testing keeps showing up in NIS2 content, usually with a vague claim that essential entities need it. They mostly don’t — TLPT is defined and mandated under a different regulation entirely.

DORA’s Article 26 requires in-scope financial entities to run TLPT “at least every 3 years,” covering “several or all critical or important functions,” performed on live production systems, using accredited external threat intelligence and red-team providers. That’s a DORA-specific obligation. It doesn’t appear in NIS2’s text, and CIR 2024/2690’s Point 6.5 sets a materially lighter bar: a documented, risk-scoped test methodology — no live-production mandate, no fixed 3-year clock, no accredited-provider requirement.

	NIS2 / CIR 2024/2690 Point 6.5	DORA Article 26 TLPT
Who	All NIS2 essential/important entities	In-scope financial entities (ex-microenterprises)
Frequency	“Regular basis,” risk-justified	At least every 3 years, fixed
Environment	Risk-scoped; live systems not mandated	Live production systems required
Provider	No accreditation requirement stated	Accredited threat intelligence + red-team providers

The overlap that matters: a bank or market-infrastructure operator can be an essential entity under NIS2 and a DORA in-scope financial entity at the same time. For that specific subset, DORA operates as the more specific rule and its Article 26 TLPT obligation applies on top of — not instead of — NIS2’s Article 21 measures generally. Every other essential entity — energy, digital infrastructure, healthcare, water, transport — has no TLPT citation to point to. If your risk profile still justifies adversarial, red-team-style testing, CIR 6.5.2’s risk-based scoping lets you choose that depth voluntarily; it just isn’t a citation you can put in an audit response. See our NIS2 vs. DORA comparison for the full regime overlap.

Choosing a Tester and Setting Rules of Engagement

Point 6.5 doesn’t name required certifications or mandate third-party testers — an in-house red team can satisfy it if the methodology is documented and independent enough to be credible. Most essential entities still use external testers for anything internet-facing, partly for skills coverage and partly because an independent report carries more weight with a competent authority.

Role	Owns
CISO / IT Security Lead	Scope definition, tester selection, Rules of Engagement, technical remediation
Compliance Officer	Mapping results to Article 21(2), retaining evidence, disclosure-policy alignment
Legal / Procurement	Testing contract, liability terms, data-handling clauses for the tester
Board / Management	Sign-off on residual risk acceptance for any finding left unfixed

Before testing starts, the Rules of Engagement document should fix scope boundaries (in particular OT exclusions and safety limits), timing windows, escalation contacts for a critical finding mid-test, and the exact deliverable format — because that format is what Point 6.5.2 will later hold you to.

Turning Results Into Audit Evidence

A pentest report from your vendor is not, by itself, CIR-compliant evidence. Point 6.5.2 requires the entity to document test type, scope, timing, and results with a criticality assessment, and to apply corrective measures where findings are critical — that’s a structured record your organisation keeps, built around the vendor’s report rather than replaced by it.

Germany’s BSI states the same expectation in national terms: entities must implement technical and organisational measures that meet the state of the art, and “Auditberichte oder interne Kontrollverfahren” — audit reports or internal control procedures — are the accepted form of proof for supervisory review. That’s the same shape as 6.5.2: a report alone isn’t the evidence; the report plus your documented scope, criticality ratings, and remediation trail is.

This is the file that matters if Article 32 or 33 supervision ever reaches you. An essential entity that can hand over eighteen months of dated, scoped, criticality-rated test records with closed corrective actions is answering an audit. One that can only produce a single PDF from a vendor is starting one.

The Gap Most Entities Have Right Now

In reviewing how organisations actually arrive at this stage, the same five gaps recur regardless of sector:

Current state	Required state (Point 6.5)	Effort to close
Testing happens, but with no written policy	Documented policy and procedure (6.5.1)	Low
Scope set informally by whoever books the vendor	Scope derived from the entity’s own risk assessment (6.5.2)	Medium
OT/ICS systems excluded by default	Relevant components covered, with a documented reduced-intensity method (6.5.2)	High
Findings tracked only in the vendor’s PDF	Criticality-rated, dated internal record with closed corrective actions (6.5.2, 6.10)	Medium
Cadence fixed by budget cycle, not risk	Frequency justified against the risk assessment (6.5.1, Art.21(1))	Low

Frequently Asked Questions

Is penetration testing legally mandatory under NIS2?
Not by that name. NIS2 Article 21(2)(e) and CIR 2024/2690 Point 6.5 mandate a documented security-testing programme; penetration testing is the method most entities use to satisfy it for internet-facing and business-critical systems, but the CIR also accepts vulnerability scanning and other documented methods where the risk assessment supports that choice.

How often do we legally have to test?
The CIR says “on a regular basis” and ties scope to your risk assessment — there’s no fixed number in the text. Most essential entities use an annual baseline as a defensible starting point, tightening for internet-facing critical services and after major changes.

Does NIS2 require TLPT?
No, unless you’re also a DORA in-scope financial entity, in which case DORA Article 26 requires TLPT on its own three-year cycle, independent of NIS2. Non-financial essential entities have no TLPT obligation under either regulation.

Can we use an in-house team instead of a third party?
Point 6.5 doesn’t require third-party testing. An in-house team can satisfy it if the methodology is documented and credible. Most essential entities still use external testers for internet-facing scope, largely because independent findings carry more weight in a supervisory review.

What happens if we skip testing and then get breached?
The breach itself triggers Article 23 incident-notification duties regardless of your testing history. Separately, the absence of a documented Point 6.5 testing programme is itself a gap an authority can act on under Article 32 (essential, any time) or Article 33 (important, once there’s an indication of non-compliance) — independent of whether that specific breach traces back to an untested component.

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. NIS2 Directive (EU) 2022/2555, Article 21
2. NIS2 Directive, Article 32 (supervision of essential entities)
3. NIS2 Directive, Article 33 (supervision of important entities)
4. Commission Implementing Regulation (EU) 2024/2690, Annex Point 6.5 and 6.10 (Advisera full-text mirror)
5. Commission Implementing Regulation (EU) 2024/2690, official text (EUR-Lex)
6. Bundesamt für Sicherheit in der Informationstechnik (BSI) — NIS2 FAQ
7. Digital Operational Resilience Act (EU) 2022/2554, Article 26 (Threat-Led Penetration Testing)
8. “How Often Does NIS 2 Require Penetration Testing? Busting the Annual Myth” — ISMS.online