Penetration Testing for SOC 2, ISO 27001 and PCI DSS (2026)

Modern SaaS, cloud, and fintech company will commission penetration tests this year. The question is no longer whether it is how many separate tests, against how many separate frameworks, and how much of the work can be consolidated.

SOC 2 expects penetration testing under Common Criteria 4.1 and 7.1. ISO 27001 expects it under control 8.8. PCI DSS prescribes it explicitly under Requirement 11.4. HIPAA refers to it obliquely as "technical evaluation" under §164.308(a)(8). And in 2026, the EU's NIS2 Directive requires it across 27 member states for essential and important entities backed by penalties reaching €10 million or 2% of global annual revenue, with personal liability for management.

The frameworks ask similar questions in different language. The opportunity for any organisation managing multiple compliance obligations is in answering all of them with one well-scoped engagement, evidenced in a single well-structured report.

This guide explains exactly what each major compliance framework actually requires from penetration testing, what the report must contain to satisfy each one, and how a single annual test can serve multiple frameworks simultaneously. It is written for the CISO, compliance lead, or CFO making the procurement decision and trying to avoid running three tests when one would do the work.

1. Does SOC 2 Require Penetration Testing?
2. Does ISO 27001 Require Penetration Testing?
3. PCI DSS Requirement 11.4 — The Most Prescriptive Framework
4. HIPAA and Penetration Testing — What "Technical Evaluation" Actually Means
5. NIS2 Directive and Penetration Testing for EU Organisations
6. How One Penetration Test Satisfies Multiple Frameworks Simultaneously
7. What the Pentest Report Must Contain Per Framework
8. How SecurityWall Delivers Cross-Framework Penetration Testing

Does SOC 2 Require Penetration Testing?

Yes. SOC 2 does not have a single explicit requirement that says "conduct a penetration test" but the Trust Services Criteria make it functionally mandatory. The relevant criteria are Common Criteria CC4.1 (Monitoring of Controls) and CC7.1 (Detection and Monitoring of New Vulnerabilities), and no SOC 2 auditor in 2026 will accept a service organisation's controls as effective without recent penetration testing evidence.

CC4.1 requires the entity to "select, develop, and perform ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning." Penetration testing is the standard evidence that security controls are functioning not just documented.

CC7.1 requires the entity to "use detection and monitoring procedures to identify changes to configurations that result in the introduction of new vulnerabilities, and susceptibilities to newly discovered vulnerabilities." This is the criterion most directly associated with vulnerability identification activity, of which penetration testing is the most rigorous form.

What SOC 2 Auditors Actually Expect

For both Type 1 and Type 2 audits, auditors look for:

• A documented penetration testing methodology describing scope, frequency, and tester qualifications
• At least one annual external and internal penetration test covering the system in scope
• Severity-rated findings with CVSS scores and remediation guidance
• Tracked remediation with evidence that findings have been addressed
• For Type 2 specifically, operational evidence across the audit period pentest reports dated within the observation window

For deeper guidance on auditor expectations, see what SOC 2 auditors expect from penetration testing. For pricing, see what to budget for SOC 2 penetration testing.

A particular point of emerging emphasis in 2026: auditors are increasingly asking for evidence under CC7.2 as well monitoring for anomalies indicative of malicious activity. Assumed breach penetration testing is the testing model that produces this specific evidence, by simulating an attacker who has already gained foothold and measuring whether detection and response actually work.

Does ISO 27001 Require Penetration Testing?

Yes in practice. ISO 27001 does not explicitly mandate penetration testing in the same prescriptive language as PCI DSS, but the 2022 version of the standard makes it the de facto expectation through two controls in Annex A:

• Control 8.8 — Management of Technical Vulnerabilities. Requires information about technical vulnerabilities of information systems in use to be obtained in a timely fashion, the organisation's exposure to such vulnerabilities evaluated, and appropriate measures taken.
• Control 8.29 — Security Testing in Development and Acceptance. Requires security testing processes to be defined and implemented within the development life cycle.

In the legacy ISO 27001:2013 numbering which fully retired in October 2025 the equivalents were A.12.6.1 (Management of technical vulnerabilities) and A.18.2.3 (Technical compliance review). Certification bodies still occasionally reference the legacy numbering during transitional audits, but the 2022 controls are the active framework for all new and renewal certifications in 2026.

What ISO 27001 Certification Bodies Expect

ISO 27001 certification audits Stage 1 and Stage 2 initial certifications, surveillance audits, and three-year recertifications examine penetration testing as part of the broader vulnerability management programme:

• A documented vulnerability management procedure that specifies how penetration testing fits into the wider programme
• At least annual penetration testing of in-scope systems and applications, with the scope tied to the ISMS boundary
• Risk-based remediation prioritising findings according to the organisation's risk treatment plan
• Records of testing activity retained as evidence of the ISMS operating effectively
• Evidence of management review — pentest findings discussed at management review meetings

Where ISO 27001 Auditors Push Harder Than SOC 2

ISO 27001 is more sceptical of testing scope. Certification bodies routinely challenge whether the in-scope assets in the ISMS boundary were actually covered by the penetration test. A test of "the production environment" without a clear mapping to the asset inventory triggers findings. The scope statement matters as much as the test itself and the connection between the ISMS scope and the pentest scope needs to be explicit in both documents.

PCI DSS Requirement 11.4 — The Most Prescriptive Framework

PCI DSS is by far the most prescriptive of the major frameworks on penetration testing. Where SOC 2 and ISO 27001 imply pentest as the standard evidence for broader control requirements, PCI DSS v4.0.1 names penetration testing explicitly and dictates its scope, frequency, methodology, and reporting.

The relevant sub-requirements under Requirement 11.4:

• 11.4.1 Penetration testing methodology must be documented, based on industry-accepted approaches, and cover the full Cardholder Data Environment perimeter
• 11.4.2 Internal penetration testing at least annually and after any significant change
• 11.4.3 External penetration testing at least annually and after any significant change
• 11.4.4 Exploitable vulnerabilities and security weaknesses found during testing must be corrected per Requirement 6.3.1 and 6.3.2, with retest evidence
• 11.4.5 Segmentation testing at least annually for merchants
• 11.4.6 Segmentation testing every six months for service providers
• 11.4.7 Multi-tenant service providers must support customer external penetration testing

PCI DSS is also the framework with the highest evidence bar at audit time. QSAs reject pentest reports that lack documented methodology, severity ratings, retest evidence for closed findings, or appropriate scope coverage.

For the full breakdown of what QSAs actually accept, see PCI DSS penetration testing requirements in 2026. The article covers each sub-requirement and the format QSAs expect for the corresponding evidence.

Why PCI DSS Sets the Bar for Multi-Framework Programmes

In practice, a penetration test scoped to satisfy PCI DSS Requirement 11.4 will substantially exceed the explicit requirements of SOC 2, ISO 27001, and HIPAA in scope, rigour, and documentation. Organisations operating under multiple frameworks routinely scope their annual pentest to PCI DSS standards even when PCI DSS is not their primary driver because the resulting report satisfies every other framework as a side effect.

HIPAA and Penetration Testing — What "Technical Evaluation" Actually Means

HIPAA does not use the words "penetration testing" anywhere in the Security Rule. What it does require, under §164.308(a)(8), is a "periodic technical and nontechnical evaluation, based initially upon the standards implemented under this rule and, subsequently, in response to environmental or operational changes affecting the security of electronic protected health information."

In 2026, the Office for Civil Rights (OCR) and HIPAA assessment professionals interpret "technical evaluation" as functionally including penetration testing. The OCR's HIPAA Security Risk Assessment Tool references vulnerability and penetration testing as expected practices, and OCR enforcement actions over the past several years have increasingly cited the absence of penetration testing evidence as a contributing factor in settlement findings.

What HIPAA Assessors Expect in Practice

For covered entities and business associates holding substantial volumes of electronic protected health information (ePHI):

• Annual technical evaluation that includes vulnerability scanning and penetration testing of systems holding ePHI
• Scope coverage of the systems, applications, and infrastructure that store, process, or transmit ePHI
• Documented risk assessment linking pentest findings to the broader Security Rule risk analysis
• Remediation tracking with evidence that identified vulnerabilities have been addressed
• Post-incident testing when material changes occur to systems handling ePHI

Where HIPAA Differs From SOC 2 and ISO 27001

HIPAA is the least prescriptive of the major frameworks there is no specific frequency, no required methodology, no defined report format. Business associates and covered entities have flexibility in how they evidence the technical evaluation requirement.

In practice, this flexibility cuts both ways. Organisations with no pentest evidence are routinely cited during HHS audits. Organisations with pentest evidence aligned to a more prescriptive framework SOC 2 CC4.1 or PCI DSS 11.4 almost never face HIPAA-specific findings on the technical evaluation requirement.

The practical implication: if you are doing SOC 2 or PCI DSS, your pentest already satisfies HIPAA. If HIPAA is your only framework, scoping the pentest to SOC 2 standards is a defensive choice.

NIS2 Directive and Penetration Testing for EU Organisations

NIS2 formally Directive (EU) 2022/2555 is the EU's revised Network and Information Security framework, replacing the 2016 NIS Directive. Member states had until 17 October 2024 to transpose NIS2 into national law. As of 2026, 22 of 27 member states have completed transposition, with enforcement actively underway in Germany, France, the Netherlands, Belgium, Poland, and several others. The European Commission sent reasoned opinions to 19 member states in May 2025 for late transposition, and the regulatory environment in 2026 is moving from "preparing to enforce" to "actively auditing."

NIS2 applies to essential entities and important entities across 18 critical sectors energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, ICT service management, public administration, space, postal services, waste management, manufacturing of chemicals and food, manufacturing of certain critical products, digital providers, research, and several others. The size-cap rule generally captures medium and large entities, though member states can designate smaller organisations as essential where they are sole providers.

What NIS2 Actually Requires for Penetration Testing

NIS2 does not name penetration testing explicitly, but Article 21 the core risk management obligations article establishes the foundation:

"Essential and important entities shall take appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems… The measures shall be based on an all-hazards approach… and shall include at least the following: policies and procedures (testing and auditing) to assess the effectiveness of cybersecurity risk-management measures."

The "testing and auditing" clause is where penetration testing sits. National transpositions across member states have made this more explicit the Netherlands' Cyberbeveiligingswet, Italy's NIS2 implementation, Germany's NIS2UmsuCG, and Belgium's transposition all reference periodic security testing as part of the required measures, with penetration testing as the standard interpretation.

The Penalty Structure Is Why This Matters Now

NIS2 introduces fines that far exceed prior EU cybersecurity regimes:

• Essential entities up to €10 million or 2% of global annual turnover, whichever is higher
• Important entities up to €7 million or 1.4% of global annual turnover, whichever is higher
• Personal liability management body members can be held personally responsible for gross negligence in cybersecurity governance

Critical context: the CyberSmart April 2026 survey of 670 in-scope business leaders across eight EU countries found that 84% of organisations facing active enforcement admit they are not ready. That gap is the largest single regulatory exposure facing EU SaaS, cloud, and fintech companies in 2026.

What NIS2 Competent Authorities Are Looking For

Enforcement actions and competent authority guidance across member states converge on a consistent expectation:

• Documented cybersecurity risk management measures aligned to the Article 21 list
• Regular security testing including penetration testing of systems supporting essential or important services
• Incident reporting capability with 24-hour early warning, 72-hour notification, and 1-month final report
• Supply chain security assessments covering critical service providers
• Management body approval and oversight of the cybersecurity programme

A penetration test scoped to satisfy ISO 27001 control 8.8 or SOC 2 CC4.1 generally meets NIS2 Article 21 testing expectations but the report needs to explicitly map findings back to the NIS2 risk management framework to be defensible at audit.

How One Penetration Test Satisfies Multiple Frameworks Simultaneously

The strategic insight that most compliance teams miss until their third audit: a single well-scoped penetration test, properly documented and mapped, can satisfy every framework your organisation operates under. There is no requirement under any framework that pentests be conducted separately for each compliance regime.

The Mechanics of Cross-Framework Pentesting

A penetration test that satisfies multiple frameworks does three things differently from a single-framework test:

• Scope is set to the highest common denominator. If your environment is in scope for SOC 2, ISO 27001, and PCI DSS, the pentest scope covers the union of the three boundaries not the intersection. PCI DSS's CDE definition is typically the broadest in technical detail; ISO 27001's ISMS boundary may extend further organisationally; SOC 2's system boundary may pick up customer-facing components the others miss.
• Methodology meets PCI DSS standards. PCI DSS Requirement 11.4.1 demands the most prescriptive methodology documentation. A test conducted to PCI DSS methodology standards automatically satisfies SOC 2, ISO 27001, HIPAA, and NIS2 methodology expectations.
• The report maps findings to each framework's control language. Findings are reported once, then mapped explicitly to SOC 2 Common Criteria (CC4.1, CC7.1, CC7.2), ISO 27001 controls (8.8, 8.29), PCI DSS sub-requirements (11.4.1 through 11.4.7), HIPAA Security Rule provisions, and NIS2 Article 21 measures.

Where Consolidation Works and Where It Does Not

Consolidation works cleanly for:

• Application and infrastructure penetration testing test covers all frameworks
• External network testing test covers SOC 2, ISO 27001, PCI DSS external, HIPAA, NIS2
• Internal network testing test covers SOC 2, ISO 27001, PCI DSS internal, HIPAA, NIS2

Consolidation is more nuanced for:

• Segmentation testing — PCI DSS service providers need this every six months; other frameworks accept annual. The semi-annual cadence satisfies all frameworks, but doubles the cost.
• Multi-tenant testing under PCI DSS 11.4.7 — this has no direct equivalent in other frameworks, but the resulting evidence supports SOC 2 customer-shareable attestations under the PTaaS model.
• Assumed breach testing — SOC 2 CC7.1 / CC7.2 expectations are pushing toward this model; PCI DSS does not explicitly require it but does not penalise it. NIS2 sectoral guidance increasingly references it.

For SaaS companies serving Dutch and EU enterprise customers, SOC 2 penetration testing for Dutch SaaS covers the additional EU-specific scoping considerations that NIS2 introduces alongside SOC 2 expectations.

What the Pentest Report Must Contain Per Framework

The report is the artefact every framework's assessor examines. Below is what each framework expects to see and where the requirements differ.

The pattern across every row: PCI DSS is the most prescriptive in what the test must look like, NIS2 is the most consequential in what happens if you don't have one. Designing a programme that exceeds both is straightforward designing one that satisfies neither is the failure mode most organisations fall into when they treat each framework as a separate procurement exercise.

How SecurityWall Delivers Cross-Framework Penetration Testing

SecurityWall delivers penetration testing engagements that produce compliance-mapped reports accepted by SOC 2 auditors, ISO 27001 certification bodies, PCI DSS QSAs, HIPAA assessors, and NIS2 competent authorities from a single coordinated engagement. The model is built around the reality that most modern SaaS, fintech, and cloud companies operate under three or more frameworks simultaneously, and running separate tests for each one is wasteful.

One Engagement. Multiple Frameworks. One Report.

Every cross-framework engagement covers:

• Scope set to the union of all frameworks SOC 2 system boundary, ISO 27001 ISMS scope, PCI DSS CDE, HIPAA ePHI systems, NIS2 essential service infrastructure
• PCI DSS-grade methodology documentation meeting the highest prescriptive bar so the report satisfies every framework downstream
• Findings mapped to each framework's control language CC4.1 / CC7.1 / CC7.2 for SOC 2, 8.8 / 8.29 for ISO 27001, 11.4.x sub-requirements for PCI DSS, §164.308(a)(8) for HIPAA, Article 21 for NIS2
• Retest evidence for closed findings formatted to PCI DSS 11.4.4 standards
• Auditor-facing report structure designed to deliver directly to your SOC 2 auditor, ISO certification body, or QSA without rework

Certifications That Match Auditor Expectations

The team holds the credentials assessors and certification bodies recognise:

• OSCP and OSWE practical exploitation and web application testing
• CREST CRT internationally recognised penetration testing
• CISM and CISSP governance, risk, and information security management
• PCI SSC-listed Qualified Security Assessor (QSA) status for PCI DSS engagements

Specialised Testing for Specific Framework Requirements

For organisations with framework-specific testing needs beyond the standard scope:

• PCI DSS segmentation testing annual for merchants, semi-annual for service providers
• PCI DSS 11.4.7 multi-tenant service provider testing customer-shareable evidence under one annual test cycle
• SOC 2 CC7.1 / CC7.2 detection testing assumed breach engagements validating monitoring and incident response
• Continuous testing under the PTaaS model Penetration Testing as a Service for organisations needing testing evidence across the SOC 2 Type 2 observation period

Bundled with Adjacent Compliance Services

For organisations operating under multiple frameworks, we deliver pentesting alongside the broader compliance programme:

• SOC 2 readiness and gap analysis
• PCI DSS gap assessment, ROC coordination, and AoC support see the PCI DSS overview for the full pathway
• ISO 27001 readiness and certification body coordination
• HIPAA Security Rule technical evaluation programmes
• NIS2 Article 21 risk management measure implementation

Single point of contact. Consistent evidence formatting. No coordination overhead at audit time across frameworks.

Related reading:

• What Is SOC 2 Compliance? A Plain-English Guide for SaaS Companies in 2026
• SOC 2 Penetration Testing Requirements: What Auditors Expect
• SOC 2 Penetration Testing Cost: What to Budget
• SOC 2 Penetration Testing for Dutch SaaS Companies
• PCI DSS Penetration Testing Requirements in 2026
• Penetration Testing as a Service (PTaaS): A Practical Guide
• Assumed Breach Penetration Testing for SOC 2 CC7.1 / CC7.2
• What Is PCI DSS Compliance? A Plain-Language Guide for 2026

Frequently Asked Questions

Does SOC 2 require penetration testing?

Yes. SOC 2 does not name penetration testing explicitly, but Common Criteria CC4.1 and CC7.1 require ongoing evaluation of control effectiveness and vulnerability identification. No SOC 2 auditor in 2026 accepts a service organisation's controls as effective without recent penetration testing evidence. Annual testing of in-scope systems is the de facto standard.

Does ISO 27001 require penetration testing?

Yes in practice. ISO 27001:2022 Annex A control 8.8 requires management of technical vulnerabilities, and control 8.29 requires security testing in development and acceptance. Certification bodies expect at least annual penetration testing of the ISMS scope, with documented methodology and tracked remediation.

Can one penetration test satisfy SOC 2, ISO 27001, and PCI DSS at the same time?

Yes, if it is scoped and documented for that purpose. Scope must cover the union of the three framework boundaries, methodology must meet PCI DSS Requirement 11.4.1 standards (the most prescriptive), and the report must map findings explicitly to each framework's control language. Most organisations save 60–70% of pentest costs by consolidating versus running separate tests.

What is the minimum penetration testing frequency for NIS2?

NIS2 does not specify a minimum frequency in the directive itself Article 21 requires "regular" testing and auditing. National transpositions across member states vary, but annual testing is the prevailing interpretation across the Netherlands, Germany, Italy, and Belgium for essential and important entities. Sectoral implementing acts may impose more frequent testing for specific industries.

What happens if we cannot produce penetration testing evidence at audit?

SOC 2: audit finding, potentially preventing a clean opinion. ISO 27001: certification body finding, potentially blocking certification. PCI DSS: QSA non-compliance, leading to acquiring bank penalties and processing privilege impact. HIPAA: OCR finding during enforcement audits. NIS2: up to €10 million or 2% of global annual turnover for essential entities, plus personal liability for management body members. The financial exposure across frameworks materially exceeds the cost of conducting the test.

Can SecurityWall conduct pentests that satisfy all five frameworks?

Yes. SecurityWall is a PCI SSC-listed QSA and ASV, with team certifications spanning OSCP, OSWE, CREST CRT, CISM, and CISSP. Cross-framework engagements are scoped, documented, and reported to satisfy SOC 2, ISO 27001, PCI DSS, HIPAA, and NIS2 from a single coordinated test cycle.

What is the next step if we want a cross-framework quote?

A 30-minute scoping conversation to confirm which frameworks apply, current architecture, system scope, and timeline constraints. From that conversation we produce a scoped engagement proposal with framework mapping, scope, deliverables, and pricing within one business day. No procurement commitment is required to have the scoping call.