PCI DSS Requirement 6 Guide: Secure Software in v4.0.1

Requirement 6 is where PCI DSS turns software risk into testable obligations: how in-house code is written and reviewed, how vulnerabilities are ranked and patched, how public-facing web applications are shielded, and how changes reach production. This guide works through PCI DSS v4.0.1 Requirement 6, "Develop and Maintain Secure Systems and Software", section by section: secure development of bespoke and custom software (6.2), vulnerability identification, ranking and patching (6.3), public-facing web applications (6.4) and change management (6.5). It is written for application security leads, platform engineers and PCI programme owners preparing evidence for a Qualified Security Assessor (QSA) or a self-assessment. Payment page scripts (6.4.3) have their own page and are only summarised here. Requirement wording is summarised, not quoted, because the standard is distributed as a PDF through the PCI SSC Document Library; check each value against the current standard before relying on it.

Source note: this page summarises the official text and the sources listed at the end. Confirm against the official text before relying on it.

Key takeaways

Your own ranking drives everything: 6.3.1 requires vulnerabilities to be risk-ranked by impact to the entity, with at least high-risk and critical identified, and PCI SSC FAQ 1597 confirms you may override external scores such as CVSS when your environment justifies it.
Critical patches have a hard clock: 6.3.3 requires patches for critical vulnerabilities within one month of release; every other applicable patch follows a timeframe the entity sets from its own risk assessment.
Bespoke code must resist named attack classes: 6.2.4 lists injection, attacks on data and data structures, cryptography, business logic (including XSS and CSRF), access control, and any high-risk vulnerability from 6.3.1.
6.4.2 replaced 6.4.1: since 31 March 2025 public-facing web applications need an automated technical solution that continually detects and prevents web attacks; FAQ 1593 says 6.4.1 is reported as not applicable after that date.
Change control covers environments and data: 6.5.3 to 6.5.6 require separated pre-production, separated roles, no live PAN outside the CDE and removal of test data and test accounts before go-live.

How Requirement 6 is structured

Requirement 6 sits in the "Maintain a Vulnerability Management Program" goal alongside Requirement 5 (malware). The wider standard is summarised in the PCI DSS 4.0 Guide. Sub-requirement titles below follow the v4.0.1 numbering.

Section	Subject	Sub-requirements	What assessors usually ask for
6.1	Policies, procedures, roles	6.1.1, 6.1.2	Secure development, vulnerability and change procedures with named owners
6.2	Bespoke and custom software developed securely	6.2.1, 6.2.2, 6.2.3, 6.2.3.1, 6.2.4	SDLC documentation, training records, code review records, secure coding standards
6.3	Vulnerabilities identified and addressed	6.3.1, 6.3.2, 6.3.3	Risk ranking method, software and component inventory, patch records with dates
6.4	Public-facing web applications protected	6.4.1 (superseded), 6.4.2, 6.4.3	Web application protection configuration, alert handling, script inventory
6.5	Changes managed securely	6.5.1 to 6.5.6	Change tickets, post-change PCI checks, environment separation, test data controls

"Bespoke and custom software" means software developed by or for the entity, including code written by a third party to the entity's specification. Commercial software bought and used unchanged is not bespoke, but it is still covered by 6.3 (vulnerabilities and patching). If you sell payment software to others, the separate PCI Secure Software Standard and Secure SLC Standard may also apply; see the PCI Secure Software Standard and Secure SLC Guide.

6.2: secure development of bespoke and custom software

6.2.1 secure development: bespoke and custom software is developed according to industry standards or best practice for secure development, with security considered at every stage of the life cycle. A recognised framework gives assessors a reference point: the NIST Secure Software Development Framework (SSDF, SP 800-218) Guide maps cleanly.
6.2.2 training: developers working on bespoke and custom software are trained at least once every 12 months on software security relevant to their role and languages, including secure design, secure coding and the use of any security testing tools.
6.2.3 review before release: code is reviewed before release to production or to customers, to find and correct coding vulnerabilities. Review can be manual, automated (static analysis), or both, and must check adherence to secure coding guidelines and look for both existing and emerging vulnerabilities.
6.2.3.1 manual review independence: where manual code review is used, the review is done by someone other than the author who is knowledgeable in code review and secure coding, and changes are approved by management before release.
6.2.4 attack prevention: engineering techniques are defined and in use to prevent or mitigate common attacks.

6.2.4 attack class	Examples named or implied	Typical control evidence
Injection	SQL, LDAP, XPath, OS command, parameter and object injection	Parameterised queries, ORM rules, SAST rules for taint flows, ASVS V1 encoding requirements
Data and data structures	Buffer, pointer and input data manipulation, shared data	Memory-safe languages or compiler hardening, input validation libraries, fuzzing results
Cryptography	Weak algorithms, cipher suites or modes, poor implementations	Approved crypto library list, banned API rules, key handling reviewed against PCI DSS Requirement 3 Key Management Guide
Business logic	Abuse of features, APIs, client-side functions; XSS and CSRF	Threat models per feature, CSRF tokens, Content Security Policy, abuse-case tests
Access control	Bypass of identification, authentication or authorisation	Central authorisation middleware, object-level authorisation tests, session tests
High-risk vulnerabilities	Anything ranked high-risk under 6.3.1	Feedback loop from 6.3.1 ranking into coding standards and SAST rules

The OWASP ASVS Guide is a practical way to turn 6.2.4 into testable requirements; the Application Security Requirements from ASVS template gives a starting baseline. The McKinsey AI platform hack is a recent reminder that injection in unauthenticated APIs is still found in production.

6.3: vulnerability ranking, inventory and patching

6.3.1 identification and ranking: new vulnerabilities are identified from industry sources, including alerts from international and national CERTs, and each is assigned a risk ranking based on industry best practice and potential impact. PCI SSC FAQ 1597 (May 2025) adds three points worth building into procedure: rankings are based on impact to the entity; at a minimum the method must identify vulnerabilities that are high-risk or critical to the environment; and the entity does not have to accept an external ranking but can evaluate it and assign its own. Write down the rule: for example, CVSS base score as the starting point, raised for exploitation evidence (CISA KEV listing, public exploit) and internet exposure, lowered only with documented compensating conditions. The ranking also applies to bespoke software and to third-party components.

6.3.2 inventory: an inventory of bespoke and custom software and of third-party components incorporated into it is maintained to support vulnerability and patch management. In practice this means a software bill of materials (SBOM) per application, kept current from the build. See the SBOM Guide and the SBOM operations page for keeping one usable.

6.3.3 patching: all system components are protected from known vulnerabilities by installing applicable patches. FAQ 1597 restates the two clocks:

Ranking (from 6.3.1)	Patch timeframe	Where it comes from	Evidence
Critical	Within one month of release	Fixed by 6.3.3	Release date and install date per component
High-risk	Entity-defined, faster than lower ranks	Entity risk assessment; FAQ 1597 says timeframes should follow the ranking	Documented SLA and records showing it was met
Medium and low	Entity-defined	Entity risk assessment	Documented SLA, exception register

FAQ 1597 also distinguishes "resolved" (the vulnerability is fixed) from "addressed" (the entity decides whether to fix it or reduce the risk another way, such as a compensating control or disabling the vulnerable service). Critical and high-risk findings from internal scans must be resolved under 11.3.1; lower-ranked ones are addressed per a targeted risk analysis under 11.3.1.1. Scanning itself sits in the PCI DSS Requirement 11 Guide. For patch operations see the Patch Management Guide and, for urgent cases, the Emergency Out-of-Band Patching Playbook.

6.4: public-facing web applications

6.4.1 (superseded): allowed either regular application vulnerability assessments or an automated technical solution. PCI SSC FAQ 1593 (March 2025) lists 6.4.1 as superseded by 6.4.2 and says superseded requirements are marked "Not Applicable" in a Report on Compliance or SAQ after 31 March 2025.

6.4.2 automated technical solution: for public-facing web applications, an automated technical solution is deployed that continually detects and prevents web-based attacks. Assessors typically look for four properties: it sits in front of every in-scope public-facing application, it is configured to block attacks or to generate an alert that is immediately investigated, it generates audit logs, and it is kept up to date with current threats. A web application firewall (WAF) or web application and API protection (WAAP) service is the common choice. The Capital One breach shows the other side: the protective layer itself was misconfigured and its cloud role credentials were the prize, so treat the WAF as an in-scope, hardened component. See Securing the web application firewall (WAF) itself.

6.4.3 payment page scripts: scripts loaded in the consumer's browser on payment pages are inventoried, authorised with a business justification and integrity-checked. This pairs with 11.6.1 and is covered in depth in the PCI DSS for E-commerce Payment Page Scripts Guide.

6.5: change management and environment separation

Sub-requirement	Obligation in short	Common evidence
6.5.1	Production changes follow established procedures: reason and description, security impact, authorised approval, testing that the change does not harm security, and back-out procedures; for bespoke software, compliance with 6.2.4 is tested before deployment	Change tickets with approver, test results, rollback plan
6.5.2	After a significant change, all applicable PCI DSS requirements are confirmed on new or changed systems and documentation is updated	Post-change checklist: hardening, logging, scanning, scope diagram updated
6.5.3	Pre-production is separated from production and the separation is enforced with access controls	Separate accounts or subscriptions, network rules, access lists
6.5.4	Roles and functions are separated between production and pre-production so only reviewed and approved changes are deployed	Pipeline approvals, deployer roles distinct from developers
6.5.5	Live PANs are not used in pre-production unless that environment is in the CDE and fully protected	Test card data policy, data discovery scans of test stores
6.5.6	Test data and test accounts are removed before a system goes into production	Go-live checklist, account reviews

Forgotten test identities are a recurring breach pattern: the Microsoft Midnight Blizzard breach began with a legacy test tenant account. General change practice is in the Change Management Security guide and the Change Management Policy Template.

Where identity fits

6.5.4 is, in modern delivery, an identity question. In CI/CD the deployer is usually a pipeline service account or workload identity, not a person. Separation of duties holds only if that identity can deploy nothing that has not passed review, cannot be used interactively by developers, and has no standing write access to production outside the pipeline. Build secrets and deploy keys must not live in source code (6.2.4 and Requirement 8 both bite here). See the PCI DSS Requirements for Service Accounts and NHIs Guide (8.6).

Decision guidance

Manual review or automated review for 6.2.3: automated SAST scales and gives consistent evidence; manual review catches business logic flaws that tools miss. Most mature programmes use SAST on every merge and manual review for security-sensitive changes (authentication, payment flows, cryptography). If you rely on manual review, 6.2.3.1 independence and approval apply. AI-assisted review can add coverage but needs the same evidence trail; see the AI-Assisted Code Review and AI SAST Guide.
Accept or override CVSS: overriding downward is allowed but must be justified in writing per finding; overriding upward for KEV-listed or internet-exposed issues is the safer default.
WAF or RASP for 6.4.2: an edge WAF or WAAP covers many applications quickly; runtime protection inside the application sees more context but needs per-application deployment. Either can meet 6.4.2 if it detects and prevents continually, logs and stays current.
Small merchants: if you run no bespoke software, 6.2 may not apply, but 6.3 still does. Hosted payment pages move most of 6.4 to the provider; confirm the split in the responsibility matrix.
Large or multi-team organisations: standardise one pipeline template with mandatory SAST, dependency scanning, SBOM generation and approval gates, so each team inherits 6.2, 6.3.2 and 6.5.4 evidence instead of building it.

How to implement Requirement 6

Scope the software: list every bespoke application and every public-facing web application in or connected to the CDE. Agree with the assessor which are in scope.
Write the ranking rule (6.3.1): sources monitored, scoring inputs, override rules, and the patch SLA per rank (6.3.3). Get it approved as part of 6.1.1 procedures.
Build inventory from the pipeline (6.3.2): generate an SBOM on every build and feed it to dependency alerting, so component vulnerabilities reach the 6.3.1 process automatically.
Add gates in report mode first: turn on SAST and dependency scanning in report-only mode for one release cycle, tune false positives, then make high-risk and critical findings block the merge. Keep an exception path with expiry dates.
Deploy 6.4.2 protection in detection mode, then blocking: run the WAF or WAAP in alert mode against production traffic, tune rules, then switch to blocking application by application. Keep a documented rollback to alert mode for false-positive incidents, with every alert investigated while in that mode.
Harden the change path (6.5): separate pre-production accounts, restrict deployer identities, add a post-change PCI checklist for significant changes, and add test data and test account removal to the go-live checklist.
Train and record (6.2.2): annual role-specific secure coding training with completion records per developer, including contractors writing bespoke code.

Detection and measurement

Critical patch compliance: percentage of critical-ranked patches installed within one month of release, per platform. Target 100 per cent; every miss needs a recorded reason.
Median time to remediate by rank: compared with your own SLA for high, medium and low.
Pipeline coverage: share of bespoke applications whose builds run SAST, dependency scanning and SBOM generation.
Override rate: number of downward ranking overrides per quarter, reviewed for drift.
6.4.2 alert handling: time from alert to investigation for applications in alert mode, and share of public-facing applications in blocking mode.
Change hygiene: changes deployed without an approved ticket (target zero), and test accounts found in production during reviews.

Log the protective layers too: WAF policy changes, pipeline approval bypasses and deployer identity sign-ins belong in the Requirement 10 review set. See the PCI DSS Requirement 10 Guide.

Framework mapping

PCI DSS	NIST SP 800-53 Rev 5	NIST CSF 2.0	ISO/IEC 27001:2022 Annex A	CIS Controls v8.1
6.2.1 to 6.2.4	SA-3, SA-8, SA-11, SA-15	PR.PS-06	A.8.25, A.8.26, A.8.28, A.8.29	Control 16
6.3.1, 6.3.3	RA-5, SI-2	ID.RA-01, PR.PS-02	A.8.8	Control 7
6.3.2	CM-8, SR-4	ID.AM-02	A.5.9	Controls 2 and 16
6.4.2	SC-7, SI-4	PR.IR-01, DE.CM-01	A.8.20, A.8.26	Control 13
6.5.1 to 6.5.6	CM-3, CM-4, AC-5	PR.PS-02	A.8.31, A.8.32, A.8.33	Control 16

The main attack technique Requirement 6 counters is MITRE ATT&CK T1190 Exploit Public-Facing Application; weak build and dependency controls also expose you to T1195.002 Compromise Software Supply Chain. A full PCI to ISO mapping is in the PCI DSS 4.0 to ISO 27001 Mapping Guide.

Common failure patterns

Ranking by CVSS alone: a scanner score copied into tickets is not a 6.3.1 method. Without a documented rule there is nothing for the assessor to test, and exploited medium-scored issues slip through.
The one-month clock starts at release, not discovery: teams that measure from scan date routinely miss 6.3.3 for critical patches.
Patching without hunting: on edge and collaboration servers, attackers may already have persisted. In ToolShell stolen ASP.NET machine keys kept attackers inside after patching; critical patch procedures should include compromise checks and key rotation where advised.
Inventory without components: listing applications but not their third-party libraries leaves 6.3.2 half done and dependency vulnerabilities invisible.
WAF in permanent alert mode with nobody reading alerts: 6.4.2 accepts alerting only when alerts are immediately investigated.
Developers holding production deploy rights "for emergencies": this defeats 6.5.4; use a break-glass path with logging and after-the-fact review instead.

Practitioner checklist

Document which applications are bespoke or custom and which are public-facing, in scope or connected.
Publish a 6.3.1 ranking method with override rules and a patch SLA per rank, with critical at one month.
Generate and retain an SBOM for every bespoke application build (6.3.2).
Run SAST and dependency scanning on every merge and keep review records (6.2.3, 6.2.3.1).
Map coding standards and tests to each 6.2.4 attack class.
Place every public-facing application behind a maintained, logging 6.4.2 solution and track blocking coverage.
Require change tickets with security impact, testing and back-out for production changes (6.5.1), plus a post-change PCI check for significant changes (6.5.2).
Enforce environment separation, deployer identity separation, no live PAN in test and test account removal (6.5.3 to 6.5.6).
Record annual secure coding training for every developer of bespoke code (6.2.2).

Standards and references

Related NHI Mgmt Group resources: PCI DSS 4.0 Guide, PCI DSS Readiness Checklist, PCI DSS Customised Approach and Targeted Risk Analysis Guide, CIS Control 7 Continuous Vulnerability Management Guide, NIST SP 800-40 Rev 4 Patch Management Guide. This guide summarises PCI DSS v4.0.1 Requirement 6 and is not legal or assessment advice.

PCI DSS Requirement 6 Guide: Secure Software, Patching and Change Control in v4.0.1