A Vulnerability Scan Is Not a Penetration Test: A PCI DSS Merchant's Guide

Imagine your online store has a service running an outdated software version.

A vulnerability scan may flag it and add it to your remediation list. A penetration test goes further: it tries to find out whether that outdated version could actually be used as a stepping stone to your cardholder data.

Same weakness, two different verdicts. That's why a PCI DSS assessment won't accept a vulnerability scan report on its own.

What's the Difference Between a Vulnerability Scan and a Penetration Test?

Vulnerability scan (VA): automated tools check your systems on a schedule and produce a list of known weaknesses for your team to prioritize and fix.

Penetration test (PT): qualified testers work within an agreed scope to actually try exploiting a weakness, then document how far they got, what stopped them, and what didn't.

A vulnerability scan answers “where might there be a problem.” A penetration test answers “could this problem actually let someone reach cardholder data.”

What Do “Internal” and “External” Mean?

PCI DSS gives “internal” and “external” precise definitions (Requirement 11.4.1 applicability notes):

• Internal testing: testing from within the cardholder data environment (CDE), and from trusted and untrusted internal networks into the CDE.
• External testing: testing the exposed perimeter of trusted networks, and any critical systems connected to or reachable from public network infrastructure.

Vulnerability scanning follows the same logic: an internal vulnerability scan looks at your systems from inside the network and can be run by qualified internal staff. An external vulnerability scan simulates an attacker's view from the internet to perform the specific service scan (such as HTTPS), which is why PCI DSS requires it to be performed by a PCI SSC Approved Scanning Vendor (ASV).

How Often Does PCI DSS Require Vulnerability Scans and Penetration Tests?

PCI DSS v4.0.1 covers vulnerability scanning in Requirement 11.3 and penetration testing in Requirement 11.4. Which requirements apply depends on your environment and validation method, including the Self-Assessment Questionnaire (SAQ), if used. Confirm these with your acquirer or assessor before setting the testing schedule.

For merchants subject to these requirements, the principal schedules under the defined approach are:

* If you use network segmentation to reduce PCI DSS scope, you also need a penetration test of the segmentation controls at least every 12 months (a service provider must test the segmentation controls at least every 6 months), plus after any change to the segmentation methods (Requirement 11.4.5).

Internal scans, post-change external scans, and penetration tests require qualified personnel with organizational independence (either inside or outside the organization). The additional external scan after a significant change does not have to be performed by an ASV.

How Can You Tell If You've Received a Real Penetration Test Report?

The two documents can look alike. Both come from an outside firm, both list weaknesses, and both carry a date and a scope. Three signs show that a document reports a penetration test:

• Look for a methodology and a narrative: the report explains how the test was planned and performed, then describes what the tester attempted, what stopped the attempt, and what succeeded. PCI DSS names OSSTMM and OWASP as examples of accepted methodologies.
• Look for findings with a path: for each weakness, the report explains whether and how it could be used against the payment environment, rather than listing a reference number and a score alone.
• Look for coverage that matches Requirement 11.4.1: the entire CDE perimeter and critical systems, internal and external testing, the application layer and the network layer, and validation of segmentation and scope-reduction controls. These can arrive as separate documents.

What to Ask For When Requesting Quotes and Filing Reports

When requesting a quote, list vulnerability scanning and penetration testing as separate activities, even if one provider delivers both. Ask who performs the manual testing, the scope, the testing window, and the documents you will receive. For vulnerability scanning, request the systems covered, findings, remediation actions, and applicable rescan evidence.

Plan the follow-up alongside the testing. Under Requirement 11.4.4, exploitable vulnerabilities and security weaknesses must be corrected according to assessed risk, with penetration testing repeated to verify the corrections. Keep penetration test and remediation results for at least 12 months under Requirement 11.4.1, and file the two kinds of report separately so the right evidence is at hand for the next assessment.

Source: PCI DSS v4.0.1, Requirements 11.3 and 11.4 and their accompanying guidance, available through the PCI SSC Document Library. Requirement clause numbers summarize requirements; the store example is illustrative, and procurement suggestions are editorial recommendations.

FAQ

What's the difference between a vulnerability scan and a penetration test?
A vulnerability scan is an automated tool that checks your systems on a schedule and lists known weaknesses. A penetration test is a qualified tester actually trying to exploit those weaknesses to see whether they could reach cardholder data. PCI DSS requires both, and they serve different purposes.

How often does PCI DSS require vulnerability scans?
Both internal and external vulnerability scans are required at least every three months, plus an additional scan after any significant change to the environment.

How often does PCI DSS require penetration tests?
Both internal and external penetration tests are required at least every 12 months, plus an additional test after any significant infrastructure or application upgrade or change.

Does an external vulnerability scan always have to be performed by an ASV?
The regular quarterly external vulnerability scan must be performed by a PCI SSC Approved Scanning Vendor (ASV). The additional scan required after a significant change does not have to be performed by a QSA or an ASV.

What makes a report a legitimate PCI DSS penetration test report?
It should describe a recognized methodology (such as OSSTMM or OWASP), explain the exploitation path for each finding, and cover the CDE perimeter, internal and external testing, the application and network layers, and validation of segmentation controls, in line with Requirement 11.4.1.