6.3.1 Vulnerability identification and risk ranking

Security vulnerabilities must be identified and managed so that: new vulnerabilities come to light through sources of vulnerability information that the industry recognises, such as alerts issued by national and international computer emergency response teams (CERTs); each vulnerability receives a risk ranking based on industry good practice and its possible impact; the rankings at minimum pick out every vulnerability the environment treats as critical or high-risk; and vulnerabilities in bespoke and custom software and in third-party software (such as operating systems and databases) are all included. It applies to all entities. Applicability: this is separate from, and additional to, the internal and external vulnerability scans (11.3.1, 11.3.2); it is a process to actively watch industry sources and for the entity to assign its own risk ranking to each vulnerability. Objective under the customized approach: new system and software vulnerabilities able to affect cardholder or sensitive authentication data are tracked, catalogued and risk assessed.

Source: PCI DSS v4.0.1, 6.3.1. The statement above is our statement of the clause, read from the published text and cited so you can check it against the official text, not the instrument verbatim. Open PCI DSS v4.0.1 in the compliance library.

Version 4.0.1 is the active version; 4.0 has been retired. Appendix A1 applies only to multi-tenant service providers, A2 only to card-present POS POI terminals that still use SSL or early TLS, and A3 only when a payment brand or acquirer requires it. Which requirements apply to you follows your validation type.