PCI DSS 4.0
Req 6: Secure Systems and Software

PCI DSS 4.0 6.2.3.1: 6.2.3.1 Manual code review independence and approval

Where bespoke and custom software is reviewed manually before it goes to production, each code change must be: examined by someone other than the person who wrote it, who is knowledgeable about secure coding practice and techniques for reviewing code; and reviewed and approved by management before release. It applies to all entities that perform manual code reviews. Applicability: manual reviews may be carried out by knowledgeable internal staff or knowledgeable third parties; a person formally given accountability for release control, who is neither the author nor the reviewer, counts as management for this purpose. Objective under the customized approach: the manual review process cannot be skipped and reliably uncovers security vulnerabilities.

Maintained by Gerard BlokdykControl text last updated

What else in your programme already covers this

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

ISO 27001:2022 · 5 controls

  • 5.35 Independent review of information security
  • 8.25 Secure development life cycle
  • 8.28 Secure coding
  • 8.29 Security testing in development and acceptance
  • 8.32 Change management

SOC 2 · 5 controls

  • SOC2-CC4.1 CC4.1 Ongoing and separate evaluations of control (COSO principle 16)
  • SOC2-CC4.2 CC4.2 Evaluating and communicating control deficiencies (COSO principle 17)
  • SOC2-CC5.1 CC5.1 Selecting control activities that mitigate risk (COSO principle 10)
  • SOC2-CC6.1 CC6.1 Logical access security over protected information assets
  • SOC2-CC8.1 CC8.1 Managing changes to procedures, software, data and infrastructure

FedRAMP High · 3 controls

  • SA-11 Developer Testing and Evaluation
  • SA-11(1) Developer Testing and Evaluation | Static Code Analysis (SA-11(1))
  • SI-2 Flaw Remediation

FedRAMP Moderate · 3 controls

  • SA-11 Developer Testing and Evaluation
  • SA-11(1) Developer Testing and Evaluation | Static Code Analysis (SA-11(1))
  • SI-2 Flaw Remediation

NIST SP 800-218 · 3 controls

NIST SP 800-53 Rev 5 · 3 controls

ISO 27002:2022 · 2 controls

  • 8.25 Secure development life cycle
  • 8.28 Secure coding

APRA CPS 234 · 1 control

  • CPS234-P30 Independence and Skill of Testing Personnel
  • ASBv3-DS-4 Integrate static application security testing into DevOps pipeline

C5 (Germany) · 1 control

CIS Controls v8 · 1 control

  • CIS-16.12 Implement Code-Level Security Checks

ISO 27701:2019 · 1 control

  • 6.11.2 Security in development and support processes

NIS2 Directive · 1 control

  • Art.21.4 Take corrective measures without undue delay on finding that the measures are not met
  • 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-172 · 1 control

  • 3.14.7e Verify Correctness of Security Functions
  • P1-3.1.7 P1-3.1.7 Management signs off test results before release

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.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 36 it maps to, and the evidence behind each claim, over MCP and REST.