Penetration Testing Requirements by Framework: The 2026 Matrix

Quick answer: Of the twelve frameworks buyers ask about, five name penetration testing in binding requirement text with a stated cadence: PCI DSS v4.0.1 at Requirement 11.4, NYDFS 23 NYCRR 500.5(a)(1), FedRAMP through NIST SP 800-53 control CA-8, CMMC at Level 3 only, and DORA for financial entities. Five accept it as evidence but mandate nothing and set no interval: SOC 2, ISO/IEC 27001:2022, HIPAA, NIS2 and GDPR. One row cannot be answered from published material at all: HITRUST publishes its assessment process but not its CSF requirement statements, so this matrix does not print a HITRUST cadence. One row is about to move: a proposed HIPAA Security Rule amendment published on 6 January 2025 would require penetration testing at least once every 12 months, and as of 5 September 2026 no final rule has been issued.

The annual cadence most organisations run is real for about a third of these frameworks and self-imposed for the rest. Knowing which you are in changes what you buy, when you buy it, and what you have to be able to show.

This page is the requirements index. For a vendor shortlist see our guide to compliance and regulation pentesting services, and for the clause-level walk through what auditors accept as evidence see pentest evidence auditors accept.

The matrix

Every row below traces to the regulator or standards body's own requirement text. Where the operative text is not public, the row says so rather than borrowing a number from commentary.

Mandate, cadence and who may test

Scope, evidence and primary source

How to read the matrix: three categories, not two

Most articles on this topic sort frameworks into "requires" and "does not require". That produces the wrong buying decision, because the second bucket contains two very different situations.

Category one: mandated in requirement text. The framework's own binding language names penetration testing and attaches a frequency. PCI DSS, NYDFS, FedRAMP, DORA and CMMC Level 3. Miss the window and you have a finding regardless of how good your security is.

Category two: accepted as evidence, with the cadence set by you. SOC 2, ISO 27001, HIPAA today, NIS2 and GDPR. Nothing in the framework requires a test. Something in the framework requires you to demonstrate that controls work, and a test is the most credible way most organisations do that. The trap is that the moment you write "annually" into a policy, a control description or a customer contract, that word becomes auditable. ISO 27001 makes this explicit through A.5.36 Compliance with policies, rules and standards for information security. SOC 2 makes it explicit through the control description you wrote yourself.

Category three: not publicly verifiable. HITRUST. The requirement statements sit behind a subscription, so nobody outside the programme can quote a cadence, and everyone who does is quoting each other.

Framework by framework

PCI DSS v4.0.1: the broadest mandate

Requirement 11.4 reads: "External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected." Seven sub-requirements hang off it, and the important detail is that they carry different clocks.

11.4.2 covers internal testing and 11.4.3 covers external testing. Both require testing "At least once every 12 months" and "After any significant infrastructure or application upgrade or change", performed "By a qualified internal resource or qualified external third party" with "Organizational independence of the tester exists (not required to be a QSA or ASV)". That last parenthetical is the single most commonly mis-sold fact in this market: a QSA is not required to run your PCI penetration test.

11.4.1 requires a documented methodology with nine named elements, including coverage of the entire CDE perimeter and critical systems, testing from inside and outside the network, application-layer testing covering at minimum the vulnerabilities in Requirement 6.2.4, network-layer testing across components supporting network functions and operating systems, review of threats experienced in the last 12 months, and retention of results and remediation records for at least 12 months.

11.4.4 is the retest requirement, and it is the one that most affects cost: exploitable findings are corrected in line with the risk assessment under 6.3.1, and "Penetration testing is repeated to verify the corrections."

11.4.5 and 11.4.6 cover segmentation. Every entity using segmentation to isolate the CDE tests those controls at least once every 12 months, and service providers do it every six.

One correction worth carrying: only 11.4.7, the multi-tenant service provider obligation, carried the "best practice until 31 March 2025" applicability note. The 12-month cadences were never future-dated. Full walkthrough in our PCI DSS Requirement 11.4 guide.

NYDFS Part 500: annual, inside and outside

The Second Amendment adopted on 1 November 2023 retitled section 500.5 from "Penetration testing and vulnerability assessments" to "Vulnerability management", and rewrote the obligation. Covered entities must develop written vulnerability management policies and procedures designed to ensure they "conduct, at a minimum: (1) 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".

Three things follow. The cadence is annual and unconditional, with none of the old "absent effective continuous monitoring" escape route. The scope explicitly includes both perspectives, so an external-only test does not satisfy it. And 500.5(a)(2) adds a separate scanning obligation "at a frequency determined by the risk assessment, and promptly after any material system changes", which had an 18-month transition period under 500.22(d)(3). Deeper walkthrough in our NYDFS Part 500 penetration testing guide.

FedRAMP: the most prescriptive on method

FedRAMP inherits NIST SP 800-53 Rev 5 control CA-8, "Conduct penetration testing {frequency} on {systems or system components}", and fills the parameter with "at least annually" across the Low, Moderate and High baselines. CA-8(1) adds: "Employ an independent penetration testing agent or team to perform penetration testing on the system or system components."

The FedRAMP Penetration Test Guidance, Version 3 dated 30 June 2022, is what the canonical FedRAMP URL served during this research pass, and it is far more prescriptive than any other framework here. It sets six mandatory attack vectors: External to Corporate, External to CSP Target System, Tenant to CSP Management System, Tenant to Tenant, Mobile Application to Target System, and Client-side Application or Agents to Target System. On timing it states: "This initial penetration test must be performed no more than 6 months prior to the submission of the SAR. Once within the continuous monitoring phase of the FedRAMP process, additional penetration testing activities must be performed at least every 12 months." On who may test: "All penetration test activities must be performed by a 3PAO that has demonstrated penetration testing proficiency and maintains a defined penetration test methodology. The penetration test team lead must have an industry-recognized credential for penetration testing".

FedRAMP is therefore the only framework in this matrix that constrains the tester's organisation type, the tester lead's credential, and the attack paths that must be exercised.

CMMC: Level 3 only

The word "penetration" appears exactly once in all of 32 CFR part 170, inside a Level 3 requirement. CMMC Levels 1 and 2 place no penetration testing obligation on a contractor, and any vendor telling a Level 2 organisation otherwise is selling against a control that does not exist. Level 3 mandates it through CA.L3-3.12.1e, with a DoD-assigned parameter of at least annually or when significant security changes are made, and it requires both automated tools and ad hoc tests by subject matter experts. Nothing in CMMC requires the Level 3 test to be performed by a third party. Full analysis in does CMMC require a penetration test.

DORA: two clocks, one of them the strictest here

DORA runs two separate testing obligations. The baseline is Article 24(6): "Financial entities, other than microenterprises, shall ensure, at least yearly, that appropriate tests are conducted on all ICT systems and applications supporting critical or important functions." Article 25(1) lists the test types that can satisfy it, penetration testing among them, and Article 24(4) requires that "tests are undertaken by independent parties, whether internal or external".

The advanced tier is threat-led penetration testing. Article 26(1) requires designated entities to "carry out at least every 3 years advanced testing by means of TLPT", with the competent authority able to raise or lower that frequency based on risk profile. Article 27(1) sets five criteria for TLPT testers, covering suitability and reputability, demonstrated expertise in threat intelligence and red team testing, certification by an accreditation body in a Member State or adherence to formal codes of conduct, independent assurance over their own risk management, and professional indemnity insurance. Article 26(8) adds that entities using internal testers must contract external testers every three tests.

Designation is not self-selected. See our DORA threat-led penetration testing guide for the designation criteria, and the TIBER, CBEST and DORA TLPT comparison for how the frameworks relate.

SOC 2: one mention, in a point of focus

Penetration testing appears in the 2017 Trust Services Criteria only inside a point of focus under CC4.1, which lists evaluation types management may use. Points of focus are not criteria and are not requirements. The binding thing is the control description you wrote in your own system description, and if it says annual penetration testing, the auditor tests you against that.

The Type 2 wrinkle is a population problem rather than a cadence problem. A single annual test gives the auditor a population of one, so one missed or late test is a 100 percent exception rate on that control. See SOC 2 penetration testing and SOC 2 Type 2 penetration testing timing.

ISO/IEC 27001:2022: no clause, no control title, no frequency

ISO/IEC 27001:2022 never names penetration testing in any of its clauses, and none of the 93 Annex A control titles contains the word. The standard sets no testing frequency anywhere. What it does require is the comparison against the Annex A reference set at clause 6.1.3 c), a Statement of Applicability at 6.1.3 d), and a determination at clause 9.1 of what you monitor and measure, by what method, and when.

That makes a test the strongest available evidence for A.8.8 Management of technical vulnerabilities, A.8.29 Security testing in development and acceptance, A.8.25 Secure development life cycle, A.5.35 Independent review of information security and A.5.36 Compliance with policies, rules and standards for information security. Full control mapping, evidence wording and audit-cycle timing in our ISO 27001 penetration testing guide.

HIPAA: zero today, twelve months if the proposed rule lands

The word "penetration" appears zero times in 45 CFR part 164 subpart C. The Security Rule requires a risk analysis at 164.308(a)(1)(ii)(A) and a periodic technical and nontechnical evaluation at 164.308(a)(8), and names no test type.

The proposed rule published at 90 FR 898 on 6 January 2025 would change that. It would add, at 45 CFR 164.312(h)(2)(iii): "Penetration testing. Perform penetration testing of the covered entity's or business associate's relevant electronic information systems by a qualified person." A qualified person is defined in the proposed text as someone with appropriate knowledge of and experience with generally accepted cybersecurity principles and methods, and the proposed cadence is: "Penetration testing must be performed at least once every 12 months or in accordance with the covered entity's or business associate's risk analysis required by Sec. 164.308(a)(2), whichever is more frequent."

As of 5 September 2026 the Federal Register lists exactly one document under that rulemaking, the proposed rule. No final rule has been issued, and the current Security Rule text is unchanged. Detail in our HIPAA penetration testing requirements guide.

HITRUST: the row nobody can source

HITRUST is the only framework here where the honest answer is that the requirement text is not public. The CSF requirement statements are delivered under subscription through MyCSF rather than published, and HITRUST's own public pages describing the e1, i1 and r2 assessments do not state a penetration testing requirement or a cadence.

What HITRUST does publish is its Assessment Handbook, and the word "penetration" appears in it exactly twice: once listing "Penetration testing (excluding remediation activities that involve implementation or operation of a control)" as a service an External Assessor may provide without conflicting with its assessor role, and once stating that "Reports used to support direct testing of a requirement statement (such as Penetration Tests, Vulnerability Assessments, Risk Assessments, etc.) should not be included in the Audits and Assessments Utilized webform".

Read carefully, that second line tells you something useful: HITRUST clearly contemplates penetration test reports as evidence supporting direct testing of requirement statements. What it does not tell you is which requirement statements, or how often. Anyone publishing a HITRUST penetration testing cadence is either quoting a licensed document they should not be quoting, or quoting another article. We do neither. See our HITRUST penetration testing requirements guide for what can be said from published sources.

NIS2: risk-based, with no frequency in the Directive

Directive (EU) 2022/2555 sets no testing frequency. Article 21(2) lists ten minimum measure categories, none of which names a test type or a cadence. Point (f) requires policies and procedures to assess the effectiveness of cybersecurity risk-management measures, which is a results obligation rather than a method obligation. Commission Implementing Regulation (EU) 2024/2690 makes security testing mandatory for eleven categories of digital entity, and even there the entity determines the need, scope, frequency and type of tests from its own risk assessment. Full reading in does NIS2 require penetration testing or red teaming.

GDPR: a process, not a test

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". The word "penetration" appears zero times in the Regulation. Article 28(3)(c) pushes the same obligation into processor contracts, and Article 28(3)(h) gives controllers an audit and inspection right that testing evidence is the practical way to satisfy at scale. See GDPR Article 32 and penetration testing for the obligation-to-evidence mapping and a data processing agreement clause template.

OSFI: an expectation in B-13, a supervisory programme in I-CRT

OSFI Guideline B-13, dated 31 July 2022, sets no numeric cadence. It states that federally regulated financial institutions "should set defined triggers, and minimum frequencies, for intelligence-led threat assessments to test cyber security processes and controls", and should "regularly perform tests and exercises, to identify vulnerabilities or control gaps in its cyber security programs (e.g. penetration testing and red teaming) using an intelligence-led approach". The frequency is delegated to the institution.

Separately, OSFI's Intelligence-led Cyber Resilience Testing framework is an Advisory dated 1 April 2023 covering Systemically Important Banks and Internationally Active Insurance Groups on a three-year supervisory cycle, with event-driven assessments possible. That document states plainly that it "is not a policy instrument used to set regulatory expectations". Full detail in our OSFI I-CRT guide.

Which clock actually governs you

Most companies hold more than one of these at once, and the practical planning rule is simple: the most prescriptive framework you hold sets the programme, and everything else consumes the same evidence.

Four worked stacks.

SaaS selling to US enterprises, SOC 2 plus ISO 27001. Neither mandates a test. Both accept one. The binding cadence is whatever your SOC 2 control description and your ISO testing policy say. Write annual with change triggers, place the test inside the SOC 2 observation window, and one engagement serves both.

SaaS taking card payments, add PCI DSS. PCI now sets the clock at 12 months for internal and external testing, plus after any significant change, plus segmentation testing. That clock is stricter than anything SOC 2 or ISO will impose on you, so it becomes the programme, and the SOC 2 and ISO evidence falls out of it.

Healthcare vendor, HIPAA plus HITRUST plus SOC 2. Today nothing mandates a test. Your customers' business associate agreements almost certainly do. Watch the HIPAA rulemaking, because a final rule matching the proposal would put a 12-month floor under the whole sector.

EU financial entity, DORA plus GDPR plus NIS2. DORA governs. Yearly testing of the systems supporting critical or important functions, TLPT every three years if designated, and tester criteria that are stricter than anything else on this page. GDPR Article 32(1)(d) and NIS2 Article 21(2)(f) are both satisfied by the DORA programme's evidence.

One test, many frameworks

Buying a separate test per framework is the most common avoidable cost in this market. Three things make one engagement serve several.

Scope to the intersection first. The systems in your ISO 27001 scope, your SOC 2 system description, your PCI cardholder data environment and your GDPR processing overlap heavily for most SaaS companies. Test that intersection as one engagement, then add framework-specific scope as separate work packages rather than separate engagements.

Make the report carry the metadata every framework asks for. Scope, dates, methodology, tester independence and the retest outcome. Those five items are what PCI 11.4.1, ISO A.8.29, a SOC 2 control description, FedRAMP's SAR attachment and a GDPR Article 28(3)(h) request all want. A report missing tester independence has to be re-explained in every audit.

Track findings once, in one register. The evidence assessors actually chase is not the report, it is the closure trail. One register with severity, owner, dates and retest status answers every framework in this matrix.

Where this stops working is FedRAMP, which requires a 3PAO and six specific attack vectors, and DORA TLPT, which has its own tester criteria and authority involvement. Both are best run as their own engagements.

What the engagement data says

Compliance is the reason these tests get budgeted. Finding things is the reason they are worth budgeting. Across 55 penetration tests and 1,206 verified findings, Stingrai's State of Penetration Testing 2026 recorded that 92.7% of tests surfaced a High or a Critical, that 67.2% of all findings were High or Critical, and that the false-positive rate across the whole set was 0.74%. Where resolution time was tracked, the median Critical closed in 10.5 days and the median High in 38.0 days.

Those remediation medians are the reason the timing advice in every row above says the same thing. PCI 11.4.4 requires a retest. ISO A.8.8 is evidenced by closure. A SOC 2 Type 2 needs the control to have operated inside the window. At a 38-day median for Highs, a test booked four weeks before an assessment produces an open register rather than a closed one.

On cost, published UK rate cards put the median penetration testing day at £1,000 with a central band of £800 to £1,200, and published fixed-fee price lists put a single web application test between £3,750 and £18,000, per Stingrai's Penetration Testing Price Index 2026. Cost tracks scope, not framework. A PCI test and an ISO test of the same estate cost the same; what differs is the documentation around them.

What this means for defenders

• Find out which category you are in before you buy. A mandated cadence is a compliance deadline. A self-imposed cadence is a business decision you can right-size, as long as you write down the one you will actually run.

• Do not let a policy promise more than you fund. In the five evidence-only frameworks, the annual cadence that gets audited is the one in your own document.

• Budget the retest. PCI requires it outright, and every other framework's evidence is stronger with it.

• Get tester independence on paper. PCI, FedRAMP, DORA and ISO A.5.35 all care about it, and one line in the engagement letter satisfies all four.

• Write change triggers as conditions. "Any change that alters an authorisation decision" is auditable. "Major changes" is not, and it is the phrase that turns an annual test into an eleven-month blind spot.

• Watch the HIPAA rulemaking. A final rule matching the January 2025 proposal would move a large sector from category two to category one overnight.

Frequently Asked Questions

Which compliance frameworks require penetration testing?

Five of the twelve on this page name penetration testing in binding requirement text with a stated cadence: PCI DSS v4.0.1 at Requirement 11.4, NYDFS 23 NYCRR 500.5(a)(1), FedRAMP through NIST SP 800-53 control CA-8, CMMC at Level 3 only through CA.L3-3.12.1e, and DORA for financial entities. SOC 2, ISO/IEC 27001:2022, HIPAA as it currently stands, NIS2 and GDPR do not mandate a test and set no frequency, though all five accept one as evidence that a control is operating. HITRUST cannot be answered from published material because its requirement statements are not public.

Does SOC 2 require a penetration test?

No. Penetration testing appears in the 2017 Trust Services Criteria only inside a point of focus under CC4.1, and points of focus are not criteria and are not requirements. What binds you is the control description you wrote in your own system description. If it says annual penetration testing, the auditor tests you against that, and in a Type 2 examination a once-a-year test gives the auditor a population of one, so a single missed or late test is a 100 percent exception rate.

Does ISO 27001 require a penetration test?

No. ISO/IEC 27001:2022 never names penetration testing in any clause, none of the 93 Annex A control titles contains the word, and the standard sets no testing frequency anywhere. A test is the strongest available evidence for A.8.8, A.8.29, A.8.25, A.5.35 and A.5.36, and any cadence you are held to comes from your own policy, your clause 9.1 monitoring plan, your risk treatment plan or a customer contract.

How often does PCI DSS require penetration testing?

Internal testing under 11.4.2 and external testing under 11.4.3 are both required at least once every 12 months and after any significant infrastructure or application upgrade or change. Segmentation testing under 11.4.5 is required at least once every 12 months for all entities, and under 11.4.6 at least once every six months for service providers. Exploitable findings must be corrected and, under 11.4.4, "penetration testing is repeated to verify the corrections". Only 11.4.7, the multi-tenant service provider obligation, carried a future-dated applicability note to 31 March 2025.

Does HIPAA require penetration testing?

Not today. The word "penetration" appears zero times in 45 CFR part 164 subpart C. The Security Rule requires a risk analysis at 164.308(a)(1)(ii)(A) and a periodic evaluation at 164.308(a)(8), and names no test type. A proposed rule published at 90 FR 898 on 6 January 2025 would add a requirement at 164.312(h)(2)(iii) for penetration testing by a qualified person "at least once every 12 months or in accordance with the covered entity's or business associate's risk analysis ... whichever is more frequent". As of 5 September 2026 the Federal Register lists no final rule under that rulemaking.

Does the penetration tester have to be a third party?

It depends entirely on the framework. FedRAMP is the strictest: testing must be performed by a 3PAO and the team lead must hold an industry-recognized penetration testing credential. PCI DSS allows "a qualified internal resource or qualified external third party" provided organisational independence exists, and states explicitly that the tester is "not required to be a QSA or ASV". DORA requires "independent parties, whether internal or external" for baseline testing, and sets five specific criteria for TLPT testers. NYDFS allows "a qualified internal or external party". CMMC, SOC 2 and ISO 27001 impose no third-party requirement at all, though ISO's A.5.35 Independent review of information security makes independence easier to evidence with a third party.

What is the difference between a penetration test and a vulnerability scan for compliance?

They are different controls and most frameworks require both separately. A scan gives frequency and breadth across the estate and evidences that known-vulnerability management is running. A test gives depth on authorisation, business logic, chained attack paths and segmentation, which no scanner reaches. PCI DSS separates them explicitly: quarterly ASV scanning sits at 11.3.2 and does not satisfy 11.4. NYDFS separates them within one section, at 500.5(a)(1) and 500.5(a)(2). A UK regulator has also held that running scans inside a penetration test does not discharge a separate scanning obligation.

Which framework has the strictest penetration testing requirement?

FedRAMP and DORA, for different reasons. FedRAMP constrains the tester's organisation type, the team lead's credential, and the six attack vectors that must be exercised, and it puts the initial test within six months of SAR submission and then every 12 months. DORA sets two clocks, yearly testing of ICT systems supporting critical or important functions and threat-led penetration testing at least every three years for designated entities, with five statutory tester criteria and a rule that internal testers must be alternated with external ones every three tests.

Do I need a separate penetration test for each framework?

Usually no. The systems in your ISO 27001 scope, SOC 2 system description, PCI cardholder data environment and GDPR processing overlap heavily, so one engagement scoped to the intersection can evidence several frameworks at once, provided the report states scope, dates, methodology, tester independence and the retest outcome. The exceptions are FedRAMP, which requires a 3PAO and six specific attack vectors, and DORA threat-led penetration testing, which has its own tester criteria and involves the competent authority. Both are best run as separate engagements.

What penetration testing evidence do auditors and assessors accept?

A bundle, not a document: the policy or control description that states the cadence, the signed scope and rules of engagement, the dated report showing methodology and tester independence, the findings register with severity and owner, the retest confirmation or documented risk acceptance, and evidence that the results reached management. PCI adds a documented 11.4.1 methodology and a 12-month retention requirement. FedRAMP adds the SAR attachment and POA&M entries. The clause-level detail is in our guide to pentest evidence auditors accept.

Does GDPR or NIS2 require an annual penetration test?

Neither one does. GDPR Article 32(1)(d) requires "a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures", with no interval and no named method. NIS2 sets no testing frequency in the Directive, and its Article 21(2)(f) obligation is to assess the effectiveness of risk-management measures rather than to run a specific test. In both cases the defensible cadence is argued from the risk of the processing or the service, the rate of change in the systems, and any commitment you made contractually.

Where can I check a framework's penetration testing requirement myself?

Go to the publisher, not to a summary. PCI DSS is at the PCI SSC Document Library. NYDFS Part 500 is on the DFS site. FedRAMP's guidance is on fedramp.gov. HIPAA and CMMC are on eCFR. DORA, NIS2 and GDPR are on EUR-Lex. OSFI's guidance is on osfi-bsif.gc.ca. ISO standards are purchasable from ISO, with clause titles readable free on its Online Browsing Platform.

Related reading

• Pentest evidence auditors accept: SOC 2, ISO 27001, PCI DSS and CMMC, the clause-level evidence guide.

• Compliance and regulation pentesting services, the vendor shortlist for compliance-driven testing.

• PCI DSS penetration testing: Requirement 11.4 explained.

• ISO 27001 penetration testing requirements.

• SOC 2 penetration testing and SOC 2 Type 2 testing timing.

• HIPAA penetration testing requirements and HITRUST penetration testing requirements.

• NYDFS Part 500 penetration testing.

• GDPR Article 32 and penetration testing.

• Does CMMC require a penetration test and does NIS2 require penetration testing or red teaming.

• DORA threat-led penetration testing and OSFI I-CRT intelligence-led red teaming.

• Penetration Testing Price Index 2026 and The State of Penetration Testing 2026.

References

1. PCI Security Standards Council. PCI DSS v4.0.1, Requirements and Testing Procedures. June 2024. https://www.pcisecuritystandards.org/document_library/. Requirement 11.4 and sub-requirements 11.4.1 to 11.4.7, including the 12-month and six-month cadences and the tester independence wording.

2. PCI Security Standards Council. Information Supplement: Penetration Testing Guidance, version 1.1. September 2017. https://listings.pcisecuritystandards.org/documents/Penetration-Testing-Guidance-v1_1.pdf. Organisational independence of the tester and methodology guidance.

3. New York State Department of Financial Services. Second Amendment to 23 NYCRR Part 500, Cybersecurity Requirements for Financial Services Companies. Adopted 1 November 2023. https://www.dfs.ny.gov/system/files/documents/2023/10/rf_fs_2amend23NYCRR500_text_20231101.pdf. Section 500.5 as amended, including 500.5(a)(1), 500.5(a)(2), 500.5(c) and the transition periods at 500.22.

4. FedRAMP. FedRAMP Penetration Test Guidance, Version 3. 30 June 2022. https://www.fedramp.gov/resources/documents/CSP_Penetration_Test_Guidance.pdf. Six mandatory attack vectors, the six-month and 12-month timing rules, and the 3PAO staffing requirements.

5. NIST. SP 800-53 Revision 5, Security and Privacy Controls for Information Systems and Organizations. https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final. Control CA-8 Penetration Testing and enhancement CA-8(1) Independent Penetration Testing Agent or Team.

6. US Government. 32 CFR part 170, Cybersecurity Maturity Model Certification (CMMC) Program. https://www.ecfr.gov/current/title-32/subtitle-A/chapter-I/subchapter-G/part-170. Contains the single CMMC penetration testing requirement, at Level 3.

7. European Union. Regulation (EU) 2022/2554 (DORA). https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R2554. Articles 24 to 27 covering the digital operational resilience testing programme, tester independence, and threat-led penetration testing at least every three years.

8. European Union. Directive (EU) 2022/2555 (NIS2). https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022L2555. Article 21(2) minimum measures, including point (f) on assessing the effectiveness of risk-management measures.

9. European Union. Regulation (EU) 2016/679 (GDPR). https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679. Article 32(1)(d) and the Article 28 processor obligations.

10. US Department of Health and Human Services, Office for Civil Rights. HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information, proposed rule. 90 FR 898, 6 January 2025, RIN 0945-AA22. https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information. Proposed 45 CFR 164.312(h)(2)(iii) penetration testing requirement and its 12-month cadence.

11. US Government. 45 CFR part 164 subpart C, Security Standards for the Protection of Electronic Protected Health Information. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C. The current Security Rule text, which names no test type.

12. HITRUST. HITRUST Assessment Handbook, version 1.2. https://hitrustalliance.net/hubfs/Website/PDF%20Downloads/Final%20-%20HITRUST%20Assessment%20Handbook%20v1.2.pdf. The only HITRUST-published document retrieved in this pass that mentions penetration testing, and it does so as a permitted assessor service and as evidence handling, not as a requirement.

13. AICPA. TSP Section 100, 2017 Trust Services Criteria with Revised Points of Focus, 2022. https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022. Penetration testing appears only within a point of focus under CC4.1.

14. ISO. ISO/IEC 27001:2022. https://www.iso.org/standard/27001. Third edition, October 2022. Clause structure and Annex A reference set, with control titles readable on the ISO Online Browsing Platform.

15. International Accreditation Forum. IAF MD 26:2023, Transition Requirements for ISO/IEC 27001:2022, Issue 2. https://iaf.nu/iaf_system/uploads/documents/IAF_MD26_Issue_2_15012023.pdf. Source of the 93-control Annex A reference set figure.

16. Office of the Superintendent of Financial Institutions. Guideline B-13, Technology and Cyber Risk Management. 31 July 2022. https://www.osfi-bsif.gc.ca/en/guidance/guidance-library/technology-cyber-risk-management. Sections 3.1.2 and 3.1.3 on intelligence-led testing and vulnerability assessment, with frequency delegated to the institution.

17. Office of the Superintendent of Financial Institutions. OSFI's Intelligence-led Cyber Resilience Testing (I-CRT) Framework. Advisory, 1 April 2023. https://www.osfi-bsif.gc.ca/en/guidance/guidance-library/osfis-intelligence-led-cyber-resilience-testing-crt-framework. Scope, three-year supervisory cycle, and the statement that the document is not a policy instrument setting regulatory expectations.

18. Stingrai. The State of Penetration Testing 2026. https://www.stingrai.io/blog/state-of-penetration-testing-2026. 1,206 verified findings across 55 penetration tests, severity mix, false-positive rate and remediation timing by severity.

19. Stingrai. Penetration Testing Price Index 2026. https://www.stingrai.io/blog/penetration-testing-price-index-2026. Median published day rate, central band and published fixed-fee ranges.

20. Stingrai. Pricing. https://www.stingrai.io/pricing. Published package prices for one web application and its APIs.

Map your frameworks to one testing programme

If you hold more than one of the frameworks in this matrix, the cheapest correct answer is almost never one engagement per framework. It is one scope built on the intersection, one report carrying the metadata every assessor asks for, and one findings register that every audit can read. Stingrai's penetration testing supports SOC 2, ISO 27001, PCI DSS, HIPAA, NIST SP 800-53 and 800-171, DORA and NIS2 programmes by producing exactly that: signed scope and rules of engagement, a dated report naming method and tester independence, a tracked findings register, and a retest that closes it. We run both one-time annual engagements and continuous testing programmes, with senior penetration testers working the target alongside Snipe, our autonomous web application agent, throughout.

Book a free scoping call to map your frameworks to a single scope, request a quote for that scope, or see published package prices on the pricing page.