PCI DSS Application Security Requirements

PCI DSS Requirement 6 governs the security of payment-facing applications under the Payment Card Industry Data Security Standard, maintained by the PCI Security Standards Council. These controls apply to every entity that stores, processes, or transmits cardholder data — including merchants, service providers, and software developers operating in that ecosystem. The requirements span secure development practices, vulnerability management, and application-layer testing, creating enforceable obligations that intersect with software engineering, code review, and penetration testing disciplines.

Definition and scope

PCI DSS Requirement 6 ("Develop and Maintain Secure Systems and Software") establishes the minimum application security posture for any in-scope entity under the standard. The PCI DSS v4.0, published by the PCI Security Standards Council (PCI SSC) in March 2022, restructured prior Requirement 6 language from version 3.2.1 into a more granular set of controls organized under Requirement 6.1 through 6.5.

Scope by entity type:

The standard distinguishes between organizations that develop bespoke payment applications and those that deploy purchased or third-party software. PCI DSS 6.3.2 requires a maintained software inventory covering all bespoke and custom software. Entities relying on commercial-off-the-shelf (COTS) software are governed by 6.3.1, which mandates that only software from reputable sources with active security patches is deployed. The distinction between bespoke and COTS software creates two separate compliance tracks with different technical obligations.

Applications in scope include web-facing payment portals, mobile payment clients, APIs that transmit primary account numbers (PANs), and backend processing systems touching the cardholder data environment (CDE). The Application Security Authority providers catalog service providers operating across these functional areas.

How it works

PCI DSS v4.0 structures application security obligations into five discrete control clusters under Requirement 6:

1. 6.1 — Security governance for bespoke and custom software: Assigns formal responsibility for application security to defined roles and requires documented processes for pre-production security review.
2. 6.2 — Bespoke and custom software security: Mandates training for developers on secure coding techniques at least once per 12 months (PCI DSS 6.2.2), and requires that attacks relevant to the technology stack are incorporated into the security review process (6.2.4).
3. 6.3 — Security of software components and libraries: Requires a software bill of materials (SBOM)-equivalent inventory (6.3.2) and a process for identifying and remediating publicly disclosed vulnerabilities in third-party components.
4. 6.4 — Web-facing application protection: Organizations must either deploy a web application firewall (WAF) or an equivalent technology, or conduct a documented application vulnerability assessment reviewed by qualified personnel. Automated technical solutions require configuration management and active ruleset maintenance.
5. 6.5 — Changes to all system components: Controls apply to change management processes, requiring security review of modifications before deployment into production.

PCI DSS v4.0 introduced "customized approach" as an alternative to prescriptive control implementation. Under this track, an entity may satisfy a requirement through compensating controls if those controls demonstrably achieve the stated objective — assessed and validated by a Qualified Security Assessor (QSA). This approach shifts documentation burden substantially toward the assessed organization.

Common scenarios

E-commerce merchants with custom checkout pages: A merchant operating a direct card-capture page must satisfy 6.2.4, which requires that testing methodologies address injection attacks, broken authentication, and business logic flaws. The page describes the service categories relevant to these assessments.

Third-party software processors: Service providers whose software is used by merchants to handle cardholder data may fall under the PCI SSC's Secure Software Standard (a component of the PCI Software Security Framework, or SSF), which runs parallel to PCI DSS and imposes its own lifecycle controls on software vendors. Compliance with the SSF does not automatically satisfy PCI DSS Requirement 6 for the deploying entity.

API-based payment integrations: REST and SOAP APIs transmitting PANs are explicitly in scope. Under 6.2.4, testing must address authentication weaknesses and data exposure at the API layer. OWASP's API Security Top 10 is a recognized reference for characterizing these attack surfaces.

Containerized and CI/CD-delivered applications: PCI DSS 6.5.2 requires that security controls apply to changes deployed via automated pipelines. Static analysis security testing (SAST) and software composition analysis (SCA) tools integrated at the pipeline level satisfy parts of this requirement, but do not substitute for the human-reviewed vulnerability assessments required under 6.4.

Decision boundaries

PCI DSS Requirement 6 vs. PA-DSS (legacy): The Payment Application Data Security Standard (PA-DSS) was retired by the PCI SSC in October 2022. Applications previously validated under PA-DSS migrated to assessment against the PCI SSC's Secure Software Standard. Entities referencing PA-DSS validation after that retirement date are operating against a deprecated framework.

WAF requirement vs. vulnerability assessment alternative: PCI DSS 6.4.2 permits an automated technical solution (WAF or equivalent) as one path; 6.4.1 permits a vulnerability assessment conducted by a qualified internal or external resource as an alternative. The WAF path requires continuous monitoring and active ruleset updates — a static WAF deployment that receives no configuration updates does not satisfy the intent of the control.

QSA vs. internal assessor for Requirement 6 testing: PCI DSS does not universally require external QSA validation for Requirement 6 testing. Level 2 through Level 4 merchants may complete a Self-Assessment Questionnaire (SAQ) — specifically SAQ A-EP or SAQ D depending on their payment environment — and attest internally. Level 1 merchants (processing more than 6 million Visa or Mastercard transactions annually) require an on-site assessment by a QSA (Visa merchant level definitions). Practitioners navigating these qualification thresholds should consult the how to use this application security resource page for service-sector orientation.