PCI DSS 6.2.3.1: If manual code reviews are performed for bespoke and custom software prior to release
PCI DSS v4.0.1 control 6.2.3.1: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 6.2.
Requirement 6: Develop and Maintain Secure Systems and Software › Section 6.2
If manual code reviews are performed for bespoke and custom software prior to release to production, code changes are:
- Reviewed by individuals other than the originating code author, and who are knowledgeable about code-review techniques and secure coding practices.
- Reviewed and approved by management prior to release.
Summary
If your code review is done by people rather than tools, the reviewer must not be the author, must know what they are looking for, and management approves before release.
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.2.3.1.a | If manual code reviews are performed for bespoke and custom software prior to release to production, examine documented software development procedures and interview responsible personnel to verify that processes are defined for manual code reviews to be conducted in accordance with all elements specified in this requirement. |
| 6.2.3.1.b | Examine evidence of changes to bespoke and custom software and interview personnel to verify that manual code reviews were conducted in accordance with all elements specified in this requirement. |
Conditional: this applies only where manual code reviews are performed to meet 6.2.3. Two elements, and the second surprises people. The first is the expected one: reviewed by individuals other than the originating code author, and knowledgeable about code-review techniques and secure coding practices, so a peer who has never been trained in either is half an answer. The second is that the change is reviewed and approved by management prior to release, which is a separate approval from the technical review. An entity with a healthy pull-request culture usually satisfies the first element completely and has no management approval at all, because merging is the approval. 6.2.3.1.b examines evidence of changes, so this is tested against real commits.
What to prepare
- Documented procedures showing both elements, which 6.2.3.1.a examines.
- A sample of changes with reviewer identity visible, distinct from the author.
- Evidence that reviewers are knowledgeable, which links to the training in 6.2.2.
- The management approval record, separate from the technical review.
How to implement it
1. Block self-approval in the repository. It is a setting rather than a policy, and it is what makes the first element enforced instead of expected.
2. Tie reviewer competence to 6.2.2. The annual secure coding training is the natural evidence that reviewers know what they are looking for.
3. Decide what management approval means for you and record it. A release approval covering a batch of changes is workable; nothing at all is not.
4. Consider whether you need manual review at all. If automated review satisfies 6.2.3 for your context, this control does not apply, which is worth establishing before building a process for it.
Where this commonly fails
- A strong pull-request process with no management approval, meeting one element of two.
- Self-approval possible in the repository, even if it rarely happens.
- Reviewers with no secure coding training, which the knowledgeable element asks about.
- Hotfixes bypassing both elements, which is visible in the evidence 6.2.3.1.b examines.
Related controls
Others in section 6.2:
| Control | What it requires |
|---|---|
| 6.2.1 | Bespoke and custom software are developed securely… |
| 6.2.2 | Software development personnel working on bespoke and custom software are trained at least once… |
| 6.2.3 | Bespoke and custom software is reviewed prior to being released into production… |
| 6.2.4 | Software engineering techniques or other methods are defined and in use by software development… |
← 6.2.3 · All controls · 6.2.4 →
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.