NIS2 Red Teaming: Zero Mentions in the Directive, Three Places ENISA Says It Counts

Search all 46 operative Articles of Directive (EU) 2022/2555 for red team, threat-led or penetration and the count is zero — not one occurrence anywhere in the binding text. Commission Implementing Regulation (EU) 2024/2690, the technical rulebook that turns Article 21 into named controls, never uses red team either, and uses penetration exactly once, in a recital [1][5]. Recitals explain intent; they impose no obligations.

That is the honest legal baseline, and most of what is published about NIS2 red teaming contradicts it. The useful question is not whether red teaming is mandatory — it isn’t — but where a red team exercise actually earns its place in an evidence file, who can compel adversarial testing against you, and why the one EU framework that tells you how to run a proper red team test is explicitly open to entities that have nothing to do with banking.

What NIS2 Actually Says About Adversarial Testing

In plain language: NIS2 obliges you to test your security measures and to assess whether they work. It never tells you which test to use. Every reference to a named test type — penetration testing, red teaming, bug bounties — lives in non-binding text.

Where the Directive does mention penetration testing, it does so in recitals about buying the service, not performing it: Recital 86 (describing managed security service providers active “in areas such as incident response, penetration testing, security audits and consultancy”) and Recital 87 (noting that competent authorities “may also benefit from cybersecurity services such as security audits, penetration testing or incident responses”) [1]. Neither is about an entity testing itself. The nearest the operative text comes to the vocabulary of adversary simulation is Article 29(2), which lets entities voluntarily share information on “adversarial tactics” — an intelligence-sharing provision, not a testing one [1].

The Implementing Regulation is tighter still. Recital 15 offers the menu — security tests “may include automated or manual tests, penetration tests, vulnerability scanning, static and dynamic application security tests, configuration tests or security audits” — while the binding provision, Annex point 6.5.2, names no method at all. It requires entities to set “the need, scope, frequency and type of security tests” from their own risk assessment, to test “according to a documented test methodology”, to document “the type, scope, time and results of the tests, including assessment of criticality and mitigating actions for each finding”, and to remediate critical findings [5].

National guidance follows the same pattern. Ireland’s National Cyber Security Centre published a 65-page draft NIS2 Risk Management Measures Guidance in June 2025. Across the whole document, red team appears zero times and penetration once — inside RMM005.SA01, as a parenthetical example: “define the need and the frequency of security test types (penetration tests, system tests, etc.)” [14].

Instrument	Who it binds	What it says about red teaming
Directive (EU) 2022/2555, Art. 21(2)	All essential and important entities, through national transposition	Names no test type. Points (b), (e) and (f) create the duties that testing serves.
CIR (EU) 2024/2690	Only the entity types listed in its Article 1 — DNS providers, TLD registries, cloud and data centre providers, CDNs, managed service and managed security service providers, online marketplaces, search engines, social networks, trust service providers	Annex 6.5.2 requires documented security testing. “Red team” appears zero times.
ENISA Technical Implementation Guidance v1.0 (June 2025)	Nobody — non-binding guidance	Names red teaming in three separate places as one option among many.
Regulation (EU) 2022/2554 (DORA) + Delegated Regulation (EU) 2025/1190	Financial entities identified by competent authorities	Mandates threat-led penetration testing — a supervised red team test — at least every three years.
TIBER-EU framework (ECB, January 2025)	Nobody — adoption by authorities is voluntary	The operational method for running a red team test. Explicitly sector-agnostic.

Note the second row carefully. The Implementing Regulation binds eleven categories of digital and ICT providers, not every essential entity. A water utility or a hospital is governed by its member state’s transposition of Article 21, not by CIR 2024/2690 — although in practice most national authorities treat the Implementing Regulation’s annex as the reference standard. Our guide to NIS2 penetration testing covers what point 6.5 demands of a conventional test; this article picks up where that one stops.

Red Team, Pen Test, TLPT — The Distinction That Decides Your Scope

In plain language: a penetration test asks whether a system can be broken into. A red team exercise asks whether your people and tooling notice someone breaking in. Threat-led penetration testing (TLPT) is a red team exercise wrapped in a regulatory process, and only financial supervisors can order one.

DORA defines TLPT as “a framework that mimics the tactics, techniques and procedures of real-life threat actors perceived as posing a genuine cyber threat, that delivers a controlled, bespoke, intelligence-led (red team) test of the financial entity’s critical live production systems” [9]. The parenthetical matters: TLPT contains a red team test. It is not an alternative to one.

	Penetration test	Red team exercise	TLPT
Question answered	What is exploitable in this scope?	Would we detect and respond to a realistic attacker?	The same — under supervision, with a recognised result
Scope	Agreed systems or applications	Objective-led; crosses systems, people and processes	Critical or important functions on live production systems
Defenders informed?	Usually yes	No	No — the blue team “is not aware of the TLPT” [7]
Threat intelligence input	Optional	Typical	Mandatory, from an external provider
Minimum duration in law	None	None	At least 12 weeks of active red team testing [7]
Who can compel it	Nobody, under NIS2	Nobody, under NIS2	Your competent authority, if you are an identified financial entity [8]
Output	Findings report	Findings plus a detection-and-response timeline	Both, plus a supervisory attestation recognised across the EU [8]

Delegated Regulation (EU) 2025/1190, applicable since 8 July 2025, supplies the vocabulary the rest of the market borrows loosely. The red team is “the testers, internal or external, contracted for, or assigned to, a TLPT”. The control team — renamed from “white team” to align with DORA — is the internal group that manages the test. Purple teaming is “a collaborative testing activity that involves both the testers and the blue team”, and under TIBER-EU it now belongs to the closure phase, after the attack ends [7][12]. If your provider proposes “purple teaming” as a cheaper substitute for the red team engagement itself, they are using the word differently from the regulator.

The Three Places Red Teaming Counts Under NIS2

In plain language: ENISA’s June 2025 guidance names red teaming three times, and each mention hangs off a different Article 21(2) duty. That means one red team engagement can produce evidence for three obligations — but only if you collect three different artefacts from it.

CIR annex point	Article 21(2) duty	What ENISA lists	Evidence it produces	Frequency ENISA attaches
3.1.3	(b) incident handling	“tabletop exercise, simulation of an incident…, red team/blue team exercise and past incident walk-through”	A test of the incident-handling policy: roles, responsibilities and procedures, plus what you changed afterwards	“Test the roles, responsibilities and procedures laid down in the policy at least annually”
6.5.2	(e) acquisition, development and maintenance	“vulnerability assessments, penetration testing, code review, ethical hacking, bug bounty programmes, cyber attack simulations, red teaming, protocol conformance testing or cyber response exercises”	Type, scope, time and results, with criticality assessed and mitigating actions recorded per finding	None for the test itself; the testing policy is reviewed “at least once every two years”
7.2	(f) effectiveness assessment	“penetration testing (e.g. internal, external, red/blue team)”	A measured conclusion on whether a specific control is effectively implemented and maintained	Set by the entity itself under 7.2(c)

The practical consequence is one that vendor guides skip. A red team engagement procured and filed only as a “security test” under 6.5.2 leaves the other two hooks unevidenced. The 3.1.3 hook needs the defenders’ side of the story — what the security operations team saw, when it escalated, and how the incident-handling policy was amended — which is why TIBER-EU makes the blue team produce its own report mapping its actions alongside the testers’ [12]. The 7.2 hook needs a judgement, not a finding list: for each control you claimed was implemented, did the exercise show it working? None of that falls out of an attacker’s report by default. It has to be commissioned in the statement of work.

One more calibration point for compliance officers. The only annual cadence ENISA attaches anywhere in this cluster is at 3.1.3, and it applies to testing the incident-handling policy — a duty that an annual tabletop exercise satisfies just as well as a red team engagement, at a fraction of the cost. Reading that annual figure across to offensive testing is the most common overclaim in this area.

The Adversarial Test You Are Most Likely to Face Is Your Regulator’s

In plain language: NIS2 does not tell you to attack yourself. It does give your competent authority the power to scan and audit you — and for essential entities, it can do so before anything has gone wrong.

Article 32(2) lets authorities subject essential entities to on-site inspections and off-site supervision “including random checks conducted by trained professionals”, to “regular and targeted security audits carried out by an independent body or a competent authority”, to “ad hoc audits, including where justified on the ground of a significant incident or an infringement of this Directive”, and to “security scans based on objective, non-discriminatory, fair and transparent risk assessment criteria” [3]. The Directive does not define “security scan”, which leaves member states meaningful latitude in how intrusive that power becomes.

The asymmetry with important entities is sharper than the usual summary suggests. Article 33(1) confines supervision of important entities to “ex post supervisory measures”, and Article 33(2) drops both the word “regular” from the audit power and the separate ad hoc audit limb entirely [15]. Essential entities can therefore be audited on a schedule with no triggering event; important entities, in principle, only after one. Our breakdown of essential versus important classification and the full supervisory powers covers the downstream consequences.

For a board, the budget line that follows is the one worth noting: Article 32 provides that the costs of a targeted audit are borne by the audited entity unless the competent authority decides otherwise on substantiated grounds [3]. An unplanned regulatory audit is a cost you may not control the timing of — which is a stronger argument for keeping an audit-ready evidence file than any voluntary red team exercise is.

You Cannot Be Ordered to Run TLPT — Unless You Are Also a Financial Entity

In plain language: TLPT is a DORA instrument. If DORA applies to you, NIS2’s Article 21 obligations largely fall away. If it doesn’t, no NIS2 authority has the power to order a threat-led test.

The bridge is explicit. DORA Article 1(2) states that “in relation to financial entities identified as essential or important entities pursuant to national rules transposing Article 3 of Directive (EU) 2022/2555, this Regulation shall be considered a sector-specific Union legal act for the purposes of Article 4 of that Directive” [10]. Article 4(1) of NIS2 then disapplies the relevant NIS2 provisions — “including the provisions on supervision and enforcement laid down in Chapter VII” — where the sector-specific act is “at least equivalent in effect” [4]. Our NIS2 versus DORA comparison works through the practical division.

Where TLPT does reach a NIS2 entity is indirectly, and this is worth flagging to any cloud, data centre or managed service provider with financial-sector clients. Delegated Regulation (EU) 2025/1190 requires pooled and joint tests to include scenarios targeting ICT third-party and intra-group service providers [7]. You will not be the entity under supervision, but you may find yourself inside the scope of someone else’s twelve-week red team engagement, negotiated through your contract rather than your regulator. That is a supply-chain clause to read before it is a security exercise to run.

TIBER-EU Is Explicitly Open to You — Here Is the Calendar Cost

In plain language: the ECB’s red teaming framework is not restricted to banks. The framework document says so directly. What it does not give a non-financial entity is the supervisory attestation.

TIBER-EU — threat intelligence-based ethical red teaming — was published in May 2018 and updated in January 2025 to align with DORA’s TLPT technical standards [13]. The passage that matters for NIS2 entities appears in the framework’s implementation section: “a national or European implementation of TIBER-EU does not need to be limited to the financial sector alone. Should a jurisdiction wish to involve other sectors (such as telecommunications, utility companies), the TIBER-EU framework does not prevent it from doing so. As such, the framework is entity-agnostic and sector-agnostic” [12]. Telecommunications and utilities are, of course, Annex I essential sectors under NIS2. The ECB names them because it anticipated exactly this question.

Adopting the method privately, without a national TIBER implementation, gets you the process and none of the recognition. There is no TIBER authority, no test manager validating your scope, and no attestation. What you gain is a defensible methodology — and, for a CISO writing a statement of work, a set of numbers to plan against. Adding up the framework’s own phase durations gives a realistic first-test calendar:

Phase	Framework duration	What happens
Preparation	Up to 6 months (initiation documents due within 3 months of notification)	Control team formed, scope and critical functions agreed, providers procured, risk controls put in place
Threat intelligence	Indicative 2–3 weeks	External provider builds the targeted threat landscape and scenarios
Active red team testing	Minimum 12 weeks	Testers execute scenarios against live systems; blue team is not told
Closure — reporting	Red team report 4 weeks, blue team report 6 weeks	Blue team is informed and maps its own actions against the testers’
Closure — replay, purple teaming, remediation	Roughly 8 further weeks	Joint replay, purple teaming, remediation plan, 360° feedback

That totals somewhere around eleven to thirteen months end to end, of which the attack itself is roughly a quarter. The ECB’s own view is that “because of the resources required and costs incurred, entities are not expected to conduct a TIBER-EU test too frequently — with 3 years intervals being the norm” [12]. Two more constraints shape the budget: an external threat intelligence provider is mandatory and external testers are strongly encouraged, and the delegated regulation’s competence bar for TLPT providers is a test manager with five or more years of experience plus two team members with at least two years each [7][12]. There is no cheap version of this exercise done properly. If your organisation has no security operations capability to surprise, the honest answer is that a red team test will only prove what you already know — spend the risk management budget on detection first.

Should Your Entity Run One? A Decision Path

Work through these in order. Stop at the first “no”.

1. Are you a financial entity in DORA scope? If yes, this is not a choice — your competent authority identifies you, and Article 26 sets the three-year cycle. Stop reading; TLPT governs.
2. Do you operate a monitored detection capability — a SOC, a managed detection service, or at minimum alerting someone is on the hook to action? If no, a red team exercise has nothing to measure. Build detection and run a tabletop against your incident-handling policy instead; that satisfies CIR 3.1.3 either way.
3. Have you completed a conventional penetration test in the last twelve months and remediated the critical findings? If no, do that first. A red team engagement that succeeds through an unpatched perimeter tells you nothing you would not have learned for a tenth of the cost.
4. Do you contract with financial-sector clients whose critical functions you support? If yes, read your contracts for pooled-test participation clauses before commissioning anything of your own.
5. Can you commit roughly a year of calendar time and keep the blue team genuinely uninformed? If the answer to either half is no, the exercise degrades into an expensive announced penetration test.

Entities that clear all five have a defensible case. Entities that do not are better served by documenting why — CIR 6.5.2(a) asks you to derive the type of testing from your risk assessment, and a recorded decision that red teaming is disproportionate at your current maturity is itself compliant evidence.

What to Document, Whatever You Decide

The obligation you cannot avoid is the paper trail. Whether you run a red team exercise, a penetration test or neither, an auditor or competent authority will look for the same file:

• A security testing policy and procedures, reviewed at planned intervals — ENISA suggests at least every two years [6]
• The risk-assessment reasoning behind the need, scope, frequency and type of testing you selected — including the reasoning for what you chose not to do
• Test records covering type, scope, time and results, “comprehensible to an expert third party”, with criticality assessed and mitigating actions per finding [5][14]
• Evidence that critical findings were actually remediated, not merely logged
• For the 3.1.3 hook: a record that incident-handling roles, responsibilities and procedures were tested at least annually, and what changed as a result
• For the 7.2 hook: a documented conclusion on control effectiveness, with the method, timing and owner recorded under 7.2(b)–(f)

The regulation is indifferent to how impressive your testing is and precise about whether you can show you chose it deliberately. An entity that runs no red team exercise but can evidence a risk-based selection of test types, a documented methodology, remediated critical findings and an annual policy test stands on firmer ground than one that commissions a twelve-week engagement and files only the attacker’s report. Decide the evidence you need first. The exercise is the means, never the obligation.

Frequently Asked Questions

Does NIS2 require red teaming? No. Neither the Directive nor Implementing Regulation (EU) 2024/2690 contains the term. ENISA’s non-binding guidance lists red teaming as one acceptable method of satisfying testing and effectiveness-assessment duties under Article 21(2), points (b), (e) and (f) [1][5][6].

Is TLPT coming to NIS2? There is no published proposal to import a TLPT regime into NIS2, and no Article in the Directive that would carry it. The mechanism runs the other way: DORA Article 1(2) makes DORA the sector-specific act, so financial entities exit NIS2’s Article 21 regime rather than NIS2 absorbing DORA’s [10].

Can a competent authority order us to run a red team exercise? Article 32(2) gives authorities powers to inspect, audit and scan essential entities themselves, and to demand “evidence of implementation of cybersecurity policies, such as the results of security audits carried out by a qualified auditor” [3]. Compelling a specific offensive-testing methodology is a different power, and it is not one the Directive names. National transpositions vary, so check your own.

Can we use TIBER-EU without being a bank? The framework document states that it is “entity-agnostic and sector-agnostic” and can be used “by any type or size of entity across the financial and other sectors” [12]. What you cannot obtain outside a formal national implementation is the TIBER authority’s involvement or an attestation.

Is purple teaming enough? For CIR 3.1.3 it can be, since ENISA accepts a red team/blue team exercise among several options for testing the incident-handling policy. It is not a substitute for a red team test under the TLPT rules, where purple teaming sits in the closure phase after the covert attack has already run [6][7][12].

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. Directive (EU) 2022/2555 (NIS2), full text — EUR-Lex
2. NIS2 Article 21 — cybersecurity risk-management measures
3. NIS2 Article 32 — supervisory measures for essential entities
4. NIS2 Article 4 — sector-specific Union legal acts
5. Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex (linked in text above)
6. ENISA, Technical Implementation Guidance on cybersecurity risk-management measures, v1.0 (June 2025) (linked in text above)
7. Commission Delegated Regulation (EU) 2025/1190 — RTS on threat-led penetration testing (linked in text above)
8. DORA Article 26 — advanced testing based on TLPT
9. DORA Article 3 — definitions, including TLPT
10. DORA Article 1(2) — DORA as a sector-specific act for NIS2 purposes
11. DORA Article 24 — digital operational resilience testing programme
12. European Central Bank, TIBER-EU Framework (January 2025) (linked in text above)
13. European Central Bank, What is TIBER-EU?
14. National Cyber Security Centre (Ireland), NIS 2 Risk Management Measures Guidance, draft 04/06/2025 (linked in text above)
15. NIS2 Article 33 — supervisory measures for important entities