Summary
A compliance-focused blog explaining where penetration testing sits across five frameworks. DORA and CyFun's Essential tier name it directly; NIS2, ISO 27001 and NIST require it in substance without using the term. It covers Ireland's NCSC adoption of CyFun as the preferred NIS2 compliance route, and uses the WannaCry outbreak as a real-world illustration of what happens when a known, patchable vulnerability goes untested. The blog closes with a practical recommendation: build a testing cadence now rather than waiting for a specific clause to demand it.
Every major cybersecurity framework now asks the same underlying question. Not “do you have policies,” but “can you prove your controls work.” That shift matters more than most compliance checklists let on. An organisation can hold every certificate on the wall and still be one unpatched vulnerability away from a breach notification. Penetration testing is the mechanism that closes that gap, and it is worth understanding exactly where each framework demands it, where it implies it, and why the distinction rarely matters in practice.
The WannaCry ransomware outbreak of 2017 is the clearest illustration of what happens when that gap goes untested. A self-propagating worm exploited a known Windows vulnerability, one Microsoft had already patched two months earlier, and spread to more than 300,000 computers across 150 countries within days, disrupting hospitals, manufacturers and telecoms operators along the way. The vulnerability was not a mystery. The fix already existed. What was missing, across thousands of affected organisations, was any process that would have surfaced the exposure and forced action before an attacker did it for them. That is precisely the gap every framework in this piece is now trying to close.
Where testing is written into the rulebook
DORA is the clearest case of a framework naming testing outright. Digital operational resilience testing is one of its core pillars, and Article 24(2) requires financial entities to use “a range of assessments, tests, methodologies, practices and tools” to confirm their defences hold up. In practice this splits into two tiers. Every in-scope entity needs at least annual testing of its ICT tools and systems. A smaller group of entities, those whose ICT risk profile puts them at greater exposure, must go further with threat-led penetration testing, or TLPT, at least every three years. Financial regulators can adjust that frequency up or down depending on the entity’s risk. The regulation does not hand organisations a fixed methodology. It leaves the detail to proportionality, but the expectation to test, and to test using adversarial techniques, is explicit rather than implied.
NIS2 sits close behind it, though it is drafted more carefully. Article 21(2)(f) requires essential and important entities to have “policies and procedures to assess the effectiveness of cybersecurity risk management measures.” The directive never uses the words “penetration test.” It does not need to. Regulators, ENISA’s technical guidance, and national authorities have converged on the same reading: you cannot demonstrate effectiveness of a technical control through documentation alone. For entities under continuous supervision, competent authorities are already treating pentest reports as standard evidence during audits. The absence of the specific term is not a loophole. It is simply drafting style, and every implementation guide that follows the directive treats adversarial testing as the practical answer to Article 21(2)(f).
CyFun: NIS2’s clause turned into a named control
Belgium’s (and Ireland’s adopted) CyberFundamentals framework, CyFun, is worth a closer look here, because it shows the journey from principle to practice in a single document set. CyFun is one of two recognised paths to NIS2 conformity, alongside NIST2.0 CSF, and its three assurance levels, Basic, Important and Essential, are built to scale with an organisation’s risk profile in exactly the way NIS2’s proportionality principle intends.
At Basic level, CyFun does not mention penetration testing. The obligation stops at identifying and documenting vulnerabilities, alongside baseline hygiene controls such as firewalls, MFA and logging. Move up to Important, and the 2023 version asks organisations to consider vulnerability scanning, a step closer but still short of adversarial testing. It is only at Essential level that CyFun names the exercise directly, advising organisations to “establish and maintain a testing program appropriate to its size, complexity” and to “consider validating security measures after each penetration test.” That is the first point across the three tiers where the words appear in print.
Where testing is implied rather than named
ISO 27001 takes a similar path. It does not mandate penetration testing by name anywhere in the standard, but two Annex A controls make the exercise close to unavoidable in practice. A.8.29 requires security testing throughout the development lifecycle, catching design and coding flaws before they reach production. A.12.6.1 requires organisations to obtain timely information about technical vulnerabilities and take appropriate action against them. Neither control tells you to hire a penetration tester. Both are extremely difficult to evidence convincingly without one. An auditor reviewing your ISMS will ask how you know these controls are operating as intended, and a clean scan report from an automated tool rarely satisfies that question the way a manual, hands-on test does.
NIST follows the same logic from a slightly different angle. Its Cybersecurity Framework and SP 800-53 controls describe assessment and continuous monitoring obligations rather than naming a specific test type. Where NIST is more concrete is in method. SP 800-115, the Technical Guide to Information Security Testing and Assessment, sets out the review techniques, target identification methods, and assessment planning that underpin most professional penetration testing today. It is frequently the methodology referenced by other frameworks, including PCI DSS, when they specify that testing must follow an industry-accepted standard. NIST, in other words, supplies much of the technical backbone that other, more principles-based frameworks lean on when they ask for effective testing without prescribing how.
Why the difference exists
The split between prescriptive and descriptive frameworks is not an oversight. Prescriptive standards like DORA and PCI DSS govern sectors where a breach has an immediate, quantifiable knock-on effect: payment fraud, market disruption, loss of public trust in financial infrastructure. Regulators writing those rules had the leverage and the specificity of purpose to name the control outright. Descriptive frameworks like ISO 27001, NIS2, and the NIST catalogues cover a far wider and more varied population of organisations, from small utilities to multinational manufacturers. Naming one specific test type risks becoming outdated or disproportionate for smaller entities. Proportionality language, common across NIS2 and DORA alike, exists precisely so that a mid-sized transport operator is not held to the same testing cadence as a systemically important bank. The frameworks differ in how prescriptive they are willing to be. They do not differ on the underlying expectation.
The common thread
Strip away the legal language and every one of these frameworks is asking the same three questions. Have you identified your risks. Have you implemented proportionate controls against them. Can you prove those controls are actually effective. The first two questions can be answered with documentation, risk registers, and policy statements. The third cannot. Effectiveness is an empirical claim, and empirical claims need empirical evidence. A vulnerability scan tells you what might be wrong. Only a penetration test, where a qualified tester attempts to actually exploit a weakness the way an attacker would, tells you what is genuinely exploitable and what the real business impact would be. CyFun’s progression from Basic to Essential is a useful illustration in miniature of that same pattern playing out across every framework in this piece: the closer an organisation sits to systemic risk, the less a regulator is willing to accept a control on paper without evidence that it holds under attack. That is why testing keeps reappearing across frameworks that otherwise have very little in common in scope, sector, or legal structure. It is the one form of evidence that regulators, auditors, and boards all treat as credible.
What this means in practice
For an Irish or EU organisation navigating NIS2 transposition, DORA obligations, or an ISO 27001 renewal, the practical takeaway is straightforward. Do not wait to be told the exact clause number before scheduling a test. Build a testing cadence, at minimum annual, more frequent for critical systems or after significant change, and make sure the resulting report is mapped explicitly to the controls it evidences. A report that sits in a shared drive unread is arguably worse than no test at all, since it becomes documented proof that a weakness was identified and not acted on. The frameworks are converging on adversarial testing as the standard of proof. Organisations that treat it as a genuine security exercise, rather than an annual box to tick, will find the compliance evidence follows naturally from the security work itself, not the other way around.