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.”
Where testing is implied rather than named
ISO 27001:2022 does not explicitly require penetration testing, but it does require organisations to identify technical vulnerabilities, assess the effectiveness of security controls, and treat the risks they uncover. In practice, this means most organisations seeking certification will need penetration testing as evidence that their controls work. The standard is outcome based rather than prescriptive, leaving organisations to choose the most appropriate method for validating their security. For environments that include internet facing systems, web applications, or sensitive data, vulnerability scanning alone is rarely enough to demonstrate effective control.
The expectation for penetration testing is driven by clauses covering risk assessment, control effectiveness, internal audit, and management review, together with Annex A controls for managing technical vulnerabilities and security testing. Auditors look for clear evidence that technical risks have been identified, tested, remediated, and retested where necessary. As a result, most organisations combine regular vulnerability scanning with at least annual penetration testing, and additional testing after significant system changes. While ISO 27001 never states that penetration testing is mandatory, it has become the recognised and auditor accepted way to demonstrate compliance for the vast majority of certification scopes.
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.
How CommSec approaches penetration testing for compliance
CommSec’s penetration testing team is made up of CREST accredited consultants, and we are an ISO 27001 certified organisation. We help organisations identify and remediate security weaknesses while demonstrating compliance with recognised frameworks and regulations, including NIS2, DORA, ISO 27001, Cyber Essentials, PCI DSS, and industry specific standards. Every penetration test provides independent, expert validation of your security controls, helping you reduce cyber risk, satisfy audit requirements, and strengthen your overall security posture.
Every engagement is tailored to your environment and business objectives, with findings prioritised by real world risk and business impact. Our reports provide clear, actionable remediation guidance and can be used as evidence for audits, compliance programmes, cyber insurance, and customer assurance activities. Where appropriate, we provide remediation validation and retesting to confirm vulnerabilities have been resolved, giving you a complete audit trail and greater confidence in your security posture.