Meeting the requirements of the Payment Card Industry Data Security Standard (PCI DSS) isn’t just about checking boxes—it’s about creating a secure environment that protects cardholder data. One of the most critical components of PCI compliance is a strong vulnerability management program. This includes patching, external and internal vulnerability scanning, and penetration testing—all conducted at the right frequency and with the right methodology.
In this article, we’ll break down what PCI DSS expects for vulnerability management, explain key concepts like authenticated vs. unauthenticated scans, differentiate between vulnerability assessments and penetration tests, and clarify how and when remediation is required.
Requirement 6.3.1 requires all new vulnerabilities are identified and managed. New vulnerabilities might be identified by a vendor, a website, email notification, or manual inspection. Each vulnerability is to be assigned a risk ranking. This is typically done ahead of time, but after evaluating the vulnerability, the assessed entity might change the risk ranking to fit their environment. This includes vulnerabilities for everything in scope (hardware, software, applications, custom apps, firmware, printers, etc.). Anything that remains with a high or critical risk ranking must be patched within 30 days of when the patch is released (not business days, 30 calendar days).
Requirement 6.3.1 is the process to identify new vulnerabilities that might affect your environment. But requirement 11.3.1 and 11.3.2 require actual scans looking to see if any of those vulnerabilities still exist on your network within your implementations.
Requirement 11.3.1 requires all in-scope assets on the internal network are scanned for vulnerabilities. This includes those with cardholder data and those that are security impacting. They must be scanned every 3 months – that’s 90-92 days. Any vulnerability found with a critical or high risk ranking must be remediated. Then another scan must be conducted of that asset to make sure the remediation was successful. All other vulnerabilities ranked anything other than critical or high have to be addressed. Addressed means to assess their impact on your environment and determine if they need to be remediated or if the vulnerability will be managed in a different way (examples: using a compensating control or by disabling a vulnerable service). Each one should be documented – especially if it will not be installed.
The new requirement for March 31, 2025, is that all internal scans have to be authenticated scans. The tool has to be updated to ensure it is aware of the latest identified vulnerabilities. If you aren’t scanning with an updated tool or using an authenticated scan, vulnerabilities will be missed and you will not be PCI compliant.
Finding this helpful? Join our newsletter.
PCI also requires external vulnerability scans. These must be completed by an ASV (approved scanning vendor) and must be completed quarterly (every 90-92 days). The ASV scans must cover all external assets that are in scope. A passing ASV scan does not have any critical or high vulnerabilities. It may be necessary to remediate a vulnerability and rescan that asset in order to achieve a passing ASV scan.
Both internal and external vulnerability scans are required after a significant change. The definition of significant is up to each assessed entity. The Council gives some examples of significant…but I like to think of it as anything that impacts the flow of cardholder data. This might be upgrading an application, redesigning a container, changing the cloud security groups, etc. It’s usually a red flag if a PCI assessment says no significant changes occurred during the assessment period. That usually means the definition of significant is too lenient.
PCI also requires penetration tests. Penetration tests are different than vulnerability scans. While both are essential, vulnerability scans and penetration tests serve different purposes. While vulnerability scans are an automated process that identifies known vulnerabilities based on signatures and configuration checks, a penetration test is a manual (or hybrid) process performed by skilled professionals who actively exploit vulnerabilities to simulate a real-world attack. Often during assessments, an ASV scan is given as a penetration test. They are not the same thing. A penetration test must also verify that segmentation is effective. An ASV scan cannot do that.
Penetration testing must be done at least annually both on internal and external in-scope assets. And here comes significant change again… a pen test must be performed on those assets affected by a significant change.
If you’re managing PCI DSS in a complex environment, automate where you can, stay disciplined with your timelines, and always validate remediation. A proactive approach today prevents breaches tomorrow.
What’s your biggest challenge with PCI DSS vulnerability management? Share your thoughts in the comments or reach out to [email protected] to discuss strategies!