Requirement 6 of PCI DSS asks you to keep every system and piece of software in your card data environment free of known security holes. For every business, that means watching for new vulnerabilities, ranking them by risk, installing patches for critical vulnerabilities within one month, and controlling changes to production systems. If you write or customize software, such as a website that takes payments or an API, it also asks for secure development, developer training, code review, and protection for public-facing web applications.
Which parts apply if I don't write software?
More than you might think. The parts on vulnerabilities, patching, and change control apply to everyone. Every business has to track new vulnerabilities, rank them, and patch on time. Every business has to control changes to production systems and keep test systems apart from live ones. And any business with a public-facing web application or a payment page has to protect it, even if a developer or agency built it for you. Code repositories that hold application code or system configuration that could affect the security of card data are in scope too.
How fast do security patches need to go on?
Requirement 6.3.1 asks you to identify new security vulnerabilities from reputable sources, such as the Microsoft Security Update Guide, Cisco Security Advisories, and alerts from computer emergency response teams (CERTs). Each one gets a risk ranking, such as critical, high, medium, or low, based on how serious it is. Requirement 6.3.3 says patches for critical vulnerabilities must be installed within one month of release. All other patches go on within a timeframe you set based on risk. This covers every piece of software, including plugins, not just the operating system.
What does change control require?
Requirement 6.5.1 says changes to production systems follow a documented procedure that records the reason for the change, its security impact, documented approval, testing to confirm it doesn't weaken security, and a way to get back to a secure state if it fails. Requirement 6.5.2 says that after a significant change, you confirm all the relevant PCI DSS requirements are still in place. Requirements 6.5.3 and 6.5.4 keep test and development environments separate from production, and keep roles apart so that only reviewed and approved changes go live. Requirement 6.5.5 says real card numbers aren't used in test environments unless those environments are themselves inside the card data environment and protected to the same standard. Requirement 6.5.6 says test data and test accounts are removed before a system goes into production.
What does secure development require?
If you build or customize software, Requirement 6.2.1 says it must be developed securely, based on industry standards and best practices. Requirement 6.2.2 says developers are trained at least once every 12 months on software security relevant to their job and the languages they use, including secure design, secure coding, and how to use security testing tools. Requirement 6.2.3 says custom code is reviewed before release to find and fix vulnerabilities. If that review is manual, Requirement 6.2.3.1 says it is done by someone other than the author who knows code review techniques, and is approved by management before release. Requirement 6.2.4 asks for techniques that prevent common attacks, such as injection, cross-site scripting, broken access control, and misuse of cryptography. The OWASP Top Ten and the CWE Top 25 are good places to start.
How must public-facing web applications be protected?
Since 31 March 2025, Requirement 6.4.2 says public-facing web applications must sit behind an automated technical solution, such as a web application firewall (WAF), that continually detects and prevents web-based attacks. It must be installed in front of the application, actively running, kept up to date, generating audit logs, and set to either block attacks or raise an alert that is investigated right away. A yearly vulnerability assessment of the application, which used to be an alternative under Requirement 6.4.1, no longer meets it.
What does Requirement 6.4.3 ask for on payment pages?
A payment page often loads scripts from many places: analytics, tag managers, chat widgets, and your payment provider's own library. Any of them could be changed to steal card numbers as they are typed. Since 31 March 2025, Requirement 6.4.3 says every script on a payment page that runs in the shopper's browser must be authorized, have its integrity assured, and be listed in an inventory with a written business or technical reason for it. Requirement 11.6.1 adds a way to detect unauthorized changes to the page and its security headers. Our guide to your payment page and Requirement 6.4.3 explains what that looks like in practice.
What else became mandatory after 31 March 2025?
Requirement 6.3.2 asks for an inventory of your custom software and the third-party components built into it, such as libraries and frameworks. When a flaw turns up in a popular open source library, this list tells you which of your applications need patching.
How does an ASV scan help with Requirement 6?
A quarterly external scan under Requirement 11.3.2 checks your public systems against known vulnerabilities, so it is a regular test of whether your patching under 6.3.3 is actually working. Unpatched software is the single biggest reason scans fail. ServerScan is a PCI Approved Scanning Vendor, and rescans are unlimited on every plan, so you can patch and confirm the fix the same day. Our guide to common scan failures covers the usual fixes, and the pricing page shows what a plan includes.
Go on to Requirement 7 - Restricted Access.
Go back to Requirement 5 - Anti Virus and Malware.