PCI DSS Requirement 6: What Is It & How to Comply?

What is PCI DSS Requirement 6?

PCI DSS Requirement 6 suggests that businesses should ensure that all systems and applications developed or used by the company are secured. This requirement also deals with patch management and addressing vulnerabilities.

By implementing watertight coding standards that are regularly reviewed, especially when it comes to your application environment, you can protect your business from experiencing an attack or a breach.

{{snapshot}}

What Requirement 6 covers

• Ensure all systems and applications developed or used by the company are secured.
• It deals with patch management and addressing vulnerabilities as they emerge.
• Watertight, regularly reviewed coding standards help protect against attacks and breaches.

{{/snapshot}}

PCI DSS 6.1: Rank vulnerabilities based on severity.

This requirement calls for companies to establish processes for identifying and addressing vulnerabilities that may impact the security of their internal systems and applications.

Verified outside sources, such as the Common Vulnerabilities and Exposures (CVE) list, would need to inform how these vulnerabilities are addressed. This also requests that companies assign risk rankings in order of severity (low, medium, high) to all vulnerabilities that have been identified.

An external assessor will also interview the relevant personnel to confirm that the controls are being performed correctly.

PCI DSS 6.2: Patches need to be applied for all known security vulnerabilities.

Businesses must ensure they are protected against all known vulnerabilities by installing security patches as soon as they’re made available by vendors. These critical patches cannot be installed any later than a month after their production, and necessity will depend on the affected network’s risk ranking.

As with PCI DSS Requirement 6.1., a qualified assessor will also need to scan a sample of the business’ system components. These results will be cross-referenced with your vendors’ lists of relevant and available patches so that they can be installed in the right time frame.

PCI DSS 6.3: Develop all apps securely.

This requirement calls for the secure development of internal, external and web apps through the following sub-sub requirements:

• PCI DSS 6.3.1 – Remove all accounts and settings created for either development or testing purposes before making apps or software usable by clients or publicly available.
• PCI DSS 6.3.2 – Review all custom code for vulnerabilities, whether manually or through an automation process, before making apps or software usable by clients or publicly available.

{{snapshot}}

Ranking, patching, and secure development

• Rank vulnerabilities by severity — low, medium, high — informed by verified sources like the CVE list.
• Install critical security patches within a month of a vendor release, based on the network’s risk ranking.
• Before release, remove development and test accounts and review all custom code for vulnerabilities.

{{/snapshot}}

PCI DSS 6.4: Install processes and procedures for change control.

Companies must ensure all relevant personnel follow change control procedures, including:

• PCI DSS 6.4.1 – Separate all development or test environments from production environments.
• PCI DSS 6.4.2 – Separate the duties between development and production environments.
• PCI DSS 6.4.3 – Ensure all production data is not used for development or testing.
• PCI DSS 6.4.4 – Remove any test-related data from all components before activation.
• PCI DSS 6.4.5 – Implement the change control procedures, which include:

• Documentation of change impact and approval.
• Testing of functionality and back-out procedures.

• PCI DSS 6.4.6 – Implement all PCI DSS Requirements once changes have been made.

PCI DSS 6.5: Address all frequent development vulnerabilities.

This sub-requirement covers the controls for mitigating the most frequent vulnerabilities in coding.

{{snapshot}}

Change control and common flaws

• Separate development, test, and production environments and never use production data for testing.
• Follow change control: document impact and approval, test functionality, and keep back-out procedures.
• Review public web apps at least annually and guard against injection, XSS, and CSRF.

{{/snapshot}}

PCI DSS 6.6: Adjust for New and Known Threats in Web Apps

PCI DSS Requirement 6.6 requires that businesses review all publicly available web applications to ensure that external users do not become victims of threats. These reviews should be either automated or manual but will need to be performed annually.

Your business may also be able to install an automated detection or prevention solution for your web apps to monitor traffic.

PCI DSS 6.7: Document all system and application controls.

As with all other PCI DSS requirements, you will also need to formally document this process. This will need to be in use throughout the company and with stakeholders who will also need to comply with the sub-requirements.

{{snapshot}}

In Hicomply's experience

Requirement 6 spans your whole software lifecycle — vulnerability ranking, patch SLAs, secure coding, and change control — so the evidence sits with engineering, not just compliance. We find it stays manageable when secure-development controls are mapped once and reused across frameworks like ISO 27001, with patch and change records collected continuously. A platform tour shows how, and our free compliance tools help you scope it.

{{/snapshot}}

Achieve PCI DSS compliance with Hicomply

If you’re looking to meet all the PCI DSS requirements, including PCI DSS Requirement 6, we can help. At Hicomply, we know that the process can seem long-winded and confusing, which is why we offer a full ISMS solution that allows you to keep everything you need to achieve certification in one place. Contact us today for a demo.