PCI DSS Requirement 6: secure systems and software

By Sam Rivera, Founder, SentinelPanda · August 6, 2026 · 3 min read · PCI DSS

Requirement 6 is where PCI DSS meets your software delivery process — and where v4.0 added the anti-skimming controls that came out of a decade of Magecart attacks.

Finding and ranking vulnerabilities

Requirement 6.3.1 requires a process to identify security vulnerabilities from reputable external sources and assign a risk ranking to each. The ranking matters because it drives the patching timeline — you need a defined method for deciding what counts as critical or high in your environment, not just a copy of the CVSS score.

Requirement 6.3.2 requires an inventory of bespoke and custom software and third-party components, including those in open-source libraries, to facilitate vulnerability and patch management. In practice this is a software bill of materials, and dependency scanning in CI is the normal implementation.

Patching timelines

Critical and high-severity patches must be installed within one month of release (6.3.3). All other applicable patches go on a defined, appropriate timeline. The one-month clock is measured from vendor release, not from when you noticed — which is why vulnerability identification (6.3.1) has to be a running process rather than a quarterly scan.

Where a patch cannot be applied in time, the compensating control route or the customised approach is available, but both require documentation and assessor agreement. An undocumented exception is simply a missed requirement.

Secure development and change control

• Bespoke and custom software developed securely, based on industry standards and secure coding guidance (6.2.1).
• Developers trained at least annually in secure software design and coding, including how to prevent common vulnerabilities (6.2.2).
• Code reviewed before release to production by someone other than the author, with reviews documented and corrections approved (6.2.3).
• Software engineering techniques preventing or mitigating common attacks — injection, insecure deserialisation, broken access control, and the rest (6.2.4).
• Changes to system components managed through a formal change control process with impact assessment, approval, testing, and rollback (6.5).

Public-facing applications and payment page scripts

Requirement 6.4.2 requires an automated technical solution deployed in front of public-facing web applications to detect and prevent web-based attacks — continually, and generating logs. In v4.0 this replaced the previous option of an annual manual application vulnerability review, so a WAF (or equivalent) is now effectively mandatory for public-facing web apps in scope.

Requirement 6.4.3 is the more consequential addition. Every script loaded and executed in the consumer's browser on a payment page must be authorised, its integrity assured, and an inventory maintained with written business justification for each. This exists because of card-skimming attacks that compromise a third-party script — analytics, chat widgets, tag managers — and harvest card data client-side without touching your servers at all.

Pair it with Requirement 11.6.1, which requires change- and tamper-detection on payment pages. Together they are the standard's answer to Magecart-style attacks, and they are the requirements most likely to require genuine engineering work rather than documentation.