Skip to content
MD-5

SOC 2, ISO 27001 and PCI DSS: What Each Requires From a Pentest

What SOC 2, ISO 27001 and PCI DSS v4.0.1 actually say about penetration testing: which require it, how often, who may test, and the evidence auditors ask for.

By 6 min read

On this page

“Does our audit require a penetration test?” gets three different answers depending on the framework. PCI DSS requires one in detail. SOC 2 names it without mandating it. ISO 27001 never uses the word, yet most certification auditors will ask what you’ve done instead.

This guide goes to the source documents for each framework: what the text says, what auditors expect in practice, and what evidence to keep.

At a glance

SOC 2 ISO/IEC 27001:2022 PCI DSS v4.0.1
Pentest explicitly required? No, but named as an expected evaluation No Yes (Requirement 11.4)
Minimum frequency Set by your own risk assessment; annual is the norm Set by your own risk assessment Every 12 months and after significant changes
Scope Systems in your SOC 2 boundary Assets in your ISMS scope Whole cardholder data environment perimeter and critical systems, internal and external
Who may test Not specified; independence expected Not specified Qualified internal resource or qualified external third party, organizationally independent
Retest required? Expected as evidence of remediation Expected as evidence of remediation Yes: exploitable findings corrected and retested

SOC 2

SOC 2 reports are built on the AICPA’s 2017 Trust Services Criteria (opens in a new tab) (with points of focus revised in 2022). Two criteria matter for security testing.

CC4.1 (monitoring activities) requires the organization to perform “ongoing and/or separate evaluations” to confirm its controls are present and working. Its points of focus list the kinds of separate evaluation management might use, and penetration testing is named explicitly, alongside independent certifications and internal audits.

CC7.1 (system operations) covers detecting new vulnerabilities and configuration changes. Its points of focus include conducting vulnerability scans periodically and after significant changes.

Points of focus are guidance, not mandatory controls, so SOC 2 doesn’t strictly require a pentest. In practice:

  • Most auditors expect an annual third-party penetration test as the main evidence for CC4.1, and many enterprise customers reading your SOC 2 report look for it.
  • For a Type II report, the test should fall inside the observation period, and findings should show a remediation trail within that period.
  • Scope should match the system description in your report: if the report covers your production SaaS platform and its supporting infrastructure, testing only the marketing site won’t satisfy anyone.

ISO/IEC 27001:2022

ISO 27001 is a management-system standard: it tells you to identify risks and choose controls, rather than prescribing specific tests. The 2022 revision became the only certifiable version after the transition deadline of 31 October 2025.

The relevant Annex A controls are:

  • 8.8 Management of technical vulnerabilities: obtain information about technical vulnerabilities, evaluate your exposure, and take appropriate measures.
  • 8.29 Security testing in development and acceptance: define and implement security testing processes in the development life cycle.

Neither control uses the words “penetration test”. But when a certification auditor asks how you evaluate your exposure to technical vulnerabilities (8.8) or how you security-test systems before accepting them into production (8.29), an independent penetration test with a remediation record is the most common and least arguable answer. Vulnerability scanning covers part of 8.8; a pentest covers the application logic and access-control flaws that scanning can’t.

Two practical points:

  • Your risk assessment and Statement of Applicability should say how you meet 8.8 and 8.29, and the pentest frequency should follow from it. Annual testing, plus testing after major changes, is the common pattern.
  • Keep the report, the remediation tickets and the retest together. Auditors sample the whole cycle, not just the PDF.

PCI DSS v4.0.1

PCI DSS is the one framework that specifies penetration testing in detail. Version 4.0 was retired on 31 December 2024, so v4.0.1 (opens in a new tab) is the current standard, and its future-dated requirements became mandatory on 31 March 2025.

Requirement 11.4 breaks down as follows:

  • 11.4.1 Methodology. You must define, document and follow a methodology that uses industry-accepted approaches, covers the entire cardholder data environment (CDE) perimeter and critical systems, tests from both inside and outside the network, tests segmentation controls, includes application-layer and network-layer testing, reviews threats and vulnerabilities from the last 12 months, documents how risks from findings are addressed, and keeps results and remediation records for at least 12 months.
  • 11.4.2 Internal testing at least every 12 months and after any significant infrastructure or application change.
  • 11.4.3 External testing on the same schedule.
  • 11.4.4 Remediation. Exploitable vulnerabilities and security weaknesses found are corrected according to your risk ranking, and the testing is repeated to verify the corrections.
  • 11.4.5 Segmentation testing. If you use segmentation to reduce scope, confirm it works at least every 12 months and after changes to segmentation controls.
  • 11.4.6 Service providers must test segmentation every six months.
  • 11.4.7 Multi-tenant service providers must support their customers’ external penetration testing.

On who may test, the standard is specific: a qualified internal resource or qualified external third party, with organizational independence from the systems being tested. The tester does not need to be a QSA or an Approved Scanning Vendor (ASV).

Don’t confuse 11.4 with 11.3.2, the quarterly external vulnerability scans. Those must be run by a PCI SSC Approved Scanning Vendor. A penetration test does not replace ASV scans, and ASV scans don’t replace a penetration test. For the difference between the two activities, see penetration testing vs vulnerability scanning.

What makes a report audit-ready

Across all three frameworks, auditors reject reports for the same few reasons. A report that will pass contains:

  1. Dates and scope that match the audit boundary: named systems, environments, IP ranges and user roles tested.
  2. The methodology, referencing a recognized standard such as the OWASP Web Security Testing Guide, PTES or NIST SP 800-115.
  3. Tester independence and qualifications, stated in the report.
  4. Findings with severity ratings and enough evidence to show they were verified, not copied from a scanner.
  5. A retest section showing which findings were fixed and verified, and a documented risk acceptance for anything left open.
  6. An attestation letter summarizing the above, for customers who ask but shouldn’t see the full report.

Our guide to what’s in a penetration test report walks through each section.

Timing it right

  • Book four to six weeks before evidence is due. Testing takes one to two weeks, and you need time to fix findings and get a retest before the auditor’s cutoff.
  • SOC 2 Type II: test early enough in the observation period that remediation and retest also fall inside it.
  • PCI DSS: anchor the schedule to your assessment date, and add a test after any significant change to the CDE, not just the annual one.
  • Keep a calendar. “Every 12 months” means the gap between tests, so a test in March followed by one in May of the following year is a finding.

If an audit is coming up, a compliance penetration test is scoped to your audit boundary and reported with everything above included.

Sources

Published by

· Certified cybersecurity services

Articles are researched and written in-house and link to their primary sources (standards, advisories, papers and public datasets) so you can check every claim. Spotted an error? Email [email protected] and we’ll correct it.

Keep reading

More on compliance →