Most organisations running annual penetration tests believe they are meeting their regulatory obligations. In many cases, they are meeting some of them, some of the time. The testing requirements across PCI DSS, DORA, ISO 27001, and NIS 2 are not identical, and a penetration test designed to satisfy one framework does not automatically satisfy the others.
Understanding what each framework actually requires, and where a single well-designed engagement can satisfy multiple obligations simultaneously, is how organisations build testing programmes that are both compliant and efficient.
PCI DSS: Annual Testing with Specific Scope Requirements
PCI DSS requires penetration testing of the cardholder data environment at least annually and after any significant infrastructure or application change. The test must cover both network and application layers, must attempt to exploit identified vulnerabilities rather than simply enumerate them, and must specifically validate whether segmentation controls used to reduce scope are effective.
The segmentation testing requirement is the most commonly missed element. A standard penetration test that does not attempt to cross the segmentation boundary does not satisfy this requirement. PCI DSS v4.0 strengthened this further, requiring segmentation validation at least every six months for organisations using it to reduce scope. A segmentation control that has never been tested under adversarial conditions is an assumption, not a control.
DORA: Testing Within an ICT Risk Governance Framework
DORA requires all in-scope financial entities to conduct vulnerability assessments and penetration testing as part of their ICT risk management framework. Unlike PCI DSS, DORA does not mandate a fixed annual cadence. The frequency and depth of testing must instead be determined through a targeted risk analysis, with the organisation documenting its reasoning for the approach chosen.
For entities not yet designated for Threat-Led Penetration Testing, structured penetration testing forms the primary technical testing requirement under DORA. What distinguishes DORA from other frameworks is the governance obligation: testing findings must feed into the ICT risk management framework, be reviewed at management level, and drive documented remediation. A penetration test that produces a report that is not formally integrated into the risk and governance process does not satisfy DORA’s intent.
ISO 27001: Testing as Part of Ongoing Control Effectiveness
ISO 27001:2022 does not mandate penetration testing in explicit terms, but it requires organisations to test, monitor, and review the effectiveness of their information security controls on an ongoing basis. Technical vulnerability management and the assessment of information security risks are embedded requirements, and a Statement of Applicability that excludes technical security testing without strong justification is unlikely to survive audit scrutiny.
The more important ISO 27001 requirement is the feedback loop. Testing findings must inform the risk assessment and treatment process. Controls that testing reveals as ineffective must be updated, and the risk register must reflect what has been learned. The standard is not satisfied by running a test and filing the report. It is satisfied when the test drives measurable improvement in the control environment.
NIS 2: Proportionate Testing for Essential and Important Entities
NIS 2 requires essential and important entities to implement appropriate and proportionate technical and organisational measures to manage cybersecurity risks. Regular security testing, including penetration testing, is an expected component of a mature programme under this standard. Competent authorities assessing NIS 2 compliance will examine whether a structured testing programme exists and whether findings are used to improve security posture.
The proportionality principle means the depth and frequency of testing should reflect the organisation’s risk profile, sector criticality, and the nature of the services it provides. Entities in critical infrastructure sectors will face higher expectations than those in lower-risk categories. What matters is that the testing programme can be demonstrated as deliberate, risk-based, and acted upon.
Where One Test Can Satisfy Multiple Requirements
With the right scope, methodology, reporting structure and regulation-aware provider, a single penetration test can generate evidence that satisfies obligations across multiple frameworks simultaneously. PCI DSS segmentation validation, DORA’s governance and documentation requirements, ISO 27001’s feedback loop into the risk assessment, and NIS 2’s expectation of a proportionate programme can all be addressed within a single engagement when designed with all applicable requirements in mind from the outset.
Running separate tests for each framework is common but inefficient. Different reports, different findings, and different remediation tracks create overhead and make the overall picture of security posture harder to manage. The better approach is one engagement, designed to serve all frameworks, with reporting structured to provide the specific evidence each requires.
What to Ask Your Testing Provider
Not all penetration testing providers are equipped with sufficient regulatory-awareness to deliver against multiple regulatory frameworks simultaneously. Does the test methodology address segmentation validation for PCI DSS? Does the reporting format support the governance and documentation requirements of DORA and ISO 27001? Is the tester qualified to advise on how findings map across each applicable framework? Is the remediation process designed to close the loop with risk assessments rather than simply produce a list of findings?
The quality of a penetration test is not purely a function of the technical skill of the tester. It is a function of whether the engagement is designed to generate the outcomes each framework requires. We work with organisations across financial services, gaming, healthcare, and technology to design testing programmes scoped and documented to satisfy their specific regulatory obligations. If your current programme was designed for one framework and you are now subject to others, a scoping review will identify what is missing. What frameworks does your penetration testing programme need to satisfy, and are you confident it currently does?
Is Your Penetration Testing Programme Built for Every Framework You’re Subject To?
Most testing programmes were designed with one framework in mind. Kyte Global designs penetration testing engagements that generate audit-ready evidence across PCI DSS, DORA, ISO 27001, and NIS 2 simultaneously, one engagement, all obligations covered.
Book a free scoping consultation to find out what your current programme is missing.
