Many organisations buy one annual penetration test and assume it satisfies every regulator, but the rules differ on frequency, scope, who may test and what evidence must follow. PCI DSS wants internal, external and segmentation tests with retests; FedRAMP prescribes six attack vectors and an accredited assessor; DORA requires yearly testing of systems behind critical functions and, for selected firms, threat-led tests every three years; NIS2 and APRA leave frequency to your risk assessment but expect you to justify it. This map sets the requirements side by side, with status and evidence expectations, so one test calendar can satisfy several regimes. It is for security testing leads, GRC teams, CISOs and procurement. Status as of 11 November 2026; proposals are marked as proposals.
Source note: this map summarises official texts, regulator guidance and the sources listed at the end, with status as of 11 November 2026. It is not legal advice. Confirm against the official text before relying on it.
Key takeaways
- Annual is the most common floor, not the rule everywhere. PCI DSS, NYDFS, FedRAMP and DORA Article 24 set at least yearly testing; NIS2 and APRA CPS 234 require a risk-based frequency you must document.
- Change triggers matter as much as the calendar. PCI DSS requires testing after significant infrastructure or application changes, and NIS2 requires changes to be tested before implementation.
- Scope is defined by the regulation, not the supplier. FedRAMP names six attack vectors including tenant-to-tenant; PCI DSS covers the whole cardholder data environment perimeter and segmentation; NYDFS requires testing from inside and outside the boundary.
- Tester rules vary. FedRAMP requires an accredited 3PAO, CBEST and DORA TLPT set provider requirements, while NYDFS and PCI DSS accept qualified internal testers with organisational independence.
- HIPAA is not there yet. The proposed Security Rule update would add annual penetration tests, but the final rule target has moved to July 2027.
Regulations and frameworks at a glance
| Regime | Who it applies to | Frequency | Scope | Tester | Status (11 November 2026) |
|---|---|---|---|---|---|
| PCI DSS v4.0.1, Requirement 11.4 | Entities that store, process or transmit cardholder data | Internal and external at least every 12 months and after significant changes; segmentation every 12 months, every 6 months for service providers | CDE perimeter and critical systems, network and application layers, segmentation controls | Qualified internal resource or third party, organisationally independent | In force |
| NYDFS 23 NYCRR 500.5 | NYDFS-regulated covered entities | At least annually | Information systems from inside and outside their boundaries | Qualified internal or external party | In force |
| FedRAMP Penetration Test Guidance v3.0 | Cloud service providers seeking or holding FedRAMP authorisation | Initial test within 6 months before the security assessment report; at least every 12 months in continuous monitoring | Six attack vectors: external to corporate, external to target system, tenant to management, tenant to tenant, mobile app, client-side apps and agents | Accredited third party assessment organisation (3PAO) | Current guidance |
| EU DORA, Articles 24 and 25 | EU financial entities other than microenterprises | At least yearly appropriate tests on ICT systems supporting critical or important functions | Programme including vulnerability scans, source code review and penetration testing | Independent internal or external parties | Applies since 17 January 2025 |
| EU DORA, Article 26 TLPT | Financial entities identified by the authority | At least every 3 years | Live production systems behind critical or important functions | Testers meeting RTS (EU) 2025/1190 requirements | RTS in force since 8 July 2025 |
| NIS2 Implementing Regulation (EU) 2024/2690, Annex 6.5 | Digital infrastructure and digital provider entities | Set by risk assessment | Need, scope and type set by risk assessment; documented methodology | Not specified | Applies |
| APRA CPS 234, paragraphs 27 to 30 | APRA-regulated entities in Australia | Commensurate with threat change and asset criticality | Information security controls, including those run by third parties | Appropriately skilled and functionally independent specialists | In force |
| HIPAA Security Rule NPRM | US covered entities and business associates | Proposed: annual penetration tests | Systems with electronic protected health information | Not final | Proposal published 6 January 2025; final rule target July 2027 |
| NIST SP 800-53 Rev. 5, CA-8 | US federal systems and organisations adopting 800-53 | Organisation-defined | Organisation-defined systems; CA-8(1) independent team; CA-8(2) red team | Independent agent or team for CA-8(1) | Current |
| CIS Controls v8.1, Control 18 | Organisations using CIS | External tests at least annually (IG2), internal at least annually (IG3) | Enterprise programme with defined scope | Not specified | Framework |
For how to run a test and choose a provider, see the Penetration Testing Guide. For TIBER-EU, CBEST and DORA TLPT in depth, see the Threat-Led Penetration Testing Guide.
Scope: who and what is covered
Penetration testing duties arrive through four routes, and the strictest one sets the floor for any shared system.
- Contractual standards: PCI DSS binds through card brand and acquirer contracts, not law, but it is the most prescriptive on scope and retesting.
- Sector regulation: NYDFS Part 500, DORA, APRA CPS 234 and the proposed HIPAA update apply by licence or sector.
- Market access schemes: FedRAMP applies to cloud providers selling to US federal agencies; the test is a condition of authorisation.
- Horizontal cyber law: NIS2 requires security testing proportionate to risk without naming penetration testing, so national authorities and auditors judge adequacy.
ISO/IEC 27001:2022 and SOC 2 do not mandate penetration testing by name, but auditors routinely accept test reports as evidence for technical vulnerability management and security testing controls. Customer contracts often turn this into an explicit annual test requirement.
Key obligations
Frequency and triggers
| Regime | Calendar | Event trigger |
|---|---|---|
| PCI DSS 11.4 | 12 months (segmentation 6 months for service providers) | After any significant infrastructure or application upgrade or change |
| NYDFS 500.5 | Annual pentest | Vulnerability scans promptly after material system changes |
| FedRAMP | Annual in continuous monitoring | Initial test within 6 months before the assessment report |
| DORA Art. 24 | Yearly for systems supporting critical or important functions | Risk-based programme |
| DORA Art. 26 | Every 3 years for identified entities | Authority can change the frequency |
| NIS2 IR 6.5 | Risk-based | Changes tested and assessed before implementation (6.4.2) |
Scope rules worth knowing
- PCI DSS: tests cover the CDE perimeter and critical systems from inside and outside, at network and application layers, and must confirm segmentation actually isolates out-of-scope networks. Exploitable findings must be corrected and retested.
- FedRAMP: the tenant-to-tenant and tenant-to-management vectors test cloud isolation; the client-side vector covers agents installed in customer environments. A mobile vector can be marked out of scope only where there is no mobile app.
- DORA: penetration testing is one of the named tests in Article 25(1). Microenterprises may combine a risk-based approach with strategic planning instead of the full list.
- APRA CPS 234: where you rely on a third party's testing of controls it runs for you, you must assess whether its nature and frequency are adequate.
Evidence and follow-up
- Documentation: NIS2 IR 6.5.2(c) requires recording test type, scope, timing and results, including criticality and mitigating actions for each finding.
- Remediation: NIS2 requires mitigation of critical findings; PCI DSS requires correction and retesting of exploitable vulnerabilities.
- Escalation: APRA CPS 234 paragraph 29 requires deficiencies that cannot be remediated promptly to be reported to the Board or senior management.
- Reporting to supervisors: DORA TLPT ends with an attestation and remediation plans submitted to the authority. See the Reading and Acting on a Penetration Test Report Guide.
Timeline and current status
- July 2019: APRA CPS 234 takes effect.
- 30 June 2022: FedRAMP Penetration Test Guidance version 3.0 published.
- 6 January 2025: HIPAA Security Rule NPRM published; comments closed 7 March 2025.
- 17 January 2025: DORA applies, including Articles 24 to 27.
- 8 July 2025: DORA TLPT RTS (EU) 2025/1190 in force.
- July 2027: current target for the final HIPAA Security Rule, moved from May 2026 according to the OMB regulatory listing. Until then, annual penetration testing is a proposal for HIPAA entities, not a rule.
Enforcement and penalties
No regime fines an organisation simply for skipping a test date; the consequences come through the wider framework. PCI DSS failures appear in the Report on Compliance and can lead to acquirer action. NYDFS treats missing testing as a violation of Part 500. FedRAMP authorisations depend on the annual assessment package. DORA and NIS2 testing gaps fall under the national penalty regimes for ICT risk management failures. Weak testing also shows up after breaches, when a reachable remote access service without MFA was never in scope; see the Change Healthcare Breach 2024.
What it means for AI agents and non-human identities
- Test the machine paths: service accounts, API keys, CI/CD tokens and OAuth integrations are routes into the CDE or the cloud control plane. Put them explicitly in scope, including secrets in code and build logs. See the Cloud Penetration Testing Guide and the API Penetration Testing Guide.
- FedRAMP client-side agents: the client-side vector covers software agents installed in customer environments, which typically hold machine credentials.
- AI agents and LLM features: none of the regimes above names AI testing, but systems supporting critical functions under DORA include AI components. Add prompt injection and tool misuse to scope. See the AI Red Teaming Guide.
- Tester identities are NHIs too: accounts and keys issued to testers must be time-bound, logged and removed at close, and autonomous testing tools need the same controls. See the AI-Assisted and Autonomous Penetration Testing Guide.
Decision guidance
| Situation | Approach | Trade-off |
|---|---|---|
| Single regime, small estate (for example a merchant under PCI DSS only) | One annual internal and external test with segmentation testing, plus retests and change-triggered tests | Low cost, but every significant change needs a decision on whether to test |
| Several regimes on shared systems (for example a payments firm under PCI DSS, DORA and NYDFS) | One risk-ranked calendar with the strictest rule per system and a scope matrix showing which regime each test satisfies | Needs a register and coordination, but avoids paying for overlapping tests that still miss specific scopes |
| Cloud provider selling to US federal agencies | Separate FedRAMP test by the 3PAO covering all six vectors; reuse results for customer assurance where scope matches | Accredited testers cost more; tenant isolation findings carry high weight |
| Identified for DORA TLPT | Keep the yearly Article 24 programme and run TLPT on the authority's cycle | TLPT does not replace yearly testing; both are needed |
| Risk-based regimes only (NIS2, APRA) | Document the risk assessment that sets frequency and scope, and test critical services at least annually unless the assessment justifies otherwise | Flexibility, but the burden of justification sits with you |
- Internal or external testers: NYDFS and PCI DSS allow qualified internal testers; use them for frequent change-triggered tests and bring in external testers annually for independence and fresh perspective. FedRAMP and scheme-based red teaming require external accredited providers.
- Continuous testing services: penetration testing as a service and automated tools help with change triggers, but confirm each regulator accepts the method and that a human-led test still covers the required scope.
- Small versus large organisations: DORA lets microenterprises take a risk-based approach to the Article 25 list, and NIS2 scales to risk; large groups should expect supervisors to ask for evidence that testing covers every critical function and its third-party providers.
Compliance steps
- Build the obligations register: list every regime above that applies by entity and system, including customer contracts.
- Merge scopes: map systems to regimes, then take the strictest frequency, scope and tester rule for each shared system.
- Set triggers: define "significant change" (new internet-facing service, network re-architecture, identity platform change) and route those changes to testing.
- Select testers: confirm accreditation where required (3PAO for FedRAMP, scheme providers for CBEST or TLPT) and independence for internal teams.
- Authorise and protect production: signed rules of engagement, third-party permissions and an agreed stop procedure.
- Remediate and retest: track findings to closure, retest exploitable issues and escalate any that cannot be fixed promptly.
- Keep evidence: scope, methodology, results, remediation and retest records for each regime's audit cycle.
- Review annually: re-check the register for the HIPAA final rule, new NIS2 national rules and TLPT notifications.
Measuring it
- Coverage: percentage of in-scope systems tested within each regime's period.
- Trigger compliance: percentage of significant changes tested before or soon after go-live.
- Time to remediate: median days to fix critical and high findings.
- Retest pass rate: findings verified fixed at first retest.
- Repeat findings: share of findings seen in a previous test.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev. 5 | CA-8 Penetration Testing; RA-5 Vulnerability Monitoring and Scanning | Testing and the scanning that precedes it |
| NIST CSF 2.0 | ID.RA-01 Vulnerabilities in assets are identified, validated and recorded; ID.IM-02 Improvements are identified from security tests and exercises | Outcomes the test programme supports |
| CIS Controls v8.1 | Control 18 Penetration Testing | See the CIS Control 18 Penetration Testing Guide |
| ISO/IEC 27001:2022 | Annex A 8.8 Management of technical vulnerabilities; 8.29 Security testing in development and acceptance | Controls auditors map test evidence to |
Common failure patterns
- One test, many claims: a single external test presented as meeting PCI DSS, FedRAMP and DORA when it covered none of their specific scopes.
- Segmentation never tested: CDE scope reduced on paper without the PCI segmentation test.
- Change triggers ignored: annual test done, but a major migration in between goes untested.
- Relying on a supplier's report blindly: APRA expects you to check whether the third party's testing is adequate.
- Machine identities out of scope: tests focus on human logins while API keys and service accounts are left untested.
Practitioner checklist
- Keep a register of every testing obligation by entity, system and contract.
- Apply the strictest frequency, scope and tester rule to shared systems.
- Define significant change and route it to testing.
- Test segmentation where PCI DSS scope reduction relies on it.
- Use accredited testers where the regime requires them.
- Include service accounts, API keys, CI/CD and AI features in scope.
- Retest exploitable findings and escalate unresolved ones.
- Track the HIPAA final rule and any TLPT notification.
Standards and references
- 23 NYCRR 500.5: Vulnerability management
- EUR-Lex: Regulation (EU) 2022/2554 (DORA)
- EUR-Lex: Commission Implementing Regulation (EU) 2024/2690 (NIS2 technical measures)
- FedRAMP: Penetration Test Guidance
- APRA: Prudential Standard CPS 234 Information Security
- Federal Register: HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information (proposed rule)
- NIST: SP 800-53 Rev. 5
- Fierce Healthcare: Feds push back HIPAA security rule overhaul to July 2027
This guide summarises penetration testing requirements as of 11 November 2026 and is not legal advice. Related NHI Mgmt Group resources: Penetration Testing Guide · Threat-Led Penetration Testing Guide · Penetration Testing Compliance Requirements Guide · Financial Services Cyber Regulation Map