PCI DSS 4.0.1 Vulnerability Management: Passing the Quarterly Scan Is No Longer Enough

For years, many teams treated PCI DSS vulnerability management as a calendar item: run the quarterly scans, get a passing report from the Approved Scanning Vendor, file it for the assessor. PCI DSS v4.x keeps the quarterly scans, but it no longer lets them carry the whole program. Since 31 March 2025, the requirements that were "future-dated" in v4.0 are mandatory, and several of them change how vulnerabilities are found, ranked and closed.

This guide walks through the vulnerability requirements in PCI DSS v4.0.1, what changed, and what an assessor will expect to see.

Where things stand

The PCI Security Standards Council retired PCI DSS v3.2.1 on 31 March 2024. It published v4.0.1, a limited revision, in June 2024. Of the 64 new requirements introduced in v4.0, 51 were future-dated and became effective on 31 March 2025. In other words, the transition period is over: an assessment today is against the full v4.x standard.

Step 1: rank every vulnerability (Requirement 6.3.1)

Everything else hangs on Requirement 6.3.1. You must identify new vulnerabilities from industry sources and assign each one a risk ranking that identifies, at a minimum, those considered high-risk or critical to your environment.

Two consequences are easy to miss:

• The ranking is yours. CVSS from the vendor is an input, not the answer. Exploitation evidence, exposure and the role of the system in the cardholder data environment are legitimate factors, as long as the method is documented.
• Your ranking drives the other requirements. Requirements 11.3.1 and 11.3.1.3 say high-risk and critical vulnerabilities must be resolved "per the entity's vulnerability risk rankings defined at Requirement 6.3.1".

If your ranking is just the scanner's severity column, you are leaving the most useful part of the standard unused. We explain a practical method in how to prioritize vulnerabilities.

Step 2: patch critical vulnerabilities within a month (Requirement 6.3.3)

Requirement 6.3.3 requires patches or updates for critical vulnerabilities to be installed within one month of release. All other applicable security patches must be installed within an appropriate time frame based on your own assessment of the risk.

This is one of the places where v4.0.1 changed the text. In v4.0, the one-month window covered both critical and high-risk vulnerabilities. v4.0.1 returned to the v3.2.1 wording, so the fixed one-month deadline applies only to critical ones. High-risk vulnerabilities are not off the hook: they still have to be resolved under 11.3.1, on a time frame you define and can defend.

A one-month SLA only works if you can measure it. Track time to remediate per severity, not as one global average; see remediation SLAs and MTTR.

Step 3: internal scans, now authenticated (Requirements 11.3.1 and 11.3.1.2)

Requirement 11.3.1 keeps the familiar rules for internal scans:

• At least once every three months.
• High-risk and critical vulnerabilities, per your 6.3.1 rankings, are resolved.
• Rescans confirm that they were resolved.
• The scan tool is kept up to date, and scans are run by qualified personnel with organizational independence.

The bigger change is Requirement 11.3.1.2, one of the future-dated requirements: internal scans must be authenticated. That means:

• Systems that cannot accept credentials for scanning are documented.
• Systems that can accept credentials are scanned with sufficient privileges.
• If the scanning accounts can be used for interactive login, they are managed under Requirement 8.2.2.

Authenticated scans see installed packages, missing patches and local configuration that an unauthenticated scan can only guess at. Expect the number of findings to go up, sometimes sharply, the first time you switch them on. That is not a regression; it is visibility you did not have. We compare the approaches in agent vs agentless scanning.

Step 4: the rest of the findings need a plan too (Requirement 11.3.1.1)

Under v3.2.1, many teams quietly ignored everything below "high". Requirement 11.3.1.1 closes that gap. All other applicable vulnerabilities, those not ranked high-risk or critical, must be addressed based on the risk defined in a targeted risk analysis (TRA) performed according to Requirement 12.3.1, with rescans as needed.

In practice, the TRA is where you write down how fast medium and low findings get fixed, and why that is acceptable for your environment. It must be documented and reviewed periodically. When you decide not to fix something, treat it as a formal decision with an owner and an expiry date, as described in vulnerability risk acceptance.

Step 5: external scans and significant changes (Requirements 11.3.2, 11.3.1.3 and 11.3.2.1)

Requirement 11.3.2 still requires external scans at least once every three months by a PCI SSC Approved Scanning Vendor (ASV), with vulnerabilities resolved and rescans until the scan passes the ASV Program Guide requirements.

Scans are also required after any significant change:

• Internal (11.3.1.3): high-risk and critical vulnerabilities per your 6.3.1 rankings are resolved, with rescans as needed.
• External (11.3.2.1): vulnerabilities scored 4.0 or higher by CVSS are resolved, with rescans as needed.

These post-change scans do not have to be run by a QSA or an ASV, but they do require qualified personnel and organizational independence.

What the assessor will ask for

A quarterly report is no longer enough evidence on its own. Be ready to show:

1. Your documented risk-ranking method (6.3.1) and examples of it applied.
2. Proof that critical patches were installed within one month (6.3.3).
3. Four quarters of authenticated internal scans, plus the list of systems that cannot accept credentials (11.3.1, 11.3.1.2).
4. Rescans showing that high-risk and critical findings were closed.
5. The TRA that sets time frames for the remaining findings (11.3.1.1, 12.3.1).
6. Four passing quarterly ASV scans (11.3.2).
7. Scans after each significant change (11.3.1.3, 11.3.2.1).

Frequently asked questions

Does a passing ASV scan mean we comply with the vulnerability requirements? No. It covers 11.3.2. Authenticated internal scans, risk ranking, patch timelines and the TRA are separate requirements.

Can we rank a vendor's "critical" as high or medium? The standard asks for your own risk ranking, so yes, if the method is documented and applied consistently. An assessor will expect to see the reasoning, not just a lower number.

Do the PCI DSS deadlines replace our internal SLAs? They set a floor for the cardholder data environment. Many teams apply the same SLAs everywhere so they run one process, not two.

How priorIQ.ai helps

priorIQ.ai is not an ASV and does not replace your quarterly external scans. It helps with the work around them. PriorIQ Core reconciles findings from ScannerIQ or from the scanners you already run, such as Tenable, Qualys, Rapid7 or Microsoft Defender, and prioritizes them with CVSS, EPSS, CISA KEV, exploit signals and business context, which gives you a documented basis for your 6.3.1 ranking. The mitigation backlog tracks every item with owner, ticket status and SLA, risk exceptions are audited, and the immutable audit log records every remediation decision. CodeIQ adds PCI DSS reports for code findings. Request a demo.