Table of contents
32
By Salman Khan, OSCP+, Founder of XHack, SRT (Synack Red Team member)
Read this in 30 seconds: Penetration testing for compliance means something different under almost every framework, and most guides flatten those differences into one generic checklist.
- Penetration testing for compliance with PCI DSS is required by name, but the “quarterly pentest” rule is a myth. Requirement 11.4 calls for a pentest at least every 12 months and after significant change. The quarterly rule under 11.3 is vulnerability scanning, not a pentest.
- SOC 2 names penetration testing in one place, but never requires it. The AICPA’s Trust Services Criteria mention it only as an example inside one optional point of focus under CC4.1, yet most auditors still expect a report.
- NYDFS used to let you swap penetration testing for continuous monitoring, but that option is gone. The 2023 Second Amendment made “at least annually” testing unconditional under 23 NYCRR 500.5.
- FedRAMP’s pentest has to come from your 3PAO, but the newer 20x track is changing how testing fits in. The FedRAMP Penetration Test Guidance says the work “must be performed by a 3PAO,” so on the traditional path no other firm’s report replaces it.
- HIPAA does not require penetration testing for compliance today, but a proposed rule would. As of mid-2026 that rule is still pending, and Clark Hill, a law firm, reported in July 2026 that HHS pushed final action to around July 2027.
Every framework in this guide asks for some security testing. What changes from one to the next is whether that testing has to be a penetration test, how often, and who can run it.
Many companies are not chasing one framework alone. A SaaS company might need SOC 2 for a deal, PCI DSS because it touches card data, and ISO 27001 for an EU customer, often in the same year. This guide sorts penetration testing for compliance into three groups: required by name, named but optional, and controls testing with no method specified.
Here is what penetration testing for compliance means under each framework in this guide.
| Framework | Pentest required? | How often | Where it says so |
|---|---|---|---|
| PCI DSS v4.0.1 | Yes, by name | At least every 12 months, and after significant change | Requirement 11.4 |
| NYDFS 23 NYCRR 500.5 | Yes, by name, unconditionally | At least annually | Section 500.5(a)(1) |
| FedRAMP | Yes, by name, only by your 3PAO (traditional path; 20x is changing this) | Initial test no more than 6 months before the SAR, then at least every 12 months | NIST SP 800-53 CA-8; FedRAMP Penetration Test Guidance |
| CMMC 2.0, Level 3 | Yes, by name | At least annually, or after significant change | CA.L3-3.12.1e |
| DORA (TLPT) | Yes, by name, only for entities your regulator identifies | At least every 3 years | Articles 26 and 27 |
| SOC 2 | Named, not required | No fixed cadence; auditors commonly expect annual | CC4.1 point of focus |
| DORA (general programme) | Named as one test type among several, not required | No pentest cadence; some appropriate test at least yearly on systems supporting critical or important functions | Articles 24 and 25 |
| ISO/IEC 27001:2022 | Not named | No fixed cadence; annual is common practice | Consultancies read it into ISO/IEC 27002:2022 guidance for controls 8.8 and 8.29 |
| HIPAA (current rule) | Not required | No fixed cadence | 45 CFR 164.308(a)(8) |
| HIPAA (proposed rule) | Would require it, if finalized | Proposed: every 12 months | Pending rule, not yet final |
| GDPR | Not named | No fixed cadence | Article 32(1)(d) |
| NIS2 | Not named | No fixed cadence | Article 21(2)(f) |
Five of these rules make penetration testing for compliance a hard requirement, two use it only as an example, and the rest leave the method to you.
A compliance framework is a set of rules for handling data and managing risk. An auditor, assessor, certification body or regulator checks your company against those rules, and a penetration test is one piece of evidence they look at, not the whole decision. Treating the evidence as the decision is where most confusion about penetration testing for compliance starts.
No pentest company can make you compliant or certified, XHack included. We deliver the pentest report; the auditor, QSA, CPA firm, certification body or regulator decides whether it satisfies their rule. Two myths follow:
Five frameworks, or tiers of them, are explicit about penetration testing for compliance: they say “penetration testing” in the part of the text that actually binds you.
PCI DSS v4.0.1 is the plainest case of penetration testing for compliance. Requirement 11.4 reads: “External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected.” Sub-requirements 11.4.2 and 11.4.3 set the cadence at least “once every 12 months” and “after any significant infrastructure or application upgrade or change,” by “a qualified internal resource or qualified external third-party” with organizational independence.
The quarterly rule people quote is Requirement 11.3, which covers vulnerability scans. The confusion has a real source: in PCI DSS v3.2.1 the pentest requirement was numbered 11.3, and some guides still use that number. See our PCI DSS penetration testing guide for the full breakdown.
New York’s cybersecurity regulation used to let a covered entity choose continuous monitoring instead of periodic testing. The 2023 Second Amendment deleted that option and now requires, at minimum, “penetration testing of their information systems from both inside and outside the information systems’ boundaries by a qualified internal or external party at least annually.”
Penetration testing for compliance with NYDFS now sits next to automated scans under 500.5(a)(2), not in place of them. See the text on Cornell’s Legal Information Institute.
FedRAMP is the framework where penetration testing for compliance cannot be outsourced to just any vendor. NIST SP 800-53 control CA-8 requires it, and the FedRAMP Penetration Test Guidance states: “All penetration test activities must be performed by a 3PAO that has demonstrated penetration testing proficiency,” with a team lead who holds “an industry-recognized credential for penetration testing.”
Timing follows the authorization cycle: the initial test happens “no more than 6 months prior to the submission of the SAR,” then “at least every 12 months” during continuous monitoring. No report from a firm other than your 3PAO, XHack’s included, substitutes for that assessment pentest.
FedRAMP 20x, the program’s newer authorization track, folds penetration testing into a continuous “vulnerability detection” duty as one technique among several. Whether that replaces the annual 3PAO pentest for traditional authorizations is not settled yet, so confirm with your 3PAO which rules apply to you.
CMMC Level 2, built on NIST SP 800-171, has no penetration testing requirement at all. Level 3 is different: control CA.L3-3.12.1e states “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,” with no specific tester accreditation named.
If your contract only requires Level 2, penetration testing for compliance is not on your CMMC checklist. At Level 3, confirm with your assessor what they expect from the tester before you hire one.
DORA has two testing tiers, and TLPT is the stricter one. Article 27(1) says testers must be “of the highest suitability and reputability,” with “specific expertise in threat intelligence, penetration testing and red team testing,” accreditation or a formal code of conduct, independent assurance, and professional indemnity insurance.
TLPT only applies to entities your regulator specifically identifies, and it runs “at least every 3 years” on live production systems, with an external tester required every third test where internal testers are used. It is the strictest version of penetration testing for compliance in this guide, closer to the adversary simulation of a real red team engagement than a standard pentest. The supporting RTS, Commission Delegated Regulation (EU) 2025/1190, took effect 8 July 2025; see Article 27 in the DORA text on EUR-Lex.
Two frameworks mention penetration testing directly and stop short of requiring it. That gap is where auditor and supervisor expectations quietly decide what penetration testing for compliance actually looks like.
SOC 2’s Trust Services Criteria name penetration testing in one place: an optional point of focus under CC4.1, listed alongside “vulnerability scans” and other evaluation types. The AICPA says plainly that not every point of focus has to be addressed, so nothing in the text forces penetration testing for compliance.
Most SOC 2 auditors ask for one anyway, because it is the cleanest evidence that CC4.1’s “ongoing and/or separate evaluations” actually happened. For SOC 2, penetration testing for compliance comes down to what your auditor expects, not what the criteria technically require.
Secureframe, a compliance-automation vendor, gives the usual timing rule: a Type I pentest can date back up to 12 months before the report date, while a Type II pentest should fall inside the audit period. Read our SOC 2 penetration testing guide for the full breakdown.
Below the TLPT tier, DORA’s Article 24 requires every financial entity except microenterprises to run “appropriate tests” “at least yearly” on all ICT systems and applications supporting critical or important functions. Article 25(1) then lists acceptable test types, including “penetration testing” alongside vulnerability scans and source code reviews, and Article 24(4) requires tests to be run by “independent parties, whether internal or external.”
For every DORA-covered firm outside the TLPT tier, penetration testing for compliance is one acceptable choice among several, not a standalone mandate.
Four frameworks do not name penetration testing in the rules that govern testing. They ask you to test your controls and leave the method to you, which is where the ISO 27001 and NIS2 myths come from.
None of the 93 Annex A controls in ISO/IEC 27001:2022 names penetration testing. Consultancies read the companion guidance, ISO/IEC 27002:2022, as pointing to it under control 8.8 (management of technical vulnerabilities) and 8.29 (security testing in development and acceptance), which is their reading, not ISO’s words. The standard itself sets no frequency and no tester rule, so for ISO 27001, penetration testing for compliance is a reading of the guidance, not a line in the standard.
Under the current HIPAA Security Rule, 45 CFR 164.308(a)(8) requires covered entities and business associates to “perform a periodic technical and nontechnical evaluation” of their security policies and procedures, with no method named and no frequency set.
A proposed rule would change that: the HHS Security Rule proposal, published January 2025, would require vulnerability scanning at least every six months and penetration testing at least every 12 months, by “a qualified person.” Clark Hill, a law firm, reported in July 2026 that HHS moved it to its long-term agenda, with final action anticipated around July 2027.
So penetration testing for compliance with HIPAA stays optional until HHS finalizes the proposal, and its move to the long-term agenda suggests that is more than a year away. See our HIPAA penetration testing guide, or the rule text at Cornell’s Legal Information Institute.
GDPR’s Article 32(1)(d) requires “a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing,” with no method and no frequency named. Penetration testing for compliance with GDPR is one defensible way to show that process is real, not the only one.
The NIS2 directive requires “policies and procedures to assess the effectiveness of cybersecurity risk-management measures” under Article 21(2)(f). The word “penetration” only shows up in non-binding recitals 86 and 87, and Implementing Regulation (EU) 2024/2690 for digital infrastructure and ICT providers leaves “the need, scope, frequency and type of security tests” to each entity’s own risk assessment.
This is the part of penetration testing for compliance most guides skip, and getting the tester wrong can invalidate the whole engagement.
| Framework | Who may test |
|---|---|
| PCI DSS | Qualified internal resource or qualified external third party, organizationally independent (not required to be a QSA or ASV) |
| SOC 2 | No rule stated; an independent third party is strongest, and your auditor generally should not also be your tester |
| ISO 27001 | No rule in the standard |
| HIPAA | No rule today; the proposed rule specifies “a qualified person” |
| GDPR | No rule |
| NYDFS | “A qualified internal or external party” |
| FedRAMP | An accredited 3PAO, with a credentialed penetration test team lead |
| CMMC Level 3 | No tester rule; the control asks for “ad hoc tests using subject matter experts” and names no accreditation |
| DORA (general) | “Independent parties, whether internal or external” |
| DORA (TLPT) | Testers meeting Article 27(1)(a) through (e); an external threat-intel provider when internal testers are used; external testers required every third test |
| NIS2 | No rule |
Most frameworks that require a pentest by name also say who may run it, from PCI’s qualified and independent tester up to FedRAMP’s accredited 3PAO, and CMMC Level 3 is the exception. Even where a rule says “qualified,” it names no certificate, which is why the word gets used so loosely. Picking a tester who meets the rule is the first decision in penetration testing for compliance, and our guide to choosing a pentest provider covers how to vet one.
One well-scoped round of penetration testing for compliance can often cover two or three frameworks at once, instead of a separate test per framework. This is our own recommendation, not a rule from any of these standards.
Two exceptions need their own engagement: the FedRAMP 3PAO pentest and DORA’s TLPT. See our penetration testing checklist for how a full engagement runs.
In penetration testing for compliance, a report full of open findings is weaker evidence than a report plus a retest showing them fixed. Several of these frameworks put that in writing.
PCI DSS 11.4.4 makes it binding: “Penetration testing is repeated to verify the corrections.” DORA’s Article 24(5) requires procedures to “remedy all issues” and validate that weaknesses are “fully addressed,” and NYDFS 500.5(c) requires timely remediation of what your testing turns up.
SOC 2 and ISO 27001 say less in their text, but auditors ask for the same thing in practice: evidence that a finding got closed, not just discovered. Penetration testing for compliance without that closing step leaves your auditor staring at open problems instead of proof they got solved. When you scope it, ask whether the retest is included, and get that in writing.
There is no single number for penetration testing for compliance, because cost tracks scope and tester rules, not the framework’s name.
For SOC 2, Astra, a pentest vendor, quotes “between $2,000 and $25,000,” and Axipro, another pentest vendor, quotes “between $1,000 and $30,000 for most companies,” with a SaaS median “around $12,000 to $15,000.” For ISO 27001, Scrut, a compliance-automation vendor, quotes “between USD 5,000 and USD 20,000.”
For DORA, SureCloud, a GRC vendor, puts a standard pentest at £10,000 to £50,000 for most engagements. Threat-led penetration testing runs higher: SureCloud puts threat-intelligence and red-team provider fees combined at £150,000 to £310,000 or more, for a first cycle that runs around six months.
For FedRAMP and CMMC, published figures bundle the whole assessment, so they do not show what the pentest alone costs.
What actually moves the price of penetration testing for compliance: scope size, authenticated testing, internal network and segmentation, mobile and cloud coverage, whether the retest is bundled in, and whether the rule demands a specially accredited tester, as FedRAMP and DORA TLPT do.
Each of these myths about penetration testing for compliance still appears on vendor pages in 2026, and none survives a read of the actual text.
Nothing in these frameworks forbids an AI-assisted test, and none has approved a fully AI-run one either. FedRAMP and DORA’s TLPT set rules about who tests, not which tools they use, so the real question is who runs and signs off on the test.
PCI DSS asks for a “qualified” tester with organizational independence and names no certificate. Before you buy AI-only penetration testing for compliance, ask your QSA whether an agent alone meets that bar.
We wrote the full answer, framework by framework: does AI-run penetration testing satisfy compliance requirements?
So yeah, here’s where we talk about what XHack brings to the table.
XHack is three things in one place: human-led managed testing, an AI agent that runs alongside our testers only with your explicit permission and at no extra cost, and a security platform that scans between engagements. Here is what that means for penetration testing for compliance.
Where an XHack pentest report fits, framework by framework:
| Framework | What the XHack pentest report gives you | Who makes the compliance call |
|---|---|---|
| PCI DSS v4.0.1 | Internal and external pentest evidence for Requirement 11.4, plus the retest that 11.4.4 requires | Your QSA, or your acquirer if you self-assess |
| SOC 2 | Pentest evidence for CC4.1 and CC7.1, run inside your audit window | Your CPA firm |
| ISO 27001 | Evidence for Annex A controls 8.8, 8.25 and 8.29 | Your certification body |
| HIPAA | Evidence for the 164.308(a)(8) security evaluation | You, and HHS’s Office for Civil Rights if it investigates |
| GDPR | Evidence for the Article 32(1)(d) testing process | You, and your data protection authority if it investigates |
In plain terms, our penetration testing for compliance gives you the pentest report that satisfies the testing part of each framework. We do not issue a PCI DSS attestation, a SOC 2 report, an ISO 27001 certificate or any other compliance approval; the party in the right-hand column does that.
Where a rule accepts any qualified, independent tester, such as NYDFS 500.5 or DORA’s general testing programme, the same report can serve as that evidence, and your regulator or assessor confirms it.
What XHack gives you:
What XHack does not give you:
Start with the tier built for exactly this kind of penetration testing for compliance: Assurance, from $5,000, “human-led testing built to stand up to an auditor,” best for “SOC 2, ISO 27001 and PCI DSS cycles, and annual testing obligations.” It covers up to 3 unauthenticated web apps, or 1 low-complexity authenticated web app, or up to 100 host IPs, run by two OSCP-certified testers with AI agents alongside if you permit it, in five days to two weeks.
Essential, from $2,500, is built for pre-launch checks, vendor questionnaires and first assessments, with AI agents leading and one certified tester verifying every finding. Comprehensive starts at $12,000 and adds attack-path chaining plus a cloud review. Enterprise is quoted per client for continuous or quarterly programmes with red team and incident response layered in.
Every tier is “NDA and DPA ready,” with a reply to every enquiry within 24 hours. Our 31-page sample report, behind a short form, shows what penetration testing for compliance evidence looks like: findings mapped to PCI DSS 4.0, ISO 27001, GDPR, HIPAA and NIST CSF 2.0, with SOC 2 cited at the framework level.
Scanning between engagements runs on the company platform, from $560 a month. The AI agent starts at $20 a month for hands-on testing of your own, and your pentest chats and session data stay on your own machine, where you can delete them any time. Both include a 7-day free trial, no credit card required; the trial does not cover VAPT.
Want a fixed-price quote scoped to your frameworks? Request one.
If you would rather talk it through first, book a free consultation, even if it ends with you deciding we are not the right fit. Brutal honesty is kind of our thing.
Five frameworks require it by name: PCI DSS (Requirement 11.4), NYDFS (23 NYCRR 500.5), FedRAMP on its traditional path (NIST SP 800-53 CA-8), CMMC 2.0 Level 3 (CA.L3-3.12.1e), and DORA’s TLPT for entities a regulator specifically identifies. Everywhere else, penetration testing for compliance is either named as one option or left to your own risk assessment.
PCI DSS and NYDFS both require it at least every 12 months, FedRAMP follows the same cycle after an initial test, CMMC Level 3 matches that annual cadence, and DORA’s TLPT runs at least every 3 years. Frameworks that only name testing as an example, like SOC 2, set no fixed cadence, though annual is the common default.
Sometimes, but for penetration testing for compliance, check the rule first. PCI DSS allows “a qualified internal resource” with organizational independence, NYDFS allows “a qualified internal or external party,” and CMMC Level 3 sets no tester rule, only a method that combines scanning with “ad hoc tests using subject matter experts,” so check with your assessor. FedRAMP is the exception, because the accredited 3PAO must run it, and DORA TLPT allows internal testers only with regulator approval, an external threat intelligence provider, and external testers every third test.
Often, yes. Scope the test to the union of all three, meet the strictest tester and timing rule, and get a report that maps findings to each framework. This is our own recommended approach to penetration testing for compliance, not a rule any of the three states, and it does not cover FedRAMP or DORA TLPT.
Generally not. For penetration testing for compliance under PCI DSS or NYDFS, scanning is a separate control that runs next to the pentest (PCI DSS 11.3 and 11.4, NYDFS 500.5(a)(2) and (a)(1)), not in place of it. A vulnerability scan and a penetration test are different tools for different jobs, and most auditors read scanner output as a starting point, not proof of manual exploitation.
No, not under the current rule. 45 CFR 164.308(a)(8) requires only a “periodic technical and nontechnical evaluation,” with no method or frequency named. A proposed rule would add a 12-month requirement, but it is still pending, and Clark Hill, a law firm, reported in July 2026 that HHS now expects final action around July 2027.
No, and any vendor claiming otherwise is overselling what a pentest does. A pentest is one piece of evidence an auditor, QSA, CPA firm, certification body or regulator weighs alongside your policies and other controls. XHack delivers penetration testing for compliance as a report built to meet what PCI DSS, SOC 2, ISO 27001, HIPAA and GDPR ask of a pentest, and the compliance decision always sits with the party grading you.
PCI DSS, NYDFS, FedRAMP, CMMC Level 3 and DORA’s TLPT tier require a pentest by name. SOC 2 and DORA’s general programme name it without requiring it, while ISO 27001, HIPAA, GDPR and NIS2 just ask you to test your controls.
Generic advice about penetration testing for compliance keeps failing readers because the answer changes with each framework and each combination of them. Get the tester rule right, get the timing right, and get a retest in writing, and the “is this required” argument stops mattering, because you will have solid evidence regardless.
If you are juggling two or three of these at once, book a free consultation and we will help you scope penetration testing for compliance before you buy anything.
Categories
Related articles
