NIS2 penetration testing and vulnerability assessment requirements — what is mandatory and what is risk-based

Not by name. Article 21 of Directive (EU) 2022/2555 lists ten minimum measures, and none of them is “penetration testing”. The words appear only in the recitals, in a sentence about managed security service providers that offer penetration testing, and as a tool supervisors themselves may use.

What the Directive does require is a set of outcomes that are hard to prove without testing:

• Art. 21(2)(e): security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure.
• Art. 21(2)(f): policies and procedures to assess the effectiveness of cybersecurity risk-management measures.
• Art. 21(1): measures appropriate and proportionate to the risk, taking into account the state of the art, the entity's exposure, its size, and the likelihood and severity of incidents.
• Art. 21(4): an entity that finds it does not comply must take corrective measures without undue delay.

The explicit wording arrives one level down. Implementing Regulation (EU) 2024/2690 turns these points into testing and vulnerability requirements for digital-infrastructure and ICT-service providers, and in Italy the ACN baseline measures write “vulnerability assessment e/o penetration test” into the requirements for essential entities. Anyone who tells you NIS2 mandates an annual penetration test for every entity is overstating the text; anyone who tells you testing is optional is understating what Articles 21 and 32 make you prove.

Articles 32 and 33 give competent authorities the power to test you and to ask for your own test results. For essential entities (Art. 32(2)), supervision is ex ante: on-site inspections and off-site supervision including random checks, regular and targeted security audits by an independent body or the authority, ad hoc audits, security scans based on objective risk assessment criteria, and requests for evidence of implementation of cybersecurity policies, such as the results of security audits carried out by a qualified auditor and the respective underlying evidence.

For important entities (Art. 33) the same tools, without regular audits, are used ex post, when the authority has evidence, an indication or information of non-compliance.

In Italy ACN applies the same split. Its FAQ on supervision (MVE.3) states that inspections of essential entities, including random checks, can be ordered ex ante, while important entities can be inspected only when ACN has evidence or information suggesting a possible violation (art. 36, comma 2, D.Lgs. 138/2024). An important entity is therefore most likely to be asked for its testing records after an incident, which is the worst moment to discover that they do not exist.

The Commission adopted Implementing Regulation (EU) 2024/2690 on 17 October 2024 under Art. 21(5) of NIS2. It is directly applicable and covers a defined list of relevant entities: DNS service providers, TLD name registries, cloud computing service providers, data center service providers, content delivery network providers, managed service providers, managed security service providers, online marketplaces, online search engines, social networking platforms and trust service providers. For other sectors it is not binding, but it is the most detailed reading of Art. 21(2) the EU has published.

The annex points that matter for testing:

• 6.5 Security testing: a policy and procedures for security testing; the need, scope, frequency and type of tests established on the basis of the risk assessment; tests carried out according to a documented methodology, covering the components identified as relevant for secure operation; the type, scope, time and results documented, including assessment of criticality and mitigating actions for each finding; mitigating actions applied for critical findings; the policy reviewed at planned intervals.
• 6.10 Vulnerability handling and disclosure: monitor vulnerability information from CSIRTs, authorities and suppliers; perform, where appropriate, vulnerability scans, and record evidence of the results, at planned intervals; address vulnerabilities critical to operations without undue delay; keep vulnerability handling compatible with change, patch, risk and incident management; lay down a disclosure procedure in line with the national coordinated vulnerability disclosure policy. Where a vulnerability does not require remediation, document and substantiate why (6.10.3).
• 7 Effectiveness assessment: a policy and procedures that define what is measured, the methods, when, by whom, and when and by whom results are evaluated.
• 2.3 Independent review: the overall approach to network and information security is reviewed independently, by people with audit competence outside the line of authority of the area under review, at planned intervals and after significant incidents or changes.

Recital 15 names the tests it has in mind: automated or manual tests, penetration tests, vulnerability scanning, static and dynamic application security tests, configuration tests and security audits, run at set-up, after significant upgrades or changes, or after maintenance. It is a list of options, not a mandate. One rule applies across the annex (Art. 2(2)): where a requirement applies “where appropriate” and you decide it is not appropriate for you, you must document your reasoning in a comprehensible manner.

Article 24, comma 2, of D.Lgs. 138/2024 transposes Art. 21(2) almost word for word: letter e) covers the management and disclosure of vulnerabilities, letter f) the policies and procedures to assess the effectiveness of risk-management measures. The detail comes from ACN. Determinazione ACN 379907 of 19 December 2025, which replaced determinazione 164179 of 14 April 2025 and applies from 15 January 2026, sets the baseline security measures in two annexes: Allegato 1 for important entities, Allegato 2 for essential entities. The measures follow the codes of the Italian Cybersecurity and Data Protection Framework (2025 edition), and each measure has numbered requirements.

The testing and vulnerability requirements, as they read in the two annexes:

• ID.RA-01, point 1 (both): vulnerability information gathered under ID.RA-08 is used to identify vulnerabilities in information and network systems.
• ID.RA-01, point 2 (essential only): for at least the relevant information and network systems, in line with the vulnerability management plan, and save for justified and documented regulatory or technical reasons, activities to identify vulnerabilities that include at least vulnerability assessment and/or penetration test are carried out periodically and in any case before the systems go into production.
• ID.RA-01, point 3 (essential only): those activities are documented in reports that contain at least a general description of the activities and their outcome, and a description of the vulnerabilities found with their level of impact on security.
• ID.RA-08 (both): monitor at least the channels of CSIRT Italia and any sector CERTs and ISACs; resolve vulnerabilities promptly through security updates or mitigations, or accept and document the risk in the risk treatment plan; keep a vulnerability management plan, approved by the management bodies, that sets how vulnerabilities are identified under ID.RA-01 and how those activities are scheduled. Essential entities also monitor the channels of the suppliers of critical software.
• ID.IM-01, points 3 and 4 (essential only): a plan to assess the effectiveness of the risk-management measures, stating which measures are assessed and how, with periodic reports to the management bodies.
• PR.PS-02, point 4 (essential only): updates to critical software are verified in a test environment before production, in line with the risk assessment.

Two details change how you plan. “For at least the relevant systems” lets you limit ID.RA-01 point 2 to the systems whose compromise would significantly affect the services for which you are in scope (ACN FAQ MSB.7), so the list of relevant systems has to exist first. And ID.RA-01 point 2 is one of the requirements that, if not implemented for documented regulatory or technical reasons, must be covered by compensating measures described in the risk treatment plan approved by the management bodies (ID.RA-06, point 2, and table 2 of Allegato 2).

Determinazione 379907/2025 sets two clocks, both running from the date the entity received the communication of its inclusion in the list of NIS entities (art. 3):

• Baseline security measures (Allegati 1 and 2): 18 months. For entities listed in 2025, ACN's NIS pages place this in October 2026.
• Notification of baseline significant incidents (Allegati 3 and 4): 9 months, which ACN places in January 2026 for entities listed in 2025.

Determinazione ACN 127434/2026, applying from 30 April 2026, sets fixed dates for entities listed for the first time during 2026: security measures by 31 July 2027, incident notification obligations from 1 January 2027. Entities listed in 2025 that remain on the 2026 list keep the original terms.

Essential and important entities share the same deadline; what differs is the annex they must implement. For an essential entity listed in 2025, the first periodic VA/PT cycle on relevant systems, its reports and the board-approved vulnerability management plan should therefore already be in place, and new systems going into production need their pre-production test from now on.

It helps to separate the text from the folklore before you size a testing budget.

Written in the rules:

• Every NIS2 entity: vulnerability handling and disclosure, and policies and procedures to assess the effectiveness of measures (Art. 21(2)(e) and (f)).
• Entities under Regulation 2024/2690: a security testing policy with scope, frequency and type set by the risk assessment; documented results with criticality and mitigation per finding; vulnerability scans at planned intervals where appropriate, with recorded evidence; independent reviews.
• Italian essential entities: vulnerability assessment and/or penetration testing of at least relevant systems, periodically and before production, documented in reports; an effectiveness assessment plan.
• Italian important and essential entities: a board-approved vulnerability management plan and prompt remediation or documented risk acceptance.

Not written anywhere in these texts:

• An annual penetration test as a universal NIS2 obligation.
• A fixed frequency for scans or tests. “Periodically” and “at planned intervals” mean the interval you set and justify.
• An obligation to use an external tester or a certified one. Regulation 2024/2690 requires audit competence and independence for the independent review, not for each test.
• Threat-led red teaming or TLPT. That is a DORA instrument for designated financial entities; see TLPT under DORA.

The risk-based parts are not softer. When a regulation lets you choose the frequency, an inspector checks that the choice is written down, follows from your risk assessment, and was actually applied.

A vulnerability assessment enumerates known weaknesses across many systems and rates them. A penetration test tries to exploit weaknesses, chains them, and shows what an attacker can actually reach. The ACN text accepts either (“and/or”), so the choice belongs in the vulnerability management plan, with reasons. A structure that is easy to defend:

1. Start from the list of relevant systems. Without it you cannot use the “at least relevant systems” scope, and your coverage cannot be measured.
2. Vulnerability assessment across all relevant systems at an interval set by your risk assessment, plus after significant changes and when new vulnerabilities affecting your stack are published through the channels you monitor.
3. Penetration testing where exploitability is the question: internet-facing services, remote access, identity infrastructure and the systems that support the services for which you are in scope. Test from outside and from inside with the access of a standard user; see black-box vs gray-box testing.
4. Pre-production tests for new relevant systems and major releases, as ID.RA-01 point 2 requires for essential entities.
5. Re-tests after remediation, so each finding closes with evidence rather than a ticket status.

If you decide that a system cannot be tested, for example a fragile OT component, write down the regulatory or technical reason and the compensating measures in the risk treatment plan; that is the route the ACN annexes provide.

ACN's FAQ MSB.11 lists the document types that support the implementation of the measures: lists, inventories, plans, policies, procedures and registers, kept current and available on paper or digitally. For testing and vulnerability management, the file usually needs:

• The vulnerability management plan (ID.RA-08, point 3) with the board approval, showing how vulnerabilities are identified and how testing is scheduled.
• The list of relevant systems and the reasoning behind it.
• VA/PT reports with, at minimum, a description of the activities, their outcome, and each vulnerability with its security impact (ID.RA-01, point 3, for essential entities).
• Records of pre-production tests for systems that went live after the deadline.
• The monitoring record of CSIRT Italia, sector CERT and ISAC channels, and of critical software suppliers for essential entities.
• Remediation records: vulnerability, decision (fix, mitigate or accept), owner, dates, re-test result, and every risk acceptance in the board-approved risk treatment plan.
• For essential entities, the effectiveness assessment plan and the periodic reports to the management bodies (ID.IM-01).
• For entities under Regulation 2024/2690: the security testing policy, the documented methodology, and per-finding criticality and mitigation (point 6.5.2).

The gaps in such a file are covered in the art. 38 sanctions playbook; the wider decree is explained in D.Lgs. 138/2024 explained.

An autonomous AI red team for networks and infrastructure does not decide your frequency, does not approve your plans, and is not the independent review that Regulation 2024/2690 describes. What it changes is how much testing evidence exists between one report and the next.

• VA and PT in one campaign. Black-box campaigns from outside and gray-box campaigns with standard-user access, run on a schedule and after changes, find vulnerabilities and try to exploit them, so each finding says whether it was proven exploitable in your environment.
• Re-test on demand. Each fix can be checked with the same proof that found it, which closes the remediation record ID.RA-08 asks for.
• Framework mapping. The engine maps findings to the NIS2 Art. 21(2)(e) and (f) controls among the 34 frameworks it supports, and exports compliance reports. It does not map to ACN measure codes; linking its reports to ID.RA-01, ID.RA-08 and ID.IM-01 stays in your documentation.
• Human approval of risky steps. Five autonomy levels define what waits for a person, from approval of any active scan at the lowest level to no approval gates at the highest, which is chosen deliberately. Exploit proofs of concept can be held for operator review. See human in the loop.
• Records that hold up. Every attack attempt is an Ed25519-signed entry in a SHA-256 hash chain per campaign, verifiable offline, so the testing record shown to ACN can be shown to be unaltered.
• No customer data leaves the appliance. Findings about exploitable systems are exactly what an attacker wants. Models run on the appliance, with no external AI service; in air-gapped mode it also stops public-source downloads. See on-premise AI red team.

• Directive (EU) 2022/2555 (NIS2), Arts. 21, 32 and 33 (EUR-Lex)
• Commission Implementing Regulation (EU) 2024/2690, Annex points 2.3, 6.5, 6.10 and 7 (EUR-Lex)
• D.Lgs. 4 settembre 2024, n. 138, art. 24 (Normattiva)
• ACN: modalità e specifiche di base, deadlines and annexes (acn.gov.it)
• Determinazione ACN 379907/2025, baseline specifications (PDF, acn.gov.it)
• Allegato 1, baseline measures for important entities (PDF, acn.gov.it)
• Allegato 2, baseline measures for essential entities (PDF, acn.gov.it)
• Determinazione ACN 127434/2026, terms for entities listed in 2026 (PDF, acn.gov.it)
• ACN FAQ: security measures and incident notification (acn.gov.it)
• ACN FAQ: monitoring, supervision and enforcement (acn.gov.it)