PCI DSS vulnerability scanning: what ASV results cannot prove in a breach investigation
Sienna VanceApril 29, 2026
Key takeaways
An ASV passing certificate satisfies Requirement 11.3.2 but does not constitute evidence of authenticated internal scanning, scope accuracy, or continuous monitoring, the three things forensic investigators request first after a breach.
PCI DSS Requirement 11.3.1 mandates authenticated internal scans, but the credential configuration is left to the organization. Unauthenticated internal scans are a documentation gap that regulators treat as a control failure.
In Vulnox assessments of retail and e-commerce environments, undocumented systems handling cardholder data appear in the majority of engagements. Those systems were never scanned because they were never in scope.
Low and medium severity findings below the ASV passing threshold are the most common entry points in post-breach forensic reviews. Compliance thresholds do not align with attacker behavior.
Card brand forensic investigators request change control logs, authenticated scan reports, and cardholder data discovery results. None of these are produced by a standard ASV scan engagement.
Organizations that treat quarterly ASV scans as their primary vulnerability management control are building a compliance record that will not survive a breach investigation.
TL;DR
PCI DSS vulnerability scanning is two separate programs the standard deliberately conflates: the external ASV scan that produces an auditable certificate, and the internal authenticated scanning program that almost no one runs correctly. The ASV certificate satisfies the QSA. The authenticated internal scan, with its credential logs and rescans and change-triggered runs, is what survives a forensic investigation. Most organizations have the first and only the paperwork of the second. That gap is where breaches hide.
The certificate that did not help
A mid-size e-commerce merchant in the Netherlands processes card payments through a third-party gateway but retains tokenized transaction logs on an internal server. Their QSA signed off on a clean assessment. Their ASV scan from six weeks prior showed no high or critical findings. When the card brands opened a forensic investigation after unusual authorization patterns triggered their fraud models, the first document request was not the ASV certificate. It was the authenticated internal scan results from the prior twelve months, the cardholder data discovery output, and the change control log showing what was modified in the CDE between the last scan and the compromise date.
The merchant had none of the three. The ASV certificate was valid. The compliance record was clean. And none of it was usable as evidence that the environment had been adequately assessed. The forensic investigation concluded that the entry point, a misconfigured internal API endpoint added during a platform migration four months earlier, would have appeared in an authenticated internal scan. It had never been in scope because the migration had not triggered a scope review.
What PCI DSS Requirement 11 actually obligates
PCI DSS v4.0 Requirement 11 separates internal and external scanning into distinct obligations with distinct evidence standards. Requirement 11.3.2 is the external ASV scan: quarterly, performed by an approved scanning vendor, producing a passing certificate. This is the one organizations reliably complete because the QSA asks for the certificate. Requirement 11.3.1 is the internal authenticated scan: also quarterly, plus after any significant environmental change, and the results must demonstrate that scans were performed with sufficient credentials to assess each system fully. The PCI DSS does not specify which credentials or how authentication must be configured. That determination is left to the organization. What the standard does require is that the scan results show authenticated access was used and that all systems in the CDE were included.
Example
The authentication requirement matters because unauthenticated scans operate from the perspective of an external attacker with no credentials. They find open ports, exposed services, and unpatched software visible from the network. Authenticated scans find everything the unauthenticated scan finds, plus locally installed software versions, service configurations, registry settings, and file permission problems that are invisible without a session. In Vulnox assessments, the authenticated internal scan regularly surfaces three to five times the finding count of the unauthenticated run against the same hosts. The unauthenticated result is not wrong. It is incomplete in a way that is invisible unless you run both and compare.
Requirement 11.3.1.1 adds the rescan obligation: if the internal scan finds high or critical vulnerabilities, the organization must rescan until those findings are resolved. The rescan must be documented. Organizations that remediate findings but do not retain the rescan report are missing evidence that a forensic investigator will specifically request. The original scan report without the follow-up rescan looks, from an evidence standpoint, like an unresolved finding.
What we find inside the scanning program
Assessment base: Vulnox vulnerability assessment engagements, retail and e-commerce sector, 2023 to 2025
Scope exclusions for systems the organization does not know are processing card data
In Vulnox assessments of retail and e-commerce environments, the initial cardholder data discovery exercise consistently identifies systems outside the defined CDE that are touching, logging, or caching card data. The most common sources are legacy integrations retained after payment gateway migrations, developer and staging environments configured against production APIs during testing, and logging systems that capture request bodies containing card numbers before tokenization occurs. These systems were not scanned because they were not in scope. They were not in scope because no one mapped the data flows carefully enough to find them.
A breach originating from an out-of-scope system collapses the compliance record retroactively. The forensic investigation does not ask whether the system was in scope. It asks whether card data was present and whether the system was adequately assessed. The answer to the second question is always no if the system was not scanned.
Internal scans run without credentials, documented as compliant
In Vulnox engagements where we review existing scan configurations before conducting our own assessment, we frequently find that internal scans are scheduled and running, producing reports, and being retained as compliance evidence, but have never been configured with authenticated credentials for the hosts they are scanning. The scan tool is operating in unauthenticated mode against internal hosts. The reports show clean or near-clean results because unauthenticated scans against patched external-facing services look fine. The local software inventory, service configurations, and privilege escalation paths that authenticated scanning reveals are entirely absent from the compliance record.
The QSA reviews the scan reports and sees results. The results are real, they are just radically incomplete. The organization has a documented scanning program that does not satisfy Requirement 11.3.1's authentication obligation, and no one in the annual audit cycle identified the gap.
Change-triggered scans that are not triggered
Requirement 11.3.1 requires internal scanning after significant environmental changes. The definition of significant is left to the organization's judgment and documented in their security policy. In practice, organizations define significant changes narrowly enough that platform migrations, new service deployments, and API integrations do not trigger a scan. The quarterly scan schedule continues, and the changes accumulate between scan cycles. In the Netherlands e-commerce case above, four months elapsed between the API endpoint deployment and the next scheduled scan. The quarterly cadence was met. The change-triggered requirement was not.
Any vulnerability introduced by an environmental change between quarterly scans will not appear in the compliance record until the next scheduled run. If the change introduces a critical vulnerability, that vulnerability has a minimum 30-day and potentially 90-day window of undocumented exposure before it appears in any scan result.
The finding that passes the scan and fails the investigation
Common belief
Organizations routinely deprioritize low and medium severity scan findings. The logic is straightforward: the ASV passing threshold focuses on high and critical findings, the QSA reviews that the highs and criticals have been addressed, and the medium and low findings go into a remediation backlog where they age out quietly. This is not negligence, it is a rational response to the standard's own severity structure.
What we found
In post-incident reviews Vulnox has participated in, the entry point was rarely the highest-severity finding in the scan history. The entry points were consistently findings that had been triaged as medium or low, placed in the backlog, and aged past the point where anyone was actively tracking them. The compliance record showed the highs and criticals addressed. The medium findings were documented. The chain that connected them was not visible until the forensic reconstruction.
The problem is that forensic investigators do not use the same severity triage that the ASV passing criteria use. Card brand investigators review the complete finding history and specifically look for vulnerability chains, combinations of lower-severity findings that together produce an exploitable path. A medium-severity finding on an internal authentication service combined with a low-severity information disclosure on the same segment combined with a misconfigured firewall rule that was never scanned because it sat outside the defined CDE is not three separate low-risk items. It is a breach path.
What the scanning program cannot see
Scope accuracy as a legal question
Scope definition is treated as a technical and operational decision. It is also an evidence decision. When a breach investigation opens, the first question is not what was scanned but what should have been scanned. If the scope definition excluded systems that were handling card data, the organization's position in the investigation changes significantly. Forensic investigators and card brand assessors will reconstruct the actual data flows from logs and network captures, not from the scope documentation. If the reconstruction shows card data in systems outside the defined scope, the compliance record does not protect the organization.
The gap between scan date and compromise date
ASV scans are point-in-time assessments. A passing scan from six weeks before a compromise tells an investigator what the environment looked like six weeks before the compromise. It does not tell them what it looked like at the time of the breach. Changes made after the scan, new deployments, configuration modifications, third-party integrations, create a documented gap between the compliance record and the actual environment state. Organizations that cannot produce change control logs showing what changed between the scan date and the compromise date cannot close that gap.
Cardholder data discovery as a separate obligation
PCI DSS v4.0 Requirement 12.5.2 requires targeted risk analyses and, depending on the entity type, periodic automated technical scans to identify where primary account numbers exist in the environment. This is cardholder data discovery, and it is separate from vulnerability scanning. Many organizations treat vulnerability scanning as their primary visibility tool for what is in the CDE. Vulnerability scanners find software flaws, not data presence. A system can pass every vulnerability scan and still be storing unencrypted card data in a log directory that no one mapped. Data discovery and vulnerability scanning answer different questions.
The evidence standard that most compliance programs do not meet
Requirement 11.3.1 authentication obligation
PCI DSS v4.0 Requirement 11.3.1 requires that internal scans be performed using authenticated scanning. The specific credential configuration, which accounts, what privilege level, how authentication is validated, is not specified by the standard. This means organizations can run unauthenticated internal scans, document them as compliant, and satisfy the QSA unless the QSA specifically asks to review the scan configuration. Most do not.
Significant change trigger
The PCI DSS defines significant changes as changes that could impact the security of the environment. The determination of what constitutes significant is left to the organization. In Vulnox assessments, the organization's definition consistently excludes changes that, in a post-breach review, would clearly qualify. Platform migrations, new API integrations, and third-party service additions are routinely classified as routine operational changes that do not trigger a rescan.
Forensic investigator evidence requests
Based on Vulnox post-incident review participation, the three most common evidence requests from card brand forensic investigators are authenticated internal scan results with configuration documentation, cardholder data discovery output, and change control logs. The ASV certificate is requested but treated as background documentation, not as primary evidence. The items that determine the outcome of the investigation are the three that quarterly ASV scanning does not produce.
Where this is heading
PCI DSS v4.0's authenticated scanning requirement will produce a wave of compliance failures when QSAs begin requesting scan configuration documentation rather than just scan reports. Organizations that have been running unauthenticated internal scans will face findings that their existing scanning programs do not address.
The v4.0 standard made the authentication requirement more explicit than v3.2.1. QSA training on v4.0 is still maturing. As assessors become more familiar with the authentication obligation and begin requesting configuration evidence rather than just results, the gap between what organizations are running and what the standard requires will become visible. The organizations most at risk are those that built their internal scanning programs around the v3.2.1 interpretation.
Confidence: highIf QSA findings data from PCI SSC or major QSA firms shows a notable increase in Requirement 11.3.1 deficiencies in v4.0 assessments conducted after mid-2025, this prediction holds. If deficiency rates remain flat, the authentication requirement is being interpreted loosely.Scope accuracy failures will become the primary driver of card brand forensic investigation outcomes within three years, displacing unpatched vulnerability findings as the leading compliance failure mode in breach reviews.
Vulnerability management tooling and patching cadences have improved materially across the merchant population. The easy findings, unpatched external-facing services, default credentials on known systems, are being addressed more reliably than they were five years ago. What has not improved at the same rate is data flow mapping and scope accuracy. As the easy technical findings become rarer, investigators will find that scope exclusions, systems with card data that were never assessed, are the remaining structural gap. One observable signal: if forensic investigation reports from card brands in 2025 and 2026 begin citing scope exclusions more frequently than specific CVEs as contributing factors, the shift is underway.
Confidence: mediumVerizon DBIR or card brand assessor data showing breach entry points by vulnerability category. If scope-related failures overtake specific CVE exploitation as contributing factors in PCI-relevant breaches by 2027, this prediction is confirmed.
The compliance record is not the defense
The framing of PCI DSS vulnerability scanning as a compliance exercise is accurate and also the wrong way to think about it. Compliance programs exist to establish a documented record of due care. The documented record is not the defense in a breach investigation, it is the starting point. Investigators use it to identify what should have been done and then determine whether it actually was. An ASV certificate shows that one type of scanning was performed on a quarterly basis. It does not show that the environment was accurately scoped, that internal scans were authenticated, that changes triggered rescans, or that cardholder data was mapped comprehensively. Organizations that optimize for the certificate rather than for the complete evidentiary record are building a defense that will not hold under the conditions that actually matter.
Counterargument
The strongest counterargument is resource constraint. Running authenticated internal scans with proper credential management, maintaining cardholder data discovery programs, and processing change-triggered rescans requires tooling and operational capacity that many mid-market merchants do not have. The quarterly ASV scan is outsourced to a vendor for a predictable cost. Everything else requires internal capability. That constraint is real. It does not change what the standard requires or what investigators request, but it explains why the gap persists. The honest answer is that PCI DSS compliance at the level the standard actually specifies costs more than the annual QSA fee implies.
One thing to do this week
Pull your last internal vulnerability scan report and look at the scan configuration log, specifically whether the scan was performed with authenticated credentials against each host. If the configuration is not documented in the report, or if the scan was run in unauthenticated mode, you have a Requirement 11.3.1 gap that your QSA may not have flagged. Document the gap, identify which hosts require authenticated access, and configure at least one authenticated scan before the next quarterly cycle. That scan will produce a different result than your current compliance record shows. The difference is what an investigator would find.
Further Reading
Vulnerability Assessment
vulnerability assessment servicesPCIDSS
PCI DSS compliance frameworkPCI DSS SAQ types explained: which one applies to your organization
https://vulnox.io/blog/pci-dss-saq-types-explainedPCI Security Standards Council
PCI Security Standards CouncilNVD Vulnerabilities Database
National Vulnerability DatabasePentesting vs Vulnerability Scanning SecurityMetrics
difference between pentesting and scanning
Frequently Asked Questions
Does passing a PCI DSS ASV scan protect a merchant from liability after a breach?
No. ASV scan results demonstrate point-in-time compliance with Requirement 11.3.2, but card brand forensic investigators and regulators request evidence of continuous monitoring, authenticated scan results, and scope accuracy documentation that quarterly ASV scans do not produce. Passing a scan before a breach does not establish that the environment was secure at the time of compromise.
What evidence do card brands actually request during a PCI DSS breach investigation?
Forensic investigators request authenticated internal scan results with credential logs, network segmentation validation evidence, change control records showing what changed between scans, and cardholder data discovery results. ASV passing certificates address none of these. In Vulnox assessments, the evidence gap between what was scanned and what was in scope appears in nearly every environment reviewed.
Why do internal PCI DSS vulnerability scans miss findings that external ASV scans catch?
Internal scans are frequently run without authenticated credentials, which means they see the same surface an unauthenticated attacker would, not what a privileged session reveals. PCI DSS Requirement 11.3.1 mandates authenticated scanning, but the specific credential configuration is left to the organization. In Vulnox assessments, the authenticated internal scan routinely surfaces three to five times the findings of the unauthenticated run on the same hosts.
What is shadow IT's impact on PCI DSS scan scope?
Systems handling cardholder data that are not included in the defined CDE scope are not scanned, which means vulnerabilities on those systems never appear in compliance reports. Regulators and forensic investigators frequently find that breach entry points were undocumented systems the organization did not know were in scope. This is a scope accuracy failure, not a scanning failure, but it collapses the compliance record retroactively.
How often do low and medium severity PCI DSS scan findings contribute to actual breaches?
Chained exploitation using low and medium severity findings is the dominant pattern in card data breaches Vulnox reviews post-incident. The ASV passing threshold focuses on high and critical findings, which creates a documented gap: vulnerabilities below that threshold are remediation backlogged for months, and forensic investigators regularly trace breach paths through exactly those findings.
What does PCI DSS Requirement 11 actually require for vulnerability scanning evidence?
Requirement 11.3.1 requires authenticated internal scans quarterly and after significant changes. Requirement 11.3.2 requires external ASV scans quarterly. Requirement 11.3.1.1 requires rescanning until no high or critical vulnerabilities remain. The evidence standard for each differs: ASV scans produce certificates; internal scans require organizations to retain authenticated scan reports, remediation records, and rescans. Most organizations retain only the ASV certificate.
What is the difference between PCI DSS vulnerability scanning and penetration testing for compliance purposes?
Scanning identifies known vulnerabilities by signature matching; penetration testing validates whether those vulnerabilities are actually exploitable in combination with the environment's specific configuration. PCI DSS Requirement 11.4 mandates penetration testing separately from scanning. The two produce different evidence types, and forensic investigators treat them as distinct. Organizations that substitute scan results for pen test evidence fail the evidentiary standard for Requirement 11.4.
Related Articles
API security assessment: what automated tools miss and manual testing finds
Automated API security tools find the vulnerabilities they were designed to look for. The findings that matter in real assessments, broken object-level authorization, JWT algorithm confusion, and unauthenticated internal endpoints, require a tester who understands what the API is supposed to do before probing what it actually does.
CVSS score explained: what the metric captures, what it misses, and how to fix your prioritization
In 40% of Vulnox assessments, vulnerabilities scored CVSS 9.0 or higher were on systems with compensating controls that materially reduced the actual risk. The score was accurate. The priority order it implied was not. This guide covers how to use CVSS correctly and what to layer on top of it.
Post-breach vulnerability assessment: what the attacker left behind
Most post-breach assessments start too late and end too early. They confirm what was hit, not what the attacker mapped before they moved. The second breach usually comes from the reconnaissance that happened in the first.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.