PCI DSS 6.3.1: Security vulnerabilities are identified and managed
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.
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. |
The most cross-referenced control in v4.0.1: eleven 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: a CERT mailing list, vendor advisories, a scanner feed, or a commercial service.
- 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. A CERT feed is the example the requirement gives, 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 are where most of your exposure lives.
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. For most entities this means dependency scanning in the build and a route for reports about your own product. It is the bullet most often missed because it has no vendor sending advisories.
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… |
← 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.