PCI DSS Application Security Requirements

PCI DSS (Payment Card Industry Data Security Standard) imposes specific technical controls on software applications that store, process, or transmit cardholder data. Requirement 6 of the standard directly governs application-layer security, establishing mandatory controls that affect development practices, testing protocols, and runtime defenses. Non-compliance exposes organizations to fines, card brand penalties, and potential loss of payment processing privileges. This page maps the application security requirements across the PCI DSS framework and describes how they interact with broader application security standards and frameworks.

Definition and scope

PCI DSS is maintained by the PCI Security Standards Council (PCI SSC), an independent body founded by American Express, Discover, JCB International, Mastercard, and Visa. The standard is versioned; PCI DSS v4.0 was published in March 2022 and became the sole active standard as of March 2024, superseding v3.2.1 (PCI SSC v4.0 Document Library).

Scope for application security purposes covers:

Bespoke and custom software developed internally or by third parties that interacts with the cardholder data environment (CDE)
Third-party software components integrated into payment flows, including open-source libraries and commercial packages
Public-facing web applications that accept payment card data directly
Internal applications that process, route, or store primary account numbers (PANs), cardholder names, service codes, or sensitive authentication data

Requirement 6, "Develop and Maintain Secure Systems and Software," is the primary application-focused control domain. It subdivides into Requirement 6.1 (processes for identifying and managing security vulnerabilities in bespoke and custom software) and Requirement 6.2 through 6.4 (protection of web-facing applications, change management controls, and third-party software management). PCI SSC's Requirement 6 applies to all entities that develop software in scope, not only large merchants.

How it works

PCI DSS v4.0 Requirement 6 operates through a structured control hierarchy that parallels the secure software development lifecycle:

Security policy for development — Requirement 6.1.1 mandates a defined, documented set of security policies and procedures for all bespoke software development. These must cover separation of development, test, and production environments.
Training for developers — Requirement 6.2.2 requires that all personnel who develop bespoke software receive training in secure coding techniques relevant to their language and environment, at least once every 12 months. Training must include coverage of the vulnerability classes relevant to the development stack.
Code review and testing — Requirement 6.2.4 mandates that all bespoke and custom software is protected against common software attacks. Controls must address injection flaws, broken authentication, insecure direct object references, cross-site scripting, and other classes aligned with OWASP Top Ten Vulnerabilities. Secure code review or automated scanning satisfies this requirement when scoped correctly.
Web application protection — Requirement 6.4.1 requires that public-facing web applications are protected against known attacks by deploying a web application firewall (WAF) or performing a documented vulnerability assessment and remediation. A WAF must be actively running, generating logs, configured to either block or detect attacks, and reviewed at least once every 12 months.
Application vulnerability management — Requirement 6.3 addresses detection and mitigation of known vulnerabilities in installed software. This includes patch application within defined timeframes: critical vulnerabilities (CVSS 4.0 score ≥ 7.0) require remediation within one month (PCI DSS v4.0, Requirement 6.3.3).
Third-party and open-source component management — Requirement 6.3.2 mandates maintaining an inventory of all third-party software components and open-source libraries. This requirement directly maps to Software Composition Analysis (SCA) tooling.

Common scenarios

E-commerce checkout pages: A merchant operating a custom-built checkout that collects PANs must deploy automated dynamic application security testing or a WAF solution for Requirement 6.4.1 compliance. A WAF alone does not satisfy the penetration testing requirements under Requirement 11.

Integrated payment terminals (IXOS/point-of-sale software): Software on physical POS devices that routes transaction data falls under PCI DSS software requirements. Custom plugins or middleware bridging POS hardware to payment processors must meet the same Requirement 6.2.4 controls as web applications.

Third-party payment processors using shared APIs: When a merchant integrates a third-party processor via API security endpoints, PCI DSS scoping depends on whether cardholder data transits the merchant's environment. Iframe and redirect models may reduce scope for the merchant's custom application, but the integration points themselves still require documented security review.

DevOps pipeline integration: Organizations running application security in CI/CD pipelines satisfy several Requirement 6.2.4 controls by embedding static application security testing gates that block builds with critical findings from reaching production.

Decision boundaries

PCI DSS application security requirements are frequently misapplied at scope and classification boundaries. Three contrasts govern most edge cases:

Bespoke software vs. purchased off-the-shelf (COTS) software: Requirement 6.2 controls apply to bespoke and custom software. COTS products fall under Requirement 6.3 (patch and vulnerability management), not the development and training requirements. Organizations that modify COTS products introduce bespoke code and shift that modified component into Requirement 6.2 scope.

WAF-based compliance vs. tested compliance: Requirement 6.4.1 allows two paths for public-facing web application protection: (a) a WAF solution, or (b) a documented application vulnerability assessment performed before deployment and after changes. Path (b) is not satisfied by an annual penetration test alone — it requires assessment tied specifically to application changes, not a fixed calendar schedule.

PCI DSS vs. PA-DSS / PCI Secure Software Standard: PA-DSS was retired in October 2022. Its replacement, the PCI Secure Software Standard, governs payment software vendors seeking product-level validation. PCI DSS Requirement 6 governs entities deploying and operating software in a CDE — these are parallel frameworks, not hierarchical ones. A software product validated under the Secure Software Standard does not automatically satisfy a deploying merchant's Requirement 6 obligations.

Organizations seeking to benchmark their controls against NIST guidance may consult the NIST Secure Software Development Framework, which maps to PCI DSS Requirement 6 at the practice level.

References

Explore This Site

Regulations & Safety Regulatory References Tools & Calculators Password Strength Calculator