PCI Quarterly Vulnerability Scanning
Reviewed by Raymond Dantes, PCI QSA
PCI DSS requires quarterly external vulnerability scanning by a PCI Council-approved Approved Scanning Vendor (ASV) and quarterly internal scans of your cardholder data environment. External scans identify known security weaknesses exposed to the internet — unpatched software, weak configurations, default credentials — and you must remediate findings and obtain clean rescan results to maintain compliance. Costs typically range from $1,000 to $5,000 per quarter depending on environment complexity.
Your acquiring bank just told you that you need quarterly vulnerability scanning to stay compliant with PCI DSS. You're not sure what this means, who does it, or how to know if you're passing. Quarterly scans feel like an audit requirement designed purely to generate consulting revenue. In reality, they're a straightforward process: a security firm runs automated tools against your external systems, looks for known vulnerabilities, identifies what they find, and your job is to fix it before the next scan. Understanding what vulnerability scanning actually does — and more importantly, what it doesn't do — keeps you from overpaying for unnecessary services or accidentally failing a compliance requirement.
Approved Scanning Vendors and What They Actually Do
External vulnerability scanning must be performed by a PCI Council-approved ASV — you cannot perform these scans yourself or use an unapproved third party.
The PCI Council requires that external vulnerability scanning be performed by an Approved Scanning Vendor, which is a firm that the PCI Council has vetted and verified meets specific standards. You can't do these external scans yourself, and your IT department can't run them either. It has to be a qualified third party from the Council's list, and there are specific reasons for this. An ASV is a licensed vendor that has committed to following PCI's testing standards, maintains the tools and expertise to run proper scans, and provides the documentation you'll need for compliance verification.
What an ASV does is straightforward: they use automated vulnerability scanning tools to probe your external systems — the ones accessible from the internet — and generate a report of what they find. The cost typically ranges from $1,000 to $5,000 per quarter depending on your environment's size and complexity. A smaller organization with a simple network perimeter might sit on the lower end. A large organization with multiple web servers, APIs, and interconnected systems will typically be higher. Some ASVs offer package deals if you commit to an annual scanning contract, which can bring the per-quarter cost down. The key point is that the ASV isn't your internal security team doing internal testing; they're an external firm verifying that your systems don't have obvious vulnerabilities exposed to the internet.
The relationship is important because your ASV becomes part of your compliance story. When your acquirer audits you or asks for evidence of compliance, your ASV's scan report is documentation that you're actually doing this verification. The ASV is accountable to the PCI Council for the quality of their scans, which is why you can't just have your neighbor's security consultant run one and call it compliant.
What Vulnerability Scanning Actually Tests — and What It Doesn't
Vulnerability scanning is an automated check for known security weaknesses — it identifies configuration problems and missing patches but does not attempt to breach your systems or assess whether an attacker could actually reach cardholder data.
The scanner checks for things like unpatched software, weak encryption configurations, misconfigured services, default credentials that should have been changed, and similar issues that attackers typically exploit first. Once it finishes running, it generates a report categorizing findings by severity: critical vulnerabilities, high-risk issues, medium-risk findings, and low-risk issues.
Here's what's important to understand: a vulnerability scan is a verification tool, not a penetration test. It doesn't attempt to actually breach your systems or compromise any data. Think of it like a security inspector walking through your building checking for unlocked doors and broken locks, but not actually trying to break in or steal anything. The scanner identifies what configuration problems exist and whether your patches are current, then hands you a report. Your job is to fix those issues before the next scan.
The scanner runs automated checks against your network and systems, which means it's looking for patterns that match known vulnerabilities. When a software vendor releases a security patch, they document the vulnerability they fixed. The scanner gets those vulnerability signatures and checks your systems to see if they're vulnerable. This automation is both the strength and the limitation of scanning. It's efficient and can check thousands of potential vulnerabilities in hours. But it only finds what it knows to look for. Novel vulnerabilities or zero-days — security flaws that haven't been discovered and published yet — won't show up in a scan.
What the scan definitely doesn't do is tell you whether an attacker can actually get to your cardholder data. That's a different conversation, and that's why PCI also requires penetration testing. The scan tells you whether your basic hygiene is good. The penetration test tells you whether good hygiene is actually sufficient.
False Positives and Why They Matter More Than You'd Think
Scanner findings flagged as false positives require specific, documented justification — claiming a finding is a false positive without evidence is a common audit failure point.
Scanners sometimes flag issues that aren't actually security risks in your specific context. A scanner might flag a service as vulnerable because the software version it detects is vulnerable in general, but your specific configuration makes it unexploitable or the service is isolated on a network segment where attackers can't reach it. A false positive isn't a real problem, but it still requires investigation and documentation.
Many organizations use false positives as an excuse to avoid fixing real problems. You'll see scan reports where a finding is marked "false positive" without any actual evidence supporting that determination. PCI auditors catch this regularly. If you're going to claim a finding is a false positive, you need to document why. That documentation should explain specifically why the vulnerability doesn't apply to your environment. "It's not vulnerable because we isolated it on a secure network segment" is legitimate. "It's not vulnerable because we hope it won't be exploited" is not.
More often than not, though, scanner findings are genuine. A missing security patch is a missing patch. A weak cipher configuration is a real weakness. A firewall rule that's too permissive is a real problem. The PCI standard expects you to remediate legitimate findings. The nuance is that PCI allows you to document false positives and move on from them, but you have to be honest about what constitutes a false positive and what constitutes a shortcut.
The Remediation and Rescanning Cycle
PCI DSS expects critical vulnerabilities to be remediated within 30 days, with high-risk issues addressed within 60 to 90 days, followed by a rescan to verify fixes before compliance is achieved for that quarter.
Once you receive scan results, the remediation phase begins. For critical vulnerabilities, you patch systems, update configurations, or remove unnecessary services that are creating risk. High-risk vulnerabilities should be addressed within a reasonable timeframe. Medium and low-risk findings might have longer remediation windows, but they still need to be addressed.
After you've remediated the findings, you request a rescan from your ASV to verify that the vulnerabilities are actually fixed. The rescan usually costs less than the initial scan because it's typically smaller in scope — you're just checking the specific issues that were remediated. A clean rescan, meaning no high or critical vulnerabilities remain, becomes your proof of compliance for that quarter.
This is where the rubber meets the road: many organizations remediate findings in a panicked rush right before a rescan, then don't maintain the fixes. That's not actually compliance. PCI expects you to maintain clean scan status continuously, which means applying patches promptly, keeping systems updated, and not letting vulnerabilities accumulate. If you remediate vulnerabilities to pass a quarterly scan in month one, then ignore patching for the next two months and new vulnerabilities appear, you're technically non-compliant even if your next scheduled scan isn't until month three.
The continuous maintenance part is what separates organizations that are actually secure from organizations that are just passing scans. A truly compliant organization is patching systems regularly, monitoring for newly released vulnerabilities, and applying fixes as part of normal operations. Quarterly scans just verify that the ongoing practices are working.
Internal Scans and Why You Need Both
PCI DSS requires both external scans (by an ASV) and internal scans (which your own qualified staff can perform), because each tests from a different attacker vantage point.
Internal scans — scanning your systems from inside your network rather than from the internet — are also required by PCI, and they can be done by your own IT staff if they have the expertise and are reasonably independent from the systems they're scanning.
Internal and external scans often find different vulnerabilities because they test from different vantage points. An external scan tests what an attacker on the internet can find. An internal scan tests what an attacker who's already inside your network could discover. A system might not be exposed to the internet and therefore not vulnerable externally, but it could be vulnerable to an internal attacker. Good practice is running monthly or quarterly internal scans in addition to your quarterly external scans. This gives you a more complete picture and helps you identify problems before they become critical findings during external assessment.
Some organizations run monthly internal vulnerability scans to catch issues early, then use quarterly external scans as their compliance verification. The monthly internal scans are not a compliance requirement, but they're a pragmatic best practice that catches problems before they show up in the external scan. It costs less to remediate a finding you discovered yourself than to remediate one that shows up in an external assessment that your acquirer sees.
Maintaining Clean Scan Status Between Quarters
PCI DSS expects continuous clean scan status — not just quarterly compliance. Letting patching slip between scans creates emergency remediation situations and potential non-compliance.
One of the most common misconceptions about quarterly vulnerability scanning is that you only need to worry about remediation right before the next quarterly scan. In reality, PCI expects you to maintain a clean scan status continuously, not just quarterly. This means applying patches promptly, keeping systems updated, and not letting vulnerabilities accumulate between scans.
The practical implication is significant. If you let patching slip for two months and then realize your third quarter scan is coming up in a week, you might find yourself in a situation where your systems have multiple critical vulnerabilities that you're now in a rush to fix. You'll end up paying for emergency remediation work, possible expedited rescans, and potentially explaining to your acquirer why you weren't maintaining clean status.
Organizations that treat patching and vulnerability management as ongoing operational practices instead of quarterly compliance projects tend to have much lower compliance costs and much better security posture. You patch systems when updates come available rather than batching everything until right before the scan. You monitor for newly disclosed vulnerabilities relevant to your environment and act on them promptly. When your quarterly scan comes around, it's typically clean or has only minor findings because you've been maintaining the environment continuously.
Where Scanning Fits Into Your Broader Compliance Program
Vulnerability scanning is one piece of PCI's verification requirements — it verifies patch management and configuration hygiene, while penetration testing, audits, and operational controls cover the rest.
You also need annual penetration testing, which is a more thorough assessment where a tester actually tries to exploit vulnerabilities rather than just identifying them. You need annual audits if you're a Level 1 merchant. You need internal controls, security policies, access management, log monitoring, and incident response procedures. Scanning verifies that you're maintaining your patch level and basic configuration security. The other controls verify that you're managing access, monitoring for breaches, and responding appropriately when something goes wrong.
That said, quarterly vulnerability scanning is often the compliance activity that organizations find most actionable. It gives you concrete feedback about whether your patch management and system hardening practices are working. When you see a clean scan, you know your maintenance practices are solid. When you see findings, you know exactly what to fix. This immediacy makes scanning valuable beyond just compliance — it's a practical tool for maintaining security.
You now understand that quarterly vulnerability scanning is an automated verification process to ensure your systems don't have known security weaknesses exposed to the internet. An Approved Scanning Vendor runs the scan, you remediate findings that they identify, the vendor rescans to confirm fixes, and you submit clean results to your acquirer as evidence of compliance. It's a straightforward process if you're maintaining your systems properly with prompt patching and regular configuration reviews. If you're not patching regularly or you're ignoring known vulnerabilities, scans become expensive remediation projects and compliance headaches. The simpler approach is continuous vulnerability management as an operational practice rather than a quarterly scramble — patch promptly, test regularly, and use quarterly scans as verification that your ongoing practices are actually working.
Frequently Asked Questions
Can my internal IT team perform the external vulnerability scan?
No. PCI DSS requires external vulnerability scans to be performed by a PCI Council-approved Approved Scanning Vendor (ASV). Your internal team can perform internal vulnerability scans, but external scans must come from an independent, qualified third party on the PCI Council's approved list. The ASV's scan report becomes part of your compliance evidence submitted to your acquiring bank.
What happens if my quarterly scan finds critical vulnerabilities?
You remediate the findings — patch systems, update configurations, remove unnecessary services — and then request a rescan from your ASV to verify the fixes. A clean rescan becomes your proof of compliance for that quarter. PCI DSS expects critical vulnerabilities to be remediated within 30 days of discovery. You are non-compliant until the rescan confirms no high or critical vulnerabilities remain.
How much does quarterly vulnerability scanning cost?
External ASV scanning typically costs $1,000 to $5,000 per quarter, depending on your environment's size and complexity. Smaller organizations with simple network perimeters fall toward the lower end; organizations with multiple web servers, APIs, and interconnected systems pay more. Annual contracts with an ASV often reduce per-quarter costs. Rescans after remediation are usually less expensive than the initial scan.
Is vulnerability scanning the same as penetration testing?
No. Vulnerability scanning is automated and identifies known weaknesses in your configuration and patch level. Penetration testing is manual, performed by a qualified security professional who actively tries to exploit vulnerabilities and chain them together to access cardholder data. PCI DSS requires both: quarterly vulnerability scans and annual penetration testing. They serve complementary purposes — scanning catches hygiene issues, testing catches architectural weaknesses.
Do I need to scan every system in my environment?
External scans cover your internet-facing systems — anything accessible from outside your network. Internal scans should cover systems within your cardholder data environment and systems that could impact its security. Not every system in your organization needs scanning, but every system that touches or could reach cardholder data does. Accurate scope definition prevents both over-scanning (wasting money) and under-scanning (missing vulnerable systems).
Fully Compliance provides educational content about IT compliance and cybersecurity. This article reflects general information about PCI DSS vulnerability scanning as of its publication date. PCI DSS requirements, ASV lists, and standards evolve — consult a qualified compliance professional for guidance specific to your organization and acquiring bank.