We use essential cookies to run this site. Analytics & marketing cookies load only with your consent — see our Cookie Policy and Privacy Policy.

Talk to an expert
PCI DSS v4.0.1 · Requirement 6 of 12

Requirement 6: Develop and Maintain Secure Systems and Software

Two disciplines in one requirement: fixing known vulnerabilities fast, and not shipping new ones. v4 added the controls e-commerce breaches begged for — an authoritative inventory of payment-page scripts and automated protection for public web applications.

Reviewed by Abhay Singh, PCI SSC-qualified QSA professional · CyberSigma is a PCI SSC-listed QSA company · Part of the Requirement 1–12 series

The controls that decide your assessment

6.2.1–6.2.4
Secure SDLC with trained developers

Bespoke software is built to a documented secure SDLC; developers train in secure coding annually (6.2.2); code is reviewed before release (6.2.3); engineering techniques address common attack classes (6.2.4).

6.3.1
Vulnerability intelligence process

New vulnerabilities are identified via industry sources and risk-ranked — the feed that drives both patching and scanning.

6.3.3
Critical patches within one month

Critical/high security patches installed within one month of release; all others within a TRA-defined window.

6.4.2
Automated protection for public web apps

Public-facing web applications sit behind an automated technical solution that detects and prevents web attacks (in practice a WAF in blocking mode) — mandatory since 31 March 2025, replacing the old "review or WAF" choice.

6.4.3
Payment-page scripts authorised and inventoried

Every script on payment pages is authorised, integrity-assured and inventoried with written justification — the anti-Magecart control, new in v4.

6.5.1–6.5.6
Change control end to end

Changes follow documented procedures: impact, approval, testing, rollback — and pre-production data/accounts never travel to production.

Control numbers reference PCI DSS v4.0.1 (June 2024). Verify wording against the standard itself — PCI SSC document library.

Where programmes actually fail

No payment-page script inventory

E-commerce entities routinely miss 6.4.3 — tag managers and third-party scripts on checkout with no inventory, justification or integrity monitoring.

WAF in monitor-only mode

6.4.2 requires detect AND prevent. A WAF that only alerts fails the control since the March 2025 date.

Patch SLA unmeasured

A policy saying 30 days without a report proving it invites sampling — and sampled hosts rarely cooperate.

Live PAN in the test environment

6.5.5 prohibits production PAN in pre-production; masked or synthetic data only.

Evidence a QSA accepts

A policy document proves intent; configuration proves control. Bring these to the assessment:

  • Patch/vulnerability management reports showing SLA adherence (6.3.3)
  • WAF configuration demonstrating blocking mode on all public web apps
  • Payment-page script inventory with authorisation and integrity mechanism (6.4.3)
  • Secure-coding training records and code-review evidence
  • Change tickets sampled end-to-end: approval, test, rollback

Requirement 6 FAQ

Is a WAF now mandatory?

For public-facing web applications, yes in effect — 6.4.2 requires an automated solution that detects and prevents web-based attacks, continuously. The former annual-review alternative is gone.

What does 6.4.3 mean for our checkout page?

Maintain an inventory of every script that loads on payment pages, written justification for each, and a mechanism (CSP, SRI, monitoring) assuring integrity — including third-party and tag-manager scripts.

How fast must we patch?

Critical and high-security patches within one month of release (6.3.3); other applicable patches within a timeframe your targeted risk analysis defines.

← Requirement 5: Anti-MalwareRequirement 7: Need-to-Know Access →

Requirement 6 in your environment

A PCI SSC-listed QSA firm can tell you in one session whether your controls will survive assessment — before the assessment.