Does PCI DSS require code review? What 6.2.3 actually says
Does PCI DSS require code review?
Yes. PCI DSS v4.0 requirement 6.2.3 says bespoke and custom software must be reviewed prior to release into production, to identify and correct potential coding vulnerabilities and confirm the code was developed according to secure coding guidelines. It is an explicit requirement, not an inference.
That is worth stating plainly because we published the opposite answer about HIPAA last week. HIPAA contains no code review standard at all; the obligation there is derived from risk analysis and audit controls. PCI is the other case. If you work under both, do not carry assumptions from one to the other.
Key takeaways
- 6.2.3 requires review of bespoke and custom software before production release.
- Automated tools are explicitly allowed, provided they cover the vulnerability categories in 6.2.4. A human does not have to read every diff.
- 6.2.3.1 is a separate branch that applies only to manual reviews: reviewer must not be the author, must be qualified, and management must approve release.
- Results and remediation must be documented. This is the part most teams underbuild.
- An AI reviewer complements rather than replaces scanner coverage for 6.2.4.
What counts as bespoke and custom software?
Bespoke software is written specifically for you. Custom software is a modified version of something existing. Both are in scope.
The scoping detail people miss: code repositories and system configurations that affect account data security are themselves subject to assessment. So the question is not only "did we review the payment service", it is "which of our repositories can influence cardholder data security", and that list is usually longer than the obvious one.
Automated review is explicitly permitted
This is the most commonly misunderstood part of the requirement, and it usually costs teams money.
The review may be performed by a technically qualified internal reviewer, an external security firm, or automated tools, as long as the tooling covers the vulnerability categories in 6.2.4. Plenty of organisations run an expensive manual review queue because they assume a human must sign off every change. The standard does not say that.
What it does say is that whatever performs the review has to actually cover the ground, and that the results have to be documented.
The 6.2.3.1 branch, and why it matters
Requirement 6.2.3.1 applies specifically if you perform manual code reviews. It adds three conditions:
| Condition | What it means in practice |
|---|---|
| Reviewer is not the author | Self-approval does not count. A one-person team has a real problem here. |
| Reviewer is qualified | Expertise in code review technique and secure coding, which you may be asked to evidence. |
| Management approves release | A separate approval step from the technical review itself. |
The interesting consequence: if your review is automated under 6.2.3, you are not on the manual branch, so the author-separation clause is not the applicable path. In a hybrid setup, which is what most teams actually run, be precise about which changes went down which route. Your QSA decides how your specific process maps, and that conversation goes better if you can show the routing rather than describe it.
The documentation requirement is the hard part
Review results and remediation must be documented. One sentence, and it is where most implementations are thin.
Producing a finding is not the same as producing evidence. An assessor asking about a specific release wants to see that the review ran on that change, what it found, whether anything was accepted rather than fixed, and who decided. Pull request comments are a poor substitute: they can be edited or deleted, they live in a git host's activity data, and they were never designed as a retained record.
This is the same gap we wrote about in what an AI code review audit trail must prove. PCI just states the documentation obligation more directly than most frameworks do.
Where a blocking gate fits
6.2.3 says review happens prior to release into production. An advisory reviewer that comments and lets the merge proceed is not obviously satisfying "prior to release" in a way you can evidence, because nothing stopped the release.
A blocking gate makes the control demonstrable rather than asserted. Gatekeep hard-blocks a merge until findings clear, records the gate decision and the policy that produced it, and requires a written justification for any override, all of which lands in an append-only hash-chained log. That maps onto the documentation obligation directly: the record shows the review ran, what it found, and what a named human decided when something was accepted.
Honest caveats
This is not QSA advice. It is a practitioner reading of v4.0. Your assessor decides how your process maps to the requirements, and reasonable programmes differ. Check the current standard text rather than relying on any vendor summary, including this one.
An AI reviewer does not replace your scanner. 6.2.4 concerns defined engineering techniques against common attacks such as injection and buffer overflows, which established SAST tooling covers systematically. Gatekeep adds judgement, enforcement and evidence on top. Anyone telling you an LLM reviewer alone discharges 6.2.4 is selling you something.
Gatekeep is not PCI certified, and no tool makes an organisation compliant. We label anything unbuilt as roadmap, and we support GitHub only as of July 2026.
Frequently asked questions
Does PCI DSS require code review?
Yes. PCI DSS v4.0 requirement 6.2.3 states that bespoke and custom software must be reviewed prior to release into production, to identify and correct potential coding vulnerabilities and confirm the code was developed according to secure coding guidelines. This is a genuine difference from HIPAA, which contains no code review standard at all.
Can an automated tool satisfy PCI DSS 6.2.3?
Yes. The requirement allows the review to be performed by a technically qualified internal reviewer, an external security firm, or automated tools, provided the tooling covers the vulnerability categories in 6.2.4. Many teams assume a human must read every diff. The standard does not say that.
What is requirement 6.2.3.1?
It is the branch that applies only if you perform manual code reviews. It requires the reviewer to be someone other than the original author, requires reviewers to have expertise in code review and secure coding, and requires management approval before release. If your review is automated under 6.2.3, the author-separation clause is not the applicable path, though your QSA decides how your specific process maps.
What do you have to document for 6.2.3?
Review results and remediation must be documented. That is the part teams underbuild. Producing a finding is not enough; you need a durable record showing the review ran on that change, what it found, and what happened next, retained long enough to hand to an assessor.
Does an AI reviewer replace SAST for PCI?
Probably not, and you should be sceptical of anyone claiming otherwise. 6.2.4 concerns defined software engineering techniques for common attacks such as injection and buffer overflows, which established scanners cover systematically. An AI reviewer is better understood as adding judgement and enforcement on top, not as a replacement for that coverage.
The short version
PCI does require code review, automated tooling is allowed to perform it, and the obligation most teams underbuild is the documentation rather than the review itself. If you can show an assessor that a check ran on a specific change, that a failure stopped the release, and that any acceptance was decided by a named human with a written reason, you are in good shape. If your answer is a link to a comment thread, you are relying on an artifact that was never built to be evidence.