Develop and maintain secure systems
Requirement 6 requires organizations to ensure that all software used within the Cardholder Data Environment (CDE) is developed securely and maintained through rigorous patching and change control. The goal is to prevent attackers from exploiting known vulnerabilities in custom code or third-party applications.
What it means
The intent of this requirement is to minimize the attack surface by eliminating software flaws before they reach production and addressing new vulnerabilities as soon as they are discovered. This applies equally to bespoke software developed in-house and commercial off-the-shelf (COTS) products.
In practice, this requires a shift toward "secure by design." Organizations must move away from reactive patching and instead implement a structured lifecycle that includes secure coding standards, rigorous testing, and a formal process for promoting code from development to production.
PCI DSS v4.0 specifically emphasizes the need for risk-based vulnerability management. This means organizations cannot simply patch everything eventually; they must have a defined timeline—typically one month for critical security patches—to mitigate high-risk threats.
How to meet it
- Establish and document secure coding standards based on industry benchmarks (such as OWASP) and ensure all developers are trained in these practices.
- Implement a formal patch management process that identifies, prioritizes, and installs critical security updates within 30 days of release.
- Separate development, testing, and production environments to ensure that untested code cannot be deployed directly into the CDE.
- Perform vulnerability assessments or manual code reviews on all custom software before it is released into production.
- Maintain an inventory of third-party software components and libraries used in applications to track and update vulnerable dependencies.
- Implement a formal change control process where every modification is documented, tested, and approved by management prior to implementation.
Evidence an auditor asks for
- Patching logs or reports showing the date a critical security patch was released versus the date it was applied to CDE systems.
- Documented secure coding guidelines and records of training completion for the development team.
- Change tickets containing a description of the change, evidence of testing in a non-production environment, and formal approval signatures.
- Reports from Static Analysis (SAST) or Dynamic Analysis (DAST) tools used to validate code security prior to deployment.
Common pitfalls
- Failing to document "emergency changes," where critical fixes are applied quickly but the change control paperwork is forgotten.
- Overlooking third-party libraries and APIs, focusing only on proprietary code while leaving known vulnerabilities in open-source dependencies.
- Applying patches directly to production systems without testing them in a staging environment first, which can lead to system instability or outages.