Requirement 6: Develop and Maintain Secure Systems and Software

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 written justification. 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 bespoke and custom software you develop, and 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 demonstrating the one-month timeline for critical items, with exceptions justified
• 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

Official source

This page is original commentary. It cites requirement identifiers and the official requirement title, and does not reproduce the text of the standard. For the authoritative wording, including each testing procedure and the customized approach objective, download PCI DSS v4.0.1 (June 2024) 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.