PCI DSS 4.0
Req 6: Secure Systems and Software

PCI DSS 4.0 6.3.1: 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.

Maintained by Gerard BlokdykControl text last updated

What else in your programme already covers this

This control maps to 119 controls across 26 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.

FedRAMP High · 13 controls

  • RA-5 Vulnerability Monitoring and Scanning
  • RA-5(11) Vulnerability Monitoring and Scanning | Public Disclosure Program (RA-5(11))
  • RA-5(2) Update Vulnerabilities to be Scanned
  • SA-11 Developer Testing and Evaluation
  • SA-11(1) Developer Testing and Evaluation | Static Code Analysis (SA-11(1))
  • SA-11(2) Developer Testing and Evaluation | Threat Modeling and Vulnerability Analyses (SA-11(2))
  • SA-15 Development Process, Standards, and Tools (SA-15)
  • SA-22 Unsupported System Components (SA-22)
  • SA-3 System Development Life Cycle
  • SA-8 Security and Privacy Engineering Principles
  • SI-2(2) Automated Flaw Remediation Status
  • SI-2(3) Flaw Remediation | Time to Remediate Flaws and Benchmarks for Corrective Actions (SI-2(3))
  • SI-5 Security Alerts, Advisories, and Directives

FedRAMP Moderate · 13 controls

  • RA-5 Vulnerability Monitoring and Scanning
  • RA-5(11) Vulnerability Monitoring and Scanning | Public Disclosure Program (RA-5(11))
  • RA-5(2) Update Vulnerabilities to be Scanned
  • SA-11 Developer Testing and Evaluation
  • SA-11(1) Developer Testing and Evaluation | Static Code Analysis (SA-11(1))
  • SA-11(2) Developer Testing and Evaluation | Threat Modeling and Vulnerability Analyses (SA-11(2))
  • SA-15 Development Process, Standards, and Tools (SA-15)
  • SA-22 Unsupported System Components (SA-22)
  • SA-3 System Development Life Cycle
  • SA-8 Security and Privacy Engineering Principles
  • SI-2(2) Automated Flaw Remediation Status
  • SI-2(3) Flaw Remediation | Time to Remediate Flaws and Benchmarks for Corrective Actions (SI-2(3))
  • SI-5 Security Alerts, Advisories, and Directives

CIS Controls v8 · 11 controls

  • CIS-14.7 Train Workforce on How to Identify and Report if Their Enterprise Assets are Missing Security Updates
  • CIS-16.1 Establish and Maintain a Secure Application Development Process
  • CIS-16.12 Implement Code-Level Security Checks
  • CIS-16.2 Establish and Maintain a Process to Accept and Address Software Vulnerabilities
  • CIS-16.3 Perform Root Cause Analysis on Security Vulnerabilities
  • CIS-16.5 Use Up-to-Date and Trusted Third-Party Software Components
  • CIS-16.6 Establish and Maintain a Severity Rating System and Process for Application Vulnerabilities
  • CIS-2.2 Ensure Authorized Software is Currently Supported
  • CIS-7.1 Establish and Maintain a Vulnerability Management Process
  • CIS-7.2 Establish and Maintain a Remediation Process
  • CIS-7.7 Remediate Detected Vulnerabilities

NIST SP 800-53 Rev 5 · 9 controls

ISO 27002:2022 · 7 controls

  • 5.6 Contact with special interest groups
  • 5.7 Threat intelligence
  • 8.25 Secure development life cycle
  • 8.27 Secure system architecture and engineering principles
  • 8.28 Secure coding
  • 8.29 Security testing in development and acceptance
  • 8.8 Management of technical vulnerabilities
  • NIST-CSF-DE.AE-07 Cyber threat intelligence and other contextual information are integrated into the analysis
  • NIST-CSF-ID.AM-08 Systems, hardware, software, services, and data are managed throughout their life cycles
  • NIST-CSF-ID.RA-01 Vulnerabilities in assets are identified, validated, and recorded
  • NIST-CSF-ID.RA-02 Cyber threat intelligence is received from information sharing forums and sources
  • NIST-CSF-ID.RA-04 Potential impacts and likelihoods of threats exploiting vulnerabilities are identified and recorded
  • NIST-CSF-ID.RA-05 Threats, vulnerabilities, likelihoods, and impacts are used to understand inherent risk and inform risk response prioritization
  • NIST-CSF-PR.PS-06 Secure software development practices are integrated, and their performance is monitored throughout the software development life cycle

CMMC 2.0 · 6 controls

SOC 2 · 6 controls

  • SOC2-CC2.1 CC2.1 Relevant, quality information to support internal control (COSO principle 13)
  • SOC2-CC3.2 CC3.2 Identifying and analysing risks to objectives (COSO principle 7)
  • SOC2-CC5.2 CC5.2 General controls over technology (COSO principle 11)
  • SOC2-CC6.8 CC6.8 Preventing and detecting unauthorised or malicious software
  • SOC2-CC7.1 CC7.1 Detecting configuration changes and new vulnerabilities
  • SOC2-CC9.1 CC9.1 Mitigating risks of business disruption

ISO 27001:2022 · 5 controls

  • 5.6 Contact with special interest groups
  • 5.7 Threat intelligence
  • 8.26 Application security requirements
  • 8.27 Secure system architecture and engineering principles
  • 8.8 Management of technical vulnerabilities

HIPAA Security Rule · 4 controls

NIST SP 800-218 · 4 controls

NIST SP 800-66 Rev 2 · 4 controls

NIST SP 800-171 Rev 3 · 3 controls

  • 03.11.02 Vulnerability Monitoring and Scanning
  • 03.14.01 Flaw Remediation
  • 03.14.03 Security Alerts, Advisories, and Directives
  • ANSSI-HYG-34 Define an Update Policy for Information System Components
  • ANSSI-HYG-38 Carry Out Regular Security Checks and Audits and Apply the Corrective Actions
  • ASD37-02 Patch applications (Essential)
  • ASD37-19 Patch operating systems (Essential)
  • SEC01-BP04 Stay up to date with security threats and recommendations
  • SEC06-BP01 Perform vulnerability management
  • DS-2 Ensure software supply chain security
  • PV-5 Perform vulnerability assessments

C5 (Germany) · 2 controls

  • C5-OPS-18 Managing Vulnerabilities, Malfunctions and Errors - Concept
  • C5-PSS-02 Identification of Vulnerabilities of the Cloud Service

ISO 27701:2019 · 2 controls

  • 6.11.2 Security in development and support processes
  • 6.9.6 Technical vulnerability management

NIST SP 800-161 Rev 1 · 2 controls

  • 161R1-RA-5 Vulnerability Monitoring and Scanning
  • 161R1-SI-5 Security Alerts, Advisories, and Directives

NIST SP 800-172 · 2 controls

  • 3.11.1e Threat-Aware Risk Assessment
  • 3.14.6e Use Threat Indicator Information for Detection
  • P1-4.2.1 P1-4.2.1 Vulnerability-management policy and procedures
  • P1-4.2.4 P1-4.2.4 Vulnerabilities ranked by criticality
  • E8-PATCHAPP-ML1 Patch Applications (ML1)

UK Cyber Essentials · 1 control

  • CE-SU.3 Critical and High Updates within 14 Days

Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.

Other controls in Req 6: Secure Systems and Software

You are reading one control. How much of PCI DSS 4.0 have you already done?

PCI DSS 4.0 6.3.1 is one control. If you already hold one of the frameworks below, a reviewed crosswalk already says how much of PCI DSS 4.0 your existing evidence covers. Hold ISO 27001:2022 and 139 of 280 PCI DSS 4.0 controls already carry evidence.

Each report names every control your existing framework evidences, every one it does not, the reasoning behind each claim, and the claims that were argued against and rejected. 415 were rejected on the ISO 27001:2022 pair alone.

Query this from an agent

The graph holds this control, the 119 it maps to, and the evidence behind each claim, over MCP and REST.