Vulnerability scanning is the PCI requirement most organizations treat as a vendor subscription and the fewest actually run well. Requirement 11.3 in PCI DSS 4.0.1 asks you to find the flaws in your cardholder environment before an attacker does, with a specific cadence, specific scan types, and specific evidence. The letter of the requirement is short. The operational reality — authenticated internal scans, ASV-run external scans, the 90-day clock, what counts as a significant change, how to handle a failed scan — is where most programs quietly fall apart. This guide walks the full shape of a pci dss vulnerability scan program in 2026: what the text says, what auditors actually check, how to pick an ASV, and how to close the loop between scan findings and the developer work that prevents the same vulnerability from showing up next quarter.
Why 11.3 Is the Requirement Auditors Find Fastest
Vulnerability scanning sits in a rare class of PCI requirements where the assessor's evidence check is almost entirely binary: either the quarterly ASV scan reports exist, they were clean (or remediated), and they are on file — or they are not. There is no essay-style evaluation, no role-mapping argument, no training curriculum to negotiate. The scan happened, the report is here, the findings were closed within the required window — or one of those pieces is missing, and the finding writes itself. That clarity is why 11.3 has historically been a source of material findings for organizations whose compliance practice is otherwise strong. A missing quarterly ASV scan report is not something a compliance narrative can paper over.
2026 is the first full assessment cycle in which PCI DSS 4.0.1's 11.3 clauses are enforced without grandfather treatment. The subrequirements — 11.3.1 (internal scans), 11.3.1.1 (risk-based handling of non-high-risk findings), 11.3.1.2 (authenticated scanning), 11.3.1.3 (scans after significant change), 11.3.2 (external ASV scans), 11.3.2.1 (external rescan after significant change) — each carry their own evidence expectation. Programs that ran a single quarterly external scan through the 3.2.1 era and called it done are not structured to produce the evidence set the 4.0.1 assessment cycle requires. The gap has to be closed, and 11.3 is the requirement where procrastination is most expensive, because the clock runs in three-month segments that cannot be re-created after the fact.
What Requirement 11.3 Actually Says
The current text of Requirement 11.3 in PCI DSS 4.0.1 reads:
"External and internal vulnerabilities are regularly identified, prioritized, and addressed."
That sentence is the parent requirement. Most of the operational specificity lives in the subrequirements. The shape of the full requirement is worth reading as a block because the clauses interact — a program that satisfies 11.3.2 (external ASV) perfectly can still fail the overall 11.3 requirement if 11.3.1 (internal scans) is neglected, and vice versa.
11.3.1 — Internal vulnerability scans. Scans of the internal in-scope environment at least once every three months and after any significant change. "Internal" means systems inside the organization's network that are in scope for the cardholder data environment — the system that processes card transactions, the database holding PAN data, the hosts that can route to them, and the supporting infrastructure. The scans must identify vulnerabilities classified as high-risk or critical according to the organization's risk ranking, and those findings must be resolved.
11.3.1.1 — Non-high-risk handling. Vulnerabilities classified below the high/critical threshold are still tracked and addressed according to the organization's risk-based approach, with documented timelines. Not a free pass — a documented posture is still required.
11.3.1.2 — Authenticated scanning. Internal scans of systems that support authentication must themselves be authenticated — the scanner logs in using credentials sufficient to see the vulnerabilities a logged-in attacker would see. This is the clause that catches the most programs off-guard, because an unauthenticated internal scan misses entire categories of findings (missing patches behind login screens, insecure service configurations visible only to authenticated users, credentialed API surface vulnerabilities).
11.3.1.3 — Scans after significant change. Any significant change to an in-scope system requires an internal scan afterward, outside the quarterly cadence. The definition of "significant change" is left to the organization to document, but the assessor will read that definition critically. A definition that excludes major deployments, new system introductions, network re-architecture, or access control changes is not a defensible definition.
11.3.2 — External ASV scans. Quarterly external scans by a PCI Council-approved scanning vendor (ASV). The scans cover all externally accessible system components in scope. "Quarterly" means once every 90 days — not once a calendar quarter with slippage. The scan report has to result in a passing scan, meaning no vulnerabilities above the threshold the PCI Council has published, or the organization must remediate and rescan until a passing scan is achieved.
11.3.2.1 — External rescan after significant change. The same external rescan trigger as internal. A significant change to an externally accessible system requires a new external ASV scan, not just a follow-up internal scan.
Every clause has an evidence artifact. The QSA's check is "show me the report": the internal scan reports for every 90-day window in the assessment period, the external ASV reports, the rescan reports triggered by significant changes, and the remediation records that close the loop between a finding and its resolution. Missing reports are not a gray area.
External Scans (11.3.2): ASV, the PCI SSC Register, and the Quarterly Clock
The external side of 11.3 is outsourced by design. The Council maintains a register of Approved Scanning Vendors — currently about seventy organizations that have passed the Council's ASV qualification and are re-certified annually. Any externally accessible system in scope has to be scanned by an ASV, using the ASV's accredited scan methodology, with the report produced in the PCI-defined Attestation of Scan Compliance format. A scan run by an internal team or by a non-ASV scanner, however technically sound, does not satisfy 11.3.2 — the ASV accreditation is a structural requirement, not a technical one.
What the ASV scan covers. Every externally accessible IP address, hostname, and web application endpoint that is in scope. The ASV will work with the organization to scope the scan — a documented exchange that lists the target IPs, the expected services, and any systems that are explicitly out of scope with justification. The scope document is itself an evidence artifact. Organizations that hand the ASV an incomplete target list and call the resulting passing scan "PCI-compliant" produce an artifact that a careful QSA can pick apart.
The 90-day cadence, not the calendar quarter. The clause says "at least once every three months". In practice, the assessor will measure the gap between successive scan completion dates. A scan completed on 4 February and the next one on 10 May leaves a 95-day window — technically out of cadence. Organizations that treat the requirement as "one scan per calendar quarter" tend to drift into these edge cases during holiday seasons or team changes. The defensible pattern is a scheduled scan at a fixed day-of-month — the 15th of February, May, August, November — with a week of buffer for remediation if findings appear.
What a passing scan looks like. The ASV scan produces a report that lists every finding with a CVSS score. The Council publishes a threshold — any CVSS 4.0 or higher is automatically a failing condition, with limited exceptions for certain finding categories (denial-of-service findings, for example, are treated differently). Findings above the threshold must be remediated or dispute-resolved, and the scan must be re-run until the report is clean. A report with outstanding findings above the threshold is not a passing scan and does not satisfy the quarterly requirement.
The dispute process. When the ASV flags a finding the organization believes is a false positive or a misinterpreted risk, a formal dispute process with the ASV resolves it. The ASV can accept the dispute (remove or downgrade the finding from the report) or reject it (the organization has to remediate). Dispute records are part of the evidence package — a clean scan report achieved after a disputed finding was removed still needs the dispute exchange on file to explain the trajectory.
Internal Scans (11.3.1): Authenticated, In-Scope, Often Neglected
Internal scanning is the half of 11.3 that programs underbuild. Organizations that have a mature external ASV practice frequently treat internal scanning as a lighter weight activity — a scheduled Nessus or Qualys scan, unauthenticated, against the CIDR range they think the CDE lives in, with no formal evidence retention. Each of those shortcuts is a potential finding.
The "in-scope" definition. Internal scans cover everything in scope, not everything the organization owns. That sounds easier but turns out to be harder in practice. PCI scope includes the systems that process cardholder data, the systems that store it, the systems that transmit it, and the systems connected to those (or able to impact the security of those). A careful scope review usually ends up larger than the compliance team's initial intuition — supporting jump boxes, DNS infrastructure, logging aggregators, and monitoring systems often end up in scope because they can influence the CDE's security posture. The internal scan target list has to reflect that reviewed scope, not a narrower "core CDE" subset.
Authenticated scanning (11.3.1.2). The scanner logs in. For servers, that is a low-privilege account with enough rights to enumerate installed packages, running services, and configuration state. For network devices, SNMP or CLI credentials. For cloud systems, IAM credentials sufficient to read configuration. An unauthenticated scan sees what is publicly exposed; an authenticated scan sees the full vulnerability surface including the patches that are missing, the services that are misconfigured, and the credentials that are weak. The gap between the two is large — for a typical Linux server, an unauthenticated scan might produce five findings while an authenticated scan produces fifty. The clause exists because the Council has observed that the gap between unauthenticated and authenticated visibility is where attackers operate once they have gotten past the perimeter.
The quarterly cadence and its practical shape. Internal scans follow the same 90-day clock as external scans. Most organizations schedule internal scans weekly or monthly, with the quarterly PCI scan being a specific named run against a documented target list with a documented report. The frequent scanning produces operational visibility; the quarterly PCI scan produces the compliance artifact. Organizations that run internal scans monthly but cannot produce a discrete "quarterly PCI scan" report — just a monthly scan from the 15th of the relevant month — can usually satisfy the requirement by documenting that the monthly scan of record for each quarter is the PCI scan for that quarter. The artifact has to be identifiable.
Risk-ranking the findings. 11.3.1 requires findings classified as high-risk or critical to be resolved. The classification methodology is the organization's own, documented in a risk-ranking policy. CVSS is the common default, but a defensible methodology can add context — an exploited vulnerability in a payment-processing path weighs more than the same CVSS score on an isolated log-aggregator. The ranking policy has to be in writing, consistently applied, and match the findings that get remediation priority. A policy that says "we use CVSS ≥ 7.0 as high-risk" but then remediates a CVSS 5.4 finding as high-risk because of business context is fine, as long as the context is recorded.
How Often You Actually Need to Scan
The minimum cadence is quarterly for both internal and external. In practice, the defensible program runs at a higher frequency — internal weekly or bi-weekly, external with quarterly ASV plus frequent self-scans — with the quarterly runs being named, documented, and retained as the compliance evidence. The higher frequency is not required by the standard; it is required by operational reality. A vulnerability introduced on day 2 of a 90-day window is present in production for 88 days before the next quarterly scan finds it, which is a long time for a critical CVE to live in a cardholder environment.
The "significant change" rescan. 11.3.1.3 and 11.3.2.1 each require a rescan after a significant change — outside the quarterly cadence. Organizations that deploy frequently need to think about this as an engineering-workflow problem rather than a compliance-calendar problem. A deployment pipeline that handles a significant change well has an automatic hook: the change is logged, the scan is triggered, the report is retained, the deployment is gated on the scan result. Organizations that handle significant changes as one-off tickets routed to the compliance team tend to miss rescans whenever the organization ships fast enough to outrun the manual process.
A note on continuous scanning. Several modern vulnerability management platforms offer continuous scanning — effectively real-time visibility into the target environment. 4.0.1 does not require continuous scanning, but the requirement text's direction — toward earlier detection, faster remediation, fewer gaps — is clearly compatible with continuous models. Programs that move from quarterly-batch to continuous scanning typically find that their assessment conversations get easier because the evidence is more granular and more current. The quarterly report is still produced as a discrete artifact, but it is produced by snapshotting the continuous system at the required intervals, which is administratively simpler than running a separate scheduled scan.
What Counts as a "Significant Change"
The phrase "significant change" is intentionally left to organizations to define — but the QSA reads the definition critically, and weak definitions get challenged. A defensible internal policy covers five categories at minimum.
New system introductions. A new server, container cluster, cloud account, or network segment brought into scope. Even if the new system is "the same as" an existing one, it is a significant change — new attack surface, new patch state, new credentials.
Major upgrades and patches. OS version upgrades, major application-framework upgrades, database engine upgrades. Minor patches in the normal operational cycle are not significant changes in most definitions, but major upgrades are.
Network and firewall changes. Any rule change that changes what is accessible from where. New ingress rules, VPN configuration changes, DNS changes affecting exposure, load balancer reconfiguration.
Access control changes. Changes to authentication mechanisms, privilege assignments, or identity provider configuration for in-scope systems. A new IdP integration is a significant change; a routine user provisioning is not.
Material application deployments. Deployments that introduce new endpoints, new data flows, new third-party integrations, or significant changes to existing authentication, authorization, or cryptographic handling in the application. The bar is not "every sprint release" — it is "changes that materially alter the attack surface of the in-scope application". A definition that excludes this category is a weak definition; a definition that defines it precisely is a strong one.
The operational mechanism for tracking these is usually a change-management system with a "PCI scope" flag. When the flag is set, the change ticket is paired with a scan trigger. The scan is run, the report is retained, the change is closed. Organizations without a change-management system suitable for this purpose typically end up missing rescans on a predictable cadence — the exact cadence at which their organizations ship.
ASV Vendor Selection: What to Actually Evaluate
Choosing an ASV is structurally similar to choosing any specialized vendor, but the PCI accreditation is the first filter. Any vendor not on the current PCI SSC ASV register is disqualified. Beyond that, the vendors differ on depth of coverage, report quality, dispute-process responsiveness, and price — factors that matter for the operational burden the compliance team will carry through every quarter.
Coverage depth. The ASV's scanner needs to handle every service your externally accessible environment runs. Modern web frameworks, modern API patterns, TLS configurations, HTTP/2 and HTTP/3, WebSocket services, GraphQL endpoints, managed-cloud services, CDN-fronted origins. Older ASV products built around scanning servers directly sometimes miss the full surface of a modern cloud-native application. The right evaluation is a scope document walkthrough — show the ASV what your environment actually looks like, and see whether they can scan it coherently.
Report clarity. ASV reports have the PCI-defined structure, but within that structure the clarity varies materially. Some reports make false-positive identification easy — they group related findings, cite the exact evidence captured, and provide enough context for a security engineer to triage in minutes. Others produce flat lists of findings that take hours to pick through. The cost of a bad report is the operational time of every quarterly cycle.
Dispute responsiveness. Every organization runs into false positives. The ASV's willingness to engage on disputes — the speed of response, the quality of the reasoning, the flexibility on edge cases — determines how much time the compliance team spends on each cycle. A slow or rigid ASV turns a one-day scan into a two-week negotiation.
Integration surface. Modern ASVs can integrate with ticketing systems, SIEM platforms, and vulnerability management pipelines. The integration turns findings into tickets, tickets into remediation work, remediation into rescan triggers. Organizations that treat the ASV as a standalone quarterly activity end up with an evidence package that requires manual assembly; organizations that integrate the ASV into the rest of the workflow produce evidence as a byproduct of operation.
Pricing structure. Per-IP, per-asset, or per-scope pricing is the norm. Buyers evaluating ASVs often over-index on the annual subscription and under-index on the per-incident costs — additional scans, significant-change rescans, dispute resolutions. A vendor with a low headline price but high per-incident costs can produce a higher total cost over a year than a vendor with a higher subscription but bundled incidentals.
Handling a Failed PCI Scan: Remediation, Rescan, Dispute
A failed scan — a report with CVSS 4.0+ findings that are not disputed out — is not a compliance catastrophe. It is a normal part of the cycle if handled within the remediation window. The problem is not the failed scan; it is the failed scan that stays failed.
The remediation window. PCI DSS 4.0.1's expectation is that findings above the threshold are remediated "as soon as possible" — with the practical bar being that the organization must achieve a passing ASV scan for the quarter. If the quarterly clock is about to close with an outstanding high-severity finding, the organization has to remediate and rescan within the quarter. Organizations that routinely close quarters with an unresolved failing scan accumulate findings against 11.3.2 that are hard to recover from.
The remediation workflow. A finding above the threshold generates a ticket, the ticket routes to the team that owns the affected system, the team produces a fix, the fix deploys, the ASV re-runs the scan, the rescan confirms the fix. This workflow has to be built. Organizations that handle each finding as a one-off email exchange between compliance and engineering end up with a workflow that runs on heroics and fails on vacation coverage.
The dispute path. When a finding is a false positive — the ASV scanner misidentified a service, flagged a disabled feature, or reported a vulnerability in a component that does not actually exist — the dispute process is the right channel. The organization files the dispute with the ASV, provides evidence, and the ASV resolves. The dispute is not a shortcut around a real finding; attempting to dispute out a legitimate vulnerability tends to harden the ASV's posture on future disputes and sometimes invites deeper scoping questions from the QSA.
Compensating controls for un-remediable findings. Occasionally a finding is real but cannot be remediated within the quarter — a legacy system the organization is actively retiring, a vendor-supplied appliance with a pending patch. The standard accommodates these cases through compensating controls, documented and accepted as a temporary posture. The compensating control is an evidence artifact and needs the QSA's eventual acceptance; it is not a unilateral decision the organization can make to close a finding without actually closing it.
Where Developers Come In: Scan Findings and Secure Coding
The unspoken half of 11.3 is that most of the findings ASVs and internal scanners produce for in-scope applications are application-layer findings — SQL injection surfaces, cross-site scripting, weak authentication flows, insecure deserialization, misconfigured security headers. These are the exact classes of vulnerability that PCI DSS Requirement 6.2.2 secure coding training exists to prevent upstream. A mature program closes the loop: scan findings inform training, training prevents future scan findings.
Triage on the developer side. When a scan surfaces an application-layer finding, the remediation usually lands with the development team that owns the affected component. A triage process that pairs a scan finding with a clear reproduction, the affected code location, and a suggested remediation pattern moves much faster than one that hands over a CVSS-scored line-item and expects the developers to investigate from scratch. The pci dss vulnerability scan output is not a communication artifact by default; the compliance or AppSec team has to translate it.
Preventing repeat findings. If the same class of finding surfaces in scan after scan — authentication bypasses, output-encoding gaps, access-control issues — the program has a structural gap, not a series of individual bugs. The gap is usually upstream in training, code review, or architectural patterns. Aligning the training curriculum to the scan-finding history is the cheapest feedback loop in the program; it is also the one most organizations do not run, because the scan data and the training curriculum live in different teams' systems.
Integration with code review (6.2.3). A code review practice that explicitly checks for the vulnerability classes the scans most often find becomes an upstream defense. The finding distribution from the last four quarters is a useful input to a code-review checklist update. The loop is tight: scan finding → root cause analysis → training or review checklist update → reduced finding rate in next quarter's scan.
The Evidence Package 11.3 Produces
A QSA working 11.3 during an assessment is looking for a specific bundle of artifacts. Having them all neatly organized turns a potentially detailed section of the assessment into a short one.
- External ASV scan reports. One per quarter, each showing a passing scan (or the final passing scan of a remediation cycle), for every quarter in the assessment period.
- Internal scan reports. Quarterly internal scan reports, authenticated where required, covering the documented in-scope target list.
- Significant-change rescan reports. Additional scan reports tied to each significant change in the assessment period, with the change-management record establishing the trigger.
- Remediation records. For each finding above the threshold, evidence of the remediation — ticket, code change, configuration update, timestamp — and the rescan that confirmed closure.
- Dispute records. For each disputed finding, the dispute filing, the ASV's response, and the updated report.
- Risk-ranking policy. The organization's documented methodology for classifying findings as high-risk, with evidence that it is consistently applied.
- Significant-change policy. The organization's documented definition of what constitutes a significant change, with examples.
- Scope documentation. The in-scope target list for internal and external scans, with evidence of periodic review to confirm that new systems are added and retired systems are removed.
Producing these eight artifacts cleanly, on request, within the same day, is the operational capability that turns 11.3 from an ongoing risk into a finished-problem section of the program. Organizations that build the capability once amortize it across every subsequent assessment and every adjacent framework — SOC 2, ISO 27001, HIPAA security rule — that expects the same kind of evidence in a slightly different format.
Scan Findings Without a Training Loop Become Next Quarter's Findings
SecureCodingHub's PCI DSS program is designed to close the loop between pci vulnerability scan output and the developer training that prevents the next occurrence — language-specific secure coding training for Req 6.2.2, awareness training for Req 12.6.1, and the evidence package your QSA expects across the 4.0.1 cycle. If your organization is preparing for the 2026 assessment and wants to walk through how our program maps to your team, we are happy to show you directly.
See Our PCI DSS ProgramCommon 11.3 Failure Modes Worth Watching For
A short catalog of the patterns that produce 11.3 findings most consistently in 2026 assessments. None are individually fatal; together they describe a program that has not matured past 3.2.1-era expectations.
Unauthenticated internal scans. The scanner runs, produces a report, the report shows few findings, the compliance team files it. An authenticated version of the same scan would have produced twenty times the findings. The 11.3.1.2 clause exists to make this gap visible, and the QSA will check that the scanner authenticated.
Stale scope documents. The in-scope target list was accurate three years ago. The organization has since migrated to containers, added two cloud accounts, and decommissioned a legacy network segment. The scan runs against the old list and misses half the current surface.
External scans only. The compliance team treats the quarterly ASV scan as the full PCI scanning program. Internal scanning is informal or non-existent. The QSA will ask for internal scan reports, and their absence is an 11.3.1 finding.
Change-triggered rescans missing. The organization deploys or changes frequently and has no mechanism to trigger a rescan after significant changes. Each significant change is a potential 11.3.1.3 or 11.3.2.1 finding for the cycle.
Remediation delay. A finding above the threshold sits open for weeks while the quarterly clock ticks toward the next cycle. The organization eventually closes the finding but cannot produce evidence that a passing rescan was achieved before the clock reset.
Risk-ranking not applied consistently. The policy says one thing, the remediation pattern does another. The assessor will check whether the documented methodology matches how findings are actually prioritized in the ticket history. Inconsistency is a quieter finding but a real one.
Findings without root-cause analysis. The same finding type appears in scan after scan. The organization remediates each instance individually but does not investigate why the pattern recurs. The assessor will notice the recurrence and question the program's feedback loop.
Closing: 11.3 Is a Program, Not a Vendor Subscription
The shape of a defensible pci vulnerability scan program in 2026 is not exotic. Internal scanning at a disciplined cadence, authenticated. External ASV scanning on the 90-day clock. Rescans triggered by significant changes. A risk-ranking policy that matches remediation behavior. Remediation workflows that close findings predictably. A feedback loop to training, code review, and architectural patterns that reduces the rate of repeat findings. An evidence package that can be produced on demand.
The organizations that run this program well are also the organizations whose Reports on Compliance in 2026 look short in the 11.3 section — because there is nothing to argue about, the evidence is complete, and the assessor's job is to verify rather than investigate. The organizations that run the program as a vendor subscription — the quarterly ASV scan filed in a folder, with no internal counterpart and no loop back to the rest of the security program — are the organizations whose 11.3 findings accumulate year after year. The difference is operational, not technical, and it is the highest-leverage part of the requirement to get right.
Scanning finds the vulnerabilities the organization already has. Training prevents the vulnerabilities the organization would have created next. A program that does both, with evidence, passes 11.3 and 6.2.2 in the same assessment cycle — and the organizations that run that kind of program are not the ones reading this article. They are the ones already shipping the evidence package. This guide is for everyone else, and the work to get there, while not trivial, is well-defined enough to plan against.