Key takeaways

• NIS2 ties penetration testing to Article 21(2)(f) through the effectiveness clause, and Implementing Regulation 2024/2690 plus the amended KSC law add concrete frequency and documentation requirements.
• Vulnerability scanning, penetration testing, and red teaming answer different questions and belong in sequence: scanning for hygiene, penetration testing for validation, red teaming for resilience.
• Scoping a hybrid-cloud penetration test requires covering five planes: external attack surface, identity, cloud control plane, interconnects, and third-party integrations.
• Financial entities designated as significant under DORA face Threat-Led Penetration Testing every three years, a regime that exceeds anything NIS2 or the KSC law requires.

NIS2 never uses the phrase “penetration test.” Yet supervisory authorities across the EU already treat penetration testing as the default way to prove compliance with Article 21(2)(f), and inspectors expect test evidence on request even when no law sets a fixed testing calendar. For CTOs, Heads of Compliance, and CISOs at essential and important entities, the distance between silence in the directive and expectation in practice is where most audit findings originate. The organizations that get this right treat testing cadence as a documented risk decision tied to the entity’s own assessment. This article works through what NIS2 and the amended KSC law require, how penetration testing differs from vulnerability scanning and red teaming, how to scope a test across a hybrid-cloud estate, what evidence survives an inspection, how to remediate findings at scale, and how DORA’s Threat-Led Penetration Testing regime changes the calculus for financial entities designated as significant.

How NIS2 and the KSC Law Regulate Penetration Testing

NIS2 is deliberately non-prescriptive. The directive never specifies a testing methodology, a frequency, or even the term penetration test. Its legal anchor is Article 21(2)(f), which obliges essential and important entities to maintain policies and procedures that assess the effectiveness of cybersecurity risk-management measures. Penetration testing has become the market-standard way to operationalize that clause, and supervisory authorities treat it that way in practice.

Three mechanisms bring specificity into a framework that starts out open-ended. The Implementing Regulation (EU) 2024/2690 binds digital infrastructure and digital service providers to security testing at a frequency set by risk assessment, backed by a documented testing policy. National transpositions add further detail: Poland’s amended KSC law requires a periodic security audit of the information systems used to deliver the regulated service, and penetration testing is the standard component of that audit. Supervisory powers add a third layer. Articles 32 and 33 let authorities order targeted security audits and scans and demand evidence on request, regardless of what any fixed calendar says.

The defensible baseline looks like this: annual penetration testing of the systems supporting essential or important services, additional testing after significant architectural change, and a written testing policy that ties scope and frequency to the entity’s own risk assessment. Where the law leaves frequency open, the burden falls on the entity to justify its own cadence. Telling an inspector that budget ran out fails to satisfy during an Article 32 review.

Vulnerability Scanning, Penetration Testing, and Red Teaming: Choosing the Right Test

A vulnerability scan is automated, broad, and shallow. Tools such as Nessus, Qualys, or cloud-native scanners enumerate known CVEs and misconfigurations across the estate, answering what weaknesses exist and leaving what an attacker can do with them to a human tester. Scanning belongs in continuous operation, or at minimum monthly, with authenticated scanning wherever the environment allows it.

A penetration test moves the work from automated enumeration to manual exploitation. Testers chain individual weaknesses into demonstrated business impact: a low-severity information disclosure combined with a weak service account can open a path through a misconfigured trust relationship that automated tools had assessed as low priority. That chaining validates real-world exploitability beyond what a scanner can demonstrate. Annual testing per critical system or environment is the standard cadence, supplemented by event-driven tests after major releases, migrations, or M&A integrations.

A red team exercise emulates a specific adversary pursuing a defined objective, such as exfiltrating a customer database or reaching a SWIFT gateway, covertly and over several weeks. Its primary product is an assessment of detection and response capability, built by testing whether the SOC notices and reacts to a live, covert attack. Running this exercise against an organization whose monitoring is immature returns limited value. That capability has to exist first. Mature organizations schedule one every one to three years, once detection capability is in place.

Building a testing program follows a natural sequence: scanning establishes hygiene, penetration testing validates that hygiene under attack, and red teaming tests resilience once both layers are operating. Each stage builds on the one before it.

Scoping a Penetration Test for Hybrid Cloud Environments

Effective scoping starts from the service, working outward to the infrastructure. The first step is identifying the critical business services, for NIS2 entities those underpinning the essential or important service designation, then mapping every asset in their delivery chain.

In a hybrid environment, that mapping needs to explicitly cover five planes that testers routinely find underrepresented in scope documents. Internet-facing applications, VPN concentrators, and exposed management interfaces make up the external attack surface. Identity is the second plane: Active Directory, Entra ID, federation, and the synchronization path between them form the most common route from a cloud foothold to an on-premises domain compromise. The cloud control plane comes third, distinct from testing the workloads themselves, and covers IAM roles, subscription and tenant configuration, and storage exposure. Fourth are the interconnects: ExpressRoute or Direct Connect links, site-to-site VPNs, and the hybrid runbooks and CI/CD pipelines that cross the boundary between environments. Third-party integrations and APIs round out the fifth plane.

Exclusions can be legitimate, provided each one carries a documented rationale and a compensating control. The hyperscaler’s underlying infrastructure sits outside scope by definition under the shared responsibility model, since major cloud providers permit testing of customer workloads but prohibit attacks on their own platform. Fragile production systems, such as legacy OT or systems with strict availability commitments, can be tested through a representative staging environment or passive techniques, with the decision recorded. Third-party SaaS requires the provider’s own authorization before testing, and vendor assurance covers that arrangement.

Excluding domain controllers or the flat internal network because they carry sensitivity produces a test of limited value, and this kind of convenience-driven scoping draws direct scrutiny during a review. A scope statement with justified exclusions is itself a compliance artifact. Supervisors read it closely.

Evidence That Satisfies NIS2 Supervisory Reviews

Supervisors assess two things: whether testing happened at adequate depth, and whether the organization acted on the results. Producing that evidence requires covering the full testing lifecycle from policy to retest.

A complete pack includes the testing policy linking scope and frequency to the risk assessment, the scope statement and rules of engagement with documented exclusions and their rationale, proof of tester competence and independence through certifications or organizational separation, the methodology reference such as OWASP, PTES, or OSSTMM, the full technical report with severity ratings and reproduction evidence, a remediation plan with named owners and deadlines, retest evidence proving closure, and formal risk-acceptance records carrying a management signature and an expiry date for anything awaiting remediation. Management-body visibility matters as much as the technical record. Article 20 makes the management body personally accountable for approving and overseeing risk-management measures, so minutes or sign-offs showing that test results reached governance level carry more weight than most CISOs assume.

National transposition sets retention periods, with the directive itself silent on specifics, but a defensible minimum is to retain records across a full supervisory cycle, in practice three years or longer, so an inspector can trace the path from finding to fix across consecutive tests. The most common evidentiary shortfall in practice sits elsewhere than report quality. It shows up as a report with critical findings and a documentation trail that stops right after delivery.

Remediating Penetration Test Findings at Scale

Two hundred findings rarely mean two hundred distinct problems, and treating them that way wastes the remediation budget. The first move is root-cause deduplication: eighty instances of the same TLS misconfiguration collapse into a single fix applied at the golden-image or IaC-template level. Organizations that cluster findings into systemic themes, such as patch management debt, identity hygiene, or network segmentation weaknesses, typically cut the workload by 60 to 70 percent and fix the underlying cause.

Re-triaging severity in the organization’s own context comes next. Tester-assigned CVSS scores are a starting point. The priority that matters in practice multiplies exploitability by asset criticality and exposure. A high-severity finding on an isolated development box carries a different weight than a medium-severity finding on an internet-facing identity provider.

Ownership and service-level agreements carry the remediation work forward. Fixing findings belongs to system and application owners, while the security team tracks progress and verifies closure. A workable SLA structure for a regulated enterprise sets critical findings at 7 to 14 days with pre-agreed emergency change paths, high findings at 30 days, medium findings at 90 days, and low findings at 180 days or through a documented risk acceptance. Every SLA breach and every risk acceptance needs an expiry date and a named accountable person, since open-ended acceptances tend to surface later as audit findings.

Running the whole process through an existing ITSM or vulnerability-management platform keeps it operational. Verifying closure by retest confirms the fix held, going beyond an owner’s declaration. Monthly reporting on a small set of metrics, SLA compliance rate, mean time to remediate by severity, and the aging tail of open findings, gives leadership the same evidence a regulator will eventually ask for.

DORA TLPT Versus Standard NIS2 Penetration Testing

NIS2 and DORA address the same underlying risk through different levels of prescription. NIS2 implies testing through the principles-based effectiveness clause covered above and leaves scope and cadence to the entity. DORA takes a more prescriptive path in two respects. Articles 24 and 25 require every financial entity to run a broad annual digital operational resilience testing program covering vulnerability assessments, scenario-based testing, and penetration testing of ICT systems supporting critical or important functions. Articles 26 and 27 add Threat-Led Penetration Testing for entities that supervisors designate as significant, and at that level discretion on scope and cadence is tightly constrained.

TLPT, operationalized through TIBER-EU-aligned regulatory technical standards, runs at least every three years against live production systems supporting critical or important functions, with no staging-environment substitution. The exercise must be intelligence-led, opening with a dedicated threat intelligence phase that profiles realistic adversaries before the red team engages. The threat intelligence provider must sit outside the organization, and testers must meet defined requirements on certification, experience, insurance, and independence. A designated TLPT authority supervises the exercise, which runs covertly against the blue team under a control-team structure and closes with a purple-team replay phase. The process ends in a formal attestation that EU authorities recognize across borders. Third-party ICT providers supporting critical functions get pulled into scope through pooled or joint testing arrangements.

For an institution subject to both regimes, DORA operates as the more specific rule for financial entities and sets the higher bar. TLPT combined with the Article 24 program covers what NIS2 implies. It exceeds it. The real compliance workload sits in planning the three-year TLPT cycle, procuring qualified testers, and coordinating with the supervisor, areas that NIS2 leaves to each entity’s discretion.

FAQ

How often does NIS2 require penetration testing?

NIS2 lets each entity’s own risk assessment set the frequency under the Article 21(2)(f) effectiveness clause. Most compliance teams settle on yearly testing of the systems tied to the essential or important service, with extra rounds after major architecture changes. Poland’s KSC law layers in its own periodic security audit requirement, and Implementing Regulation 2024/2690 sets a risk-based cadence for digital infrastructure providers.

What is the difference between a vulnerability scan and a penetration test?

Scanning is automated and broad: it flags known CVEs and misconfigurations across an environment, usually on a continuous or monthly cycle. A penetration test relies on a human tester who exploits and chains weaknesses to prove real business impact, something automated scanning leaves unproven. Most regulated entities run scans continuously in the background and schedule a full penetration test once a year for each critical system.

When should an organization run a red team exercise instead of a penetration test?

A red team exercise pays off once basic detection capability is already in place, because its purpose is testing whether the security operations center notices and reacts to a covert, objective-driven attack. Organizations that move to red teaming before their monitoring matures gain limited insight from the exercise. Those with mature detection typically run one every one to three years.

What must be included when scoping a penetration test for a hybrid cloud environment?

A thorough scope spans five planes: the internet-facing attack surface, the identity layer spanning Active Directory and Entra ID federation, the cloud control plane covering IAM and tenant settings, the interconnects joining on-premises and cloud infrastructure, and third-party integrations or APIs. Exclusions, such as the hyperscaler’s own infrastructure or fragile production systems, hold up during a review only when documented with a clear rationale and a compensating control, such as staging-environment testing.

What evidence do supervisors expect after a penetration test under NIS2?

An inspector looks for a complete lifecycle trail: the testing policy, the scope document with its exclusions explained, proof that testers were qualified and independent, the technical findings with severity ratings, a remediation plan with named owners, retest results confirming closure, and signed risk-acceptance forms with expiry dates. Evidence that results reached the management body, such as board minutes, adds significant weight under the Article 20 accountability rule.

How does DORA’s TLPT differ from standard NIS2 penetration testing?

DORA’s Threat-Led Penetration Testing only applies to financial entities that supervisors designate as significant, and it runs on a mandatory three-year cycle against live production systems under TIBER-EU-aligned rules, complete with an external threat intelligence phase and a formal attestation at the end. Ordinary NIS2 penetration testing works differently: it follows a principles-based clause that leaves scope and frequency to the entity’s own documented risk assessment.