PCI DSS Secure Code Requirements: What Developers Must Know

The Payment Card Industry Data Security Standard (PCI DSS) imposes specific obligations on developers who build, maintain, or integrate software that touches cardholder data environments. Version 4.0, released by the PCI Security Standards Council in March 2022, restructured and expanded secure code requirements significantly compared to earlier versions. This page covers the definition and scope of those requirements, how they are structured mechanically, what drives non-compliance, how requirements are classified, and where practitioners encounter genuine complexity.

• Definition and scope
• Core mechanics or structure
• Causal relationships or drivers
• Classification boundaries
• Tradeoffs and tensions
• Common misconceptions
• Checklist or steps (non-advisory)
• Reference table or matrix

Definition and scope

PCI DSS secure code requirements are a subset of the broader PCI DSS framework, which is maintained by the PCI Security Standards Council (PCI SSC). These requirements govern how software is designed, written, tested, and deployed within or adjacent to a cardholder data environment (CDE). The CDE is defined by PCI SSC as systems that store, process, or transmit cardholder data or sensitive authentication data, plus systems that could impact the security of those systems.

Under PCI DSS v4.0, Requirement 6 is the primary locus of secure code obligations. Requirement 6 is titled "Develop and Maintain Secure Systems and Software" and is divided into two major sub-groups: Requirement 6.1 through 6.3 (processes and governance) and Requirement 6.4 through 6.5 (technical controls for public-facing applications and payment software). The requirement applies to all software — including in-house developed code, third-party software, and bespoke payment applications — that operates within or connects to the CDE.

Scope is not limited to payment processing applications. A logging service, an internal API gateway, or a CI/CD pipeline system that has network access to the CDE falls within scope and therefore within the reach of Requirement 6. Determining scope accurately is foundational to compliance, and incorrect scoping is one of the most commonly cited findings in Qualified Security Assessor (QSA) reports. The regulatory context for code compliance in the payment card sector also involves interaction with state-level data breach statutes and the Gramm-Leach-Bliley Act, depending on the entity type.

Core mechanics or structure

PCI DSS v4.0 Requirement 6 is structured around six discrete sub-requirements, each carrying specific testing procedures that QSAs use during assessments.

Requirement 6.1 mandates documented policies and procedures for managing all software components in scope. This includes maintaining an inventory of all bespoke and custom software.

Requirement 6.2 governs bespoke and custom software development. It requires that all developers receive training in secure coding techniques relevant to their role at least once every 12 months (PCI DSS v4.0, Requirement 6.2.2). It also mandates pre-production code review for bespoke software, performed by personnel other than the original developer, using either manual methods or automated tools, or both.

Requirement 6.3 addresses protection against known vulnerabilities. Entities must have a process for identifying and ranking security vulnerabilities — using at least one industry-recognized source such as the OWASP Top 10 or the Common Weakness Enumeration (CWE) — and remediating critical vulnerabilities within one month.

Requirement 6.4 covers public-facing web applications. All such applications must be protected by either a web application firewall (WAF) or an automated technical solution that detects and prevents web-based attacks, or by an annual application penetration test combined with a vulnerability assessment.

Requirement 6.5 addresses payment page scripts. Any script loaded and executed in a consumer's browser from a payment page must be managed using a formal inventory, justification, and integrity method (e.g., Sub-Resource Integrity hashes).

The secure coding standards that developers are trained on must be documented and aligned with industry guidance — PCI SSC explicitly references OWASP, SANS, and CERT as acceptable source frameworks.

Causal relationships or drivers

Non-compliance with PCI DSS Requirement 6 is causally linked to several recurring failure patterns. The dominant driver in historical breach data is the injection vulnerability class — SQL injection and cross-site scripting (XSS) — which OWASP's 2021 Top 10 list ranks as the third and second most prevalent vulnerability categories respectively (OWASP Top 10:2021).

Third-party and open-source components are a second structural driver. The software bill of materials is increasingly relevant here: when developers include libraries without tracking version, license, or vulnerability status, critical patches are routinely missed. The 2021 Apache Log4j vulnerability (CVE-2021-44228) illustrated that a single dependency could expose thousands of payment-processing systems simultaneously.

Developer training gaps drive a third category of failure. PCI DSS v4.0's explicit 12-month training cadence requirement (Requirement 6.2.2) was added precisely because assessments consistently found organizations where developers had received no formal security training in the prior 24 months or more.

Organizational pressure to accelerate release velocity also contributes to non-compliance. Code review processes mandated under Requirement 6.2.4 are frequently bypassed when sprint timelines compress. The shift-left security compliance model addresses this structurally by integrating security validation into the development pipeline rather than treating it as a pre-production gate.

Classification boundaries

PCI DSS distinguishes between two categories of software subject to Requirement 6: bespoke and custom software and third-party software. These categories carry different obligations.

For bespoke and custom software, the entity that develops or commissions the software bears responsibility for all Requirement 6.2 controls — code review, developer training, and vulnerability management. For third-party software, the entity must have a process to confirm that the vendor manages vulnerabilities and delivers patches; the entity itself does not typically perform code review of vendor source code.

A further classification boundary separates payment software governed by PCI DSS Requirement 6 from software subject to the PCI Software Security Framework (PCI SSF), which includes the Secure Software Standard and the Secure Software Lifecycle (Secure SLC) Standard. Software vendors who want their products formally validated by PCI SSC use the PCI SSF pathway, not PCI DSS Requirement 6 directly.

Public-facing applications trigger additional Requirement 6.4 controls that internal-only applications do not. The boundary is network exposure: an application reachable from the internet — even indirectly through a load balancer or reverse proxy — is treated as public-facing for compliance purposes.

Tradeoffs and tensions

The most persistent tension in PCI DSS secure code compliance is between assessment flexibility and implementation specificity. PCI DSS v4.0 introduced a "customized approach" pathway alongside the traditional "defined approach," allowing entities to meet the intent of a requirement through alternative controls. While this flexibility accommodates mature organizations with sophisticated security programs, it also creates interpretive ambiguity during QSA assessments.

A second tension involves WAF dependency versus code quality. Requirement 6.4 allows a WAF to substitute for annual penetration testing of public-facing applications. Organizations that rely on this substitution may deprioritize root-cause remediation in the underlying code, treating the WAF as a permanent compensating control rather than a temporary protective layer.

The code review requirement (Requirement 6.2.4) creates resource tension for small development teams. The requirement that review be performed by someone other than the original developer is structurally sound from a security standpoint, but organizations with fewer than 5 developers face staffing constraints that make independent review logistically difficult. PCI SSC permits the use of automated static analysis tools to satisfy part of this requirement, but does not allow them to fully replace human review for bespoke code.

Common misconceptions

Misconception 1: PCI DSS only applies to production code.
PCI DSS Requirement 6.2 applies to all bespoke and custom software within scope — including staging environments, internal tools, and administrative interfaces that connect to the CDE. Development and test environments are specifically addressed under Requirement 6.3.3, which requires that production data not be used in test environments unless explicitly protected.

Misconception 2: Passing a QSA assessment means the code is secure.
QSA assessments validate that documented processes and controls exist and were followed during the assessment period. A QSA does not perform a comprehensive penetration test or full code audit in the normal course of a PCI DSS assessment. The assessment is a point-in-time verification of process adherence, not a technical certification of code quality. The distinction between code compliance vs. code quality is material here.

Misconception 3: Using a PCI-certified payment processor eliminates developer obligations.
Outsourcing payment processing to a PCI DSS-compliant processor reduces scope, but does not eliminate it. If developer-controlled payment page scripts load external resources or interact with iframes, those scripts fall under Requirement 6.5's payment page script management controls regardless of processor certification status.

Misconception 4: The OWASP Top 10 is a PCI DSS requirement.
PCI DSS Requirement 6.2.4 requires that bespoke software be protected against at least the vulnerability types in OWASP Top 10 and other industry-recognized sources. OWASP Top 10 functions as a minimum reference, not an exhaustive checklist, and PCI SSC does not formally endorse any specific version of the list.

Checklist or steps (non-advisory)

The following steps reflect the sequence implied by PCI DSS v4.0 Requirement 6 testing procedures and PCI SSC supplemental guidance.

1. Establish software inventory — Maintain a documented inventory of all bespoke, custom, and third-party software components within or connected to the CDE, including version numbers and support status (Requirement 6.1.1, 6.1.2).

2. Implement developer training program — Establish a secure coding training program documented by role, with records of completion at minimum every 12 months (Requirement 6.2.2).

3. Adopt industry-recognized secure coding standards — Select a documented standard aligned to OWASP, CERT, or equivalent; map that standard to applicable vulnerability classes including injection, authentication flaws, and cryptographic failures (Requirement 6.2.4).

4. Establish pre-production code review process — Define and document a code review procedure that uses personnel independent of the original developer, automated static analysis, or both (Requirement 6.2.4).

5. Implement vulnerability ranking and tracking — Use at least one named industry source (NVD, OWASP, or CWE) to classify discovered vulnerabilities by criticality; establish a remediation SLA of no longer than one month for critical findings (Requirement 6.3.3).

6. Deploy and configure WAF or equivalent — For public-facing web applications, implement a WAF with active blocking or detection capability, or document the annual penetration test alternative (Requirement 6.4.1, 6.4.2).

7. Manage payment page scripts — Maintain an inventory of all scripts authorized to execute on payment pages, document the business justification for each, and implement integrity verification (e.g., Sub-Resource Integrity) (Requirement 6.5.1–6.5.6).

8. Document evidence for QSA review — Retain training records, code review logs, vulnerability tracking records, WAF configuration documentation, and script inventories as evidence artifacts (Requirement 6.1–6.5, evidence testing procedures).

Reference table or matrix

The code compliance tools comparison page provides a structured overview of static analysis, software composition analysis, and dynamic testing tools mapped against Requirement 6 sub-requirements. For a broader view of how PCI DSS intersects with other regulatory frameworks, the index catalogs the full range of compliance frameworks addressed across this reference site.

References

• PCI Security Standards Council — PCI DSS v4.0 Document Library
• PCI Security Standards Council — PCI Software Security Framework
• OWASP Top 10:2021
• OWASP — Web Security Testing Guide
• MITRE Common Weakness Enumeration (CWE)
• NIST National Vulnerability Database (NVD)
• CERT Secure Coding Standards — Carnegie Mellon University Software Engineering Institute