July 9, 2026
Updated: November 5, 2026
A practical guide to using authorized penetration testing to support NIS2 Article 21 readiness, vulnerability management, remediation evidence, supplier risk review, and board reporting.
Mohammed Khalil
NIS2 penetration testing is authorized security testing that produces evidence for the cybersecurity risk-management measures the NIS2 Directive requires, but it is only one part of compliance. NIS2 requires essential and important entities to implement at least the ten Article 21(2) measures, have their management bodies approve and oversee them, and report significant incidents in stages within 24 hours, 72 hours and one month. This guide gives you the full NIS2 requirements checklist, the reporting timeline and the current transposition status, then shows where testing adds evidence and where it does not.
Figure 1: NIS2 penetration testing readiness workflow.
Penetration testing supports NIS2 compliance readiness by validating whether relevant technical controls work under authorized, documented, and risk-based testing. A test can uncover exploitable weaknesses in web applications, APIs, cloud environments, networks, identity systems, and supplier-connected interfaces. The output is not a legal compliance certificate; it is evidence: scope, rules of engagement, findings, remediation tickets, retest results, and executive summaries. This evidence can support Article 21 risk-management discussions, vulnerability handling, control effectiveness assessment, incident readiness, and board reporting. It should be used alongside governance, policies, supplier management, incident reporting processes, training, and Member State legal requirements.
U.S. defense contractors face a different, assessment-based regime under CMMC.
For Italy, see Penetration Testing Services in Italy; for Germany, see Penetration Testing Services in Germany. For a broader German shortlist that includes product vendors and managed SOC providers, see the top cybersecurity companies in Germany.
NIS2 penetration testing is authorized security testing designed to help an organization validate technical controls that are relevant to NIS2 readiness. It is not a separate NIS2 certification, a regulator stamp, or a substitute for legal compliance review. It is a controlled way to test whether critical systems can resist realistic attack paths and whether remediation processes produce reliable evidence. The financial stakes echo the GDPR regime, where the GDPR fines statistics track penalties into the hundreds of millions. Under NIS2 itself, Article 34 of the Directive requires Member States to allow maximum fines of at least EUR 10 million or 2% of total worldwide annual turnover (whichever is higher) for essential entities, and at least EUR 7 million or 1.4% for important entities, for breaches of the Article 21 risk-management and Article 23 reporting obligations.
For a NIS2-focused program, the scope usually centers on systems that support important services: internet-facing assets, web applications, APIs, cloud accounts, identity infrastructure, internal networks, supplier interfaces, backup and recovery systems, and high-impact business processes. The objective is not to test everything. The objective is to test the right systems with clear authorization, safe rules of engagement, and evidence that can support governance decisions.
A strong NIS2 penetration testing program should connect findings to business risk. A critical API authorization flaw, for example, is not only a technical bug. It may affect vulnerability handling, access control, supplier data exchange, incident readiness, and board reporting. The value of the test comes from linking technical evidence to risk-management measures and remediation decisions. Dutch entities under NIS2 can compare penetration testing companies in the Netherlands.
The safest answer is: NIS2 does not make a single penetration test a complete compliance requirement for every organization. NIS2 requires covered entities to apply appropriate and proportionate cybersecurity risk-management measures. Penetration testing is a practical method for assessing the effectiveness of relevant technical controls, but exact obligations can depend on Member State implementation, sector rules, competent authority guidance, contracts, and the organization’s risk profile. Member States had to transpose NIS2 by 17 October 2024, and on 8 July 2026 the European Commission referred Ireland, Spain, France and the Netherlands to the EU Court of Justice for not notifying full transposition (the Dutch Cyberbeveiligingswet has since entered into force on 15 August 2026). Check the status of the national law that applies to you.
For specific digital or ICT service providers (DNS service providers, TLD name registries, cloud computing, data centre and content delivery network providers, managed service and managed security service providers, online marketplaces, online search engines, social networking platforms and trust service providers), Commission Implementing Regulation (EU) 2024/2690 is a binding NIS2 implementing act adopted under Article 21(5) that sets the technical and methodological requirements for the Article 21(2) measures. Point 6.5 of its Annex requires these entities to establish, implement and apply a policy and procedures for security testing, to decide the need, scope, frequency and type of tests based on their risk assessment, to test according to a documented methodology, to document results, and to apply mitigating actions for critical findings. It does not mandate penetration testing specifically; the test type follows from the risk assessment. National transposition details and sector authority guidance must still be verified against the official text before relying on them for procurement. UK organizations fall under the UK's own NIS regime (the NIS Regulations 2018, as amended) rather than NIS2, and the Cyber Essentials requirements belong to a separate UK scheme.
| Question | Answer | What to check |
|---|---|---|
| Is penetration testing mandatory under NIS2? | Not universally from the directive text alone. Penetration testing can support risk-management and effectiveness assessment, but obligations vary by sector and Member State. For certain digital providers, Implementing Regulation (EU) 2024/2690 requires a risk-based security-testing policy, though not penetration testing specifically. | Directive (EU) 2022/2555, Implementing Regulation (EU) 2024/2690 where it applies, national transposition law, competent authority guidance, and sector-specific rules. |
| Can penetration testing support Article 21? | Yes. It can help validate technical measures related to secure systems, vulnerability handling, access control, supplier interfaces, and control effectiveness. | Exact Article 21 wording and any official guidance explaining effectiveness assessment or security testing expectations. |
| Is vulnerability scanning enough? | Scanning is useful but may not validate business logic, exploit chains, identity paths, or cloud attack paths. High-risk systems often require deeper assessment. | Sector guidance, internal risk assessment, contracts, insurer requirements, and competent authority expectations. |
| Does testing prove compliance? | No. Testing is evidence for specific controls and remediation, not proof of complete NIS2 compliance. | Legal/compliance counsel and audit expectations. |
| Can suppliers be tested? | Only with explicit authorization. Otherwise, test organization-controlled interfaces and require supplier evidence. | Contracts, supplier security clauses, and written permission. |
Penetration testing matters because it turns policy assumptions into evidence. NIS2 readiness is not only about having security documents. Security leaders must be able to show that controls are implemented, issues are found, risks are prioritized, and remediation is tracked.
Article 21 is the main place where security testing becomes relevant to NIS2 readiness. Penetration testing should be framed as a control validation and evidence activity, not as a full compliance substitute. The table below maps common Article 21 themes to practical testing support.
Figure 2: Article 21 themes that security testing can support. The diagram is a compliance-support visual, not legal advice.
| Article 21 Theme | How Testing Can Support It | Evidence to Preserve | Caveat |
|---|---|---|---|
| Risk analysis and security policies | Findings can update risk registers and validate whether policies are reflected in actual systems. | Scope, tested systems, risk ratings, policy references, remediation plan. | Testing informs risk analysis; it does not replace it. |
| Incident handling | Controlled scenarios can validate detection, escalation, and response coordination. | Scenario summary, timeline, alerts, lessons learned, action owners. | Full incident readiness also needs tabletop exercises, training, and process review. |
| Business continuity and crisis management | Testing can validate whether security weaknesses could affect service continuity and whether recovery controls are protected. | Recovery validation notes, backup access review, resilience gaps, retest evidence. | Do not run disruptive tests on critical systems without specific approval. |
| Supply chain security | Assess organization-controlled supplier interfaces, APIs, federated identity, remote access, and data flows. | Supplier interface scope, approvals, findings, vendor evidence, risk decisions. | Do not test third-party systems without written permission. |
| Secure acquisition, development, and maintenance | Web, API, mobile, and cloud testing can validate secure development and deployment controls. | Release scope, test report, remediation tickets, secure SDLC evidence. | Testing should complement code review, architecture review, and change management. |
| Vulnerability handling and disclosure | Findings, prioritization, remediation, and retesting can show an operating vulnerability handling cycle. | Tickets, severity model, fix evidence, retest results, risk acceptance records. | Unfixed findings should be tracked, not hidden. |
| Effectiveness assessment | Penetration testing can assess whether selected technical controls resist realistic attack paths. | Methodology summary, control validation notes, executive summary, limitations. | A point-in-time test is not continuous assurance. |
| Access control and MFA | Identity testing can validate privileged access, segmentation, MFA enforcement, and account hygiene at a high level. | Test accounts, authorization, access-control findings, remediation evidence. | Avoid operational attack detail in public content. |
| Cryptography and secure communication | Configuration review can identify weak TLS, exposed keys, poor certificate handling, or insecure communication paths. | Configuration evidence, findings, remediation notes. | Deep cryptographic review may require specialist assessment. |
NIS2’s core requirements sit in a few articles of Directive (EU) 2022/2555. Article 21(1) requires essential and important entities to take appropriate and proportionate technical, operational and organizational measures to manage the risks to their network and information systems. Article 21(2) lists the ten measures those must include at a minimum, based on an all-hazards approach. Article 20 requires management bodies to approve the measures, oversee their implementation and follow training, and Article 23 sets the incident reporting deadlines covered in the next section. Proportionality matters: the measures should reflect the entity’s exposure to risk, its size, and the likelihood and severity of incidents.
The NIS2 checklist below quotes each Article 21(2) point and adds three practical columns: what to have in place, where an authorized penetration test or related security test can provide evidence, and what testing cannot show on its own. Use it as a starting point for a gap analysis, not as a legal opinion. National transposition laws can add detail. For DNS, cloud, data centre, managed service and other digital providers, Implementing Regulation (EU) 2024/2690 sets the technical requirements, and ENISA’s technical implementation guidance (June 2025) adds examples of evidence. Financial entities covered by DORA follow DORA’s ICT risk and testing rules instead of the NIS2 risk-management measures.
| Article 21(2) measure | What to have in place | Where testing provides evidence | What testing cannot show |
|---|---|---|---|
| (a) Policies on risk analysis and information system security | An approved risk-analysis method, a risk register and an information security policy. | Validated findings give the risk register real likelihood and impact data; the test scope shows which critical systems were assessed. | Whether the policy is approved, current and owned. |
| (b) Incident handling | Detection, triage, escalation and response procedures, with logging that supports them. | Red team, purple team or detection-focused tests show whether test activity was detected, escalated and contained, with timestamps. | Whether real incidents are classified and reported correctly; tabletop exercises and process review cover that. |
| (c) Business continuity, such as backup management and disaster recovery, and crisis management | Backup, restore, disaster recovery and crisis plans, with recovery that has been tried. | Testing can check whether backup systems and recovery consoles can be reached or changed from a compromised account. | Whether recovery meets time objectives; that needs restore and disaster recovery exercises. |
| (d) Supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers | A supplier inventory, supplier risk assessments and security clauses in contracts. | Tests of organization-controlled supplier interfaces, APIs, federated identity and remote access paths; supplier test reports requested under contract. | The supplier’s own security, unless the supplier authorizes testing in writing. |
| (e) Security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure | A secure development lifecycle, patch management, a vulnerability handling process and a disclosure channel. | Web, API, cloud and infrastructure findings, remediation tickets and retest results show the vulnerability handling cycle working. | Whether a public disclosure channel exists and is answered. |
| (f) Policies and procedures to assess the effectiveness of cybersecurity risk-management measures | An assessment plan with metrics, audits and a testing schedule. | A penetration test is a direct effectiveness assessment of selected technical controls; methodology, scope and limitations are the evidence. | The effectiveness of non-technical measures such as governance and training. |
| (g) Basic cyber hygiene practices and cybersecurity training | A hygiene baseline (patching, hardening, least privilege) and training records. | Configuration findings show hygiene gaps; authorized social engineering tests can show whether training changes behavior. | Training completion and the quality of training content. |
| (h) Policies and procedures regarding the use of cryptography and, where appropriate, encryption | A cryptography policy, key management and approved protocols. | TLS and configuration review, exposed keys or secrets, and weak protocols on the tested systems. | Key management governance and the completeness of the cryptographic inventory. |
| (i) Human resources security, access control policies and asset management | Joiner, mover and leaver processes, access reviews and an asset inventory. | Identity and internal tests show privilege escalation paths, stale accounts and segmentation gaps; external discovery shows assets missing from the inventory. | HR screening, contract terms and whether the asset register is complete. |
| (j) The use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate | MFA coverage, secured communications and an out-of-band emergency channel. | Tests can confirm whether MFA is enforced on tested logins and remote access, and whether older sign-in paths skip it. | Whether emergency communications work during a crisis; exercises test that. |
Four related obligations sit around the ten measures and are easy to miss in a compliance checklist:
Measures (e), (f) and (i) are where testing evidence is strongest, because they ask whether technical controls actually work. If you need that evidence for a NIS2 gap analysis, DeepStrike’s penetration testing services cover web applications, APIs, cloud environments, networks and identity systems, with remediation validation after fixes. Mapping the findings to your national obligations still belongs with your legal and compliance team.
Article 23 requires essential and important entities to notify their CSIRT or, where applicable, their competent authority without undue delay of any significant incident. An incident is significant if it has caused or can cause severe operational disruption of the services or financial loss for the entity, or if it has affected or can affect other people or organizations by causing considerable material or non-material damage (Article 23(3)). Where appropriate, entities must also tell the recipients of their services about significant incidents likely to affect those services. Article 23(4) then sets a staged timeline:
| Stage | Deadline | What it must contain | How testing and exercises prepare you |
|---|---|---|---|
| Early warning | Without undue delay and in any event within 24 hours of becoming aware of the significant incident | Where applicable, whether the incident is suspected of being caused by unlawful or malicious acts and whether it could have a cross-border impact. | Detection-focused tests and exercises measure how quickly an alert becomes a decision that the 24-hour clock has started. |
| Incident notification | Without undue delay and in any event within 72 hours of becoming aware | An update of the early warning and an initial assessment of severity and impact, with indicators of compromise where available. | Purple team exercises rehearse collecting indicators and scoping affected systems under time pressure. |
| Intermediate report | On request of the CSIRT or competent authority | Relevant status updates. | Clear incident ownership and logging, checked in tabletop exercises. |
| Final report | No later than one month after the incident notification | A detailed description with severity and impact; the likely threat type or root cause; applied and ongoing mitigation; cross-border impact where applicable. | Root-cause analysis and retest evidence show that the mitigation worked. |
| Progress report | If the incident is still ongoing when the final report is due | Progress at that time, followed by a final report within one month of handling the incident. | Remediation tracking and retesting of the affected systems. |
Figure 4: The NIS2 incident reporting timeline under Article 23(4).
Two details are often missed. Trust service providers must send the incident notification within 24 hours, not 72, for significant incidents that affect their trust services. And the CSIRT or competent authority should respond to an early warning without undue delay and, where possible, within 24 hours, with initial feedback and, on request, guidance on mitigation (Article 23(5)). National laws set the reporting channel, forms and any added detail, so put the national contact points in your incident response plan before you need them.
Penetration testing and incident reporting meet in one practical place: the rules of engagement. A test is not an incident, but testers sometimes find signs of a real, earlier compromise. Agree in advance that testing stops and the evidence goes to your incident lead, who decides whether the event is a significant incident under your national law. Exercises such as purple teaming are a safer way to rehearse the 24-hour decision, because they test detection and escalation with the defenders involved.
Article 41 required Member States to adopt and publish their national NIS2 measures by 17 October 2024 and to apply them from 18 October 2024. Many missed that date. On 7 May 2025, the European Commission sent reasoned opinions to 19 Member States for failing to notify full transposition. On 8 July 2026, it referred Ireland, Spain, France and the Netherlands to the Court of Justice of the EU and asked for financial sanctions, while noting that most Member States had complied. For Spanish organizations, our comparison of cybersecurity companies in Spain covers the ENS and NIS2 context for choosing a provider.
Our check on 4 November 2026: the Commission’s NIS2 transposition page links to a page for each Member State and describes its content as a state of play based on information provided by Member States, without prejudice to the Commission’s formal assessment of compliance. The page showed a last update of 1 July 2025. We could not confirm a current country-by-country status from the Commission or ENISA, and independent trackers disagree with each other, so this guide does not publish a country table. Treat any status table you find as a lead to confirm with the national authority, not as the answer. For one worked national example, our guide to penetration testing companies in Lithuania covers NKSC, the amended Law on Cyber Security and its three-year audit cycle.
What to do instead:
| Testing Area | NIS2 Readiness Value | Typical Scope | Output Evidence |
|---|---|---|---|
| External attack surface | Validates exposure of public services and remote access paths. | Domains, public IPs, VPN, email gateways, exposed cloud services. | External test report, asset list, remediation tickets. |
| Web applications | Supports secure development, access control, and vulnerability handling. | Customer portals, admin panels, authentication flows, business logic. | Web application findings mapped to remediation actions. |
| APIs | Validates authorization, tenant isolation, data exposure, and supplier integrations. | REST, GraphQL, mobile backends, partner APIs, API gateways. | Endpoint coverage, access-control findings, retest evidence. |
| Cloud environments | Validates IAM, storage exposure, network boundaries, logging, and configuration risk. | AWS/Azure/GCP accounts, containers, serverless, storage, CI/CD, secrets. | Cloud configuration findings and risk-based remediation plan. |
| Identity and access | Assesses privileged access risk, MFA enforcement, identity misconfiguration, and lateral exposure. | AD, Entra ID, SSO, privileged groups, service accounts, remote access. | Identity attack-path summary and access-control remediation evidence. |
| Internal network | Tests segmentation and exposure after an assumed foothold, within safe rules of engagement. | Internal subnets, sensitive servers, segmentation boundaries, management interfaces. | Internal risk summary and segmentation findings. |
| Supplier-connected systems | Validates trust boundaries controlled by the organization. | APIs, federation, VPN, remote support, data exchange interfaces. | Supplier interface findings and approval records. |
| Red team and incident readiness | Assesses detection, escalation, containment, and business impact in controlled scenarios. | Approved objectives, critical paths, detection use cases, incident workflow. | Executive scenario report and lessons learned. |
| Remediation retesting | Confirms whether high-risk findings were fixed and documented. | Original findings, affected systems, retest window, closure criteria. | Retest report, closure evidence, unresolved-risk notes. |
NIS2 distinguishes between essential and important entities, but the final classification depends on the directive, national implementation, sector, size thresholds, and competent authority guidance. This article cannot determine legal classification. From a testing perspective, classification should inform priority, depth, evidence, and board oversight.
| Entity / Context | Testing Priority | Why It Matters | Caveat |
|---|---|---|---|
| Essential entities | High for critical services and exposed systems. | Disruption can affect health, energy, transport, water, digital infrastructure, and other critical services. | Confirm classification under national law. |
| Important entities | Risk-based and proportionate. | Systems may still handle sensitive data or support major services, but supervisory expectations may differ. | Do not under-scope because the entity is not classified as essential. |
| Digital infrastructure and cloud providers | High for tenant boundaries, IAM, availability, logging, and supplier risk. | A weakness can affect many customers and downstream organizations. | Implementing Regulation (EU) 2024/2690 requires a risk-based security-testing policy for listed provider types (including cloud, data centre, CDN, managed service and managed security service providers); confirm your category. |
| Healthcare | High for patient safety, medical systems, and sensitive personal data. | Operational disruption can have real-world impact. | Coordinate testing windows and safety controls carefully. |
| Energy and utilities | High for OT/IT boundaries, remote access, resilience, and recovery. | Failures can affect continuity of essential services. | OT testing requires specialized safety controls and often lab/staging environments. |
| Financial services | High, especially where DORA also applies. | Financial entities may face digital operational resilience testing expectations beyond NIS2. | Do not assume DORA frequency or TLPT obligations without verifying applicability. |
| Manufacturing and supply chain | Medium to high based on criticality and dependence. | Operational downtime, supplier connections, and legacy systems are common risks. | Scope around production safety. |
A NIS2-focused test should prioritize systems that affect critical services, operational continuity, regulated data, supplier trust boundaries, and management oversight. The goal is not maximum coverage at any cost; it is risk-based validation with clear evidence.
| System / Asset | Why It Matters for NIS2 | Recommended Validation Approach | Evidence to Collect |
|---|---|---|---|
| Internet-facing systems | They are often the first attack surface and can expose critical services. | External attack-surface validation within approved scope. | Asset inventory, findings, remediation records, retest results. |
| Web applications | They may contain customer data, admin functions, and critical workflows. | OWASP-aligned web application testing focused on authentication, authorization, business logic, and configuration. | Findings, screenshots or safe proof, affected URLs, remediation tickets. |
| APIs and integrations | APIs often connect mobile apps, suppliers, internal systems, and customer portals. | API security testing focused on authorization, data exposure, rate limits, tenant isolation, and integration boundaries. | Endpoint inventory, access-control findings, retest evidence. |
| Cloud accounts and workloads | Cloud misconfiguration can expose data, identity paths, or service availability. | Cloud configuration and attack-path review within provider rules. | IAM findings, storage exposure checks, logging review, remediation notes. |
| Identity systems | Identity compromise can affect access control, lateral movement, and incident response. | High-level identity attack-path validation, privileged access review, MFA enforcement review. | Identity risk map, privilege findings, policy gaps, fix evidence. |
| Internal networks | Segmentation weaknesses can increase blast radius after compromise. | Internal network and segmentation validation with non-disruptive methods. | Segmentation findings, affected zones, remediation actions. |
| Supplier interfaces | NIS2 emphasizes supply chain security, but third-party systems require approval. | Test organization-controlled interfaces and review supplier evidence. | Approvals, interface test results, supplier assurance artifacts. |
| Backup and recovery systems | Ransomware and destructive incidents can affect continuity. | Access-control and recovery-readiness review without destructive testing. | Recovery validation notes, backup access review, closure actions. |
| Logging and monitoring | Evidence of detection and response helps management understand control effectiveness. | Detection-control validation through approved signals and safe scenarios. | Alert records, detection gaps, response notes. |
| OT/ICS where applicable | Operational environments can affect safety and availability. | Specialized, non-disruptive OT testing in lab/staging or controlled windows. | OT-specific risk notes, safety approvals, remediation plan. |
| Scope Item | What to Define | Why It Matters |
|---|---|---|
| Business objective | Critical service, board concern, compliance driver, or risk scenario. | Keeps testing tied to real NIS2 readiness goals. |
| Entity classification assumption | Essential/important status and sector context. | Influences priority, evidence, and stakeholder review. |
| Jurisdiction and national implementation | Member States, competent authority guidance, sector-specific expectations. | Avoids applying generic EU wording where national law matters. |
| Critical assets | Crown-jewel systems, sensitive data, operational dependencies. | Focuses testing on systems whose compromise would matter. |
| Web and API scope | Apps, endpoints, roles, tenants, environments, API docs. | Prevents missing modern application attack surfaces. |
| Cloud and identity scope | Cloud accounts, IAM roles, SSO, MFA, privileged users. | Addresses common control failures and access paths. |
| Supplier boundaries | Owned interfaces, third-party approvals, supplier evidence. | Supports supply chain risk without unauthorized testing. |
| Operational constraints | Testing windows, exclusions, rate limits, outage risk, OT safety. | Protects production systems and critical services. |
| Rules of engagement | Allowed methods, prohibited tests, escalation, emergency stop. | Keeps testing controlled, documented, and authorized. |
| Evidence requirements | Report format, board summary, remediation tracker, retest proof. | Turns testing into compliance-supportive evidence. |
| Remediation ownership | Owners, deadlines, risk acceptance, retest window. | Prevents findings from becoming unresolved audit risk. |
The table below summarizes what to validate in each domain, why it matters for NIS2, and what evidence to keep.
| Domain | What to Validate | NIS2 Evidence Value | Safety Caveat |
|---|---|---|---|
| Web application testing | Authentication, authorization, session handling, business logic, file handling, admin paths, transport security, and logging. | Supports secure development, access control, vulnerability handling, and remediation evidence. | Avoid publishing payloads or exploit steps. |
| API testing | Endpoint inventory, object-level authorization, tenant isolation, rate limiting, token handling, data exposure, and partner integrations. | Validates critical data flows and supplier/API trust boundaries. | Use approved test tenants and safe test data. |
| Cloud testing | IAM, storage exposure, network rules, logging, secrets, CI/CD paths, containers, serverless, and provider policy compliance. | Supports control effectiveness, access control, and cloud shared-responsibility evidence. | Follow cloud provider testing policies and avoid disruptive actions. |
| Network and identity testing | External exposure, segmentation, privileged access paths, remote access, MFA enforcement, directory configuration, and logging signals. | Supports access control, cyber hygiene, incident readiness, and board-level risk visibility. | Use high-level identity attack-path validation; do not publish technique-level instructions. |
| Supplier and third-party testing | Organization-controlled interfaces, API integrations, federation, remote support, SaaS boundaries, and supplier evidence. | Supports Article 21 supply chain security and risk management. | Do not test third-party systems without written authorization. |
| Red team and incident readiness | Detection, escalation, response workflows, business-impact scenarios, and executive reporting. | Supports incident handling, control effectiveness, and crisis-readiness evidence. | Avoid phishing templates, malware simulation detail, evasion, or destructive testing guidance. |
Findings alone do not support NIS2 readiness unless they trigger remediation, ownership, and verification. A clean report with no retest can still leave the organization unable to prove that risk was reduced.
Figure 3: Evidence loop for remediation and retesting.
| Stage | What to Document | Why It Supports NIS2 Readiness |
|---|---|---|
| Planning | Scope, rules of engagement, authorization, tested systems, test dates, responsible owners. | Shows testing was controlled, approved, and risk-based. |
| Findings | Severity, affected assets, business impact, evidence, limitations, duplicate/false-positive decisions. | Creates traceable vulnerability handling records. |
| Remediation plan | Owner, due date, fix strategy, compensating controls, risk acceptance if needed. | Demonstrates accountability and governance. |
| Fix implementation | Change tickets, code/config changes, patch records, screenshots or configuration evidence. | Shows action was taken, not just reported. |
| Retesting | Original finding, retest date, outcome, residual risk, closure evidence. | Validates whether remediation worked. |
| Governance reporting | Executive summary, risk register updates, board metrics, unresolved risk. | Supports management oversight and decision-making. |
NIS2 raises the importance of management oversight. Security teams should translate technical findings into risk evidence that legal, compliance, procurement, and the board can understand.
| Evidence Type | Primary Audience | Why It Matters |
|---|---|---|
| Scope and authorization record | Compliance, legal, auditors | Shows the test was approved, bounded, and lawful. |
| Technical test report | Security, engineering, auditors | Explains affected systems, validated weaknesses, risk ratings, and remediation guidance. |
| Executive summary | Board, executives, risk committee | Converts findings into business impact, trends, decisions, and priorities. |
| Remediation tracker | Security, IT, compliance | Shows owners, deadlines, current status, and closure progress. |
| Retest results | Auditors, compliance, board | Demonstrates whether high-risk issues were actually fixed. |
| Supplier evidence | Procurement, legal, vendor risk | Supports supply chain security review without unauthorized testing. |
| Risk register updates | Risk committee, board | Connects technical weaknesses to enterprise risk and acceptance decisions. |
NIS2 overlaps with other frameworks, but the obligations are not interchangeable. A useful penetration testing report can map evidence to multiple control environments while clearly stating limitations.
| Framework | Main Focus | How Penetration Testing Supports It | Caveat |
|---|---|---|---|
| NIS2 | Cybersecurity risk-management measures for covered essential and important entities in the EU. | Provides evidence for technical control validation, vulnerability handling, remediation, supply chain security, and board reporting. | NIS2 is implemented through Member State law. Testing does not guarantee compliance. |
| ISO/IEC 27001 | Information security management system, risk treatment, and control governance. | Can support vulnerability management, technical review, secure development, and evidence for an ISMS depending on scope and controls. | Avoid relying on outdated control numbers; verify the relevant 2022 control mapping. |
| DORA | Digital operational resilience for financial entities and relevant ICT third-party risk. | Testing can support digital operational resilience evidence, with more advanced testing applying to certain entities under specific criteria. | Do not claim annual TLPT or universal advanced testing without verifying DORA applicability. |
| GDPR Article 32 | Security of personal data processing. | Testing can support evidence that relevant security measures are assessed and improved for systems processing personal data. | GDPR also requires privacy governance, legal basis, DPIAs, processor controls, and data subject rights. |
| NIST CSF | Risk governance and cybersecurity program structure. | Testing findings can inform Identify, Protect, Detect, Respond, and Recover outcomes. | NIST CSF is a framework, not EU law. |
One more EU law is worth keeping separate. The Cyber Resilience Act, Regulation (EU) 2024/2847, sets security requirements for products with digital elements rather than for the organizations that run services. Its manufacturer reporting duties for actively exploited vulnerabilities apply from 11 September 2026, and most of its obligations from 11 December 2027. If you build software or connected products and also run NIS2-covered services, see our Cyber Resilience Act guide for how the two overlap.
There is no single universal NIS2 penetration testing frequency that applies to every covered entity in every Member State. Testing cadence should be risk-based and should consider sector expectations, critical service exposure, system changes, incident history, supplier changes, customer requirements, and competent authority guidance.
| Question | Why It Matters | Strong Answer Looks Like |
|---|---|---|
| Can the provider map findings to Article 21 themes? | NIS2 evidence needs to connect technical issues to risk-management measures. | They can provide a report structure that maps findings to risk, control, remediation, and evidence categories. |
| Can they test web, API, cloud, network, and identity systems? | NIS2-relevant risk often spans multiple layers. | They can scope the relevant asset classes without forcing everything into one generic test. |
| Do they avoid compliance guarantees? | A reputable provider should not claim a pentest proves compliance. | They explain that testing supports evidence and readiness, not legal compliance guarantees. |
| Do they define rules of engagement clearly? | Unauthorized or poorly scoped testing can create legal and operational risk. | They require written authorization, scope, exclusions, contacts, and stop conditions. |
| Can they support remediation and retesting? | NIS2 readiness depends on verified improvement, not only findings. | They provide remediation-focused reporting and retest planning. |
| Can they handle supplier and cloud boundaries safely? | Third-party and cloud systems require special approvals and provider rules. | They test only authorized interfaces and respect provider policies. |
| Can they produce board-ready summaries? | Management bodies need risk decisions, not only technical evidence. | They summarize business impact, unresolved risk, and remediation status. |
| Do they verify official sources? | NIS2 interpretation can change with national implementation and guidance. | They rely on official EU, national, and standards sources, not only vendor blogs. |
| Mistake | Why It Is Risky | Safer Approach |
|---|---|---|
| Claiming one pentest proves compliance | NIS2 readiness requires governance, policies, incident handling, supplier risk, and evidence. | Frame testing as control validation and remediation evidence. |
| Testing only the public website | APIs, identity, cloud, suppliers, and internal systems may carry greater risk. | Scope based on critical services and attack paths. |
| Ignoring APIs and identity systems | Modern breaches often involve authorization and identity weaknesses. | Include API and identity attack-path validation where relevant. |
| Using operational attack language in public content | It can create safety and brand risk. | Use high-level validation language and avoid technique-level details. |
| Testing third-party systems without consent | Creates legal and contractual risk. | Obtain written approval or test only organization-controlled interfaces. |
| No retesting | Findings remain unproven fixes. | Define retesting windows and closure evidence. |
| No board reporting | Management cannot supervise what it cannot understand. | Produce executive summaries and risk register updates. |
| Relying on secondary legal sources | NIS2 obligations can be misrepresented. | Verify official EU, national, and competent authority sources. |
| Confusing NIS2 with ISO, DORA, or GDPR | Each has different scope and obligations. | Map overlaps, but preserve distinctions. |
| Claiming NIS2 certification | Can be misleading unless an official scheme is verified. | Use readiness, evidence, and compliance-support language. |
NIS2 penetration testing is authorized security testing that validates systems and controls relevant to NIS2 readiness. It can cover applications, APIs, cloud environments, networks, identity systems, supplier interfaces, and incident-readiness scenarios. It is not a legal certification or regulator approval. Its value is practical evidence: what was tested, what failed, what was fixed, and what remains risky.
NIS2 requires appropriate cybersecurity risk-management measures for covered entities. The directive should not be summarized as “every organization must run a penetration test.” Penetration testing can support control effectiveness, vulnerability handling, and remediation evidence, but exact obligations depend on national implementation, sector rules, contracts, and competent authority guidance. For certain digital providers, such as cloud, data centre, managed service and managed security service providers, Implementing Regulation (EU) 2024/2690 requires a risk-based security-testing policy, though not penetration testing specifically.
It helps show whether selected technical controls resist realistic attack paths. Findings can support vulnerability management, secure development, access control, supply chain risk, incident readiness, remediation, and board reporting. Testing should be scoped, authorized, documented, and followed by retesting where needed.
Article 21 describes cybersecurity risk-management measures for covered entities. It includes themes such as risk analysis, incident handling, business continuity, supply chain security, secure development, vulnerability handling, effectiveness assessment, cyber hygiene, access control, and secure communications. Penetration testing can support several of these themes, but does not cover all of them.
Scanning is useful for recurring checks and vulnerability management, but it may miss business logic flaws, authorization issues, identity paths, cloud attack paths, and chained weaknesses. High-risk systems often need manual security testing, architecture review, configuration review, or red team validation depending on risk.
A scope should define critical services, entity classification assumptions, jurisdiction, asset inventory, web/API/cloud/identity/supplier systems, operational constraints, rules of engagement, written authorization, evidence requirements, remediation ownership, and retesting expectations.
Testing frequency should be risk-based. Organizations often test after major changes, new exposed services, cloud migrations, supplier changes, serious incidents, or high-risk remediation. Some sectors or contracts may expect a defined cadence, but a universal NIS2 frequency should not be claimed without source verification.
No. A penetration test can produce evidence for specific controls and remediation, but NIS2 compliance also depends on governance, policies, risk management, training, incident reporting, supply chain security, business continuity, and national legal obligations.
ISO 27001 is an information security management system standard, while NIS2 is an EU directive implemented through Member State law. Testing evidence may support both risk management and control validation, but ISO certification and NIS2 legal compliance are not the same thing.
DORA applies to financial-sector digital operational resilience and includes specific testing obligations for relevant financial entities. NIS2 is broader across many essential and important sectors. For financial entities covered by DORA, DORA’s ICT risk-management and testing rules apply instead of the NIS2 risk-management obligations (NIS2 recital 28 and Article 4); groups with entities in other NIS2 sectors may still need to align testing evidence to both frameworks, while keeping their obligations distinct.
Security and engineering teams should review technical findings, while compliance, legal, risk, procurement, and management stakeholders should review evidence, unresolved risk, supplier implications, and board-level reporting. High-risk findings should have clear owners and deadlines.
NIS2 requires essential and important entities to take appropriate and proportionate cybersecurity risk-management measures, including at least the ten listed in Article 21(2): risk analysis and security policies, incident handling, business continuity and crisis management, supply chain security, secure acquisition and development with vulnerability handling, effectiveness assessment, cyber hygiene and training, cryptography, HR security with access control and asset management, and MFA with secured communications. Management bodies must approve and oversee these measures (Article 20), and significant incidents must be reported under Article 23.
For a significant incident, an early warning goes to the CSIRT or competent authority within 24 hours of becoming aware of it, an incident notification within 72 hours, an intermediate report on request, and a final report no later than one month after the incident notification. If the incident is still ongoing at that point, a progress report is due, with the final report within one month of handling the incident.
The directive does not publish a checklist, but Article 21(2) is in effect the minimum list of measures, and the checklist in this guide follows it point by point. For digital infrastructure and digital providers, Implementing Regulation (EU) 2024/2690 and ENISA’s technical implementation guidance add detailed requirements and examples of evidence. Your national law and competent authority may publish their own guidance.
NIS2 penetration testing is most valuable when it is treated as security validation and compliance-support evidence, not as a one-time checklist exercise. Authorized testing can help organizations assess whether important applications, APIs, cloud environments, networks, identity controls, supplier interfaces, and incident-readiness processes can withstand realistic attack paths. Belgian organizations sourcing a tester locally can start from our list of penetration testing companies in Belgium.
The strongest NIS2 testing programs connect scope, findings, remediation, retesting, and board reporting. They avoid claims that a clean penetration test proves compliance. They also avoid unsafe technical detail and rely on official EU, national, and sector-specific sources when discussing obligations.
DeepStrike can support authorized penetration testing, remediation validation, and evidence-focused reporting across web applications, APIs, cloud environments, networks, identity systems, and red team scenarios. Penetration testing can support NIS2 readiness conversations, but final compliance obligations should be reviewed by qualified legal, compliance, governance, and sector-specific stakeholders. Irish organizations that prefer a provider in the same jurisdiction can also compare the penetration testing companies in Ireland.
Mohammed Khalil is a Cybersecurity Architect at DeepStrike, specializing in advanced penetration testing and offensive security operations. With certifications including CISSP, OSCP, and OSWE, he has led red team and application security engagements across technology, finance, healthcare, cloud, and regulated environments. His work focuses on real-world attack path validation, application vulnerabilities, API security, cloud security, identity exposure, breach-risk reduction, and adversary emulation.
Stay secure with DeepStrike penetration testing services. Reach out for a quote or customized technical proposal today
Contact Us
