Requirement 6.2.3 lets you review bespoke and custom code before release manually, with automated tools, or with both. If you do manual reviews, 6.2.3.1 adds that someone other than the author reviews the change and that management approves it before release. This is a plain-language summary, not legal advice.
What 6.2.3 requires
Per the SAQ D text, code is reviewed before it reaches production or customers to find and correct potential coding vulnerabilities. Reviews check the code against secure coding guidelines, look for existing and emerging vulnerabilities, and corrections are made before release. The note adds that the requirement covers internal and public-facing software, and that reviews may be manual, automated or a combination.
Manual versus automated
| Manual review | Automated review | |
|---|---|---|
| Extra rule | 6.2.3.1 applies | None stated beyond 6.2.3 |
| Reviewer | Someone other than the author, knowledgeable in review and secure coding | A tool configured to your guidelines |
| Approval | Management approval before release | Document your process |
| Strength | Context and logic flaws | Consistency and speed |
Practical teams combine both, but the standard does not demand it.
What 6.2.3.1 means by management
The note says an individual who has been formally granted accountability for release control, and who is neither the author nor the reviewer, meets the criteria. That can be a release manager, not necessarily a senior executive.
Evidence an assessor may ask for
The expected testing for 6.2.3 includes examining documented software development procedures, interviewing personnel, and examining evidence of changes to bespoke and custom software. Keep:
- The written review procedure.
- Pull requests showing the reviewer and approval.
- Tool output tied to the release.
- Records of fixes made before release.
Try it yourself
Click through it at your own pace, or open it full screen. Look at what a code scan reports.
Quick check
Can the author approve their own change?
For manual reviews, 6.2.3.1 requires review by someone other than the originating author.
Does a tool run alone satisfy 6.2.3?
The note permits automated review, and you still need to show corrections were made before release. Confirm your approach with your assessor.
On Safeguard: policies and gates can block a pull request that fails a configured check, which gives you a record tied to each change. Try the free scan at gold.safeguard.sh/scan.
Sources
Wording is from v4.0. Confirm in the current version.
Last reviewed: 19 October 2026.