Requirements 6.2 and 6.3.1: code review inside a PCI DSS programme

PCI DSS never asks for "a secure code review". It asks for four distinct things, and an annual review engagement delivers almost none of them: every release of bespoke and custom software reviewed before it ships (6.2.3); conditions that bite only if that review is manual (6.2.3.1); a defined list of attack classes the code must be engineered against (6.2.4); and a risk-ranking scheme other requirements defer back to by number (6.3.1). The clock on the review is the release, not the year — 6.2.2, developer training, is the only element of Requirement 6.2 with a twelve-month cadence at all. What follows is against PCI DSS v4.0.1, June 2024.

Outsourced development does not escape it

Requirement 6 governs bespoke and custom software. The glossary splits them: "Bespoke software is developed for the entity by a third party on the entity's behalf and per the entity's specifications. Custom software is developed by the entity for its own use." Third-party software falls outside 6.2.1 and 6.2.4 — but code written for you by a development partner, to your specification, is bespoke, which is to say yours. The scoping section is explicit: entities using software vendors to develop bespoke or custom software that could impact cardholder data security "are responsible for ensuring those software vendors develop the software according to PCI DSS Requirement 6." A statement of work silent on code review moves nothing.

6.2.3 is per release, and a scanner alone does not close it

"Bespoke and custom software is reviewed prior to being released into production or to customers, to identify and correct potential coding vulnerabilities, as follows: Code reviews ensure code is developed according to secure coding guidelines. Code reviews look for both existing and emerging software vulnerabilities. Appropriate corrections are implemented prior to release."

Three phrases decide scope. "Prior to being released" — the trigger is the release; there is no annual option and no threshold below which a change is too small. "Both internal and public facing", from the applicability note — the internal admin console is in scope on the same terms as the checkout. "Manual or automated processes, or a combination of both" — an automated-only programme is permitted; an unreviewed release is not. The guidance expects more than a linter's output: implant tools and backdoors, external components integrated insecurely, logging that lets sensitive data into logs, and behaviour that reveals logical vulnerabilities.

6.2.3.1: the conditions that apply only if the review is manual

6.2.3.1 is conditional, and the condition is easy to misread. It applies "if manual code reviews are performed for bespoke and custom software prior to release to production". An automated-only programme does not trigger it — but 6.2.3 still applies, and you then own the argument that a tool alone finds emerging vulnerabilities and logic flaws. Where it does apply, code changes must be:

• "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."

Two applicability notes settle recurring questions. "Manual code reviews can be conducted by knowledgeable internal personnel or knowledgeable third-party personnel" — an external reviewer is expressly contemplated, often the only route to real independence on a small team. And on what counts as management: "An individual that has been formally granted accountability for release control and who is neither the original code author nor the code reviewer fulfills the criteria of being management." A director's signature is not the requirement; a documented, separate accountability for release control is.

The testing procedure is where this parts company with a general engagement. 6.2.3.1.b directs the assessor to "examine evidence of changes to bespoke and custom software and interview personnel to verify that manual code reviews were conducted" — the assessor samples changes and traces each back to a review and an approval. A PDF covering the codebase as it stood in March answers a question nobody asked; merge-request records showing reviewer identity, comments, resolution and approval, retained per change, answer the one that was.

6.3.1 is not vulnerability scanning, and much of the standard points at it

6.3.1 requires new vulnerabilities to be identified from industry-recognised sources including CERT alerts, then risk-ranked so that everything high-risk or critical is identified, across bespoke and custom software and third-party software alike. Its applicability note draws the line most programmes get wrong: "This requirement is not achieved by, and is in addition to, performing vulnerability scans according to Requirements 11.3.1 and 11.3.2. This requirement is for a process to actively monitor industry sources for vulnerability information and for the entity to determine the risk ranking to be associated with each vulnerability." It is a scheme, not an activity — and it is the scheme other requirements are written against by number:

Where the ranking methodology is undocumented, the deadline in each of those is undefined and a finding cannot be closed against a standard it never had — a common reason a programme that looks complete does not survive review. See what gets a PCI penetration test report rejected.

The 31 March 2025 change that retired the annual application review

Requirement 6.4.1 used to offer a choice: review the public-facing web application "at least once every 12 months and after significant changes, by an entity that specializes in application security", or install an automated technical solution in front of it. That choice is gone. 6.4.1 carries the note "This requirement will be superseded by Requirement 6.4.2 after 31 March 2025", and the PCI SSC summary of changes is explicit about what went: 6.4.2 "removes the option in Requirement 6.4.1 to review web applications via manual or automated application vulnerability assessment tools or methods."

An annual application security assessment therefore discharges nothing under 6.4; the automated technical solution is now mandatory. The code-review obligation was never in 6.4 anyway — it sits in 6.2.3, per release, and came through untouched. A proposal still selling "annual review for PCI Requirement 6.6" is quoting a v3.2.1 number, since renumbered to 6.4.1 and superseded again.

What else a code-review scope collides with

• 6.2.4 — the enumerated attack list: injection, attacks on data and data structures, cryptography usage, business logic including XSS and CSRF, access control mechanisms, and anything ranked high-risk under 6.3.1. The same list 11.4.1 requires application-layer penetration testing to cover.
• 6.5.1 — "for bespoke and custom software changes, all updates are tested for compliance with Requirement 6.2.4 before being deployed into production": a per-change test on top of the per-release review.
• 6.3.2, 6.5.5, 6.5.6 — a component inventory, mandatory since 31 March 2025; live PANs kept out of pre-production unless it sits in the CDE; test data and accounts removed before production.

How the work should be scoped

A code review that satisfies Requirement 6 is not a deliverable dated once a year. It is a reviewer independent of the author, working to the 6.2.4 attack list and the entity's own secure coding guidelines, leaving per-change evidence that ties a review and a release approval to each change an assessor might sample, with findings ranked under the 6.3.1 scheme so the deadline is defined rather than negotiated. Security Brigade performs secure code review scoped that way, alongside the Requirement 11.4 testing that covers the same 6.2.4 attack list from the outside — what Requirement 11.4 demands of a penetration test sets out where the two meet.