Is Penetration Testing Mandatory? What Compliance Frameworks Actually Require
Guest Authored by Kaycie Waldman at Software Secured
A penetration test can be essential for compliance even when not explicitly required by the framework you're following by providing technical evidence that complements audit and compliance requirements. PCI DSS contains specific penetration testing requirements. SOC 2, ISO 27001, and the current HIPAA Security Rule take a less prescriptive approach. They ask organizations to evaluate controls, manage vulnerabilities, assess risk, or test security without always mandating a penetration test by name.
The request sometimes comes from outside the framework itself. An auditor may expect evidence that controls work in practice. An enterprise customer may request a recent penetration test as part of a security review. A contract may require annual testing regardless of what the underlying compliance framework says.
| Framework | Is penetration testing explicitly required? | What drives the requirement? | Frequency |
|---|---|---|---|
| SOC 2 | No | The Trust Services Criteria require organizations to evaluate whether controls are present and functioning. Penetration testing is one possible method of evaluating controls under CC4.1. | Not prescribed by SOC 2 itself |
| ISO 27001 | No | The standard takes a risk-based approach to information security. Annex A includes controls addressing technical vulnerability management and security testing, while ISO 27002 provides implementation guidance for security testing, including penetration testing. | Risk-based; periodic testing may be appropriate |
| HIPAA | No, under the current Security Rule | The Security Rule requires risk analysis, evaluation, and implementation of appropriate security measures. A proposed rule would explicitly require annual compliance audits and penetration testing. | Currently risk-based; annual testing has been proposed |
| PCI DSS v4.0.1 | Yes, when Requirement 11.4 applies | PCI DSS includes specific requirements for internal and external penetration testing, including testing methodology, remediation, and retesting where applicable. | At least annually and after significant changes for applicable environments |
Does SOC 2 Require Penetration Testing?
Not explicitly, but penetration testing is directly relevant to the SOC 2 Trust Services Criteria.
SOC 2 is an attestation framework built around the AICPA Trust Services Criteria. Security, represented by the Common Criteria, is included in every SOC 2 examination. Other categories, such as Availability, Confidentiality, Processing Integrity, and Privacy, are added depending on the organization's commitments and systems.
The clearest connection to penetration testing is CC4.1. It requires an organization to perform ongoing and/or separate evaluations to determine whether components of internal control are present and functioning. The AICPA's Points of Focus specifically identify penetration testing and vulnerability assessments as examples of evaluations management can consider.
A penetration test can also produce evidence relevant to access and security controls. Testing authentication, role-based access controls, privilege escalation, external defenses, and unauthorized data access can support controls across the CC6 family.
That does not mean SOC 2 says every company must perform an annual penetration test. It means a well-scoped test can provide strong evidence that controls documented on paper actually withstand an attack.
This distinction becomes especially important during SOC 2 Type 2, where the auditor evaluates whether controls operated effectively throughout an observation period rather than assessing their design at a single point in time.
Does ISO 27001 Require Penetration Testing?
ISO/IEC 27001:2022 does not prescribe penetration testing as a universal requirement either.
Instead, ISO 27001 requires organizations to build an Information Security Management System around their specific risks. Annex A contains 93 reference controls that organizations evaluate through their risk assessment and Statement of Applicability.
Two controls are particularly relevant to penetration testing:
A.8.8, Management of Technical Vulnerabilities
A.8.29, Security Testing in Development and Acceptance
ISO 27002, the companion implementation guidance for ISO 27001 controls, references periodic penetration testing as part of implementing technical vulnerability management.
Clause 9.1 also requires organizations to determine how they will monitor, measure, analyze, and evaluate the effectiveness of their ISMS. A penetration test can provide objective evidence that technical controls work against realistic attack paths rather than simply showing that the controls have been configured.
The important word here is risk-based. Your testing scope should follow your ISMS boundary and the risks identified through your ISO 27001 program. A SaaS application handling sensitive customer information may justify extensive application, API, cloud, and access-control testing. Another organization may have a different scope based on its systems and Statement of Applicability.
Software Secured's ISO 27001 penetration testing service covers how penetration testing can support technical control validation during ISO 27001 certification.
Does PCI DSS Require Penetration Testing?
PCI DSS differs because it explicitly addresses penetration testing.
Under PCI DSS v4.0.1, Requirement 11 separates vulnerability scanning from penetration testing. For environments where Requirement 11.4 applies, organizations must conduct penetration testing at least annually and after significant changes, with requirements that cover both internal and external testing.
A significant change can include adding or upgrading hardware or software in the cardholder data environment, changing how account data flows or is stored, modifying the boundaries of the cardholder data environment, or making changes to supporting infrastructure. PCI SSC emphasizes that whether a change is "significant" depends on the organization's environment and risk.
PCI DSS also makes another distinction that matters beyond payment security: vulnerability scanning and penetration testing are separate activities. A clean vulnerability scan does not substitute for an applicable penetration testing requirement.
If segmentation is used to reduce PCI scope, that segmentation must also be tested. Vulnerabilities identified through penetration testing must be remediated and successfully retested.
PCI DSS v4.0.1 is currently the active version of the standard. PCI SSC retired v4.0 at the end of 2024, and the future-dated v4.x requirements became effective on March 31, 2025.
Does HIPAA Require Penetration Testing?
Under the current HIPAA Security Rule, penetration testing is not explicitly required by name.
The Security Rule instead requires covered entities and business associates to implement administrative, physical, and technical safeguards to protect electronic protected health information (ePHI).
Penetration testing can support several of those obligations. The strongest connection is 45 CFR §164.308(a)(8), Evaluation, alongside the required risk analysis under §164.308(a)(1)(ii)(A). Testing can also validate technical safeguards around access control, authentication, audit controls, and transmission security.
There is an important regulatory development to watch.
In December 2024, HHS proposed a major update to the HIPAA Security Rule that would explicitly require vulnerability scanning at least every six months and penetration testing at least once every 12 months. The proposal would also strengthen requirements around MFA, encryption, network segmentation, asset inventories, and risk analysis.
As of this writing, those annual penetration testing requirements are proposed rather than final. HHS states that the current Security Rule remains in effect while rulemaking continues.
That distinction is important for any organization planning its compliance program. Annual penetration testing may be a sensible security practice and could become an explicit HIPAA requirement, but it should not currently be described as a universal annual requirement under the existing Security Rule.
Can I Use Last Year's Penetration Test?
Sometimes. A penetration test is a snapshot of a system, its scope, and attack surface at a specific point in time. If the application, infrastructure, authentication model, APIs, integrations, or network architecture have changed substantially since the test, an old report may no longer represent the system an auditor or customer is evaluating.
Framework requirements also differ.
PCI DSS is explicit about testing after significant changes when its penetration testing requirements apply. SOC 2 and ISO 27001 take a more risk-based approach, so it’s important to note whether your existing evidence still demonstrates that the controls and systems currently in scope are operating effectively.
For fast-moving SaaS teams, annual testing alone can be a poor fit, even when it satisfies the baseline compliance cadence. More frequent testing can focus on material changes between larger assessments rather than waiting for the next annual test.
Do I Need to Fix Every Finding Before My Audit?
Finding a vulnerability does not automatically mean you fail an audit. Auditors generally care about what the finding says about the underlying control and how the organization responds. That makes the remediation trail important: what was found, how it was assessed, who owned the fix, when it was remediated, and whether the remediation was verified.
For SOC 2, for example, CC4.2 addresses the evaluation and communication of internal control deficiencies so corrective action can be taken. Software Secured's SOC 2 evidence checklist maps the pentest report, remediation tracking, and retest evidence back to CC4.1 and CC4.2.
PCI DSS goes further where Requirement 11.4 applies. Vulnerabilities identified during penetration testing must be remediated according to risk and retested to confirm the remediation was successful.
The exact remediation timeline can depend on the framework, severity, organizational policy, contractual obligations, and auditor or assessor expectations. A universal "critical findings in X days, high findings in Y days" rule does not apply across all four frameworks.
What Happens If I Skip Penetration Testing?
That depends on why you needed the test in the first place.
For PCI DSS, skipping required testing can create a direct compliance gap.
For SOC 2, ISO 27001, or HIPAA, the issue may be less direct. You still need evidence that applicable security controls, risk-management processes, and technical safeguards are operating effectively. If you choose not to use penetration testing, you need to understand what evidence will demonstrate that instead.
There is also a requirement that exists outside formal compliance frameworks: your customers' contracts and security reviews.
An organization can satisfy the letter of a framework and still have an enterprise buyer ask for a recent third-party penetration test before approving the vendor.
The practical requirement is therefore sometimes stricter than the framework itself.
How to tell the difference between vulnerability scanning and Pentesting.
Vulnerability scanning and penetration testing solve related but different problems.
A vulnerability scanner automatically looks for known vulnerabilities, outdated software, exposed services, and common misconfigurations. That makes scanning valuable for frequent or continuous coverage.
A penetration tester goes further by attempting to validate whether vulnerabilities can be exploited and by examining context-dependent attack paths. That can include chaining multiple weaknesses together, testing authorization between user roles, and identifying business logic flaws that automated tools struggle to understand.
PCI DSS makes the distinction particularly clear by treating vulnerability scanning and penetration testing as separate requirements.
The same distinction matters when defining a testing program for other frameworks. Continuous scanning can tell you what may be vulnerable while a manual penetration test can tell you what an attacker can actually do with it. Understand the difference in more detail here.
Do I Need Black-Box or Gray-Box Penetration Testing?
The right testing method should follow the risk you are trying to validate.
Black-box testing gives the tester little or no prior access and is useful for evaluating what an unauthenticated external attacker can discover and exploit.
Gray-box testing gives the tester limited legitimate access, such as credentials for defined user roles. That allows the test to examine what happens after authentication, including broken access controls, privilege escalation, cross-account or cross-tenant access, and application-specific business logic.
For SaaS applications, authenticated testing is particularly important when authorization determines which customers, users, or administrators can access sensitive functionality or data.
The scope should follow the actual attack surface rather than a blanket rule to test everything. For SOC 2, for example, Software Secured maps common scope areas to the documented system boundary, including web applications, APIs, cloud infrastructure, authentication systems, internal networks, and third-party integrations.
How Long Does a Penetration Test Take, and When Should I Start?
A typical engagement may take roughly two to three weeks from kickoff through testing, followed by quality assurance and final reporting. The exact timeline depends on scope, application complexity, testing methodology, access requirements, and the number of systems involved.
If compliance is driving the deadline, work backward from the audit or assessment date rather than from the day you want testing to begin.
Leave time for three separate activities:
Testing and reporting.
Remediation by your engineering or IT team.
Retesting to verify that important findings were actually resolved.
Starting a penetration test immediately before an audit can leave you with a technically complete report but no time to address what the test uncovered.
So, What Penetration Testing Do You Actually Need?
There is no single penetration testing requirement that applies to every compliance framework.
PCI DSS can explicitly require penetration testing for applicable environments. SOC 2 and ISO 27001 focus more on demonstrating that security controls and risk-management processes operate effectively. The current HIPAA Security Rule requires risk analysis, evaluation, and technical safeguards, while HHS has proposed making annual penetration testing explicit.
That means scope should start with four questions:
Which framework are you being assessed against?
What systems and controls are actually in scope?
What evidence does your auditor or assessor need to evaluate those controls?
Have your customers or contracts imposed testing requirements beyond the framework itself?
Answer those before choosing a pentest-scope.
The goal is not to buy the largest penetration test possible or to find the smallest test you can get away with. It is to produce credible evidence that the systems and controls your business depends on hold up when someone actively tries to break them.
If penetration testing is part of that evidence, scope it around the risk you actually need to prove.