PCI DSS Requirement 6 Explained: Secure Systems & Software

How Is PCI DSS Requirement 6 Organized?

Requirement 6 contains five groups of controls.

Sub-Requirement	Focus	Practical Meaning
6.1	Governance	Documented processes, assigned roles
6.2	Bespoke and custom software	Secure lifecycle, training, code review
6.3	Vulnerabilities and components	Risk ranking, inventory, patching
6.4	Public-facing web applications	Attack protection, payment page scripts
6.5	Change management	Approved, tested changes

Three controls were future-dated in v4.0: the component inventory (6.3.2), automated protection for public-facing web applications (6.4.2), and payment page script management (6.4.3). All became mandatory on March 31, 2025.

How Does PCI DSS Require Bespoke Software to Be Developed Securely?

Requirement 6.2 requires bespoke and custom software to follow a secure development lifecycle, with trained developers and code review before release. Developers need training relevant to their role and languages at least once every 12 months (6.2.2), and code is reviewed before production release (6.2.3). Manual reviews are performed by a knowledgeable person other than the author, with management approval (6.2.3.1). Requirement 6.2.4 expects techniques that prevent common attacks such as injection flaws and access control bypass, and the OWASP Top 10 is a widely used reference. Static analysis helps, but business logic flaws need human judgment, which is where an independent source code review adds assurance on payment-critical code.

How Should Organizations Manage Vulnerabilities and Patching Under Requirement 6.3?

Requirement 6.3 requires organizations to identify vulnerabilities from reputable sources, rank them by risk, inventory software components, and install patches for critical vulnerabilities within one month of release. Under 6.3.1, the risk ranking must identify, at a minimum, all vulnerabilities considered high-risk or critical. Requirement 6.3.2 adds an inventory of bespoke, custom, and third-party components, including libraries, which speeds impact analysis when an advisory appears. PCI DSS v4.0.1 clarified that the one-month window applies to critical vulnerabilities, while other applicable patches follow a timeframe set by risk (6.3.3).

Consider a hypothetical example: a payment API uses a library that an advisory rates critical. The risk ranking record, patch ticket, and deployment date show whether the deadline was met, and without a component inventory the team may never learn the library was in use. Structured vulnerability remediation guidance helps teams prioritize fixes and verify closure.

How Do You Protect Public-Facing Web Applications and Payment Pages?

Requirement 6.4.2 requires an automated technical solution that continually detects and prevents web-based attacks on public-facing web applications, and Requirement 6.4.3 requires every payment page script to be authorized, integrity-checked, and inventoried.

For 6.4.2, the solution must sit in front of public-facing applications, run with current protection, generate audit logs, and either block attacks or raise alerts that are investigated immediately. A web application firewall is the usual example, although the requirement does not mandate one product type.

For 6.4.3, follow this sequence:

Inventory every script the browser loads on live payment pages, including tag-manager scripts.
Remove scripts without a business or technical justification.
Record who authorized each remaining script.
Assure integrity with controls such as Content Security Policy and Subresource Integrity.
Add the tamper detection required by Requirement 11.6.1.

The PCI SSC discusses its payment page security guidance for merchants and service providers.

How Does Requirement 6.5 Control Changes to Systems and Software?

Requirement 6.5 requires documented change control so that every change to in-scope systems is approved, tested, and reversible, with security impact assessed before release. Records cover the reason for the change, security impact, authorized approval, testing, and recovery procedures (6.5.1). After significant changes, the organization confirms applicable PCI DSS requirements remain in place (6.5.2). Pre-production stays separated from production, live account numbers stay out of pre-production unless protected as in production, and test data is removed before go-live (6.5.3 to 6.5.6).

What Evidence Do Assessors Expect for Requirement 6?

Assessors expect documented procedures together with records proving the controls operated across the assessment period. Typical requests include:

Training curricula and completion records
Code review records with reviewer, approval, and closure
Risk-ranking records and patch timelines against the one-month window
Component inventory and payment page script inventory with justifications
WAF configurations, coverage maps, audit logs, and alert investigation records
Change tickets with security impact analysis and test results

Time-stamped exports carry more weight than screenshots because they show consistent operation.

What Are the Most Common Requirement 6 Gaps?

Common gaps are incomplete inventories, critical patches that slip past one month, and web protection that exists on paper but is neither enforced nor investigated.

Tag managers let marketing teams add third-party scripts to payment pages without review.
Inventories capture direct dependencies and miss transitive ones.
A WAF covers the main domain but skips APIs or alternate hostnames, or stays in detect-only mode.
Code reviews happen but leave no approval record.
Pre-production databases contain live card numbers.

Independent web application VAPT helps surface weaknesses that code review and automated protection miss.

What Should Organizations Do Next to Strengthen Requirement 6 Compliance?

Organizations should begin with a gap assessment against each Requirement 6 sub-requirement and prioritize the component inventory, payment page scripts, and patch timelines. A practical sequence:

Map in-scope applications, public hostnames, and payment pages.
Build inventories from live sources instead of documentation.
Validate WAF coverage and test alert investigation.
Run application testing and code review on payment-critical software.
Track days to patch critical vulnerabilities and the share of releases with review evidence.

A gap assessment led by a Qualified Security Assessor (QSA), supported by application testing and remediation guidance, turns findings into a prioritized plan that holds up during the Report on Compliance (ROC) or self-assessment.

Test Your Requirement 6 Controls Against PCI DSS v4.0.1 Before Assessment Begins.

Speak with Ampcus Cyber’s PCI DSS specialists about assessing your secure development, patching, web application protection, and payment page script controls.