PCI DSS quarterly scanning: what ASV scans miss and what that costs during a QSA investigation
Sienna VanceApril 29, 2026
Key takeaways
PCI DSS Requirement 11.3 mandates quarterly external ASV scans and internal vulnerability scans. A passing ASV scan certifies no high-risk external vulnerabilities were detected on the scan date. It does not certify the cardholder data environment is secure or that scope is correctly defined.
ASV scans cannot access authenticated application areas, internal network segments, or test environments. Vulnerabilities inside these boundaries do not appear in ASV results regardless of severity.
Network segmentation between the CDE and out-of-scope systems is a required compensating control for scope reduction. PCI DSS v4.0 Requirement 11.4.1 requires penetration testing to validate segmentation effectiveness annually. A passing ASV scan does not validate segmentation.
SAQ A eligibility requires that the merchant has no ability to modify the payment page. Merchants using iframes that their own developers can edit are SAQ A-EP or SAQ D, not SAQ A. This is a scope definition failure that quarterly scanning does not surface but QSA investigators check directly.
Card brand fines for PCI DSS non-compliance are assessed to acquiring banks, who contractually pass them to merchants. Fine ranges run from $5,000 to $100,000 per month depending on the card brand and violation tier. Forensic investigations after breaches consistently find that network segmentation had drifted since the last QSA review.
PCI DSS v4.0 introduced customized approach as an option for controls in Requirement 12.3.2. Any organization using a customized approach must document a targeted risk analysis. QSA investigators reviewing a breach scenario will request that documentation as the first evidence artifact.
TL;DR
PCI DSS quarterly scanning is a compliance floor, not a security ceiling. ASV scans validate external exposure against known vulnerabilities on a given date. They do not validate scope accuracy, segmentation effectiveness, or internal configuration state. The merchants who face enforcement after a breach are not usually the ones who skipped scanning. They are the ones who passed scanning while scope had drifted, segmentation had degraded, or a test environment that was never properly isolated had accumulated the same card data as production.
The passing scan that preceded the breach
A mid-size e-commerce merchant had passed quarterly ASV scans for three consecutive years. Their QSA had reviewed and signed off on annual assessments. When a breach exposed approximately 40,000 card records, the forensic investigation traced the entry point to a staging environment running on a subdomain that had been excluded from CDE scope on the grounds that it processed no live transactions. The staging environment shared a database replica with production for testing purposes. It had not been updated with the same patch cycle as production systems. It was reachable from the internet. The ASV scans had not flagged it because it had not been included in the scan scope provided to the ASV. The merchant had provided the scope. The QSA had accepted the scope. The card brands assessed fines to the acquiring bank within 30 days of breach notification.
The breach was not caused by a scanning failure. It was caused by a scoping failure that scanning never had the opportunity to detect. This is the enforcement pattern that QSA investigators see most often: not organizations that failed their scans, but organizations whose scope definition allowed the vulnerable systems to sit outside the scan boundary.
What PCI DSS Requirement 11.3 actually requires and where the gaps are built in
PCI DSS v4.0 Requirement 11.3.2 requires quarterly external vulnerability scans by an ASV, with passing results defined as no vulnerabilities scored 4.0 or higher on the CVSS scale. Requirement 11.3.1 requires quarterly internal vulnerability scans performed by qualified personnel, with all high-risk vulnerabilities addressed before the scan is considered passing. These are separate obligations with different scope, different methodologies, and different evidence standards. ASV scans cover externally accessible components of the CDE as defined by the scope the merchant provides to the ASV. Internal scans cover systems within the defined CDE boundary as assessed from inside the network. Neither scan type is required to validate that the scope itself is correct. Scope validation is a separate QSA function under Requirement 12.3.1. The structural gap is that scope can drift between annual QSA reviews without triggering a scan failure.
Example
Test environments are the most consistent source of scope creep in merchant environments. A development team creates a staging subdomain to test checkout flow. It is excluded from CDE scope because it does not process live cards. Over time, it begins receiving actual card data from QA testing, or it shares a database connection with production for data fidelity in tests. The exclusion stays on the scope document because nobody reviewed it when the environment changed. The ASV scans the systems on the scope list. The staging environment is not on the list. A passing scan result is produced for an environment that now contains card data in an unmonitored location.
PCI DSS v4.0 introduced a significant change in how penetration testing relates to scanning. Requirement 11.4.1 now requires penetration testing that validates network segmentation between the CDE and out-of-scope networks. This is separate from quarterly scanning and must be performed annually and after significant infrastructure changes. Organizations that treat ASV scanning as their primary validation of segmentation effectiveness are not meeting this requirement. The pen test must specifically attempt to breach segmentation controls, not just confirm they are configured.
What the assessment data shows about PCI scanning programs
Assessment base: Patterns observed across PCI DSS gap analysis and vulnerability assessment engagements by Vulnox, primarily covering e-commerce merchants, payment processors, and hospitality organizations.
Scope documents do not reflect actual CDE boundaries at the time of scanning
In a consistent pattern across merchant environments, the scope document provided to the ASV reflects the CDE as it was defined at the last QSA assessment. Infrastructure changes between assessments, new cloud environments, SaaS integrations with payment APIs, subdomains spun up by development teams, are added to production without triggering a scope review. The ASV scans what is on the list. The systems added after the list was last reviewed are not scanned. When we perform our own discovery scan against the IP ranges and domains associated with a merchant's payment operations, we regularly find externally accessible systems that are not on the ASV scope list and that the merchant's internal team was not aware were reachable.
A passing ASV result is only meaningful if the scope it covers is current. Organizations that do not perform their own external discovery before submitting scope to the ASV are producing compliance documentation based on an incomplete view of their attack surface. QSA investigators reviewing a post-breach environment ask for the scope document and then run their own discovery. The delta between what was scanned and what was reachable is the first place they look.
SAQ A eligibility is claimed by merchants whose integration does not qualify
SAQ A is the lightest compliance pathway, available to merchants who have fully outsourced payment processing and retain no ability to access or modify cardholder data. The specific requirement is that the payment page is entirely controlled by the payment service provider, with no merchant-controlled code executing on that page. Merchants using iframe integrations where the iframe is served by the PSP and the merchant's own developers can modify the iframe container page do not qualify for SAQ A. They qualify for SAQ A-EP at minimum, which requires quarterly ASV scanning and a broader internal assessment. The merchants claiming incorrect SAQ type are not conducting quarterly scans because their self-assessed compliance pathway does not require them. A QSA who reviews the actual integration architecture during an investigation will reclassify the merchant immediately.
SAQ type is a scope determination, not just a documentation choice. A merchant claiming SAQ A who is actually SAQ A-EP or SAQ D has been operating outside the required compliance program for however long the misclassification has been in place. Card brand fines in breach scenarios are calculated from the last date of confirmed compliance, which in a misclassification scenario may be the original SAQ submission date.
Network segmentation degrades between QSA reviews without detection
Network segmentation is validated during annual QSA assessments and, under PCI DSS v4.0, through annual penetration testing. Between those validation points, configuration changes accumulate. A firewall rule added to allow a business application through opens a path that was not there at the last review. A VLAN reassignment changes which systems can reach CDE components. A cloud security group is modified to allow broader access for operational convenience. None of these changes are individually alarming. Cumulatively they erode the segmentation boundary that the QSA certified. The next quarterly ASV scan does not detect this because ASV scans test external exposure, not internal network paths.
The enforcement pattern after cardholder data breaches consistently reflects segmentation that was valid at the last assessment and had drifted by the time of the incident. Merchants who rely on annual segmentation validation with no intermediate monitoring are carrying undisclosed risk for the eleven months between checks.
Internal scans are performed less rigorously than ASV scans because they produce no external artifact
ASV scan results are submitted to acquiring banks and QSAs as compliance documentation. There is external accountability for the result. Internal scans are conducted by the merchant's own team or a third party, and the output stays internal unless a finding requires remediation documentation. In engagements where we review internal scan histories, we find a consistent pattern: ASV scan schedules are followed precisely, internal scan schedules slip, scope for internal scans is narrower than the defined CDE, and findings from internal scans are tracked with less rigor than external findings because there is no acquiring bank waiting for a clean result.
Requirement 11.3.1 internal scan obligations carry the same compliance weight as Requirement 11.3.2 ASV obligations. A QSA conducting an investigation after a breach will request internal scan results alongside ASV results. Missing, incomplete, or unaddressed internal scan findings are PCI DSS violations regardless of whether the ASV results were clean.
ASV scanning versus internal scanning: what each actually covers
ASV external scanning
Covers externally accessible IP addresses and hostnames in the scope provided by the merchant. Uses approved scanning methodologies validated by PCI SSC. Cannot access authenticated application areas, internal network segments, or systems behind network address translation. Scope accuracy is the merchant's responsibility. Results submitted to acquiring bank as compliance evidence.
ASV scan results are the compliance artifact that acquiring banks and card brands review. A passing result is required for annual QSA sign-off. Passing results from an incomplete or outdated scope document satisfy the compliance requirement while leaving actual vulnerabilities undetected. Organizations that want ASV results to reflect real security posture need to perform their own external discovery before submitting scope.
Internal vulnerability scanning
Covers systems within the defined CDE from inside the network. Can access internal hosts, authenticated pathways if credentials are provided, and network segments not reachable from external scans. Methodology and tooling chosen by the merchant. Results are internal compliance documentation, not submitted to external parties.
Internal scans surface vulnerabilities that ASV scans structurally cannot reach: database server configurations, internal application services, lateral movement paths between CDE and out-of-scope segments. The absence of external accountability for internal scan results creates a consistent pattern of less rigorous execution. Treating internal scan results with the same documentation discipline as ASV results is the correct approach and the one that survives a forensic review.
Segmentation penetration testing (Requirement 11.4.1)
Required annually under PCI DSS v4.0 and after significant infrastructure changes. Must specifically attempt to breach segmentation controls, not just review configuration. Performed by qualified internal or external personnel. Results validate whether out-of-scope systems can reach CDE components through any path.
This is the control that closes the gap between documented segmentation and actual segmentation effectiveness. Organizations that have not incorporated segmentation pen testing since upgrading to PCI DSS v4.0 have an unaddressed compliance obligation that will surface during the next QSA review. The test must be documented with the methodology, scope, and findings in a format that a QSA can evaluate.
What quarterly scanning programs consistently do not catch
Cloud infrastructure added outside the change management process
Development and DevOps teams provision cloud resources faster than security review processes track them. An S3 bucket configured with public read access to store payment confirmation pages, a Lambda function with a payment API key in its environment variables, a cloud database instance whose security group was left open during development: none of these appear in ASV scan scope unless someone explicitly adds the IP or domain. Cloud-native environments require a discovery process that queries the cloud provider's asset inventory, not just a scan of known IP ranges.
Third-party scripts executing on payment pages
PCI DSS v4.0 Requirement 6.4.3 introduced specific controls for scripts executing on payment pages, including an inventory requirement and integrity verification. Merchants who have passed quarterly ASV scans for years may have analytics scripts, chat widgets, or A/B testing tools running on checkout pages that execute in the browser alongside the payment form. These scripts are not evaluated by ASV scans. They are evaluated under Requirement 6.4.3 and, in breach scenarios, are the vector for client-side skimming attacks. The 2024 increase in Magecart-style attacks against PCI-compliant merchants reflects the gap between scan coverage and payment page integrity.
Credentials and API keys in scan-exempt environments
Systems excluded from CDE scope on the grounds that they do not process card data may still hold credentials with access to systems that do. A CI/CD pipeline excluded from CDE scope that holds a deployment credential capable of modifying payment application code represents a path to CDE access that quarterly scanning does not evaluate. Scope exclusions based on data processing functions do not account for access relationships between excluded and in-scope systems.
Merchants with more frequent scanning have more scope drift, not less
Common belief
Organizations that scan more frequently maintain a more accurate view of their CDE and catch scope changes earlier. The assumption is that scanning cadence correlates with scope accuracy.
What we found
In engagements where we review scan histories alongside our own discovery results, the merchants with the highest scan frequency sometimes show the largest gap between scanned scope and actual CDE boundary. High-frequency scanning correlates with mature scan operations teams. It does not correlate with mature scope management processes, which sit in different organizational functions and have different review cadences.
Scanning frequency and scope accuracy are independent variables. An organization that scans weekly against a scope document that has not been reviewed since last year's QSA assessment is producing weekly confirmation that the 12-month-old scope is clean. The systems added to the environment after the scope was written are not in the scan. More frequent scanning of an incomplete scope does not improve accuracy. It reinforces a false baseline. Scope accuracy requires a discovery process that runs independently of and prior to the scan, identifying all systems in the payment environment and comparing that list against the current scope document. That process is not automated by scanning tools.
Where PCI DSS scanning enforcement is heading
By 2026, card brands will begin requiring merchants to submit external discovery results alongside ASV scan reports for Level 1 and Level 2 merchants, effectively making scope validation a documented quarterly deliverable rather than an annual QSA function.
PCI DSS v4.0 increased emphasis on continuous compliance over point-in-time assessment. The forensic investigation record from post-breach enforcement actions consistently identifies scope drift as a contributing factor. Card brands have the contractual authority to modify reporting requirements through their merchant agreements. The logical next step is requiring documented evidence that the scope submitted for scanning reflects a current discovery result, not a standing document from the last QSA cycle.
Confidence: mediumIf no major card brand publishes updated merchant reporting requirements that include external discovery documentation by end of 2026, the timeline was wrong.Client-side skimming attacks against PCI-compliant merchants will produce the first publicly documented enforcement action citing Requirement 6.4.3 non-compliance as the primary finding by end of 2025.
Requirement 6.4.3 became effective for all merchants on March 31, 2025. The requirement to maintain an inventory of payment page scripts with integrity verification is operationally demanding and was not required under PCI DSS v3.2.1. The Magecart attack pattern exploits exactly the gap this requirement targets. The first enforcement actions citing 6.4.3 deficiency will arrive shortly after the first breach investigations conducted against the v4.0 standard.
Confidence: highIf no publicly disclosed PCI DSS enforcement action cites Requirement 6.4.3 as a finding by December 2025, the prediction was wrong on timing.
The quarterly scan cadence is the wrong unit of measurement for PCI compliance
PCI DSS quarterly scanning produces four compliance data points per year against a cardholder data environment that changes continuously. The compliance framework treats those four data points as the primary evidence of external vulnerability management. They are not. They are the minimum documentation required to maintain a merchant agreement. The organizations that maintain genuine security posture between QSA reviews are not the ones with the cleanest scan records. They are the ones that treat scope management as a continuous operational function, perform change-triggered discovery when infrastructure changes rather than waiting for the next quarterly cycle, and validate segmentation more than once per year. The quarterly cadence was established when merchant environments changed slowly. It was not designed for cloud-native payment architectures where new components can be provisioned in minutes.
Counterargument
The counterargument is that more frequent mandatory scanning would create compliance burden without proportionate security benefit, and that the real solution is better scope management processes rather than a different scanning schedule. That argument is correct about the solution. It does not resolve the gap between what quarterly scanning is designed to certify and what merchants represent to their acquirers when they submit a passing result.
One process change this week
Before your next quarterly ASV scan cycle, run an external discovery process against your payment domain's IP ranges and subdomains independently of the scope document you submit to the ASV. Use passive DNS enumeration, certificate transparency logs, and an active port scan of your registered IP space to identify all externally accessible systems associated with your payment operations. Compare that list to your current ASV scope. Any system on the discovery list that is not on the ASV scope requires a documented scope decision: either add it to scope, or document specifically why it is out of scope and what controls prevent it from being a path to CUI. That documentation is what survives a forensic review. The undocumented exclusion does not.
Further Reading
Gap Analysis
framework gap analysisVulnerability Assessment
comprehensive vulnerability assessmentPCI 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 CouncilNational Vulnerability Database Home
National Vulnerability DatabaseOWASP ZAP for Penetration Testing
OWASP ZAP for penetration testing
Frequently Asked Questions
What does a passing PCI DSS ASV scan actually certify?
A passing ASV scan certifies that no vulnerabilities scored 4.0 or higher on the CVSS scale were detected on the externally accessible systems included in the scope provided by the merchant, on the date the scan was conducted. It does not certify that the scope is complete, that internal systems are secure, that network segmentation is effective, or that the cardholder data environment has not changed since the scope document was last updated.
Why does my ASV scan pass while my QSA still finds compliance gaps?
ASV scans test external exposure against the scope you submit. QSA assessments evaluate whether the scope is accurate, whether internal controls satisfy all requirements, and whether documentation reflects actual implementation. The most common reason a passing ASV scan coexists with QSA findings is scope drift: systems added to the environment after the scope document was last reviewed are not included in the scan and are not visible to the ASV result.
What is the difference between ASV scanning and internal scanning under PCI DSS?
ASV scanning covers externally accessible systems from outside the network, is conducted by a PCI SSC-approved vendor, and produces a result submitted to acquiring banks. Internal scanning covers CDE systems from inside the network, can be performed by qualified internal personnel or third parties, and results are internal compliance documentation. Both are required under Requirement 11.3. Internal scan results carry the same compliance weight as ASV results during forensic investigations, even though they do not generate an external artifact.
Does PCI DSS v4.0 change quarterly scanning requirements?
PCI DSS v4.0 retained quarterly ASV and internal scanning requirements under Requirement 11.3. It added Requirement 11.4.1, which requires annual penetration testing specifically to validate network segmentation effectiveness, separate from quarterly scanning. It also added Requirement 6.4.3, requiring an inventory of all scripts executing on payment pages with integrity verification, which is not addressed by quarterly scanning and became mandatory for all merchants on March 31, 2025.
What SAQ type applies to merchants using payment iframes?
Merchants using iframes served entirely by the payment service provider, where the merchant has no ability to modify the iframe or the payment page code, qualify for SAQ A. Merchants using iframes where their own developers control the container page or can modify the iframe integration qualify for SAQ A-EP at minimum. SAQ A-EP requires quarterly ASV scanning. Merchants claiming SAQ A eligibility for an integration that actually qualifies as SAQ A-EP are operating outside their required compliance pathway, which becomes a finding during QSA investigation.
How are PCI DSS fines calculated and who pays them?
Card brand fines for PCI DSS non-compliance are assessed to acquiring banks under card brand operating regulations. Acquiring banks pass fines to merchants through contractual agreements. Fine levels vary by card brand and violation category, ranging from $5,000 to $100,000 per month. Fines in breach scenarios are typically calculated from the last confirmed date of compliance. For merchants with scope definition failures or incorrect SAQ classification, that date may be earlier than expected.
What does network segmentation validation require under PCI DSS v4.0?
PCI DSS v4.0 Requirement 11.4.1 requires penetration testing that specifically validates network segmentation between the CDE and out-of-scope systems, performed annually and after significant infrastructure changes. The test must attempt to breach segmentation controls, not just review their configuration. A passing ASV scan does not satisfy this requirement. The segmentation pen test must be documented with methodology, scope, and findings in a form that a QSA can evaluate during an assessment.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.