Requirement 6: Develop and Maintain Secure Systems and Software

PCI DSS v4.0.1 Requirement 6: secure development, patching timelines, public-facing web application protection and the 6.4.3 payment page script controls.

PCIComplianceHubLast updated Last reviewed against PCI DSS v4.0.1

Requirement 6 covers how software gets built, patched and changed. It also contains 6.4.3, one of the two controls written specifically in response to digital skimming.

PCI DSS v4.0.1 breaks this requirement into 5 sections containing 19 individual controls.

What this requirement is actually asking

Critical patches must be installed within one month (6.3.3). The clock starts at vendor release, not at the point you noticed, which is why vulnerability intake (6.3.1) is a named control in its own right.

6.4.3 is the one to read carefully if you take payments in a browser. Every script loaded on a payment page must be authorised, its integrity assured, and an inventory maintained with a written business or technical justification. If you embed a payment provider's form in an iframe, the scripts on your own page are yours to manage and the scripts inside the provider's form are the provider's. Combined with 11.6.1 it is the standard's answer to Magecart-style attacks, and it became mandatory on 31 March 2025.

Does it apply to you?

Applies to all system components: vulnerability management and patching (6.3) and change management (6.5) cover everything in scope. Secure development (6.2) applies only to bespoke and custom software on components in or connected to the CDE, and 6.4 to public-facing web applications regardless of who wrote them.

The controls

Requirement 6 contains 19 controls across 5 sections. Each links to its own page with the requirement in full and the testing procedures an assessor uses to verify it.

6.1: Governance for secure development and maintenance

Control What it requires Guidance
6.1.1 All security policies and operational procedures that are identified in Requirement 6… Yes
6.1.2 Roles and responsibilities for performing activities in Requirement 6 are documented, assigned… Yes

6.2: Bespoke and custom software developed securely, including developer training and code review

Control What it requires Guidance
6.2.1 Bespoke and custom software are developed securely… Yes
6.2.2 Software development personnel working on bespoke and custom software are trained at least once… Yes
6.2.3 Bespoke and custom software is reviewed prior to being released into production… Yes
6.2.3.1 If manual code reviews are performed for bespoke and custom software prior to release… Yes
6.2.4 Software engineering techniques or other methods are defined and in use by software development… Yes

6.3: Identifying and fixing vulnerabilities, with defined patch timelines

Control What it requires Guidance
6.3.1 Security vulnerabilities are identified and managed… Yes
6.3.2 An inventory of bespoke and custom software, and third-party software components incorporated… Yes
6.3.3 All system components are protected from known vulnerabilities by installing applicable… Yes

6.4: Public-facing web applications, including the 6.4.3 payment page script controls

Control What it requires Guidance
6.4.1 For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing… Yes
6.4.2 For public-facing web applications, an automated technical solution is deployed… Yes
6.4.3 All payment page scripts that are loaded and executed in the consumer’s browser… Yes

6.5: Change management across all system components

Control What it requires Guidance
6.5.1 Changes to all system components in the production environment are made according… Yes
6.5.2 Upon completion of a significant change, all applicable PCI DSS requirements are confirmed… Yes
6.5.3 Pre-production environments are separated from production environments and the separation… Yes
6.5.4 Roles and functions are separated between production and pre-production environments to provide… Yes
6.5.5 Live PANs are not used in pre-production environments… Yes
6.5.6 Test data and test accounts are removed from system components before the system goes into… Yes

Evidence your assessor will ask for

  • A script inventory for every payment page, each entry with a written business justification and an integrity method
  • Vulnerability intake records showing sources monitored and severity assigned
  • Patch records showing patches for critical vulnerabilities installed within one month of release, and the risk ranking behind the timeframe for all other patches
  • Change tickets showing testing and approval before production

Where this commonly fails

  • Treating 6.4.3 as done because a WAF is deployed. The control is about script authorisation and integrity, not filtering
  • Third-party tag managers that can inject arbitrary scripts into a payment page, which defeats the inventory
  • Patch timelines measured from ticket creation rather than vendor release

Terms

Glossary entries that name a control in this requirement:

Official source

The commentary on this page is our own. The requirement title, and the control text in the tables above (shortened where it ends in an ellipsis), are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. Each control's own page carries its requirement text in full. For the authoritative wording, including each testing procedure and the customized approach objective, download the standard from the PCI Security Standards Council document library.

PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site.