PCI DSS Vulnerability Scanning: A Complete Guide

Quick Overview: This guide explains PCI DSS vulnerability scanning in plain terms. It covers what it is, who needs it, what falls in scope, and what the standard requires. You will also learn what makes a scan pass or fail, how to run the process step by step, and what internal and external scans typically cost.

Day 85 of the quarter. The external scan just came back, and one finding scored 4.0 on CVSS. That single line fails the whole report, and the quarter is almost over.

Sound familiar? PCI DSS vulnerability scanning looks simple on paper: scan every three months, fix what fails, rescan. In practice, teams get stuck on the details. What is in scope? Who is allowed to run the scan? What counts as a pass? And what will it all cost?

The stakes go beyond audit paperwork. Verizon's 2026 DBIR found that exploitation of vulnerabilities accounted for 31% of breaches, making it the most common way attackers get in. The same report shows the fixing side is slipping. Only 26% of critical vulnerabilities on CISA's Known Exploited Vulnerabilities list were fully remediated in 2025, down from 38% the year before.

That gap is exactly what compliance-driven vulnerability scanning exists to close. But a passing scan is a snapshot, and attackers do not work in snapshots.

This guide covers what PCI DSS vulnerability scanning is, who needs it, what to scan, what the standard requires, and what makes a scan pass or fail. It then walks through the process step by step and breaks down what it costs. By the end, you will know what to do before the next quarter closes.

Fixing findings is easier than explaining them. Start with proof-backed results, no setup. Try ZeroThreat Free

What is PCI DSS Vulnerability Scanning?

PCI DSS vulnerability scanning is the automated process of checking systems, networks, and applications for known security weaknesses, as required by the Payment Card Industry Data Security Standard. Organizations that store, process, or transmit cardholder data use these scans to find and fix weaknesses before attackers can use them.

The requirement sits mainly under Requirement 11.3 of PCI DSS v4.x. A scanner compares what it finds on each system against databases of known vulnerabilities and flags the matches. Typical findings include:

• Missing security patches
• Outdated or vulnerable software versions
• Insecure default settings and misconfigurations
• Weak encryption protocols and ciphers
• Exposed services and open ports that should not be reachable

The scans cover the cardholder data environment (CDE) and any connected systems that could affect its security. Some scans run from inside the network, while others test internet-facing systems from the outside. External scans must be performed by a PCI SSC Approved Scanning Vendor (ASV).

The key distinction to know is that a scan identifies potential weaknesses. It does not prove that an attacker can exploit them. That job belongs to penetration testing, which PCI DSS treats as a separate requirement. In the same way, a clean scan report is evidence for one control. It does not make an organization PCI compliant.

Who Needs PCI DSS Vulnerability Scanning?

Any organization that stores, processes, or transmits cardholder data needs PCI DSS vulnerability scanning. The requirement also applies to organizations whose systems could affect the security of the cardholder data environment (CDE), even when those systems never touch card data directly.

That covers a wide range of businesses:

• Merchants of Every Size: Retailers, restaurants, e-commerce stores, and subscription businesses that accept card payments. Business size changes how compliance is validated, but it does not remove the scanning obligation.
• Payment Processors and Acquirers: Organizations that handle card transactions between merchants and card networks.
• Issuers: Banks and financial institutions that issue payment cards and handle cardholder data.
• Service Providers: Hosting companies, payment gateways, managed IT providers, and cloud platforms that store, process, or transmit card data for other businesses, or that can affect the security of a customer's CDE.
• Organizations with Connected Systems: Teams running internal networks, databases, or applications that connect to the CDE. These systems fall inside the scanning scope because a weakness there can give attackers a path into card data.

The important thing to understand here is who must scan and who must prove it. PCI DSS applies the scanning requirement to every in-scope entity. How an organization reports compliance depends on its merchant level or service provider status, its self-assessment questionnaire (SAQ) type, and the rules of its acquirer or payment brand. Those bodies, not the PCI Security Standards Council, decide the validation requirements.

Outsourcing payment handling does not remove responsibility. A merchant that uses a third-party payment page may reduce its scope, but it still has to confirm which of its own systems remain in scope and validate accordingly. The service provider's scans also do not replace scans of the merchant's own in-scope systems.

What is the Scope for PCI Vulnerability Scans?

The scope for PCI vulnerability scans includes every system component in the cardholder data environment (CDE), plus any connected system that could affect the CDE's security. It also includes every internet-facing IP address and domain that is part of the CDE or could give an attacker a path into it. Scope is defined by what a system can reach and affect, not only by where card data is stored.

What Falls Inside the Scope

In-scope assets typically include:

• CDE Systems: Servers, databases, POS terminals, payment applications, and network devices that store, process, or transmit cardholder data.
• Connected Systems: Systems with unrestricted connectivity to the CDE, or those that provide security services to it, such as authentication servers, DNS, logging, and admin workstations.
• Segmentation Controls: Firewalls, routers, and other devices that separate the CDE from the rest of the network.
• Public-Facing Assets: Web servers, load balancers, APIs, and payment pages that the organization hosts itself.
• Cloud Components: Virtual machines, containers, and cloud services within the organization's side of the shared responsibility model.

A system does not need to hold card data to be in scope. A logging server that collects events from payment servers on the same flat network may store no card data at all. It is still in scope, because a compromise there could expose or disrupt the CDE.

Internal vs External Scan Scope

The two scan types cover different parts of the environment.

The organization, not the ASV, is responsible for defining external scan scope. An ASV scans what it is given. If an internet-facing system is left off the list, it goes untested even though it sits in scope.

Payment pages change between quarters. Scan them with 130K+ checks whenever they do. Scan Between Quarters

PCI DSS Vulnerability Scanning Requirements and Frequency: Quick Glance

PCI DSS requires organizations to run internal and external vulnerability scans at least once every three months, and again after any significant change to the environment. Internal scans must be authenticated and performed by qualified personnel. External scans must be performed by a PCI SSC Approved Scanning Vendor (ASV). The table below summarizes each requirement under Requirement 11.3.

How to Perform PCI DSS Vulnerability Scanning

PCI DSS vulnerability scanning follows a repeatable loop: define scope, run internal and external scans, rank the findings, fix them, rescan, and keep the evidence. PCI DSS v4.0.1 treats scanning as a scan, remediate, and rescan process rather than a quarterly reporting exercise. The steps below show how that loop works in practice.

[  {Visual Recommendation}  - Type: Circular process flow diagram  - Purpose: Show that PCI scanning is a recurring loop, not a one-time task.  - Elements: Scope inventory, internal scan, external ASV scan, prioritize, remediate, rescan, retain evidence, with an arrow back to the start labeled "every 3 months and after significant changes."  ]

1. Turn Scope into a Scan Inventory

Scope tells you what must be scanned. The inventory tells the scanner where to look. Build it from the asset inventory and network diagrams, and list the following:

• Internal IP ranges and hosts in the CDE and connected systems
• Public IP addresses and domains that are part of the CDE or lead into it
• Systems that need credentials for authenticated scanning
• Components added or changed since the last scan

An outdated inventory is the most common reason a scan passes while a real exposure goes untested. Update the list before every cycle, not once a year.

2. Choose the Scanner and Scan Provider

The two scan types have different rules on who can run them.

• External scans: These must be performed by a PCI SSC Approved Scanning Vendor. The Council tests and approves an ASV's scan solution before adding the vendor to its official list. An in-house scanner cannot replace an ASV for this requirement, however capable the tool is.
• Internal scans: Qualified internal staff or a third party can run these, as long as organizational independence exists. For internal scanning, look for a scanner that supports credentialed (authenticated) scans, since the standard now expects them.

3. Run Internal and External Scans

Run both scan types at least once every three months, and again after significant changes. Schedule them early in the quarter so there is time to fix and rescan before the deadline.

Internal scans should be authenticated. Under Requirement 11.3.1.2, scans of systems that accept credentials must use those credentials, and the scanning tool must store them securely. This has been mandatory in applicable v4.x assessments since March 31, 2025. Credentials matter because a logged-in scan can see installed software, patch levels, and local configuration that an outside-in scan cannot.

External scans run from the internet against the public targets the organization supplies. The ASV only tests what it is given, so a missing IP address means an untested system. Before the scan starts, confirm that intrusion prevention systems and firewalls will not block the scanner, since blocked probes can hide real findings.

For example, an unauthenticated internal scan may report a database server as clean. An authenticated scan of the same server can show a missing operating system patch that only appears once the scanner can inspect the host.

4. Prioritize Findings and Remediate

Findings need a ranking before they need a fix. The pass criteria differ by scan type.

• External scans: A single vulnerability scored 4.0 or higher on CVSS fails the whole ASV scan. Automatic fail conditions under the ASV Program Guide also apply.
• Internal scans: The organization ranks vulnerabilities through its own process under Requirement 6.3.1. That ranking, applied to the entity's environment, decides which findings are treated as high-risk and must be resolved.
• Lower-risk internal findings: Requirement 11.3.1.1 lets a targeted risk analysis set how quickly non-high-risk findings must be fixed and rescanned.

CVSS gives a starting point, but severity is not the same as risk. A medium-scored flaw on an internet-facing payment host can matter more than a higher-scored flaw on an isolated internal system. Track each finding to closure with an owner and a due date.

Scanners also report false positives. If an ASV finding looks wrong, dispute it through the vendor with supporting evidence instead of ignoring it, because unresolved findings keep the scan in a failing state.

5. Rescan and Retain Evidence

A fix is only confirmed when a rescan shows it. Rerun the affected scan after remediation, and repeat until the result passes. A failed external scan must be remediated and rescanned, with the passing rescan completed in the same quarter as the failure. A failed scan is not itself a violation. Failing to reach a passing result within the cycle is the problem.

Then keep the proof. After a successful ASV scan, the organization receives an Attestation of Scan Compliance and a detailed report. Assessors typically expect the following:

• Internal and external scan reports, including failed scans
• Rescan results that confirm remediation
• The scope documentation used for each scan
• Records of the significant changes that triggered extra scans
• Any documented exceptions, such as risk analyses for lower-risk findings

A passing report proves one control was met at one point in time. It does not make an organization PCI compliant, and it does not replace penetration testing.

Budgeting for PCI scans? Add web app and API testing with clear pricing. No surprises. Explore Pricing

What Makes a PCI Vulnerability Scan Pass or Fail?

A PCI vulnerability scan passes when no findings remain above the required threshold, and the scan completed as intended. The threshold differs by scan type: external ASV scans use a fixed CVSS cutoff, while internal scans use the organization's own risk ranking.

External ASV Scans

A scan passes when:

• No vulnerability is scored 4.0 or higher on CVSS
• No automatic fail condition is present
• The scan covered all in-scope public IP addresses and domains

A scan fails when:

• A single finding scores 4.0 or higher, even if everything else is clean
• An automatic failure condition exists, such as an unsupported operating system or default credentials
• The scan could not finish, for example because a firewall or intrusion prevention system blocked the scanner

Internal Scans

A scan passes when:

• All high-risk and critical findings are resolved
• Rescans confirm the fixes
• Authenticated scanning was used where systems accept credentials
• Lower-risk findings are handled as defined by the organization's targeted risk analysis

A scan fails when:

• High-risk or critical findings remain open
• Fixes were applied but never verified by a rescan
• In-scope systems were left out of the scan

How Much Does PCI DSS Vulnerability Scanning Cost?

PCI DSS vulnerability scanning costs depend on scan type. External ASV scans and internal scans are priced differently, and each is driven by scope, tooling, and support. Here is what to expect for each.

External ASV Scan Costs

For most small merchants, external PCI ASV scanning costs roughly $100 to $600 per year. Larger environments can exceed $3,000 per year. The number of external IP addresses and domains in scope is the biggest cost driver.

Some sources quote a wider range, $100 to $800 per quarter, or $400 to $3,200 per year. The spread reflects vendor pricing models and support levels, since the scan itself is standardized.

Internal Scan Costs

Internal PCI DSS vulnerability scanning typically costs about $1,200 to $5,000 per year for a small environment using a flat-license scanner. Per-asset platforms and managed services can cost more as the number of hosts grows. Internal scans do not need an ASV, so pricing follows the tool or service model, not a fixed PCI rate.

These figures vary by source, vendor edition, and year, so treat them as estimates.

ZeroThreat for PCI DSS Vulnerability Scanning

PCI DSS vulnerability scanning is a recurring discipline, not a one-time task. Scope must stay current, scans must run every quarter and after significant changes, and every failed finding has to be fixed and rescanned. The organizations that handle this well treat scanning as a continuous loop and keep evidence ready for every cycle.

That is the gap ZeroThreat is built to close for web applications and APIs. ZeroThreat is an AI-powered penetration testing tool that helps security teams and developers test payment-facing applications the way an attacker would, then turn the results into evidence they can act on.

Where ZeroThreat Fits in a PCI DSS Scanning Program

• Web App and API Coverage: It tests web applications and APIs, including authenticated workflows and modern single-page apps, which are common parts of the payment flow.
• Proof-Based Findings: Each finding comes with request and response evidence, so teams can separate real exploitable issues from noise instead of debating false positives after every scan.
• Faster Fix and Retest Cycles: Findings route into tools such as Jira, GitHub, and Azure Boards. Fixes can be retested automatically, which supports the remediate-and-rescan loop PCI DSS expects.
• Audit-Ready Reporting: Reports are mapped to PCI DSS compliance alongside frameworks such as OWASP, HIPAA, ISO 27001, and GDPR, which reduces manual evidence preparation.
• Continuous Testing: Scans can run on every code push through CI/CD integrations, so a significant change does not wait for the next quarterly window to be tested.
• Deployment Control: Production-safe scanning and on-prem deployment options help teams in regulated environments keep testing data and live traffic under control.

Note that no single scan makes an organization PCI compliant. Compliance comes from a repeatable process: accurate scope, timely scans, verified fixes, and clear evidence. Adding exploit-validated application testing to that process gives security teams findings they can trust and fixes they can prove.

To see how this works for your payment-facing applications, sign up with ZeroThreat and unlock a free compliance aligned AI-powered penetration test now!

Not sure what your scans miss? Bring your payment flow, get a live walkthrough today! Talk to Experts

Wrapping Up

PCI DSS vulnerability scanning comes down to a simple habit: know what is in scope, scan it on schedule, fix what fails, and keep the proof. Every organization that handles cardholder data, or connects to systems that do, needs to run internal and external scans at least once every three months, and again after significant changes.

External scans must pass the ASV criteria, internal scans depend on your own risk ranking, and a clean report never equals full PCI compliance on its own. Costs stay manageable when scope is tight and rescans are planned for.

Treat scanning as a routine, not a quarterly project. Teams that build that rhythm spend less time chasing audits and more time closing real gaps. That is what keeps cardholder data protected between assessments.

Smart security teams don’t rely on basic manual testing and reports. They use an next-gen, AI-powered vulnerability scanning tool that can exploit and validate vulnerabilities with direct compliance reporting.