PCI DSS 4.0
Req 6: Secure Systems and Software

PCI DSS 4.0 6.2.3: 6.2.3 Code review before release

Before bespoke and custom software is released to production or to customers, it must be reviewed to find and fix possible coding vulnerabilities, such that: reviews confirm the code follows secure coding guidelines; reviews look for vulnerabilities that are already known as well as newly emerging ones; and suitable fixes are made before release. It applies to all entities. Applicability: the review requirement covers every piece of custom and bespoke software, whether public facing or internal, within the development lifecycle; public-facing web applications additionally fall under Requirement 6.4; reviews may be manual, automated or both. Objective under the customized approach: coding vulnerabilities in bespoke and custom software cannot be used to exploit it.

Maintained by Gerard BlokdykControl text last updated

What else in your programme already covers this

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

NIST SP 800-218 · 6 controls

CIS Controls v8 · 4 controls

  • CIS-16.1 Establish and Maintain a Secure Application Development Process
  • CIS-16.12 Implement Code-Level Security Checks
  • CIS-16.13 Conduct Application Penetration Testing
  • CIS-16.14 Conduct Threat Modeling

NIST SP 800-53 Rev 5 · 4 controls

FedRAMP High · 3 controls

  • CM-3(2) Testing, Validation, and Documentation of Changes
  • SA-11 Developer Testing and Evaluation
  • SA-11(1) Developer Testing and Evaluation | Static Code Analysis (SA-11(1))

FedRAMP Moderate · 3 controls

  • CM-3(2) Testing, Validation, and Documentation of Changes
  • SA-11 Developer Testing and Evaluation
  • SA-11(1) Developer Testing and Evaluation | Static Code Analysis (SA-11(1))

PCI 3DS Core Security Standard · 3 controls

  • P1-3.1.4 P1-3.1.4 Security testing during development using documented methods
  • P1-3.1.5 P1-3.1.5 Testing surfaces defects and vulnerabilities
  • P1-3.1.6 P1-3.1.6 Defects and vulnerabilities fixed before release

AWS Well-Architected Security Pillar · 2 controls

  • SEC11-BP02 Automate testing throughout the development and release lifecycle
  • SEC11-BP04 Conduct code reviews

Azure Security Benchmark · 2 controls

  • ASBv3-DS-4 Integrate static application security testing into DevOps pipeline
  • ASBv3-DS-5 Integrate dynamic application security testing into DevOps pipeline

C5 (Germany) · 2 controls

Cloud Security Alliance Cloud Controls Matrix (CCM) v4.0.1 · 2 controls

ISO 27001:2022 · 2 controls

  • 8.25 Secure development life cycle
  • 8.29 Security testing in development and acceptance

ISO 27701:2019 · 2 controls

  • 6.11 Systems acquisition, development and maintenance
  • 6.11.2 Security in development and support processes

NIST SP 800-161 Rev 1 · 2 controls

CFTC System Safeguards (17 CFR 37, 38, 39, 49) · 1 control

  • CFTC-SS-5 Systems Development and Quality Assurance Category

ISO 27002:2022 · 1 control

  • 8.29 Security testing in development and acceptance

NIS2 Directive · 1 control

  • Art.21.2.e Security in acquisition, development and maintenance, including vulnerability handling and disclosure

NIST Cybersecurity Framework 2.0 · 1 control

  • NIST-CSF-PR.PS-06 Secure software development practices are integrated, and their performance is monitored throughout the software development life cycle

NIST SP 800-171 Rev 3 · 1 control

NIST SP 800-172 · 1 control

  • 3.14.7e Verify Correctness of Security Functions

SOC 2 · 1 control

  • SOC2-CC8.1 CC8.1 Managing changes to procedures, software, data and infrastructure

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.2.3 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.

If you hold ISO 27001:202249.6% covered · 141 gapsIf you hold FedRAMP Moderate49.3% covered · 142 gapsIf you hold NIST SP 800-53 Rev 547.5% covered · 147 gapsIf you hold ISO 27002:202243.2% covered · 159 gapsIf you hold CIS Controls v838.2% covered · 173 gapsIf you hold Cloud Security Alliance Cloud Controls Matrix (CCM) v4.0.136.4% covered · 178 gaps

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.

See the released pairs, $299 eachBrowse the graph free

Query this from an agent

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

MCP endpointAll PCI DSS 4.0 controls