PCI DSS 6.3.1: Watch a real source of vulnerability news, rank what you find by how much it matters to your environment, and cover the software you wrote as well as the software you bought.
PCI DSS v4.0.1 control 6.3.1: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 6.3.
PCIComplianceHubLast updated Last reviewed against PCI DSS v4.0.1
Requirement 6: Develop and Maintain Secure Systems and Software › Section 6.3
Security vulnerabilities are identified and managed as follows:
- New security vulnerabilities are identified using industry-recognized sources for security vulnerability information, including alerts from international and national computer emergency response teams (CERTs).
- Vulnerabilities are assigned a risk ranking based on industry best practices and consideration of potential impact.
- Risk rankings identify, at a minimum, all vulnerabilities considered to be a high-risk or critical to the environment.
- Vulnerabilities for bespoke and custom, and third-party software (for example operating systems and databases) are covered.
Summary
Watch a real source of vulnerability news, rank what you find by how much it matters to your environment, and cover the software you wrote as well as the software you bought.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 6.3.1.a | Examine policies and procedures for identifying and managing security vulnerabilities to verify that processes are defined in accordance with all elements specified in this requirement. |
| 6.3.1.b | Interview responsible personnel, examine documentation, and observe processes to verify that security vulnerabilities are identified and managed in accordance with all elements specified in this requirement. |
Many other controls depend on the ranking this one produces, including 6.3.3 for patching timescales and 6.2.4 for the attacks your developers must defend against. Get the ranking wrong and everything downstream inherits it. 6.3.1.a examines whether the process is defined; 6.3.1.b interviews people and observes it running, so a documented process nobody performs fails the second half. Note the last bullet: bespoke and custom software is explicitly in scope, so a feed that only covers your operating systems and databases is incomplete.
What to prepare
- The named sources you monitor, and evidence you actually receive them: CERT alerts, which the requirement names, plus vendor advisories or a commercial service. Scan results can feed the process, but scans under 11.3.1 and 11.3.2 do not meet this requirement on their own.
- Your risk-ranking method, written down, including what makes something high-risk or critical in your environment rather than in general.
- A current list of vulnerabilities with their assigned rankings, covering third-party and your own code.
- Evidence the process runs: dated records, not a policy document alone.
How to implement it
1. Pick sources that cover what you actually run. The requirement names CERT alerts as one source, not the whole answer. If you run a specific framework, its advisories matter more to you than a general feed, and if you write your own code, its dependencies need sources of their own.
2. Rank for your environment, not by the CVSS score alone. A critical-rated vulnerability in a component you do not expose may matter less than a medium in your payment path. The requirement asks for industry best practice and consideration of potential impact, which means the base score is an input, not the output.
3. Define "high-risk" and "critical" explicitly. The requirement only insists that your ranking identifies those two levels. If your definition is not written down, the assessor has no way to check the ranking is applied consistently, and neither do you.
4. Cover bespoke and custom software deliberately. In practice this means dependency scanning in the build and a route for reports about your own product. It needs deliberate effort because no vendor sends advisories for it.
5. Make the output feed the patch process. The ranking exists so that 6.3.3 knows what to fix first. If the two are separate documents maintained by separate people, they will disagree.
Where this commonly fails
- Subscribing to a feed nobody reads, so 6.3.1.a passes on the policy and 6.3.1.b fails on the interview.
- Ranking straight from the CVSS base score with no consideration of the environment, which the requirement explicitly asks for.
- Covering purchased software and forgetting the code the entity wrote itself, which is a named bullet.
- A ranking scheme that has more levels than the process uses, so everything ends up medium and nothing is ever high-risk.
Related controls
Others in section 6.3:
| Control | What it requires |
|---|---|
| 6.3.2 | An inventory of bespoke and custom software, and third-party software components incorporated… |
| 6.3.3 | All system components are protected from known vulnerabilities by installing applicable… |
Terms
Glossary entries that name this control, each with its own example, limits and sources:
← 6.2.4 · All controls · 6.3.2 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.