Welcome back to our series on PCI DSS Requirement Changes from v3.2.1 to v4.0. Today, we’re discussing Requirement 6, which is crucial for protecting cardholder data. It mandates the use of vendor-supplied security patches and secure coding practices for in-house developed applications. These measures help mitigate vulnerabilities that hackers could exploit. The requirement also emphasizes the importance of vigilance in identifying and remediating vulnerabilities. So, let’s get started! To learn more about the other requirements of PCI DSS, check out our comprehensive guide on the “12 requirements of PCI DSS.”
Below, we provide an explanation of the changes made in Requirement 6 from v3.2.1 to v4.0:
| PCI DSS v3.2.1 | PCI DSS v4.0 |
|---|---|
| Requirement 6.3 focused on the development of both internal and external software applications, including web-based administrative access to applications. | In PCI DSS v4.0, Requirement 6.2.1 focuses on secure development of “bespoke and custom software”, replacing the terms “internal and external”. |
| - 6.3.a: Verify that software-development processes align with industry standards/best practices. | - The software should be developed based on industry standards and/or best practices for secure development. |
| - 6.3.b: Ensure information security is integrated throughout the development life cycle. | - The development should be in accordance with PCI DSS (Payment Card Industry Data Security Standard). This includes aspects like secure authentication and logging. |
| - 6.3.c: Confirm that software applications comply with PCI DSS. | - Information security issues should be considered during each stage of the software development lifecycle. |
| - 6.3.d: Interview developers to ensure these processes are implemented. | - The requirement mandates that software development procedures must be documented and examined to ensure that all security considerations are integrated into every stage of the development process. This ensures a clear documentation trail of security practices. |
| PCI DSS v3.2.1 | PCI DSS v4.0 |
|---|---|
| Requirement 6.5 addressed common coding vulnerabilities in software-development processes. | The updated requirement of PCI DSS v4.0 is now 6.2.2. |
| - It required developers to be trained at least annually in up-to-date secure coding techniques, including how to avoid common coding vulnerabilities. | It focuses on "bespoke and custom software" and mandates annual training for developers working on such projects. |
| -It also required applications to be developed based on secure coding guidelines. | This training covers software security related to their roles, development languages, secure design, and coding techniques. |
| -The verification process involved examining software-development policies and procedures, records of training, and verifying that processes are in place to protect applications from certain vulnerabilities. | Additionally, it includes learning how to use security testing tools for detecting software vulnerabilities. |
| The verification process involves checking development procedures, training records, and interviewing personnel to ensure relevant training in line with job functions and languages. |
| PCI DSS v3.2.1 | PCI DSS v4.0 |
|---|---|
| PCI DSS v3.2.1 Requirement 6.3.2 mandated review of custom code before release to identify potential vulnerabilities. | PCI DSS v4.0, Requirement 6.3.2 is renumbered to 6.2.3 with a new sub-requirement 6.2.3.1 for manual code reviews. |
| - It required code changes to be reviewed by others than the author, following secure coding practices. | It now specifically targets “bespoke and custom software” for review before release to identify and correct potential coding vulnerabilities. |
| - Code had to adhere to secure coding guidelines and any corrections were to be made before release. | - Code reviews still follow secure coding guidelines and look for both existing and emerging software vulnerabilities. |
| - The results of the code review had to be approved by management. | - Corrections are implemented before release. |
| - Verification involved examining software-development procedures and interviewing personnel. | - Verification involves examining procedures, evidence of changes, and interviewing personnel. - Manual code reviews have similar requirements under 6.2.3.1. |
| PCI DSS v3.2.1 | PCI DSS v4.0 |
|---|---|
| PCI DSS v3.2.1 Requirement 6.5.1 – 6.5.10 | PCI DSS v4.0 Requirement 6.2.4 emphasizes a holistic approach to software security, requiring organizations to prevent: |
| 6.5.1 Injection Flaws: | Injection Attacks: |
| - Prevent attacks where hackers modify code in your system with bad data. | - Prevent attackers from sneaking malicious commands into your system by masquerading them as normal data (e.g., injecting SQL code into a website form). |
| - Validate all user input to block tampering attempts. | Attacks on Data Structures: |
| - Use database safeguards (parameterized queries) to stop injections. | - Prevent attackers from manipulating memory in ways that allow them to run unauthorized code (e.g., buffer overflows). |
| 6.5.2 Buffer Overflows: | Attacks on Cryptography Usage: |
| - Prevent memory misuse attackers can exploit to run malicious code. | - Protect against attempts to break weak encryption, flawed implementations, or exploit vulnerable cryptographic modes. |
| - Check memory boundaries when handling data. | Attacks on Business Logic: |
| - Limit the length of data your system accepts. | - Prevent attackers from abusing application functions designed for normal use (e.g., manipulating client-side web code, circumventing API safeguards, exploiting features beyond their intended purposes). This includes attacks like XSS and CSRF. |
| 6.5.3 Insecure Cryptographic Storage: | Attacks on Access Control: |
| - Protect encryption keys and sensitive data they can access. | - Securely implement login systems, permissions checks, and any mechanism responsible for granting users access - attackers exploit flaws here to gain unauthorized control. |
| - Use strong encryption, prevent flawed implementations. | High-Risk Vulnerabilities: |
| 6.5.5 Improper Error Handling: | - Prevent any serious weaknesses known within your system as discovered in the vulnerability process outlined in Requirement 6.3.1. |
| - Don't give away system details with specific error messages. | |
| - Show users generic errors to prevent information leaks attackers can exploit. | |
| 6.5.6 High-Risk Vulnerabilities: | |
| - Fix serious weaknesses ASAP that attackers could use to harm your system. | |
| - Identify weaknesses: See PCI DSS Requirement 6.1 for this process. | |
| 6.5.7 Cross-Site Scripting (XSS): | |
| - Stop attackers injecting code into your websites that can harm users. | |
| - Validate and sanitize data coming from users, don't include it directly. | |
| 6.5.8 Improper Access Control: | |
| - Prevent unauthorized access to system data and functions. | |
| - Check user rights at every access point. | |
| - Secure file and code to stop users bypassing website checks. | |
| 6.5.9 Cross-Site Request Forgery (CSRF): | |
| - Stop websites tricking users into performing actions they don't mean to. | |
| - Don't rely solely on cookies for authorization, add further checks. | |
| 6.5.10 Broken Authentication and Session Management: | |
| - Protect user sessions from hijacking. | |
| - Secure cookies, prevent exposing session IDs, timeout inactive sessions. |
Organizations are required to maintain documented procedures that ensure their developers are well-versed in understanding potential threats. Moreover, developers should actively employ techniques to counter these threats in the software they build.
In a broader perspective, version 4.0 mandates a flexible, risk-based approach to software security. This approach should be tailored to the organization’s unique environment and associated risks. The primary objective is to address common software vulnerabilities throughout the development process.
| PCI DSS v3.2.1 | PCI DSS v4.0 |
|---|---|
| Requirement 6.1: Organizations need to have a system in place where they can spot and rank security issues. They should be using trustworthy sources for this. And to make sure everything is on track; they should check their policies and have a chat with the people responsible. | Requirement 6.3.1: Expands on v3.2.1’s Requirement 6.1 by specifying sources for identifying new security vulnerabilities, including alerts from CERTs. Introduces a risk ranking system for all high-risk or critical vulnerabilities. Now covers vulnerabilities for bespoke, custom, and third-party software. |
| Requirement 6.2: Organizations need to shield their systems from known issues by using patches provided by the vendor. And if a patch is critical, they should be installing it within a month. To ensure this is happening, they should be checking their policies and doing some system checks. | Requirement 6.3.2: New requirement for maintaining an inventory of bespoke, custom, and third-party software components. This inventory aids in vulnerability and patch management. |
| Requirement 6.3.3: Builds on v3.2.1’s Requirement 6.2 by specifying that all system components must be protected from known vulnerabilities by installing applicable security patches/updates within set timelines. |
The requirement 6.3 of PCI DSS v4.0 provides more detailed guidelines for identifying and managing security vulnerabilities, maintaining software inventories, and installing security patches/updates. It expands the scope to include bespoke, custom, and third-party software components.
| PCI DSS v3.2.1 | PCI DSS v4.0 |
|---|---|
| Requirement 6.6 focused on addressing new threats and vulnerabilities. | Requirement 6.4.1 builds upon this by introducing more specific guidelines: |
| - It required either a manual or automated application vulnerability security assessment at least annually and after any changes, or the installation of an automated technical solution that continually checks all traffic. | - The frequency of reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods is now specified to be at least once every 12 months and after significant changes. |
| - The requirement now explicitly states that the review should be conducted by an entity that specializes in application security. | |
| - It includes, at a minimum, all common software attacks in Requirement 6.2.4. | |
| - All vulnerabilities must now be ranked according to Requirement 6.3.1. | |
| - All vulnerabilities must be corrected, and the application must be re-evaluated after the corrections. | |
| - If an automated technical solution is installed that continually detects and prevents web-based attacks, it must be actively running and up to date, generate audit logs, and be configured to either block web-based attacks or generate an alert that is immediately investigated. |
| PCI DSS v3.2.1 | PCI DSS v4.0 |
|---|---|
| Requirement 6.3.1: Before activating or releasing an application, all development-related accounts, user IDs, and passwords must be removed to prevent misuse. | Requiement 6.5.1: All production system changes must follow documented procedures. These procedures must ensure: - Clear change justification & description. - Documented analysis of security risks introduced by the change. - Authorization by approved personnel. - Testing to prevent security compromise from the change. - For custom code: Verification of compliance with Requirement 6.2.4 (secure coding practices). - Processes to handle failures, ensuring a return to secure operation. |
| 6.4: Organizations must have strict change control procedures, which ensure | 6.5.2: When significant system changes occur, organizations must: Re-verify that they comply with all relevant PCI DSS requirements Update all documentation to accurately represent the changed systems |
| - 6.4.1: Development/test environments are strictly isolated from production systems with access controls preventing unauthorized transitions. | 6.5.3: Production (handling live card data) must be strictly isolated from pre-production (dev/test) environments. This separation is enforced via access controls. |
| - 6.4.2: Personnel in development/test roles are different from those in production, enforcing accountability. | 6.5.4: Different personnel must manage production vs. pre-production environments. This promotes accountability so unauthorized changes don't reach production. |
| - 6.4.3: Live card data (PANs) are never used in development/test environments to prevent compromise. | 6.5.5: Live PANs (card numbers) should never be used in pre-production, as this risks data exposure. Exception: When a pre-production environment is fully secured within the Cardholder Data Environment (CDE) in line with all PCI DSS rules. |
| - 6.4.4: All test data and test accounts are removed before a system goes into production to prevent lingering vulnerabilities. | 6.5.6: It's essential to remove all test data and test accounts from systems before transitioning them into production to prevent later security lapses. |
| - 6.4.5: Documented change control procedures must include these elements to track and secure all changes: * Reason for the change and a full description * Analysis of security impact before implementation * Approval by authorized personnel only * Testing to ensure change doesn't weaken security * Procedures for rolling back a change if it causes problems | |
| - 6.4.6: After major changes, the system MUST be re-verified for compliance with all applicable PCI DSS rules with updated documentation. |
PCI DSS v4.0 requirement 6.5 introduces several important changes aimed at improving security for organizations involved in handling cardholder data:
- Expanded Change Control: All system changes must follow secure, robust procedures.
- Compliance Re-verification: After significant changes, systems must be checked against all relevant PCI DSS standards.
- Enforced Isolation: Stricter separation between development/test and production environments.
- Accountability Focus: Separate personnel managing different environments promote responsibility.
New Requirements:
PCI DSS Requirement 6.1.2
This requirement ensures everyone involved in security-related tasks knows their exact role and what’s expected of them. (It should be implemented immediately for v4.0 Assessments and it’s applicable to all entities.)
- Clear job descriptions should outline security responsibilities.
- Assign appropriate personnel to these roles officially.
- Communicate with staff to ensure they comprehend their security duties.
PCI DSS Requirement 6.3.2:
You need to track all the software you use, especially custom-made software, to fix security issues quickly. (This requirement is a best practice until 31 March 2025.)
- Maintain a comprehensive software list, encompassing custom and third-party components.
- Regularly review it for security vulnerabilities, applying patches.
- Compare the list with official documentation to ensure accuracy and completeness.
PCI DSS Requirement 6.4.2:
Protect your website from online attacks with specialized software. (This requirement is a best practice until 31 March 2025.)
- Employ specialized software, such as a Web Application Firewall (WAF), to safeguard against web attacks.
- Deploy it for public-facing websites.
- Keep the software running and up to date, logging its detections.
- Configure it for either automatic blocking or immediate alerts for investigation.
Requirement 6.4.3:
Control the scripts running on your payment pages to keep them secure. (This requirement is a best practice until 31 March 2025.)
- Establish clear guidelines for authorized scripts on payment pages.
- Verify scripts’ integrity and maintain a list with justifications for each script’s necessity.
- Implement official script management procedures within the company.
- Monitor staff adherence through interviews and record checks.
We have summarized all the PCI DSS Requirement 6 changes from Version 3.2.1 to 4.0 in this video
Also Read:
Conclusion:
In summary, PCI DSS v4.0 Requirement 6 emphasizes secure software development and vulnerability management with significant enhancements. Defined roles and responsibilities, alignment of custom code review and developer training, consolidation of secure coding practices, separate requirement for vulnerability management, elimination of manual web app assessments, and new mandates for change control and script management aim to strengthen system security. Robust patch management, strict change control, and secure coding practices are essential for protecting cardholder data. Visit VISTA InfoSec’s website for more information on PCI DSS Requirement 6 and related topics. Stay informed and secure.
Lets us help you
Need help navigating PCI DSS v4.0?
With experience in the PCI DSS field dating back to 2008 and having served as a certified payment brand, our PCI DSS services deliver quality results in card security controls through comprehensive attestations for both product platforms and back-end services.
We have a dedicated team of auditors and a separate team for consulting/advisory assignments helps our esteemed clients to define processes and achieve compliance.
We have completed multiple PCI DSS 4.0 certifications too right from scoping to Readiness Assessment, Advisory and Final Certification.
Our main USP is that we are vendor neutral and have a strict no-outsourcing policy. We are open to also assisting you with the technical assessments needed for PCI DSS Compliance – Vulnerability Assessment, Penetration Testing, Network Segmentation Testing, Network Architecture Review, Firewall Assessment, Secure Configuration Assessment, Web and Mobile Application Security Assessment, and Secure Code Review.
Narendra Sahoo (PCI QPA, PCI QSA, PCI SSF ASSESSOR, CISSP, CISA, CRISC, 27001 LA) is the Founder and Director of VISTA InfoSec, a global Information Security Consulting firm, based in the US, Singapore & India. Mr. Sahoo holds more than 25 years of experience in the IT Industry, with expertise in Information Risk Consulting, Assessment, & Compliance services. VISTA InfoSec specializes in Information Security audit, consulting and certification services which include GDPR, HIPAA, CCPA, NESA, MAS-TRM, PCI DSS Compliance & Audit, PCI PIN, SOC2 Compliance & Audit, PDPA, PDPB to name a few. The company has for years (since 2004) worked with organizations across the globe to address the Regulatory and Information Security challenges in their industry. VISTA InfoSec has been instrumental in helping top multinational companies achieve compliance and secure their IT infrastructure.
