Vulnerability Management for PCI DSS: Requirements 6 and 11

Critical patches must be installed within one month of release under Requirement 6.3.3. PCI DSS 4.0 also changes how other patch timelines are set. Targeted risk analysis, or TRA, now supports those decisions, so the old rule of handling critical patches within 30 days and leaving everything else to a general policy is no longer enough. You need a documented process that records each patch decision, not only decisions about critical vulnerabilities.

From DSS 3.2.1 to 4.0

Under DSS 3.2.1, Requirement 6.3.3 required critical security patches to be installed within one month of release. For noncritical patches, organizations only had to define and document a patch policy with set timelines.

DSS 4.0 Requirement 6.3.3 keeps the one-month deadline for critical patches, while requiring a targeted risk analysis for timelines covering other vulnerabilities. A TRA is a documented decision, not simply a form. It considers vulnerability severity, the affected system's context, whether it is directly in the CDE or isolated, patch availability, and compensating controls during remediation. Its result is an authorized timeline for that specific patch, documented and signed off.

Operationally, a merchant could once defer a medium-severity patch indefinitely if its policy said medium vulnerabilities would be patched within 90 days. Under 4.0, extending that timeline requires a new TRA that supports the extension. Patches cannot simply remain in a growing backlog. Each unpatched vulnerability above the minimum severity needs a current, documented reason for its status.

Internal and External Scanning

Requirement 11.3 addresses vulnerability scanning and separates internal scans from external scans, with different requirements for each.

An Approved Scanning Vendor, or ASV, listed on the PCI SSC website must perform external scans at least every 90 days. Scans must cover every externally accessible IP address and hostname within the CDE scope. A passing result means high-risk findings, CVSS 4.0 and above, are resolved or have an accepted exception. A failed scan must be rescanned, with findings resolved before the compliance period ends.

Qualified internal staff or an external provider may perform internal scans, but the staff must be organizationally independent of the systems under review. This prevents the person managing CDE servers from also running scans and potentially leaving findings out of the report. Independence may come from separate teams or an external provider conducting internal scans.

DSS 4.0 added authenticated scanning for internal scans. Without credentials to log in and inspect installed software versions, a scan can miss findings that are visible only to an authenticated scanner. Internal scans must use authentication where technically feasible. If a system cannot support it, document the exception.

Penetration Testing Under 11.4

Requirement 11.4 calls for an annual penetration test of the CDE, covering its external perimeter and internal network. This differs from vulnerability scanning. A scan automates the search for known, unpatched vulnerabilities, while a penetration test uses a qualified tester to attempt exploitation and assess the environment as a whole.

The penetration test must cover network segmentation controls, the application layer of CDE web-facing components, and the CDE internal network. If segmentation is used to limit CDE scope, the test must verify that it works. A qualified internal resource or an approved third party, independent of the systems tested, must conduct the test.

Your QSA will review the penetration test scope document as evidence. It should show that the test boundary matched the actual CDE boundary, rather than only part of it. Testing a public payment page while omitting backend processing servers is insufficient. If segmentation supports a narrower scope, the test should also verify that segmentation.

Putting Targeted Risk Analysis to Work

The TRA requirement causes much of the confusion around DSS 4.0 vulnerability management. Merchants often ask whether every individual patch decision needs its own formal document.

QSAs generally want evidence of a consistent process, not a separate document for every patch. One defensible approach is a vulnerability register listing findings above the minimum severity, criticality, affected system, remediation owner, and authorized timeline, with TRA reasoning in a note. Critical vulnerabilities have a 30-day timeline and need no TRA reasoning. For other findings, the note can explain the timeline, such as an isolated system, medium CVSS, WAF inspection as a compensating control, and a 60-day timeline authorized through security review.

This documentation meets the TRA intent without adding an operational burden that stops patch work. Decisions must be recorded when made, rather than rebuilt from memory during an audit. A maintained vulnerability register gives your QSA the evidence needed for Requirement 6.3.3 under 4.0.

Finding Vulnerabilities Beyond Scans

Requirement 6.3.1 under DSS 4.0 requires a defined process for managing every security vulnerability. That includes findings from CVE publications, vendor advisories, bug bounty programs, and threat intelligence feeds, not only automated scans. A merchant that patches only findings from a quarterly ASV scan is overlooking other findings that need attention.

Your process needs to collect new CVE information for software components in the CDE and compare it with installed versions. At its core, this is a software composition analysis task: identify which versions run where and follow the notification channels that report relevant CVEs.

In cloud-native CDE environments, a cloud provider may patch managed infrastructure while you remain responsible for software components you own. Documenting which components are provider-managed and which are customer-managed clarifies the scope of Requirement 6.

Continuous Monitoring and Vulnerability Management

Continuous CDE configuration monitoring can find vulnerability-management drift between scheduled scans. It can surface a rollback after a system was patched or a new CDE component added without standard hardening, before the next quarterly scan.

Automation has clear limits. Penetration testing needs human judgment and cannot be replaced by automated scanning. TRA requires human reasoning about risk context, though automated systems can support it. The team responsible for remediation must maintain the vulnerability register, the central Requirement 6.3.3 artifact under 4.0. Automation can populate it with findings and alert when remediation timelines approach or pass their authorized dates, reducing the chance that an approved patch window expires unnoticed.