If you write code that touches a cardholder data environment (CDE), PCI DSS 4.0 is now part of your job description, not just your security team's. The standard became fully enforceable on 31 March 2025, and its biggest change for engineers is philosophical: PCI DSS 4.0 treats secure development as a continuous practice you prove on every change, rather than a review you pass once a year. This guide translates the parts of the standard developers actually own into concrete engineering practice.
What PCI DSS is, in one paragraph
PCI DSS (Payment Card Industry Data Security Standard) is the security standard maintained by the PCI Security Standards Council that any organisation storing, processing, or transmitting payment card data must meet. It applies to merchants and service providers of every size, though the assessment path — self-assessment questionnaire versus a full Report on Compliance from a Qualified Security Assessor — scales with transaction volume. For developers, the relevant heart of the standard is Requirement 6: Develop and Maintain Secure Systems and Software.
The Requirement 6 clauses developers own
Rather than memorising the whole standard, focus on the clauses that map directly to what you build:
- 6.2.1 — Secure development. Software must be developed following secure practices, based on industry standards and secure coding guidance, with security built into the SDLC.
- 6.2.2 — Developer training. Engineers working on bespoke and custom software must be trained at least annually on secure software design and coding relevant to their role.
- 6.2.3 / 6.2.4 — Code review and injection defence. Custom code must be reviewed before release to find vulnerabilities, and software engineering techniques must prevent or mitigate common attacks (injection, insecure deserialization, and the rest of the OWASP-style categories).
- 6.3.1 — Vulnerability identification. You must have a process to identify and rank security vulnerabilities using reputable sources, assigning risk rankings so criticals are addressed first.
- 6.3.2 — Component inventory. You must maintain an inventory of bespoke and custom software and the third-party components it uses — in practice, a software bill of materials — to enable vulnerability management.
- 6.4.3 — Payment page scripts. All scripts on payment pages must be authorised, integrity-verified, and inventoried, a control written in direct response to browser-based skimming (Magecart) attacks.
Requirement 11 adds the testing cadence around this work: 11.3.1 requires internal and external vulnerability scans at least quarterly and after significant changes, and 11.4.1 requires penetration testing at least annually.
What this changes in your daily workflow
The 6.3.2 component inventory is the clause most likely to reshape how you work. It effectively makes an SBOM mandatory, because you cannot manage vulnerabilities in dependencies you have not enumerated — and an assessor evaluating 6.3.1 will ask how you know a critical CVE in a transitive dependency did not ship. A one-off dependency spreadsheet does not survive contact with a real audit; the inventory has to track what actually ships in each release.
The 6.2.3 pre-release review clause pushes vulnerability testing left into the pull request, not a pre-release gate run by a separate team. And 6.4.3's script integrity requirement means front-end developers now need to justify every third-party script on a checkout page and verify it has not changed unexpectedly.
Developer compliance checklist
- Secure coding standard documented and referenced in your SDLC (6.2.1)
- Annual secure-development training completed for engineers on the CDE (6.2.2)
- Automated code review / SAST running before merge on custom code (6.2.3)
- Input validation and injection defences applied systematically (6.2.4)
- Risk-ranking process for newly disclosed vulnerabilities (6.3.1)
- Maintained SBOM covering bespoke code and third-party components (6.3.2)
- Inventory and integrity checks for all payment-page scripts (6.4.3)
- Quarterly vulnerability scans and annual penetration test scheduled (11.3, 11.4)
- Remediation SLAs defined (e.g., critical in 15 days, high in 30) with evidence retained
Where teams commonly fall short
The most frequent gap is treating software composition analysis as separate from the "real" AppSec program. Static analysis catches first-party bugs, but the majority of code in a modern payment application is open source, and 6.3.2 is explicit that third-party components are in scope. The second common gap is evidence fragmentation: assessors performing a Report on Compliance want a reconstructable trail showing that a high or critical finding did not reach production, and stitching that together from three disconnected dashboards under deadline is painful and error-prone.
How Safeguard helps
Safeguard maps cleanly onto the Requirement 6 clauses developers actually own. Software composition analysis continuously identifies and risk-ranks vulnerabilities in your third-party components — the exact 6.3.1 and 6.3.2 obligations — while SBOM Studio maintains the component inventory 6.3.2 requires, regenerated per release so it reflects what truly shipped rather than a stale export.
The Safeguard CLI runs the same checks inside your pull requests and CI pipeline, so the 6.2.3 "review before release" gate is automated and produces a timestamped record instead of a manual sign-off. Griffin AI triages findings against your codebase and applies risk rankings the way an assessor expects to see them documented, keeping remediation focused on genuinely exploitable issues. Because all of this feeds one queryable evidence trail — scan history, SBOM snapshots, remediation timestamps — you can hand a Qualified Security Assessor a coherent record rather than reconstructing it.
Our compliance pages break down how each control maps to PCI DSS 4.0, so you can point a Qualified Security Assessor at the exact capability behind each clause.
PCI DSS 4.0 rewards teams that make secure development a continuous, evidenced habit. Wire the checks into your pipeline and the audit trail builds itself.
Want to see it on your own repository? Sign up free or explore the Safeguard documentation to connect a project and generate your first SBOM.