Internal Scans, ASV Scans, Pen Tests
An e-commerce operator we work with keeps its most recent passing ASV report pinned to the top of a shared drive. When a prospective enterprise buyer raises security during procurement, that report is the first thing sent across. The instinct is reasonable and it is common. A passing scan feels like a verdict. It is closer to a single witness statement: precise about one thing, silent about most others.
PCI DSS v4.0.1 asks merchants to run three distinct forms of testing, and the quickest way to misread all three is to treat them as interchangeable proofs of the same claim. Each answers a different question about a different part of the environment. Passing one says very little about the questions the other two exist to ask. Read as evidence, each test has a defined scope, and the risk it cannot see does not disappear because the report came back clean.
What an internal scan can testify to
Requirement 11.3.1 of PCI DSS v4.0.1 requires internal vulnerability scans at least once every three months, with high-risk and critical vulnerabilities resolved, rescans to confirm the fixes, and a scan tool kept current. The scans must be run by qualified personnel with organizational independence from the systems being scanned, though the standard is explicit that a QSA or ASV is not required to perform them.
Version 4.0.1 also added authenticated scanning at Requirement 11.3.1.2. The scanner runs with credentials, so it can see local patch levels and configuration that an unauthenticated view cannot reach. That closes a real visibility gap. What it produces is an inventory: known weaknesses present on systems inside the environment, viewed from a position that already assumes some internal access. An internal scan attests to what is there. It does not attest to whether any of it can be exploited, or whether two findings that look minor on their own could be linked into something that is not.
What an ASV scan can testify to
Requirement 11.3.2 requires external vulnerability scans at least once every three months, performed by a PCI SSC Approved Scanning Vendor, with vulnerabilities resolved to the passing standard set in the ASV Program Guide. What a passing scan needs and who is authorized to run it is the subject of our earlier piece, What PCI ASV Scans Require, so it is worth reading alongside this one rather than repeating here.
Two points matter for the distinction. First, for v4.x the PCI Security Standards Council extended ASV scanning into SAQ A, which reaches the e-commerce merchants whose checkout pages redirect to, or embed a payment form from, a compliant third party. Many US online sellers are completing Requirement 11.3.2 for the first time because of that change. Second, the vantage point defines the scope. An ASV scan looks at internet-facing systems, unauthenticated, from the outside, at the moment it runs. That is breadth across the public perimeter. It is silent on anything internal, and it does not test whether a finding it lists is actually reachable and exploitable.
An ASV scan and an internal scan both enumerate. Neither one walks through the door it finds, and neither one tries to connect that door to another.
What a penetration test can testify to
Penetration testing sits in a separate requirement family, Requirement 11.4, and the separation is deliberate. Requirement 11.4.1 requires a documented, implemented methodology built on industry-accepted approaches, such as the OWASP Web Security Testing Guide, covering the entire cardholder data environment perimeter and critical systems, testing from both inside and outside, and validating segmentation. Requirement 11.4.2 requires internal penetration testing at least once every 12 months and after any significant infrastructure or application change; Requirement 11.4.3 sets the same cadence for external testing. Requirement 11.4.4 requires exploitable findings to be corrected and the test repeated to verify the correction. Where segmentation is used to keep systems out of scope, Requirement 11.4.5 requires that segmentation be penetration tested at least every 12 months, tightened to at least every six months for service providers under Requirement 11.4.6.
The mechanism is what sets it apart. A scanner enumerates known weaknesses. A tester exploits them, and then chains them. The standard's own guidance is unusually direct on this: it notes that a tester will often chain several vulnerabilities together to compromise a system component, and that a penetration test has no pass or fail outcome, because a test that finds nothing usually reflects a weak tester rather than a strong environment. A penetration test attests to whether the weaknesses that exist can be turned into a path to cardholder data. That is the one question neither scan is built to answer.
Why a clean scan does not close the case
Enumeration and exploitation are different acts, and the distance between them is where breaches live. A scanner lists that a door is unlocked. It does not open the door, move through the building, or test whether three unremarkable findings combine into one route to card data. That combining is ordinary attacker behaviour, not an edge case.
The exploited-vulnerability data lands on the same point. In Palo Alto Networks Unit 42's Global Incident Response Report 2026, vulnerability exploitation tied with phishing as the leading initial-access vector at 22 percent of 2025 incidents, rising to 26 percent among the largest enterprises. Unit 42 also found that most intrusions spanned more than one attack surface and that most breaches turned on preventable exposure gaps rather than novel tradecraft. CISA's Known Exploited Vulnerabilities catalog is the authoritative record of CVEs confirmed to be exploited in the wild, which is precisely the population an external scan checks against, but only from the outside and only when it runs. And the findings that automated tools most reliably miss, according to the OWASP Web Security Testing Guide, are business-logic and authorization flaws, the high-severity issues a human tester is engaged to find.
Vulnerability exploitation matched phishing as the top way in during 2025, at 22 percent of incidents, and reached 26 percent at the largest firms (Unit 42, 2026).
So a clean scan closes a narrow and useful question: were known, externally visible weaknesses found from where the scanner looked, on the day it looked. It leaves open exploitability, chaining, internal exposure, and whether segmentation actually holds.
The accountability a passing report leaves with you
The failure mode we see from the operator's seat is consistent. A merchant presents a passing ASV report to an auditor or a customer as evidence of a secure environment, then fails a penetration test in that same environment, because the scan never attempted to chain anything and never claimed to. The report was accurate. It was answering a different question than the one being asked of it.
Treating the three tests as evidence with defined scope resolves this. An internal scan attests to known internal exposure. An ASV scan attests to known external exposure. A penetration test attests to whether that exposure can be exploited and connected into a breach, and whether segmentation stands up when someone actively tries to cross it. Compliance requires all three because each testifies to something the others structurally cannot. The risk each test cannot see remains yours to carry, and a clean report is the beginning of that accounting rather than the end of it.
Sources
PCI Security Standards Council, Payment Card Industry Data Security Standard: Requirements and Testing Procedures, v4.0.1 (Requirements 11.3.1, 11.3.1.2, 11.3.2, and 11.4.1 through 11.4.6). https://www.pcisecuritystandards.org/document_library/
PCI Security Standards Council, Resource Guide: Vulnerability Scans and Approved Scanning Vendors (Requirement 11.3.2 and SAQ A applicability). https://blog.pcisecuritystandards.org/resource-guide-vulnerability-scans-and-approved-scanning-vendors
Palo Alto Networks Unit 42, Global Incident Response Report 2026. https://www.paloaltonetworks.com/resources/research/unit-42-incident-response-report
Cybersecurity and Infrastructure Security Agency (CISA), Known Exploited Vulnerabilities Catalog. https://www.cisa.gov/known-exploited-vulnerabilities-catalog
OWASP Foundation, Web Security Testing Guide. https://owasp.org/www-project-web-security-testing-guide/
Disclaimer
This article is provided for general information and educational purposes only. It is not legal, compliance, or professional security advice, and it does not create an advisory relationship. PCI DSS applicability, including which self-assessment questionnaire applies and which testing requirements are in scope, depends on an organization's specific environment, validation path, and acquirer or card brand obligations. Requirement references are drawn from PCI DSS v4.0.1; confirm the version in force at the time of your assessment. Organizations should consult a Qualified Security Assessor and their acquiring bank before relying on any interpretation set out here.
PCI DSS v4.0.1 · Frequently Asked Questions
Internal Scans, ASV Scans, Pen Tests
Yes, where they apply to your validation path. PCI DSS v4.0.1 places vulnerability scanning under Requirement 11.3 and penetration testing under Requirement 11.4. They are separate controls and one cannot substitute for the other. A scan identifies known weaknesses; a penetration test attempts to exploit and chain them into a path to cardholder data.
An ASV scan (Requirement 11.3.2) is an automated external vulnerability scan run at least every three months by a PCI SSC Approved Scanning Vendor, enumerating known weaknesses on internet-facing systems. A penetration test (Requirement 11.4) is a human-led exercise run at least every 12 months that actively exploits weaknesses, chains them, and tests segmentation. The scan measures breadth; the penetration test measures depth.
An internal vulnerability scan (Requirement 11.3.1) runs inside the environment and under v4.0.1 must use authenticated scanning (Requirement 11.3.1.2). An external scan (Requirement 11.3.2) runs from outside, unauthenticated, and must be performed by an Approved Scanning Vendor. They cover different vantage points and are not interchangeable.
Internal and external vulnerability scans are required at least once every three months (Requirements 11.3.1 and 11.3.2). Internal and external penetration tests are required at least once every 12 months and after any significant change (Requirements 11.4.2 and 11.4.3). Segmentation must be penetration tested at least every 12 months, and at least every six months for service providers (Requirements 11.4.5 and 11.4.6).
No. A passing ASV scan confirms that no known, externally visible high-risk weaknesses were found from outside on the day it ran. It does not test whether those weaknesses are exploitable, whether they can be chained, what exposure exists internally, or whether segmentation holds. Those questions belong to internal scans and penetration testing.
