PCI Quarterly Vulnerability Scanning
This article is for educational purposes only and does not constitute professional compliance advice or legal counsel. PCI DSS requirements and standards evolve, and you should consult with a qualified compliance professional about your specific situation.
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
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
A vulnerability scan is an automated security assessment that connects to your systems and looks for known security weaknesses. 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
Here's where vulnerability scanning gets complicated. Scanners sometimes flag issues that aren't actually security risks in your specific context. This is called a false positive. 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
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. The timeline for remediation depends on severity. PCI expects critical vulnerabilities to be fixed within 30 days for most cases, though your acquirer or your internal policy might have stricter timelines. High-risk vulnerabilities should be addressed within a reasonable timeframe—typically 60 to 90 days. 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. The rescan is usually done by the same ASV, though you can use another approved scanner if needed. 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
External vulnerability scans done by ASVs are mandatory for PCI compliance. But 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
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, but it's not the only piece. 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.
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.