Requirement 6 of the PCI DSS is titled "Develop and Maintain Secure Systems and Software," and in version 4.0 it became the clause where the standard's shift from periodic checkbox to continuous discipline is most visible. If your organisation stores, processes, or transmits cardholder data, Requirement 6 governs how you build software, how you find and fix vulnerabilities in it, and how you protect the public-facing applications that touch payment pages. This guide walks through the structure of Requirement 6 in PCI DSS 4.0 (and the 4.0.1 revision published in June 2024) so you can see exactly what an assessor will ask for.
What Requirement 6 covers
The current standard is PCI DSS v4.0, with a minor revision at v4.0.1. A large set of "future-dated" requirements that were best practice during the transition became mandatory on 31 March 2025, so as of 2026 they are fully in force and assessed. Requirement 6 breaks into four working areas:
- 6.2 — Bespoke and custom software is developed securely.
- 6.3 — Security vulnerabilities are identified and addressed.
- 6.4 — Public-facing web applications are protected against attacks.
- 6.5 — Changes to all system components are managed securely.
Clause by clause
6.2 Secure development. Requirement 6.2.1 asks that bespoke and custom software be developed based on industry standards and secure development practices, with security built in throughout the software development lifecycle. Requirement 6.2.2 requires that developers receive relevant secure-coding training at least annually. Requirement 6.2.3 mandates that bespoke and custom software be reviewed before release to identify and correct potential coding vulnerabilities, whether by manual or automated review, covering common software attacks. Requirement 6.2.4 requires engineering techniques or methods to prevent or mitigate common software attacks — injection, cryptographic flaws, business-logic abuse, and access-control errors among them.
6.3 Vulnerability management. This is the clause with the largest supply-chain footprint. Requirement 6.3.1 requires that security vulnerabilities be identified and assigned a risk ranking, using industry-recognised sources for vulnerability information. Requirement 6.3.2 — the one that catches teams off guard — requires an inventory of bespoke and custom software, and third-party software components incorporated into it, maintained to facilitate vulnerability and patch management. In plain terms, that is a software bill of materials. Requirement 6.3.3 requires that all system components be protected from known vulnerabilities by installing applicable security patches, with critical or high-severity patches installed within one month of release.
6.4 Public-facing web applications. Requirement 6.4.1 and 6.4.2 concern protecting public-facing web apps: 6.4.2 (a future-dated requirement now in force) requires an automated technical solution that continually detects and prevents web-based attacks — a web application firewall or equivalent — replacing the older option of periodic manual review. Requirement 6.4.3 requires that all payment-page scripts loaded in the consumer's browser are authorised, their integrity assured, and an inventory maintained, a direct response to digital-skimming and Magecart-style attacks.
6.5 Change management. Requirement 6.5.1 through 6.5.6 covers secure change control: changes follow a documented process, separate development/test and production environments, enforce separation of duties, and ensure that live cardholder data is not used in test.
Compliance checklist
| Sub-requirement | Evidence an assessor expects |
|---|---|
| 6.2.2 | Records of annual secure-coding training |
| 6.2.3 / 6.2.4 | Pre-release code review results; mitigations documented |
| 6.3.1 | Risk-ranked vulnerability list from recognised sources |
| 6.3.2 | Maintained SBOM of custom and third-party components |
| 6.3.3 | Patch timelines; critical/high patched within one month |
| 6.4.2 | Automated web-attack detection in place and monitored |
| 6.4.3 | Authorised, integrity-checked payment-script inventory |
| 6.5.x | Documented change control with environment separation |
How Safeguard helps
The clause most teams underestimate is 6.3.2, and it is exactly the one Safeguard is built around. SBOM Studio maintains the inventory of bespoke and third-party software components that 6.3.2 demands, kept current automatically rather than rebuilt by hand before each assessment. Safeguard's SCA satisfies 6.3.1 by identifying vulnerabilities from industry-recognised sources and assigning risk rankings, and its reachability analysis helps you focus the one-month patch window in 6.3.3 on the components that are genuinely exploitable. Because Safeguard records scan history, risk rankings, and remediation timestamps in a single trail, the evidence a Qualified Security Assessor asks for during a Report on Compliance — proof that a critical finding did not ship, and that patches landed inside the window — is retrievable rather than reconstructed. Our compliance pages map these capabilities to the individual sub-requirements of Requirement 6.
Frequently Asked Questions
Does Requirement 6.3.2 really require an SBOM? It requires a maintained inventory of bespoke and custom software and the third-party software components incorporated into it, kept current to support vulnerability and patch management. That is the working definition of a software bill of materials. The standard does not mandate a specific SBOM format, but assessors expect a complete, current component list you can query.
What is the patch deadline under Requirement 6.3.3? Critical and high-severity security patches must be installed within one month of release, and all other applicable patches within an appropriate timeframe based on your risk ranking. The one-month window makes continuous vulnerability visibility a practical necessity, because you cannot meet it if you only scan quarterly.
Is a web application firewall mandatory now? Requirement 6.4.2 requires an automated technical solution that continually detects and prevents web-based attacks for public-facing web applications. A WAF is the common way to meet it, but the standard describes the capability rather than the product. This requirement became mandatory on 31 March 2025, replacing the previous option to perform periodic manual application reviews.
How does Requirement 6 relate to Requirement 11? Requirement 6 governs how you build and remediate software; Requirement 11 governs testing of the running environment — quarterly internal and external vulnerability scans (11.3) and at least annual penetration testing (11.4). They overlap on vulnerability management but from different angles, and an assessor will expect the evidence trails to line up rather than contradict each other.
Preparing for a PCI DSS 4.0 assessment? See how our SCA engine and SBOM inventory evidence Requirement 6 on the compliance pages, or read the Safeguard documentation.