PCI DSS 6.3.1 asks you to do three things: watch industry sources for new vulnerabilities, give each one a risk ranking based on industry practice and potential impact, and make sure the ranking at least identifies everything high-risk or critical. It covers your own code and third-party software. This is not legal advice.
What the requirement says
The SAQ D text lists four elements. New vulnerabilities are identified using industry-recognized sources, including alerts from national and international computer emergency response teams. Vulnerabilities get a risk ranking based on industry practice and potential impact. Rankings identify, at a minimum, all high-risk or critical items. And both bespoke and third-party software are covered.
The applicability note adds that this is not achieved by the scans in 11.3.1 and 11.3.2. It is a process for actively monitoring sources and deciding the ranking, so a scan report alone does not satisfy it.
Why the ranking matters downstream
Your ranking drives other requirements. In 6.3.3 it decides which patches have a one month target. In 11.3.1 it decides which internal scan findings must be resolved and rescanned. Rank badly and the downstream deadlines are wrong.
A practical method
- Write down the sources you monitor: advisory feeds, vendor bulletins and CERT alerts.
- Define the scale, for example critical, high, medium, low, and who may change a ranking.
- Start from a base severity such as a published score.
- Adjust for context: is the component internet facing, does it touch the payment flow, is there a known exploit?
- Record the result with date, source and reason.
| Factor | Raises rank | Lowers rank |
|---|---|---|
| Exposure | Public facing, in the payment path | Internal, isolated |
| Exploit status | Public exploit or active abuse | None known |
| Code use | Vulnerable function is called | Function is never reached |
| Compensating control | None | Validated mitigation in place |
The table is a way to structure judgement, not a PCI rule. Whatever you pick, apply it consistently and write it down.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how exploitability is checked for a finding.
Quick check
Is a CVSS score enough for the risk ranking?
The text asks for a ranking based on industry practice and potential impact. A base score can be an input, but add context and document how you decided.
Do I need to rank low severity issues?
The minimum is identifying everything high-risk or critical. Ranking the rest helps with 11.3.1.1 and makes your process easier to defend.
On Safeguard: reachability analysis shows whether your code calls a vulnerable function, which is one input to a ranking. Try the free scan at gold.safeguard.sh/scan.
Sources
Wording is from v4.0. Confirm in the current version.
Last reviewed: 19 October 2026.
