Compliance-to-Pentest
Matrix
Which compliance frameworks require penetration testing, what kind, and how often. One reference. No ambiguity.
10
Frameworks
4
Require Pentesting
3
Expect Pentesting
"Do we need a pentest for compliance?" is the most common question we hear from VCISOs and IT leaders. The answer depends on the framework, and the language is rarely straightforward. Some frameworks mandate it. Others imply it. A few leave it open to interpretation -- until an auditor or regulator decides otherwise.
This matrix cuts through the ambiguity. It maps 10 major compliance frameworks to their actual penetration testing requirements, specifies the types of testing needed, and flags the gotchas that trip up organizations during audits and assessments.
Requirement Levels
Required
Framework legally mandates security testing, by name or by binding "shall be tested/resilient" language
Expected
Not explicitly mandated, but auditors will ask for it
Recommended
Framework recommends security testing; pentest is the accepted method
Quick Reference Matrix
Side-by-side comparison across all 10 frameworks. Scroll horizontally on mobile.
| Framework | Requirement | Frequency | Key Citation | Pentest Types |
|---|---|---|---|---|
| PCI DSS v4.0.1 | Required | Annual + after significant changes | Req. 11.4.2 / 11.4.3 | External, Internal, Segmentation |
| SOC 2 | Expected | Annual (de facto) | CC4.1, CC7.1 | External, Internal, Web App |
| HIPAA | Recommended | Annual (industry standard) | 45 CFR 164.308 | External, Internal, Web App |
| ISO 27001 | Expected | Annual | A.8.8, A.5.36 (2022) | External, Internal, Web App |
| CMMC Level 2+ | Expected | Annual / per assessment cycle | Multiple practices | External, Internal, Web App |
| NIST CSF 2.0 | Recommended | Not prescribed | ID.RA, PR.PS, DE.CM | Varies by implementation |
| FedRAMP | Required | Annual | FedRAMP Pentest Guidance | External, Internal, Web App |
| NY DFS (23 NYCRR 500) | Required | Annual | Section 500.5 | External, Internal |
| GDPR | Recommended | Regular (not specified) | Article 32(1)(d) | External, Web App |
| EU AI Act | Required | Per risk assessment cycle | Art. 15(4) | AI/ML, Web App, API |
Detailed Framework Breakdowns
What each framework actually says, what auditors look for, and what catches organizations off guard.
PCI DSS v4.0.1
Payment Card Industry Data Security Standard
| Key Requirement | Requirements 11.4.2 and 11.4.3 mandate internal and external penetration testing (respectively) at least annually and after any significant infrastructure or application change. Requirement 11.3.2 requires quarterly external ASV scans (11.3.1 covers quarterly internal scans). Requirement 11.4.6 requires segmentation controls to be tested every six months for service providers, on top of the 11.4.5 annual segmentation test required of all entities. |
|---|---|
| Frequency | Annual at minimum. After significant changes (network architecture, OS upgrades, new system components, web server software changes). Segmentation testing every 12 months for all entities, every 6 months for service providers. |
| Pentest Types |
|
| Scope | All systems in the cardholder data environment (CDE), connected systems, and systems that could impact CDE security. The pentest must validate that segmentation controls are operational and effective. |
Common Gotchas
- "Significant change" is broadly defined. A firewall rule update, adding a new VLAN, or updating payment application software all qualify. Many organizations miss the re-test trigger.
- PCI DSS v4.0.1 requires the tester to follow a recognized methodology (NIST SP 800-115, OSSTMM, PTES). Simply running a vulnerability scanner does not satisfy 11.4.2/11.4.3.
- QSAs will reject automated-only results. The test must include manual exploitation attempts.
- Segmentation testing is frequently overlooked. If you claim segmentation reduces scope, you must prove it works.
Full breakdown: PCI DSS 4.0 Penetration Testing Requirements.
SOC 2
Service Organization Control 2 (AICPA Trust Services Criteria)
| Key Requirement | CC7.1 requires the entity to use detection and monitoring procedures to identify changes to configurations that introduce new vulnerabilities, and susceptibility to newly discovered vulnerabilities — commonly satisfied by vulnerability scanning. Penetration testing is explicitly named one control over, in CC4.1's points of focus: management uses ongoing and separate evaluations, "including penetration testing," to assess whether controls are present and functioning. Type II auditors expect it as evidence of proactive security testing. |
|---|---|
| Frequency | The Trust Services Criteria do not specify a testing frequency. Annual, aligned with the SOC 2 audit period, is the de facto industry standard and what auditors expect to see within the 12-month observation window. |
| Pentest Types |
|
| Scope | Systems in scope for the SOC 2 report. This typically includes production infrastructure, customer-facing applications, and supporting systems that process, store, or transmit customer data. |
Common Gotchas
- Organizations assume "not required" means "not needed." Auditors will ask for penetration test results. Not having one creates a finding or a qualification in the report.
- A vulnerability scan is not a penetration test. Auditors know the difference. Submitting a Nessus or Qualys report as your "pentest" will be flagged.
- Remediation evidence matters as much as the test itself. Auditors want to see findings, remediation actions, and retest confirmation.
- If your SOC 2 report covers the Security and Availability trust criteria, the expectation for a pentest is even stronger.
Full breakdown: SOC 2 Penetration Testing Requirements.
HIPAA
Health Insurance Portability and Accountability Act
| Key Requirement | The HIPAA Security Rule (45 CFR 164.308(a)(1)(ii)(A)) requires covered entities and business associates to conduct an accurate and thorough risk analysis. The paired Risk Management implementation specification, 45 CFR 164.308(a)(1)(ii)(B), requires implementing security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level. Penetration testing is not named, but it is the most effective way to identify technical vulnerabilities in systems that handle ePHI. |
|---|---|
| Frequency | The Security Rule says "regular" without defining a cadence. Annual testing is the industry standard. OCR has cited the absence of technical security testing in multiple enforcement actions. |
| Pentest Types |
|
| Scope | All systems that create, receive, maintain, or transmit electronic protected health information (ePHI). This includes EHR systems, patient portals, medical devices on the network, and cloud environments. |
Common Gotchas
- OCR enforcement actions frequently reference "failure to conduct a thorough risk analysis." A vulnerability scan alone does not meet this bar. Pentesting demonstrates that you tested for exploitability, not just the presence of vulnerabilities.
- Business associates are held to the same standard as covered entities. Third-party vendors that handle ePHI need their own testing.
- After a breach, OCR will examine your testing history. Organizations without regular pentests face larger fines and longer corrective action plans.
- Medical device networks often go untested. If devices are on the same network as ePHI systems, they are in scope.
Full breakdown: HIPAA Penetration Testing Requirements.
ISO 27001
Information Security Management System (ISMS)
| Key Requirement | ISO/IEC 27001:2022 Annex A.8.8 (Management of Technical Vulnerabilities) requires obtaining vulnerability information, evaluating exposure, and taking appropriate measures. Annex A.5.36 (Compliance with Policies, Rules and Standards for Information Security) requires regular review that systems comply with security implementation standards. Annex A.8.34 additionally requires protecting systems during audit and testing activities. Penetration testing is the standard method to demonstrate technical compliance and is expected by certification auditors. |
|---|---|
| Frequency | Annual. Aligned with the ISMS review cycle. Surveillance audits (annual) and recertification audits (every 3 years) will both check for recent test results. |
| Pentest Types |
|
| Scope | Systems within the ISMS scope. The scope is defined during certification and typically covers production systems, corporate infrastructure, and externally-facing services. |
Common Gotchas
- The standard says "technical compliance review," not "penetration test." But auditors interpret this as requiring a pentest. Relying on vulnerability scans alone creates a nonconformity risk.
- ISO 27001:2022 updated Annex A controls. Make sure your testing addresses the current version, not the 2013 control set.
- Auditors will verify that findings from pentests feed into your risk treatment plan. A test without follow-up is a nonconformity.
- Scope creep is common. If your ISMS scope expands, your pentest scope must expand to match.
Full breakdown: ISO 27001 Security Testing Requirements.
CMMC Level 2+
Cybersecurity Maturity Model Certification
| Key Requirement | CMMC Level 2 maps to the 110 practices in NIST SP 800-171 Revision 2. Risk assessment (RA.L2-3.11.1), security assessment (CA.L2-3.12.1), and system and communications protection practices all benefit from penetration testing. Level 3 (Expert) has additional requirements drawn from NIST SP 800-172 that more directly call for adversarial testing. DoD contractors handling CUI must demonstrate they can identify and address vulnerabilities. |
|---|---|
| Frequency | Level 2 runs on a triennial (3-year) assessment cycle with annual affirmations in between. Third-party C3PAO assessment applies only to prioritized acquisitions handling critical CUI when a contract explicitly requires it — most Level 2 work instead uses Level 2 self-assessment. Note: DoD suspended the "Phase 2" rollout that would have made C3PAO assessment a default condition of award (July 2026 memo, converted to a binding class deviation September 2026); contracting officers are currently directed to strip third-party-assessment requirements from solicitations pending a CMMC Reform Task Force review. Annual pentesting still supports continuous compliance regardless of assessment path. |
| Pentest Types |
|
| Scope | All systems that process, store, or transmit Controlled Unclassified Information (CUI). This includes endpoints, servers, network infrastructure, and cloud environments within the CUI boundary. |
Common Gotchas
- CMMC assessors are looking for evidence of proactive security testing, not just policies. Having a penetration test report significantly strengthens multiple practice areas.
- Many contractors underestimate their CUI scope. Systems that touch CUI indirectly (email, file shares, backup systems) are in scope.
- CMMC Level 3 references NIST SP 800-172, which includes red team exercises and adversarial simulation. Basic vulnerability scanning will not satisfy these requirements.
- Subcontractors in the supply chain also need appropriate testing. Prime contractors are responsible for flow-down requirements.
- The C3PAO third-party assessment requirement is in flux following the 2026 Phase 2 suspension. Don't assume self-assessment is a permanent exemption — check your specific contract's current CMMC clause, since the Reform Task Force review could reinstate third-party requirements.
NIST CSF 2.0
National Institute of Standards and Technology Cybersecurity Framework
| Key Requirement | ID.RA (Risk Assessment, under Identify) calls for identifying and documenting vulnerabilities. PR.PS (Platform Security, under Protect — the CSF 2.0 category that absorbed the vulnerability and patch management outcomes covered by a retired CSF 1.1 category) includes security testing in its implementation guidance. DE.CM (Continuous Monitoring, under Detect) recommends monitoring and testing to detect cybersecurity events. The framework is intentionally non-prescriptive but positions security testing as a core component of risk management. |
|---|---|
| Frequency | Not prescribed. The framework is risk-based, so frequency depends on the organization's risk profile, threat environment, and rate of change. Annual testing is the most common implementation. |
| Pentest Types |
|
| Scope | Determined by the organization based on critical assets, business processes, and risk appetite. The framework does not define a fixed scope. |
Common Gotchas
- Because NIST CSF is voluntary and non-prescriptive, organizations sometimes interpret "recommended" as optional. But many regulatory bodies and industry standards reference NIST CSF as a baseline. If you claim alignment, you need evidence of security testing.
- NIST CSF 2.0 (released 2024) added the Govern function and expanded guidance on supply chain risk. Testing should reflect these updates.
- Insurance carriers increasingly reference NIST CSF in underwriting questionnaires. Claiming a high maturity tier without a pentest creates a misrepresentation risk.
FedRAMP
Federal Risk and Authorization Management Program
| Key Requirement | FedRAMP requires an annual penetration test conducted by an independent third-party assessor (3PAO). The test must follow FedRAMP's penetration test guidance document, which specifies methodology, scope, and reporting requirements. Monthly vulnerability scanning is also required with 30-day remediation for high-risk findings. |
|---|---|
| Frequency | Annual penetration test. Monthly vulnerability scanning. Continuous monitoring with ConMon reporting. |
| Pentest Types |
|
| Scope | The entire FedRAMP authorization boundary, including all system components, interconnections, and data flows. Cloud infrastructure, management planes, and customer-facing interfaces are all in scope. |
Common Gotchas
- The penetration test must be performed by an accredited 3PAO. Internal testing or testing by a non-accredited firm does not satisfy the requirement.
- FedRAMP pentest reports must follow a specific format. A standard pentest report will need to be reformatted or supplemented to meet the program's reporting requirements.
- High-risk findings from the pentest must be remediated within 30 days. Moderate findings within 90 days. This timeline is enforced during continuous monitoring reviews.
- FedRAMP is transitioning to "FedRAMP 20x" under the 2026 Consolidated Rules (mandatory for new Low/Moderate authorizations by January 1, 2027), which replaces the Rev 5 control catalog with continuously-validated Key Security Indicators for those baselines. Rev 5 remains in force for existing authorizations and for the former High baseline, which has no 20x path yet — confirm which track your 3PAO is testing against.
- 2026 guidance closed a common loophole: penetration testing must now run against live production environments, not a staging environment standing in for it.
NY DFS (23 NYCRR 500)
New York Department of Financial Services Cybersecurity Regulation
| Key Requirement | Section 500.5 ("Vulnerability Management" as renamed by the 2023 Second Amendment) requires annual penetration testing from both inside and outside the information systems' boundaries by a qualified internal or external party. The fixed bi-annual vulnerability assessment that the original 2017 rule required was replaced by risk-based automated scans plus manual review of systems the scans don't cover, at a frequency set by the entity's own risk assessment and promptly after material system changes. Class A companies face additional requirements, including independent audits of their cybersecurity program, with frequency likewise tied to their risk assessment. |
|---|---|
| Frequency | Annual penetration test (unchanged since 2017). Risk-based automated scanning and manual review in place of the old fixed bi-annual cadence, effective since May 1, 2025. After material changes to systems or infrastructure. |
| Pentest Types |
|
| Scope | All information systems of the covered entity. This is broad and includes any systems that store, process, or transmit nonpublic information (NPI). Banks, insurance companies, and financial services firms licensed by NY DFS are covered. |
Common Gotchas
- The 2023 amendments to 23 NYCRR 500 tightened requirements significantly. Organizations relying on pre-amendment compliance programs may have gaps.
- NY DFS applies to any financial services company operating in New York, even if headquartered elsewhere. Out-of-state firms often discover they are covered late.
- The regulation requires the CISO to report material findings to the board. Pentest results must flow into governance processes, not just sit in an IT folder.
- The 72-hour cybersecurity-incident notification to the Superintendent (Section 500.17(a)) applies. If a pentest reveals evidence of a prior breach, it may trigger notification obligations. The 2023 amendment added a separate 24-hour extortion-payment notice on top of it.
GDPR
General Data Protection Regulation (EU)
| Key Requirement | Article 32(1)(d) requires controllers and processors to implement "a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing." Penetration testing is the most widely accepted method to satisfy the "testing and assessing" component. Data protection authorities across the EU have referenced penetration testing as a recommended practice. |
|---|---|
| Frequency | "Regularly" is not defined. Annual testing is the accepted standard. Organizations processing sensitive personal data (health, financial, children's data) should consider more frequent testing. |
| Pentest Types |
|
| Scope | All systems that process personal data of EU residents. This includes customer-facing web applications, backend databases, APIs, third-party integrations, and cloud infrastructure. |
Common Gotchas
- GDPR applies to any organization processing EU residents' data, regardless of where the company is located. US companies with EU customers are in scope.
- GDPR fines are two-tiered: up to €10M or 2% of global turnover (Article 83(4)) for security-of-processing failures under Article 32, and up to €20M or 4% (Article 83(5)-(6)) for violations of core principles, consent, data-subject rights, or transfer rules. A missing testing program caps at the 2% tier on its own, but a DPA investigating a separate 4%-tier breach will cite it as an aggravating factor.
- Processors (vendors) are directly liable under GDPR. If you process data on behalf of an EU controller, you need your own testing program.
- Data Protection Impact Assessments (DPIAs) for high-risk processing should reference penetration test findings. DPAs expect this connection.
EU AI Act
Regulation (EU) 2024/1689 on Artificial Intelligence
| Key Requirement | Articles 9 and 15 require providers of high-risk AI systems to implement risk management processes and ensure accuracy, robustness, and cybersecurity. Article 15(4) specifically requires high-risk AI systems to be resilient against attempts by unauthorized third parties to exploit vulnerabilities. Security testing of AI/ML components -- including adversarial testing, model robustness evaluation, and API security assessment -- is the practical method to demonstrate compliance. |
|---|---|
| Frequency | Throughout the AI system lifecycle. Initial conformity assessment plus ongoing monitoring. Testing should align with the risk management cycle defined in Article 9. |
| Pentest Types |
|
| Scope | High-risk AI systems as classified by the regulation (Annex III). This includes AI used in critical infrastructure, education, employment, essential services, law enforcement, and migration. The scope covers the AI model, training pipeline, inference infrastructure, and all interfaces. |
Common Gotchas
- Traditional penetration testing alone is insufficient. AI systems require specialized testing for model evasion, data poisoning, prompt injection, and adversarial inputs.
- The regulation is phased and largely already in force. Prohibited AI practices have been enforced since February 2, 2025. High-risk system requirements (Annex III) took effect August 2, 2026 — organizations deploying high-risk AI now need to demonstrate compliance, not prepare for a future deadline. Legacy high-risk systems already on the market before that date get until August 2, 2027 (extended to December 31, 2030 for AI embedded in regulated products like medical devices).
- Documentation requirements are extensive. Conformity assessments must include evidence of cybersecurity testing. Test reports need to address AI-specific attack vectors.
- General-purpose AI models (GPAI) have their own obligations under Article 53. Even if your system is not "high-risk," GPAI requirements may still apply.
Voke Cyber provides specialized security testing for AI and ML systems, including adversarial robustness testing, API security assessment, and EU AI Act conformity support.
EU AI Act Testing
Need a Compliance-Driven Pentest?
We scope every engagement to your compliance requirements. Tell us which frameworks apply, and we will deliver a test that satisfies your auditors.