This is one of the most common and most expensive misunderstandings in PCI DSS compliance, and it is frequently encouraged by vendors who would rather sell you the cheaper of the two.
The two requirements
Requirement 11.3 covers vulnerability scanning. Internal scans quarterly and after significant change; external scans quarterly by an Approved Scanning Vendor (ASV), and after significant change. The output is a scan report.
Requirement 11.4 covers penetration testing. Internal and external penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or modification, following a documented methodology. Exploitable vulnerabilities and security weaknesses found must be corrected and the testing repeated to verify the correction.
These are distinct requirements in distinct sub-sections. An assessor will expect evidence of both. Producing a scan report against 11.4 produces a finding.
Why they are not interchangeable
A vulnerability scan compares observed software versions and configurations against a database of known issues. It is broad, cheap, repeatable and appropriate for exactly what 11.3 asks of it — continuous coverage of a large estate.
A penetration test is a person attempting to achieve an objective. It finds the things a database cannot contain: authorisation flaws specific to your permission model, business logic that can be abused, chained weaknesses that are individually low severity and jointly critical, and paths through your application that exist because of how your application works.
The distinction the standard draws is not arbitrary. A scanner cannot tell you that a support agent can read every customer record, because no CVE describes your support role.
What 11.4 actually demands
Read the sub-requirements carefully, because they constrain the engagement:
- 11.4.1 — a defined, documented methodology, based on an industry-accepted approach. PTES and NIST SP 800-115 both satisfy this; a vendor who cannot name their methodology does not satisfy it.
- 11.4.2 — internal penetration testing, at least every 12 months and after significant change.
- 11.4.3 — external penetration testing, on the same cadence.
- 11.4.4 — exploitable vulnerabilities and security weaknesses corrected, and testing repeated to verify the corrections. Retesting is not optional and not an upsell. If your vendor charges separately for it, factor that into the comparison.
- 11.4.5 and 11.4.6 — where segmentation is used to reduce scope, testing must confirm the segmentation controls are operational and effective.
Segmentation testing is the one people forget
If you rely on network segmentation to keep systems out of your cardholder data environment, that reliance has to be tested. Segmentation testing verifies that the isolation actually holds — that a compromised system outside the CDE cannot reach into it.
This is worth doing early rather than late, because it is also the single biggest lever on the cost of your assessment. Scope reduction that turns out not to hold is an expensive surprise at the wrong moment.
Version currency
PCI DSS v4.0.1 is the active version. v3.2.1 retired at the end of 2024, and requirements previously designated future-dated became mandatory on 31 March 2025. If a vendor’s proposal cites v3.2.1 requirement numbers, that tells you something about how recently they updated their templates.
The practical model
Continuous vulnerability scanning through the year against 11.3, plus a manual penetration test at your compliance interval against 11.4, with retesting of anything exploitable. They serve different purposes and satisfy different requirements, and you need both.
Any vendor who offers to satisfy 11.4 with a scan is either mistaken or hoping you are. Neither is a good basis for a relationship with the firm testing your payment environment.