PCI DSS penetration testing: the one framework that names it directly

Does PCI DSS require a penetration test?

Yes, literally. PCI DSS v4.0.1 Requirement 11.4 requires entities to define, document, and implement a penetration testing methodology, and to perform internal and external penetration testing at least once every 12 months and after any significant change to the network or applications. This is the one framework in this hub where "requires a pentest" is accurate rather than a marketing stretch.

PCI DSS is the exception among the frameworks on this site: it names penetration testing directly, with a fixed cadence and explicit tester expectations, instead of implying it through a general risk-management or effectiveness-review obligation.

The nuance that still matters is not whether a pentest is required, but who is allowed to perform it and what else Requirement 11 expects alongside it - a documented methodology, segmentation testing where relevant, and separate, more frequent vulnerability scanning under Requirement 11.3.

Requirement 11.4 explained

Requirement 11.4.1 requires the penetration testing methodology itself to be defined, documented, and implemented, based on an industry-accepted approach, covering the entire cardholder data environment (CDE) perimeter and critical systems, testing from both inside and outside the network, and validating segmentation controls. It also requires application-layer and network-layer testing, review of threats and vulnerabilities from the prior 12 months, a documented approach to risk-ranking what is found, and retention of results for at least 12 months.

Requirement 11.4.2 requires internal penetration testing at least once every 12 months and after any significant change. Requirement 11.4.3 requires the same cadence for external penetration testing. Requirement 11.4.4 requires that exploitable vulnerabilities and security weaknesses found during testing are corrected, with the test repeated to verify the fix.

Internal, external, and segmentation testing

Internal (11.4.2) and external (11.4.3) penetration tests cover different vantage points on the same cardholder data environment - from inside the network and from the outside looking in. Where an entity uses network segmentation to reduce PCI DSS scope, Requirement 11.4.5 requires a separate penetration test of those segmentation controls at least once every 12 months for all entities, tightening to every 6 months for service providers under Requirement 11.4.6.

Requirement 11.3 is a distinct, more frequent obligation and is not a substitute for penetration testing: internal vulnerability scans are required at least once every 3 months and must be authenticated scans (11.3.1, 11.3.1.2), while external vulnerability scans are required at least once every 3 months and must be performed by a PCI SSC Approved Scanning Vendor (ASV) under Requirement 11.3.2. Scanning is automated and vulnerability-focused; penetration testing is exploit-driven, less frequent, and goes deeper.

Tester qualification and independence

Requirements 11.4.2 and 11.4.3 require the penetration test to be performed by a qualified internal resource or qualified external third party, with organizational independence of the tester (not required to be a QSA or ASV) - an internal team can run the test if it is independent of the group that built and manages the environment and holds verifiable qualifications. That tester does not need to be a Qualified Security Assessor (QSA); QSA status is a separate credential for signing your PCI DSS assessment, not a requirement for the pentest itself.

That qualified, organizationally-independent tester expectation is the honest limit on automation here: an AI-only or fully automated test, by itself, does not satisfy Requirement 11.4 without a qualified human tester defining the methodology, directing the engagement, and standing behind the findings. Requirement 11.3.2 has its own separate, non-negotiable gate - the external vulnerability scan must be run by a vendor on the PCI SSC's list of Approved Scanning Vendors. No amount of tester qualification substitutes for ASV status on that specific requirement.

How Intrudify fits

Intrudify's engagements are human-validated by OSCE3-certified testers, not run on automated output alone, which is why Intrudify engages as an external testing provider intended to meet the qualified, organizationally-independent tester expectation in Requirements 11.4.2 and 11.4.3. Your QSA or assessor confirms tester qualification for your assessment, with reproducible proof-of-exploit and developer-ready remediation mapped to Requirement 11.4.

Intrudify is not a QSA and does not issue your PCI DSS attestation, and Intrudify is not a PCI SSC Approved Scanning Vendor: it does not perform the ASV scans that Requirement 11.3.2 specifically requires. If you need external vulnerability scans for Requirement 11.3.2, you still need a separately listed ASV for that requirement - Intrudify supports the Requirement 11.4 penetration testing and 11.4.5/11.4.6 segmentation testing obligations, not the ASV scanning obligation.

• Findings mapped to Requirement 11.4 methodology elements, with segmentation testing support for 11.4.5/11.4.6
• Human-validated by OSCE3-certified testers - the qualified, organizationally independent tester Requirements 11.4.2 and 11.4.3 require
• Reproducible proof-of-exploit for high and critical findings, developer-ready remediation, and a re-test window supporting 11.4.4
• Does not replace ASV scanning under Requirement 11.3.2 - use a PCI SSC-listed Approved Scanning Vendor for that specific obligation

How a pentest maps to controls

Need audit-ready evidence for PCI DSS?