Compliance penetration testing requirements, by framework

Introduction

Your auditor wants your latest pentest report to close a control. That same week, a prospect's security team asks for the same PDF before they'll sign. The good news is that the penetration testing requirements behind both mostly agree on timing, and this guide to penetration testing compliance shows where they diverge, so you know which security testing to keep, what to automate, and what to ask your assessor before the audit.

TL;DR

• Who runs the test matters more than how often. Most frameworks agree on yearly, but they don't agree on the tester.
• Continuous evidence already counts in places. The FTC accepts it, and SOC 2 leaves it to your assessor.
• Keep a human where a rule names one. NYDFS, PCI DSS, FedRAMP and DORA's TLPT require a qualified or independent tester, and HIPAA's proposal and CMMC Level 3 would too.
• Three rules moved in 2026. HIPAA's update is still a proposal, CMMC's Phase 2 and later milestones are suspended as Phase 1 remains in place,, and FedRAMP now treats pentesting as part of vulnerability detection subject to its new Vulnerability Detection and Response.

Penetration testing requirements at a glance

Security teams juggle the compliance requirements of several of these nine frameworks: some are regulatory requirements with fines behind them, others only bite when an auditor or customer asks, and all want proof that your security controls were tested and vulnerabilities were fixed.

Who asks for your pen testing report

The same report usually gets requested twice, to close a control and to close a deal, and both stall on whether anyone trusts evidence automated tools produced. The security teams quoted below said as much on calls with Escape over the past six months, and they're named by role and sector only.

Your auditor

For a lot of teams the audit is the reason the test exists at all. A security lead at an enterprise services company described their pentest simply as "that compliance obligation to do pen testing", and a security team member at a cyber insurance company, speaking in the middle of their own audit, said they were "running a pen test with an external firm specifically for audit purposes".

Your auditor wants to know when you tested, against what scope, and whether the penetration testing evidence meets the requirement, with a remediation status for technical findings.

Customers weighing business risk

Customers ask for a different reason, because once your product touches their sensitive data, your security posture becomes part of their business risk. A security lead at a mid-market fintech platform explained why a compliance badge alone doesn't settle it:

"Compliance is part of the process. I can't simply say my application is compliant but not secure." A security lead at a mid-market fintech platform, on a call with Escape

Larger vendors build the report into the customer relationship, and a penetration tester at a large enterprise software company told Escape their team tests its external cloud-facing web applications every year "and we provide the reports to our customers".

Bridgetech Group, a UK B2B SaaS company certified to ISO 27001, gets these requests from its own enterprise customers constantly, and Chief Delivery Officer Ben Dalby says Escape "allows us to demonstrate that we're diligent to existing and new customers", with the case study recording that many of those customers now accept Escape's automated reports in lieu of a manual engagement.

Before that, each manual pentest "ran into tens of thousands of pounds per engagement" and, in Dalby's words, could "take weeks and weeks and weeks". On-demand reports now cut "the security gate in customer onboarding from weeks to the same day", and he's clear the platform isn't "a box-ticking exercise" either, since his team is "actually using it to drive security into our platforms".

Requirements by US framework

Security and compliance teams tend to read each framework's frequency clause first, but the tester clause determines auditor acceptance.

FTC Safeguards Rule for financial institutions

Short answer: a yearly penetration test and six-monthly vulnerability assessments, unless you run effective continuous monitoring. The rule names no tester.

The Safeguards Rule covers non-bank financial institutions under FTC jurisdiction, such as mortgage brokers, payday lenders, tax preparers, and auto dealers offering financing. Its testing clause, 16 CFR 314.4(d)(2), requires either continuous monitoring or, "absent effective continuous monitoring", a yearly penetration test scoped "based on relevant identified risks" and a vulnerability assessment every six months.

Firms holding data on fewer than 5,000 consumers are exempt from that clause under 16 CFR 314.6. The rule names no tester, making it the most flexible here, though it requires a Qualified Individual who reports to your board yearly and FTC notice within 30 days of a breach affecting 500 or more consumers.

For the continuous monitoring route, show your assessor testing frequency, coverage, and remediation evidence. Escape's results list every endpoint and asset assessed next to each dated finding, which also feeds the board report.

NYDFS Part 500

Short answer: a yearly penetration test from inside and outside your system boundaries by a qualified internal or external party, with no continuous-monitoring alternative.

New York's rule covers DFS-licensed banks, insurers, and other financial institutions. 23 NYCRR 500.05 requires testing "from both inside and outside the information systems' boundaries by a qualified internal or external party at least annually", so internal pen testing of your internal systems and external pen testing from the internet.

Automated scans, plus a manual review of anything they miss, run on a risk-based schedule and "promptly after any material system changes". You also have to "timely remediate vulnerabilities, giving priority to vulnerabilities based on the risk they pose", report incidents within 72 hours, and file an April 15 compliance certification signed by your highest-ranking executive and your CISO.

It has to rest on "data and documentation sufficient to accurately determine and demonstrate such material compliance", kept for five years. Qualified internal teams count the same as a consultancy, but with no continuous-monitoring alternative, the annual test still happens. Use Escape's exploit-backed findings to scope it, and keep the re-test history behind that signed certification.

SEC data breach and risk disclosure

Short answer: no pentest is required, but your 10-K must describe how you assess cybersecurity risk, including whether you use outside assessors.

Under the SEC's 2023 rules, a Form 8-K for a data breach or material incident will "generally be due four business days after a registrant determines that a cybersecurity incident is material". Your 10-K must also "describe their processes, if any, for assessing, identifying, and managing material risks", and Item 106 of Regulation S-K asks "whether the registrant engages assessors, consultants, auditors, or other third parties" and how you oversee service-provider risk.

No test is named, so regulatory compliance means describing your program accurately in a public filing. Spell out the mix you run, such as an annual third-party pentest plus continuous testing, and keep a per-build DAST history to back it up.

PCI DSS penetration testing (Requirement 11.4)

Short answer: Internal and external penetration tests at least once every 12 months and after significant changes, by a qualified, organizationally independent tester. Continuous testing covers the application layer between tests, not the network layer or segmentation.

PCI DSS v4.0.1 is the standard in force for anyone who has to store, process or transmit cardholder data. Requirement 11.4 requires internal and external penetration tests of system components in your cardholder data environment at both the application and network layers, at least annually and after significant changes.

Requirement 11.4 breaks down into six parts. 11.4.1 requires a documented methodology covering the whole cardholder data environment perimeter and critical systems, at both the application and network layers. 11.4.2 and 11.4.3 require internal and external tests at least once every 12 months and after any significant change. 11.4.4 requires exploitable findings to be corrected and retested. 11.4.5 requires segmentation testing at least every 12 months, and 11.4.6 tightens that to every six months for service providers.

Requirement 11.3 sits alongside it: quarterly internal vulnerability scans (11.3.1) and quarterly external scans by an Approved Scanning Vendor (11.3.2).

Your own staff can run the test if they're qualified and organizationally independent of the systems being tested.. Scope from your cardholder data flows, then give the web applications and web services that change every release to continuous application testing; Escape covers that half by re-testing every fixed exploit on each build (see its PCI DSS v4.0 walkthrough).

PCI-compliant teams tend to add this rather than swap anything out, and a security contact at a Latin American payments company described continuous testing to Escape as "another step on our security pipeline", "something more than our manual testing and our SAST".

Network segmentation and network configurations, like firewall rules and cloud security groups, sit in a separate network-layer scope, so plan a scheduled engagement for that part and let continuous testing carry the application side between tests.

SOC 2 and ISO 27001

Short answer: neither sets a pentest interval or names a tester, so your auditor decides what evidence counts.

SOC 2 sets no pentest interval, and the nearest it gets is a CC4.1 point of focus in the trust services criteria that lists penetration testing among the "different types of ongoing and separate evaluations" management can use.

ISO 27001:2022 likewise has Annex A controls for management of technical vulnerabilities (8.8) and security testing in development and acceptance (8.29), but no fixed test or tester. A SOC 2 Type II report does check controls across the whole review period, though, which regular penetration testing shows better than a single test.

An annual test became the norm anyway, and a security engineer at a developer-infrastructure company explained how, noting that SOC 2 doesn't "technically" require one and that "someone somewhere at one point did a pen test, and that became the expectation".

Because the standard leaves the tester open, your audit firm decides what evidence counts, and that flexibility is what lets continuous testing in. Bridgetech's experience shows how it plays out with customers:

"Customers will often ask for a penetration test against our platforms, and some customers will accept the output of tools like Escape. That is massively beneficial for us." Ben Dalby, Chief Delivery Officer, Bridgetech Group

Escape maps findings to named compliance standards, including SOC 2 and ISO 27001, which is exactly what a prospect at a fintech lender asked about during an Escape demo: "Will that map to SOC and ISO as well?" Scope scans to your report's system description, and agree the approach with your auditor before the observation window.

HIPAA's proposed penetration testing requirement and data security

Short answer: Nothing in place yet. Today's Security Rule doesn't require a pentest. A January 2025 proposal would require one yearly, but it isn't final, and HHS now targets July 2027 for final action.

Today's Security Rule doesn't mention penetration testing, only a periodic evaluation under 45 CFR 164.308(a)(8). The January 6, 2025 proposal, not yet final, would require a yearly penetration test by "a qualified person" able to perform "'ethical hacking' or 'offensive security'", plus vulnerability scanning every six months. 

It would also require an asset inventory and network map, MFA, encryption of ePHI, and an annual compliance audit, with compliance due about 240 days after a final rule is published (a 60-day effective date plus 180 days). Escape's per-build DAST already exceeds that scanning cadence, so start now on choosing your qualified tester and building the asset inventory, since a test only covers what you've mapped.

CMMC Level 3

Short answer: only Level 3 names a pentest, and Level 3 assessments are on hold while DoD reviews the program.

CMMC applies to defense contractors handling controlled unclassified information, with Level 2 drawing 110 requirements from NIST SP 800-171 and Level 3 adding 24 from NIST SP 800-172. The Program rule took effect December 16, 2024, and the acquisition rule followed on November 10, 2025.

Only Level 3 requires a pentest under CA.L3-3.12.1e, which asks you to "conduct penetration testing at least annually or when significant security changes are made to the system, leveraging automated scanning tools and ad hoc tests using subject matter experts". On July 13, 2026, the DoW suspended Phase 2, including the November 10, 2026 date for third-party Level 2 certification, along with every later implementation milestone, which puts Level 3 assessments on hold too. Phase 1 self-assessments and NIST SP 800-171 obligations still apply, and a CMMC Reform Task Force is reviewing the program. Treat 3.12.1e as the requirement you would be assessed against if Level 3 resumes, not a current contract term.

FedRAMP cloud security

Short answer: yes. A FedRAMP-recognized independent assessor still assesses penetration testing yearly, but since June 2026 FedRAMP treats pentesting as part of vulnerability detection.

FedRAMP's Consolidated Rules for 2026 (CR26), released June 24, bring the program's requirements into a unified ruleset and shift from authorization to certification terminology. For Rev5 providers, CA-8 now explicitly places penetration testing under the Vulnerability Detection and Response (VDR) rules, which become mandatory for cloud offerings obtaining or maintaining FedRAMP certification on December 7, 2026.

FedRAMP's existing Penetration Test Guidance (Version 3.0) remains a detailed reference for test scoping, including six attack vectors spanning external-to-corporate, tenant-to-tenant, and mobile and client-side applications. It specifies testing at least every 12 months during continuous monitoring, and an initial test no more than six months before the security assessment report. Confirm with your 3PAO how these legacy provisions apply under CR26 and to your next assessment.

Your own testing can't replace the 3PAO's, but under VDR it is now part of the detection program the 3PAO reviews. Keep findings, fixes, and re-tests dated, and hand over Escape's record of every endpoint and asset assessed.

DORA threat-led penetration testing and resilience testing

For anyone touching EU financial services, DORA is probably the toughest requirement here. It has applied since January 17, 2025, and its threat-led penetration testing (TLPT) is a live test whose scope your regulator signs off.

Short answer: every in-scope financial entity except microenterprises must test the ICT systems behind critical or important functions at least yearly, using independent testers; only entities their regulator designates must also run TLPT every three years.

What Articles 24 and 25 require of every in-scope entity

Before TLPT, DORA sets a baseline that applies far more widely. Article 24 requires financial entities other than microenterprises to test all ICT systems and applications supporting critical or important functions at least yearly, with tests run by independent parties, whether internal or external. Article 25 lists the tests that programme can include, from vulnerability assessments and scans to scenario-based tests and penetration testing.

What Article 26 requires

Under Article 26, designated entities "shall carry out at least every 3 years advanced testing by means of TLPT" on "live production systems" supporting critical or important functions, so a red team runs real-world attack scenarios against your production environments, including functions "outsourced or contracted to ICT third-party service providers".

You propose the scope definition, the competent authority validates it, then issues an attestation. TLPT sits on top of DORA's broader system resilience and ICT risk-management duties, which Escape covers in how API security fits into DORA compliance.

Who's in scope

DORA covers twenty-one types of entities, from banks to crypto-asset and ICT third-party providers, but most won't run TLPT, because competent authorities "shall identify financial entities that are required to perform TLPT" by sector impact, systemic importance and ICT risk profile.

DORA also reaches US and UK vendors through contracts with European financial entities, so check yours for testing and audit clauses. Plenty of vendors aren't there yet, and a security lead at a European developer-tooling company, in the middle of a SOC 2 audit, told Escape, "overall we're only SOC 2", adding "NIS 2, we'll need to get into that".

Who can run the test

DORA is the strictest rule here on testers. Internal testers need competent-authority approval, every third test needs an external tester (significant credit institutions must always use external ones), and Article 27 sets five conditions for anyone running it:

• "of the highest suitability and reputability"
• demonstrated "specific expertise in threat intelligence, penetration testing and red team testing"
• "certified by an accreditation body in a Member State", or adhering to "formal codes of conduct or ethical frameworks"
• independent assurance or an audit report on how they manage testing risks
• professional indemnity insurance, "including against risks of misconduct and negligence"

Continuous testing won't replace any of that, but running Escape beforehand clears the easy findings, so experienced testers spend their days on the hard ones.

Can AI pentesting satisfy an auditor?

It depends on the framework and on your assessor. Side by side, the rules barely differ on how often you test, but they differ a lot on who's allowed to run the test, and that clause decides how much automated evidence an auditor will take. The heatmap below shows where each framework lands, from the FTC naming no tester at all to DORA requiring accredited, insured ones.

Where continuous evidence counts

One test a year can't keep up with daily releases, and continuous AI pentesting fills that gap with evidence an auditor can actually check. A pile of potential vulnerabilities from automated vulnerability scanning gives a skeptical auditor little to check, but a working exploit, a record of what was tested, and proof the fix held do.

Escape's AI Pentesting delivers reports that both auditors and engineers can act on, giving every finding a request sequence, working exploit, and framework-specific remediation guidance.

Testing as several users at once, it catches access control failures and privilege escalation paths a single-account scan misses, and DAST re-runs each proven exploit on every build, leaving hidden vulnerabilities and new security gaps less time between audits.

That automated validation counts most under the FTC rule, the SEC's disclosure rules, DORA's Article 25 testing programme and NIS2, and under SOC 2 and ISO 27001 once your assessor agrees, and it keeps working between audits, when most real changes ship.

Where a human still signs off

Wherever a rule names a qualified person, an accredited tester or an outside assessor, as NYDFS, PCI DSS, FedRAMP and DORA's TLPT do, and as HIPAA's proposal and CMMC Level 3 would, continuous evidence supports that engagement rather than competing with it. The tester signs off, and Escape's findings give them a head start.

That head start matters, because a once-a-year engagement has real limits, and a security lead at a SaaS company with a mature bug bounty program doubted that "a fresh pentester who hasn't touched our application before is going to find sophisticated exploitation ways" in a short engagement.

Give penetration testers Escape's proven findings on day one, and their extensive knowledge goes into attack paths nobody has mapped.

Checklist before your next audit

Compliance pentesting gets easier once you can produce evidence on request.

• List every framework you answer to, including SOC 2 or ISO 27001 required by customer contracts.
• Mark the rules whose tester clause names a person, accredited firm, or outside assessor.
• Ask your assessor, in writing, whether continuous evidence counts.
• Check the status of anything that moved in 2026: HIPAA's proposal, CMMC's suspension, and FedRAMP's CR26 deadlines.
• Keep human engagement where a rule names a tester, and share your continuous findings.
• Feed findings into vulnerability management, and keep one evidence pack with dated reports, scope, proof of exploit, and re-test results.

Conclusion

Nearly every framework asks for a yearly test, so the calendar is rarely the problem. The tester clause decides how much of your testing an auditor accepts, and it's still moving: HIPAA's proposal would name a qualified person, CMMC's assessments are paused, and FedRAMP now treats pentesting as part of vulnerability detection. Keep a human where a rule names one and let continuous testing cover the months between, so you're ready for auditors and customers alike. To see how proven, re-tested findings hold up as audit evidence on your own apps and APIs, book a demo.

FAQs

Is penetration testing a legal requirement?

For some organizations, since the FTC Safeguards Rule, NYDFS Part 500 and DORA are binding law, while SOC 2 is a contractual expectation and PCI DSS is enforced through card-brand contracts.

Does an AI pentest satisfy PCI DSS?

Only the application part, since PCI DSS also tests the network layer and segmentation, which still need a scheduled engagement.

Can automated pentesting produce evidence for DORA and NIS2?

Yes, for DORA's Article 25 testing programme and NIS2's effectiveness assessments, as long as an independent party runs the testing and the records are dated. It can't stand in for DORA TLPT, which needs accredited, insured testers and regulator sign-off.

Does HIPAA require penetration testing in 2026?

No. The current Security Rule doesn't name it. The proposed update would require a yearly test by a qualified person, but it isn't final, and HHS targets July 2027 for final action.

Does SOC 2 require a penetration test?

Not in writing, but most SOC 2 auditors expect one each year, and what satisfies one assessor's view of SOC 2 compliance may not satisfy another's.

Do auditors expect black, white or grey box testing?

Usually not, since most frameworks leave testing methodologies to you. Black box testing starts with no inside knowledge, grey box testing adds credentials and some documentation, and white box testing hands over source code. Grey box is a popular middle ground for reaching logged-in features.

Should your internal team or a cybersecurity company run the test?

New York accepts a qualified internal team, while DORA's TLPT and FedRAMP usually mean hiring a cybersecurity company. Many teams test continuously in-house and bring in a security partner yearly.

Does cloud penetration testing count toward compliance?

Yes, when your cloud infrastructure is in scope, as with FedRAMP or PCI DSS on cloud-hosted cardholder data. Cloud penetration testing adds configuration and identity checks to application testing.

What are the key benefits of continuous pentesting for compliance?

You stop scrambling before each audit, because instead of one aging PDF you have comprehensive coverage between annual tests, exploit-backed findings and dated re-tests showing fixes held.

Sources

• 16 CFR 314.4, Standards for Safeguarding Customer Information (eCFR)
• 23 NYCRR Part 500, Second Amendment (New York State Department of Financial Services)
• HIPAA Security Rule to Strengthen the Cybersecurity of Electronic Protected Health Information (HHS Office for Civil Rights)
• Unified Agenda entry RIN 0945-AA22, HIPAA Security Rule (Office of Information and Regulatory Affairs)
• Regulation (EU) 2022/2554, Articles 24 to 27 (EUR-Lex)
• Directive (EU) 2022/2555 (NIS2), Article 21 (EUR-Lex)
• Commission Implementing Regulation (EU) 2024/2690 (EUR-Lex)
• SEC Adopts Rules on Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure by Public Companies (U.S. Securities and Exchange Commission)
• Cybersecurity Maturity Model Certification Program final rule (Department of Defense)
• Defense Federal Acquisition Regulation Supplement: Assessing Contractor Implementation of Cybersecurity Requirements (Department of Defense)
• Forging the Arsenal of Freedom: Department of War Suspends CMMC Phase II Requirements, July 13, 2026 (Department of War)
• PCI SSC Document Library (PCI Security Standards Council)
• FedRAMP Consolidated Rules for 2026 (FedRAMP)
• What defense contractors should know about DoD's suspension of CMMC Phase 2 (Latham & Watkins)
• FedRAMP Penetration Test Guidance, version 3.0, legacy scoping reference (FedRAMP)