PCI DSS Requirement 6: Explained

Requirement 6: Develop and maintain secure systems and applications

PCI DSS Requirement 6 mandates that organizations develop and maintain secure systems and applications to safeguard cardholder data. This involves implementing a rigorous security vulnerability management process, which includes timely installation of vendor-supplied security patches and regular vulnerability scans. Secure development practices must be embedded throughout the software development life cycle (SDLC), utilizing secure coding guidelines and conducting thorough code reviews and security testing to mitigate vulnerabilities.

Change control processes are essential to ensure that any modifications to system components are properly tested, documented, and authorized. Additionally, regular penetration testing and the use of web application firewalls (WAFs) are required to identify and defend against application-layer threats. Training and awareness programs for developers and relevant personnel on secure coding practices and application security are crucial to maintaining a strong security posture. Adherence to these practices helps prevent data breaches and ensures the ongoing protection of sensitive cardholder information.

PCI DSS Requirement 6.1: Processes and mechanisms for developing and maintaining secure systems and software are defined and understood

This requirement is divided into 6.1.1 and 6.1.2. Let's explore these in detail.

PCI DSS Requirement 6.1.1: Manage security policies and procedures effectively

This requirement emphasizes the importance of effective management for all security policies and operational procedures outlined in Requirement 6. Effective management ensures everyone understands, implements, and follows these critical security controls. Requirement 6.1.1 mandates that your organization:

• Documents all security policies and procedures: Clearly document all security policies and procedures related to system and application security. This documentation should be clear, concise, and easily accessible to relevant personnel.
• Maintains up-to-date documentation: Regularly review and update your security policies and procedures to reflect any changes in your systems, technologies, or security threats. Don't wait for a predefined cycle; update them promptly after relevant changes occur.
• Ensures policy and procedure use: Implement and enforce the documented security policies and procedures within your organization. This ensures everyone adheres to the established security controls.
• Communicates policies and procedures: Effectively communicate these policies and procedures to all personnel whose roles are impacted by them. This fosters awareness and understanding of security expectations.

Business implication

• Enhanced security posture and reduced risk: By effectively managing your security policies and procedures, you establish a clear framework for secure system and application development and maintenance. This reduces the risk of security vulnerabilities and potential breaches, protecting your cardholder data and minimizing financial losses.

Best practices to meet this requirement

• Develop clear and comprehensive documentation: Craft well-defined security policies and procedures that are easy to understand and follow for relevant personnel.
• Maintain a document management system: Implement a system for version control and easy access to current security policies and procedures.
• Schedule regular reviews and updates: Establish a process for periodically reviewing and updating your security policies and procedures to reflect changes in your environment or security landscape. Consider updating them promptly after significant changes occur.
• Conduct security awareness training: Train your employees on the documented security policies and procedures relevant to their roles. This raises awareness and ensures they understand their security responsibilities.

How to comply with this requirement

Here's a table outlining how compliance with Requirement 6.1.1 will be verified during a PCI DSS assessment:

PCI DSS Requirement 6.1.2: Define and communicate roles and responsibilities for secure systems

This requirement ensures clear ownership and accountability for secure system development and maintenance activities outlined in Requirement 6. It mandates that your organization:

• Documents roles and responsibilities: Clearly document the roles and responsibilities associated with each activity within Requirement 6. This documentation should specify who is accountable for performing each task related to secure systems and applications.
• Assigns roles and responsibilities: Assign these documented roles and responsibilities to specific personnel within your organization. Ensure the assigned individuals possess the necessary knowledge and skills to fulfill their security duties effectively.
• Communicates roles and responsibilities: Effectively communicate these assigned roles and responsibilities to the relevant personnel. This fosters understanding and ensures everyone is aware of their security obligations.

Business Implication

• Improved system security and reduced risk: By clearly defining and communicating roles and responsibilities for secure systems, you ensure accountability for security tasks. This helps prevent security gaps and reduces the risk of vulnerabilities being exploited, ultimately protecting your cardholder data and minimizing financial losses.

Best practices to meet this requirement

• Develop a RACI Matrix: Consider using a responsibility assignment (RACI) matrix to document roles and responsibilities. A RACI matrix outlines who is responsible, accountable, consulted, and informed for each security activity.
• Integrate with security policies: Integrate the roles and responsibilities into your security policies or create a separate document for clarity.
• Obtain acknowledgement: Implement a process where personnel acknowledge their understanding and acceptance of their assigned roles and responsibilities.

How to comply with this requirement

Here's a table outlining how compliance with Requirement 6.1.2 will be verified during a PCI DSS assessment:

PCI DSS Requirement 6.2: Bespoke and custom software are developed securely

This requirement is divided into 6.2.1, 6.2.2, 6.2.3, and 6.2.4. Let's explore these in detail.

PCI DSS Requirement 6.2.1: Develop secure bespoke and custom software

This requirement focuses on secure development practices for bespoke and custom software within your organization. Bespoke software is uniquely tailored to your specific needs, while custom software is a modified version of existing software. This requirement mandates that your software development process adheres to the following principles:

• Industry standards and best practices: Your SDLC should incorporate established industry standards and best practices for secure development. These guidelines outline secure coding techniques and methodologies to minimize vulnerabilities in your software.
• PCI DSS compliance: The development process should consider and implement relevant PCI DSS controls throughout the SDLC. This ensures your custom software adheres to PCI DSS requirements, such as secure authentication and logging mechanisms, to protect cardholder data.
• Security considerations throughout the SDLC: Security should be a continuous consideration throughout all stages of the SDLC. This means integrating security practices from the initial requirement definition phase through design, development, testing, and deployment.

Definitions

• Bespoke software: Software specifically designed and developed to meet your organization's unique needs and requirements.
• Custom software: An existing software application that has been modified to fit your specific needs.
• SDLC: The structured process for planning, designing, developing, testing, deploying, and maintaining software applications.

Business implication

• Reduced risk of vulnerabilities and breaches: By incorporating security throughout the SDLC, you proactively minimize the introduction of vulnerabilities into your custom software. This reduces the risk of these vulnerabilities being exploited in a data breach, protecting your cardholder data and safeguarding your business reputation.

Best practices to meet this requirement

• Adopt a secure SDLC framework: Implement a recognized, secure SDLC framework, such as the PCI Software Security Framework (SSF), BSIMM, or Open Web Application Security Project (OWASP) methodologies. These frameworks provide a structured approach to secure development.
• Integrate security throughout the SDLC: Integrate security considerations into each stage of your SDLC. This may involve security requirements definition, secure coding practices, security testing, and vulnerability assessments throughout the development process.
• Train developers on secure coding: Provide training to your developers on secure coding practices and how to identify and avoid common coding vulnerabilities.

How to comply with this requirement

Here's a table outlining how compliance with Requirement 6.2.1 will be verified during a PCI DSS assessment:

PCI DSS Requirement 6.2.2: Train developers on secure coding for custom software

This requirement emphasizes the importance of ongoing security awareness training for developers working on bespoke and custom software within your organization. It mandates that you provide security training to your developers at least annually, covering the following critical areas:

• Security relevant to job function and languages: The training should address secure coding practices directly relevant to the developers' specific job roles and the programming languages they use. This ensures they understand the security implications of their coding choices and how to write secure code.
• Secure software design: Training should cover secure software design principles that help build security into your applications from the ground up. This may involve secure architecture concepts, threat modeling, and secure coding practices.
• Secure coding techniques: The training should delve into specific secure coding techniques that help developers avoid common vulnerabilities. This might include input validation, secure data handling, and memory management practices.
• Security testing tools (if applicable): If your organization utilizes security testing tools to identify vulnerabilities in your software, training should cover how to effectively use these tools for vulnerability detection purposes.

Definitions

• Bespoke software: Software specifically designed and developed to meet your organization's unique needs and requirements.
• Custom software: An existing software application that has been modified to fit your specific needs.
• Secure coding: The practice of writing code that is resistant to vulnerabilities and exploits.

Business implication

• Reduced risk of vulnerabilities and breaches: By providing regular training on secure coding practices, you equip your developers with the knowledge and skills to write more secure custom software. This minimizes the introduction of vulnerabilities during development, ultimately reducing the risk of these vulnerabilities being exploited in a data breach and safeguarding your cardholder data.

Best practices to meet this requirement

• Develop a secure coding training program: Establish a comprehensive training program that covers the elements specified in this requirement. This program can be delivered inhouse or through external training providers.
• Tailor training to developer roles and languages: Ensure the training content is relevant to the specific programming languages and development roles within your organization.
• Incorporate secure design principles: Integrate secure design principles into the training curriculum to promote secure software development from the beginning.
• Update training for new threats: Regularly update your training program to reflect the latest secure coding practices and emerging security threats.

How to comply with this requirement

Here's a table outlining how compliance with Requirement 6.2.2 will be verified during a PCI DSS assessment:

PCI DSS Requirement 6.2.3: Review bespoke and custom software before release

This requirement emphasizes the importance of code reviews for bespoke and custom software before it's released into production or deployed to customers. These reviews aim to identify and address potential coding vulnerabilities that could be exploited by attackers. Here's what the requirement mandates:

• Secure coding review: The code review process should verify that the code adheres to established secure coding guidelines. This ensures the code is written with security best practices in mind, minimizing the likelihood of vulnerabilities.
• Vulnerability detection: The code review should also focus on identifying both existing and emerging software vulnerabilities. This proactive approach helps mitigate the risk of known vulnerabilities and stay ahead of newly discovered threats.
• Vulnerability remediation: The review process should ensure that any identified vulnerabilities are addressed and corrected before the software is released. This proactive approach minimizes the window of opportunity for attackers to exploit vulnerabilities.

Definitions

• Bespoke software: Software specifically designed and developed to meet your organization's unique needs and requirements.
• Custom software: An existing software application that has been modified to fit your specific needs.
• Coding vulnerabilities: Weaknesses or flaws in the code that can be exploited by attackers to gain unauthorized access or compromise a system.
• Code review: A systematic process of examining code for functionality, security, and adherence to coding standards.

Business implication

• Reduced risk of breaches and business disruption: By implementing code reviews for bespoke and custom software, you proactively identify and address vulnerabilities before they can be exploited by attackers. This reduces the risk of a data breach that could compromise cardholder data, potentially leading to financial losses and reputational damage.

Best practices to meet this requirement

• Develop a code review process: Establish a formal code review process that incorporates the elements specified in this requirement. This process should define who performs the reviews, what aspects are reviewed, and how vulnerabilities are addressed.
• Utilize secure coding guidelines: Integrate the use of established secure coding guidelines into your development process. These guidelines provide best practices for writing secure code and should be a reference point during code reviews.
• Combine manual and automated reviews: Consider using a combination of manual code reviews by experienced developers and automated code analysis tools for comprehensive vulnerability detection.
• Focus on common attack vectors: Tailor your code reviews to address vulnerabilities associated with common software attacks as outlined in Requirement 6.2.5 of PCI DSS.

How to comply with this requirement

Here's a table outlining how compliance with Requirement 6.2.3 will be verified during a PCI DSS assessment:

This requirement is further divided into requirement 6.2.3.1. Let's explore this in detail.

PCI DSS Requirement 6.2.3.1: Conduct effective manual code reviews (if applicable)

This requirement applies specifically to organizations that perform manual code reviews for bespoke and custom software before release. It outlines the specific criteria for conducting effective manual code reviews to enhance security:

• Independent reviewers: The code review process must involve individuals other than the original code author. These reviewers should possess expertise in code review techniques and secure coding practices. This ensures a fresh perspective and reduces the risk of overlooking vulnerabilities the original developer might have missed.
• Management approval: In addition to the code review, the requirement mandates management approval before releasing the software. This management oversight helps ensure the code review process is not bypassed and reinforces the importance of secure coding practices.

Definitions

• Bespoke software: Software specifically designed and developed to meet your organization's unique needs and requirements.
• Custom software: An existing software application that has been modified to fit your specific needs.
• Manual code review: A systematic process where developers or other qualified personnel manually examine code for functionality, security, and adherence to coding standards.
• Secure coding practices: Techniques employed during development to write code that is resistant to vulnerabilities and exploits.

Business implication

• Reduced risk of vulnerabilities and breaches: By implementing effective manual code reviews with independent reviewers and management approval, you minimize the likelihood of introducing vulnerabilities into your bespoke and custom software. This proactive approach reduces the risk of these vulnerabilities being exploited in a data breach, protecting your cardholder data and safeguarding your business reputation.

Best practices to meet this requirement

• Develop a code review methodology: Establish a formal code review methodology that outlines the review process, reviewer qualifications, and defect tracking procedures. This ensures consistency and effectiveness in your code reviews.
• Utilize review checklists: Employ code review checklists that address specific security considerations and common coding vulnerabilities. These checklists can help guide reviewers and ensure comprehensive analysis.
• Manage the reviewer workload: Recognize that code review can be mentally demanding. Assign reviewers manageable amounts of code at a time and consider reviewing applications they are familiar with to maintain focus and effectiveness.
• Train your reviewers: Provide regular training for your code reviewers to ensure they stay current with the latest security threats, emerging vulnerabilities, and best practices in secure coding.

How to comply with this requirement

Here's a table outlining how compliance with Requirement 6.2.3.1 will be verified during a PCI DSS assessment:

PCI DSS Requirement 6.2.4: Develop secure coding practices for bespoke and custom software

This requirement emphasizes the importance of implementing secure coding practices during the development of bespoke and custom software within your organization. It mandates that you define and utilize specific software engineering techniques to mitigate the risk of common software attacks and vulnerabilities. The requirement focuses on the following key areas:

• Mitigating common attacks: Your software development process should incorporate methods to prevent or mitigate common software attacks, such as injection attacks, data manipulation attacks, cryptographic weaknesses, business logic abuse, access control bypasses, and any high-risk vulnerabilities identified through your vulnerability identification process.
• Shifting security left: The goal is to detect and address security vulnerabilities as early as possible in the development lifecycle. This approach of shifting security left minimizes the risk of vulnerabilities persisting through to production and potentially being exploited in a data breach.

Definitions

• Bespoke software: Software specifically designed and developed to meet your organization's unique needs and requirements.
• Custom software: An existing software application that has been modified to fit your specific needs.
• Software engineering techniques: Methods and tools employed during software development to ensure code quality, security, and maintainability.
• Common software attacks: Well-known and frequently exploited vulnerabilities in software applications.

Business implication

• Reduced risk of breaches and financial loss: By proactively mitigating common software attacks through secure coding practices, you significantly reduce the risk of vulnerabilities being exploited in your bespoke and custom software. This helps safeguard your cardholder data from breaches and protects your business from potential financial losses and reputational damage.

Best practices to meet this requirement

• Define secure coding standards: Establish documented secure coding standards that outline coding practices and techniques to prevent common vulnerabilities. These standards should be tailored to the specific programming languages used in your development projects.
• Utilize static code analysis tools: Integrate static code analysis tools into your development process. These tools can automatically scan code for potential vulnerabilities and coding errors.
• Train developers on secure coding: Provide regular training for your developers on secure coding practices and how to mitigate common software attacks. This training should keep them updated on emerging threats and best practices.
• Conduct code reviews: Implement code review processes that specifically consider secure coding principles and common vulnerabilities.

How to comply with this requirement

Here's a table outlining how compliance with Requirement 6.2.4 will be verified during a PCI DSS assessment:

PCI DSS Requirement 6.3: Security vulnerabilities are identified and addressed

This requirement is further divided into 6.3.1, 6.3.2, and 6.3.3. Let's explore these in detail.

PCI DSS Requirement 6.3.1: Proactively identify and manage security vulnerabilities

This requirement focuses on establishing a proactive process for identifying and managing security vulnerabilities within your organization's IT environment. It outlines the following critical elements:

• Utilize industry sources: You must actively monitor industry-recognized sources for security vulnerability information. This includes alerts from national and international computer emergency response teams (CERTs), vendor security advisories, and industry news sources.
• Vulnerability risk ranking: For each identified vulnerability, you need to assign a risk ranking based on industry best practices and the potential impact on your environment. This helps prioritize remediation efforts by addressing the most critical vulnerabilities first.
• Risk ranking levels: The risk ranking should at least identify vulnerabilities considered high risk or critical to your environment. These vulnerabilities pose the greatest potential for compromise and require immediate attention.
• Vulnerability coverage: The vulnerability identification process should encompass all software within your environment, including bespoke and custom software, as well as third-party software like operating systems and databases.

Definitions

• Security vulnerability: A weakness or flaw in a system, software application, or process that can be exploited by attackers to gain unauthorized access or compromise data.
• Industry-recognized sources: Trustworthy sources for vulnerability information such as CERT advisories, vendor security bulletins, and industry security newsgroups.
• Risk ranking: A method for classifying vulnerabilities based on their severity and potential impact on an organization's environment.

Business implication

• Reduced risk of breaches and data loss: By proactively identifying and prioritizing high-risk vulnerabilities, you can effectively address them before they can be exploited by attackers. This significantly reduces the risk of a data breach that could compromise your cardholder data and lead to financial losses and reputational damage.

Best practices to meet this requirement

• Establish a vulnerability management program: Develop a formal program that outlines your process for identifying, evaluating, prioritizing, and remediating security vulnerabilities.
• Subscribe to security alerts: Sign up for vulnerability alerts from reputable sources like CERTs, software vendors, and security mailing lists.
• Utilize vulnerability scanning tools: Consider using automated vulnerability scanning tools to identify potential vulnerabilities in your systems and applications.
• Develop a risk ranking methodology: Define a clear and objective methodology for assigning risk rankings to vulnerabilities based on their severity, exploitability, and potential impact on your environment.
• Integrate with other processes: Ensure your vulnerability management program is integrated with other relevant processes like patch management, incident response, and application security.

How to comply with this requirement

Here's a table outlining how compliance with Requirement 6.3.1 will be verified during a PCI DSS assessment:

PCI DSS Requirement 6.3.2: Maintain a software inventory for vulnerability and patch management (currently a best practice)

This requirement, currently a best practice but mandatory after March 31, 2025, emphasizes the importance of maintaining an accurate inventory of software within your environment. This inventory specifically focuses on:

• Bespoke and custom software: Software applications designed and developed specifically for your organization's needs.
• Third-party components: Software components or libraries integrated into your bespoke and custom software.

The purpose of this inventory is to facilitate effective vulnerability and patch management. By knowing exactly what software you have, you can:

• Identify potential vulnerabilities: You can leverage the inventory to identify potential vulnerabilities in your bespoke and custom software and any third-party components they utilize. This allows you to prioritize patching and remediation efforts.
• Manage patch deployment: The inventory helps ensure you are aware of available security patches for all software components, enabling you to deploy them effectively and address known vulnerabilities.

Definitions

• Software inventory: A comprehensive list of all software applications and components within your IT environment.
• Bespoke software: Software specifically designed and developed to meet your organization's unique needs and requirements.
• Custom software: An existing software application that has been modified to fit your specific needs.
• Third-party components: Software libraries, modules, or APIs incorporated into your bespoke and custom software developed by external vendors.

Business implication

• Reduced risk of breaches: Maintaining a software inventory allows you to proactively identify and address vulnerabilities in both your bespoke and custom software and any third-party components they rely on. This reduces the risk of attackers exploiting these vulnerabilities to gain unauthorized access to your systems and compromise cardholder data.

Best practices to meet this requirement

• Develop a software inventory process: Establish a process for identifying, documenting, and maintaining an accurate inventory of all software within your environment.
• Utilize automated tools: Consider using automated software discovery and composition analysis tools to assist in creating and maintaining your inventory.
• Regularly update the inventory: Ensure your software inventory is regularly updated to reflect any changes in your environment, such as new software installations or upgrades.
• Integrate with vulnerability management: Integrate your software inventory with your vulnerability management program to identify vulnerabilities associated with specific software components.

How to comply with this requirement(after March 31, 2025)

Here's a table outlining how compliance with Requirement 6.3.2 will be verified during a PCI DSS assessment after March 31, 2025:

PCI DSS Requirement 6.3.3: Implement patch management to address vulnerabilities

This requirement emphasizes the importance of implementing a timely patch management process to address known vulnerabilities in your IT environment. It outlines specific timeframes for installing security patches based on their severity:

• Critical and high-risk patches: For vulnerabilities identified as critical or highrisk through your risk ranking process (Requirement 6.3.1), you must install the corresponding security patches or updates within one month of their release.
• Other security patches: For all other vulnerabilities with lower risk rankings, you can define an appropriate timeframe for installing the security patches/updates. However, industry best practices recommend doing so within three months of release.

Definitions

• Security patch: A software update designed to fix a security vulnerability in an application, operating system, or firmware.
• Patch management: The process of identifying, acquiring, testing, and deploying security patches to address vulnerabilities in a timely manner.
• Critical vulnerability: A vulnerability that can be exploited to gain unauthorized access to critical systems or data with a high potential for negative impact.
• High-risk vulnerability: A vulnerability that can be exploited to gain unauthorized access to systems or data with a significant potential for negative impact.

Business implication

• Reduced risk of exploits: By promptly installing security patches for critical and high-risk vulnerabilities, you significantly reduce the window of opportunity for attackers to exploit these vulnerabilities and compromise your systems or cardholder data. This helps safeguard your business from potential financial losses and reputational damage.

Best practices to meet this requirement:

• Develop a patch management policy: Establish a documented patch management policy that outlines your process for identifying, prioritizing, testing, and deploying security patches.
• Prioritize criticalpatches: Prioritize the installation of security patches for critical vulnerabilities within one month of their release.
• Define patching timeframes: Define appropriate timeframes for installing security patches for vulnerabilities with lower risk rankings. Consider industry best practices that recommend patching within three months.
• Test patches before deployment: Whenever possible, implement a process for testing security patches in a non-production environment before deploying them to production systems.
• Monitor patch deployment: Monitor your patch deployment process to ensure timely installation of security patches across your environment.

How to comply with this requirement

Here's a table outlining how compliance with Requirement 6.3.3 will be verified during a PCI DSS assessment:

PCI DSS Requirement 6.4: Public-facing web applications are protected against attacks

This requirement is further divided into 6.4.1, 6.4.2, and 6.4.3. Let's explore these in detail.

PCI DSS Requirement 6.4.1: Protect public-facing web applications (currently superseded)

This requirement, currently superseded by Requirement 6.4.2 after March 31, 2025, focuses on securing public-facing web applications within your environment. It mandates that you implement either of the following approaches to address new threats and vulnerabilities:

Approach 1: Periodic vulnerability assessments

• Frequency: Conduct vulnerability assessments of your public-facing web applications at least once every 12 months and after any significant changes.
• Qualified assessors: The assessments must be performed by an entity specializing in application security, ensuring a thorough evaluation.
• Vulnerability coverage: The assessments should cover all common software attacks as outlined in Requirement 6.2.4, such as SQL injection and cross-site scripting (XSS).
• Vulnerability ranking and remediation: All identified vulnerabilities need to be ranked according to their severity (Requirement 6.3.1) and subsequently addressed through remediation efforts.
• Post-remediation reevaluation: After vulnerabilities are fixed, the web application should be reevaluated to verify the effectiveness of the remediation.

Approach 2: Automated threat detection and prevention

• Solution placement: Implement an automated technical solution like a WAFin front of your public-facing web applications.
• Solution functionality: The solution should continuously detect and prevent web-based attacks in realtime.
• Active maintenance: Ensure the automated solution is actively running, up-to-date with the latest threat signatures, and generating audit logs for monitoring purposes.
• Alert configuration: Configure the solution to either block detected attacks or generate immediate alerts for investigation and mitigation.

Definitions

• Public-facing web application: A web application accessible to the general public over the internet, not just for internal use.
• Vulnerability assessment: A systematic process for identifying, classifying, and prioritizing vulnerabilities within a web application.
• Web application security: The practice of protecting web applications from security threats and vulnerabilities.
• WAF: A security device that monitors and filters traffic between a web server and the internet, protecting against common web application attacks.

Business implication

• Reduced risk of web application breaches: By proactively addressing vulnerabilities and implementing real-time attack prevention measures, you significantly reduce the risk of attackers compromising your public-facing web applications and potentially accessing sensitive cardholder data. This safeguards your business from financial losses, reputational damage, and potential regulatory penalties.

Best practices to meet this requirement (although superseded)

• Choose your approach: Select either the periodic vulnerability assessment approach or the automated threat detection and prevention approach based on your resources and risk tolerance.
• Engage qualified assessors: If opting for vulnerability assessments, select a reputable and qualified application security vendor to conduct the assessments.
• Implement a WAF solution: Consider implementing a WAF as an automated solution for continuous protection.
• Maintain and monitor security solutions: Ensure your chosen security solutions are actively maintained, updated, and monitored for effectiveness.

How to comply with this requirement (although superseded)

PCI DSS Requirement 6.4.2: Implement automated WAF for public-facing web applications (effective after March 31, 2025)

This requirement, effective after March 31, 2025, mandates the deployment of an automated technical solution to protect your public-facing web applications from web-based attacks in realtime. This solution must meet the following criteria:

• Placement and functionality: The solution should be installed in front of your public-facing web applications and actively configured to detect and prevent web-based attacks as they occur.
• Active and up-to-date maintenance: The solution must be actively running and updated with the latest threat signatures to ensure continuous protection.
• Audit log generation: The solution needs to generate audit logs for monitoring purposes, allowing you to track and analyze security events.
• Alert configuration: The solution should be configured to either block detected attacks or generate immediate alerts that require investigation and mitigation.

Definitions

• Public-facing web application: A web application accessible to the general public over the internet, not just for internal use.
• Web-based attack: Any malicious attempt to exploit vulnerabilities within a web application to gain unauthorized access to data or systems.
• Automated technical solution: A security device like a WAF that operates autonomously to detect and prevent attacks.
• WAF: A security device that monitors and filters traffic between a web server and the internet, protecting against common web application attacks.
• Audit log: A record of security events and activities within a system, which is used for monitoring and forensic analysis.

Business implication

• Enhanced protection against web application threats: By implementing a WAF, you gain real-time protection against evolving web-based attacks. This significantly reduces the risk of attackers compromising your public-facing web applications and potentially accessing sensitive cardholder data. This safeguards your business from financial losses, reputational damage, and potential regulatory penalties.

Best practices to meet this requirement

• Deploy a WAF: Implement a WAF solution that aligns with the specifications outlined in the requirement. Consider cloud-based or on-premises WAF options depending on your needs.
• Maintain and update the WAF: Ensure the WAF is actively maintained, updated with the latest threat signatures, and properly configured for optimal protection.
• Establish alert response procedures: Develop procedures for timely investigation and mitigation of alerts generated by the WAF.
• Regularly review WAF logs: Regularly review WAF audit logs to identify potential security incidents and trends in attack attempts.

How to comply with this requirement (effective after March 31, 2025)

PCI DSS Requirement 6.4.3: Manage payment page scripts for client-side security (effective after March 31, 2025)

This requirement, effective after March 31, 2025, focuses on securing scripts loaded and executed within the customer's browser during the online payment process. It mandates a three-pronged approach to manage these scripts and mitigate potential vulnerabilities:

1. Script authorization: Implement a method to verify that each script running on the payment page is authorized and approved for use. This could involve manual review or automated workflows.
2. Script integrity assurance: Ensure the integrity of each script to prevent tampering. Techniques like subresource integrity (SRI) or content security policy (CSP) can help achieve this.
3. Script inventory with justification: Maintain a comprehensive inventory of all payment page scripts. Each script entry should include written justification explaining its necessity for the payment functionality.

Definitions

• Payment page script: Any code loaded and executed within the customer's browser during the online payment process.
• Script authorization: The process of verifying that a script is legitimate and approved for use on the payment page.
• Script integrity: The assurance that a script hasn't been tampered with and remains in its original, unaltered state.
• SRI: A web security technique that allows browsers to verify the integrity of scripts before loading them.
• CSP: A security policy that restricts where browsers can load resources (scripts, styles, images) from.
• Script inventory: A comprehensive list of all scripts used on the payment page along with justifications for their inclusion.

Business implication

• Reduced risk of script-based attacks: By managing and securing payment page scripts, you significantly reduce the risk of attackers injecting malicious code that could steal cardholder data during the checkout process. This safeguards your business from financial losses, reputational damage, and potential regulatory penalties.

Best practices to meet this requirement

• Implement script authorization: Establish a process to approve and authorize all scripts used on the payment page. This could involve manual review by IT security personnel or automated workflows within a change management system.
• Enforce script integrity: Utilize techniques like SRI or CSP to ensure the integrity of scripts loaded from external sources. These mechanisms prevent attackers from modifying scripts to steal cardholder data.
• Maintain a script inventory: Create and maintain a comprehensive inventory of all payment page scripts. Each script entry should include a clear explanation of its purpose and justification for its presence.
• Consider inline frame (iframe) restrictions: If your payment page is loaded within an iframe, implement restrictions using the parent page's CSP. This helps prevent unauthorized content from being substituted for your payment page.

How to comply with this requirement (effective after March 31, 2025)

PCI DSS Requirement 6.5: Changes to all system components are managed securely

This requirement is further divided into 6.5.1, 6.5.2, 6.5.3, 6.5.4, 6.5.5, and 6.5.6. Now let's explore these in detail.

PCI DSS Requirement 6.5.1: Implement secure change control processes (production environment)

This requirement emphasizes the importance of establishing documented change control procedures for managing all modifications made to system components within your production environment. These procedures ensure a secure and controlled approach to changes, minimizing the risk of introducing vulnerabilities. The requirement outlines specific elements that your change control procedures must address:

• Change justification and description: Clearly document the reason for the change and provide a detailed description of what's being modified.
• Security impact assessment: Document the potential security impact of the proposed change. This helps identify any potential security risks associated with the modification.
• Authorized change approval: Implement a process for authorized personnel to review and approve changes before deployment. This ensures only sanctioned modifications are made.
• Change testing and validation: Conduct thorough testing of the change to verify it doesn't adversely affect system security. This ensures the change doesn't introduce vulnerabilities or bypass existing security controls.
• Custom software testing (for updates): For bespoke and custom software changes, ensure they comply with secure coding practices (Requirement 6.2.4) before deploying them to production.
• Rollback procedures: Establish documented procedures for addressing any failures during the change implementation. These procedures should guide how to revert to a secure state if the change has negative security consequences.

Definitions

• Production environment: The environment where your live systems and applications operate, processing cardholder data.
• Change control procedures: A documented set of processes for managing changes to IT systems and infrastructure, ensuring security and stability.
• Security impact assessment: The process of evaluating the potential security risks associated with a planned change to a system or application.
• Rollback procedures: Documented steps for reverting a system or application to a previous secure state in case of a failed or problematic change.

Business implication

• Reduced risk of security incidents: By implementing a secure change control process, you significantly reduce the risk of security incidents caused by unauthorized or poorly planned changes to your production systems. This safeguards your business from potential financial losses, reputational damage, and regulatory penalties.

Best practices to meet this requirement

• Develop documented change control procedures: Create and maintain documented procedures outlining your change control process, addressing all elements specified in the requirement.
• Define roles and responsibilities: Clearly define roles and responsibilities within the change control process, including personnel authorized to initiate, review, and approve changes.
• Implement a change tracking system: Consider implementing a change tracking system to automate the change control process, improve tracking, and ensure adherence to procedures.
• Conduct regular reviews: Periodically review your change control procedures to ensure they remain effective and aligned with current business needs and security best practices.

How to comply with this requirement

PCI DSS Requirement 6.5.2: Verify PCI DSS compliance after significant changes

This requirement mandates that after completing a significant change to your systems or network within the PCI DSS scope, you must verify that all relevant PCI DSS controls are still in place and functioning effectively. Additionally, any documentation related to the system or network needs to be updated to reflect the changes.

Definitions

• Significant change: Any modification to your systems or network that has the potential to impact the security of cardholder data. Examples include adding new servers, upgrading software, or changing network configurations.
• PCI DSS control: A security measure or process outlined in the PCI DSS standard that helps protect cardholder data. Examples include firewalls, vulnerability scanning, and access controls.
• In-scope environment: The systems, applications, and data that PCI DSS compliance requirements apply to within your organization.

Business implication

• Reduced risk of non-compliance: By verifying PCI DSS compliance after significant changes, you significantly reduce the risk of non-compliance findings during an official PCI DSS assessment. This helps avoid potential fines and reputational damage associated with non-compliance.

Best practices to meet this requirement

• Integrate PCI DSS verification into change management: Incorporate PCI DSS verification steps into your existing change management process. This ensures that compliance checks are routinely conducted after significant changes are implemented.
• Develop a PCI DSS verification checklist: Create a checklist outlining the specific PCI DSS controls you need to verify after a significant change. This helps ensure a thorough and consistent verification process.
• Maintain updated system documentation: Regularly update your system documentation to reflect any changes made to your systems or network. This ensures your documentation remains accurate and reflects the current state of your environment.
• Train personnel on PCI DSS verification: Train personnel involved in the change management process on how to verify PCI DSS compliance after significant changes. This ensures they understand the verification requirements and can perform them effectively.

How to comply with this requirement

PCI DSS Requirement 6.5.3: Segregate preproduction and production environments with access controls

This requirement mandates the separation of your preproduction environments (development, testing, UAT) from your production environment where cardholder data is processed. This separation needs to be enforced using access controls to prevent potential risks and vulnerabilities from preproduction activities from impacting the security of your production systems.

Definitions

• Preproduction environment: Any environment used for development, testing, user acceptance testing (UAT), etc. where code, configurations, and data might be unstable or untested.
• Production environment: The live environment where your operational systems and applications process cardholder data.
• Access controls: Security measures that restrict access to systems and data based on authorized users and their permissions.

Business implication

• Reduced risk of data breaches: By segregating preproduction and production environments, you significantly reduce the risk of vulnerabilities introduced during development or testing from compromising your production systems where cardholder data resides. This helps safeguard your business from potential data breaches and associated financial losses and reputational damage.

Best practices to meet this requirement

• Develop clear separation policies: Establish clear policies and procedures that define the separation requirements between preproduction and production environments.
• Logical or physical separation: Implement logical (network segmentation) or physical separation of preproduction and production environments, or a combination of both, depending on your infrastructure.
• Enforce access controls: Implement robust access controls to restrict access to preproduction environments. This may involve user authentication, authorization levels, and network access controls.
• Limit production data in preproduction: Minimize the use of live cardholder data in preproduction environments. Consider using masked or test data whenever possible.
• Regular security reviews: Conduct regular security reviews of both preproduction and production environments to identify and address any potential vulnerabilities.

How to comply with this requirement

PCI DSS Requirement 6.5.4: Segregate roles and functions between production and preproduction environments

This requirement mandates the separation of duties between personnel working in your preproduction environments (development, testing, UAT) and those managing the production environment where cardholder data resides. This segregation helps ensure accountability and minimizes the risk of unauthorized, unintentional, or inappropriate actions that could compromise your production systems.

Definitions

• Preproduction environment: Any environment used for development, testing, user acceptance testing (UAT), etc. where code, configurations, and data might be unstable or untested.
• Production environment: The live environment where your operational systems and applications process cardholder data.
• Separation of duties (SoD): A security principle that distributes critical tasks among different individuals or teams to reduce the risk of errors, fraud, or abuse.

Business implication

• Reduced risk of fraudulent activity: By separating duties between preproduction and production personnel, you significantly reduce the risk of a single individual gaining unauthorized access to production systems and cardholder data for malicious purposes. This helps safeguard your business from potential financial losses and reputational damage associated with fraud.

Best practices to meet this requirement

• Develop clear role definitions: Define clear roles and responsibilities for personnel working in both preproduction and production environments. These roles should outline the authorized access and activities for each role in each environment.
• Implement least privilege: Grant users the minimum level of access privileges required to perform their job duties. This helps minimize the potential damage caused by unauthorized access or human error.
• Implement dual control procedures: Consider implementing dual control procedures for critical tasks, especially those involving production systems and cardholder data. This requires two authorized individuals to approve and execute such tasks, further enhancing security.
• Regular user reviews: Conduct periodic reviews of user access privileges to ensure they remain aligned with current job functions and access needs.

How to comply with this requirement

PCI DSS Requirement 6.5.5: Restrict live PANs in preproduction environments

This requirement prohibits the use of live primary account numbers (PANs) within your preproduction environments (development, testing, UAT) unless those environments are designated as a cardholder data environment (CDE) and meet all applicable PCI DSS security controls. Live PANs refer to actual credit or debit card numbers that can be used to conduct transactions.

Definitions

• Live PAN: A valid PAN that can be used to conduct payment transactions.
• Preproduction environment: Any environment used for development, testing, user acceptance testing (UAT), etc. where code, configurations, and data might be unstable or untested.
• CDE: The environment where cardholder data is stored, processed, or transmitted. A CDE needs to comply with all relevant PCI DSS requirements.

Business implication

• Reduced risk of data breaches: By restricting live PANs in preproduction environments, you significantly reduce the risk of a data breach if these environments are compromised. This safeguards your business from potential financial losses, reputational damage, and regulatory penalties associated with a PAN compromise.

Best practices to meet this requirement

• Use test data for preproduction activities: Whenever possible, utilize masked or test cardholder data for development, testing, and UAT activities within your preproduction environments.
• Minimize live PAN usage: If absolutely necessary to use live PANs for specific testing purposes, strictly limit the quantity of live PAN data stored and ensure its secure deletion after use.
• Secure CDE environments: If your preproduction environment is designated as a CDE, ensure it meets all applicable PCI DSS security controls to protect cardholder data.

How to comply with this requirement

PCI DSS Requirement 6.5.6: Remove test data and accounts before production

This requirement mandates the removal of all test data and test accounts from your system components before deploying them into the production environment. Test data often includes sensitive information like sample customer data or financial details used for testing purposes. Similarly, test accounts with elevated privileges are created during development and testing but pose a security risk if left active in production.

Definitions

• Test data: Data used for testing system functionality and performance. This data may contain sensitive information like sample customer data or financial details.
• Test account: An account created specifically for testing purposes, often with elevated privileges within the system.
• Production environment: The live environment where your operational systems and applications process cardholder data.

Business implication

• Reduced risk of system compromise: By removing test data and accounts before deploying systems to production, you significantly reduce the risk of unauthorized individuals exploiting this information to gain access to your production systems and potentially compromise cardholder data. This safeguards your business from potential financial losses, reputational damage, and regulatory penalties.

Best practices to meet this requirement

• Develop clear procedures: Establish documented procedures outlining the process for removing all test data and accounts before deploying systems to production.
• Integrate into the deployment process: Integrate test data and account removal into your existing deployment process to ensure it's consistently performed before production deployment.
• Automate removal (if possible): Consider automating the removal of test data and accounts whenever possible to improve efficiency and reduce the risk of human error.
• Train development and operations teams: Train both development and operations teams on the importance of removing test data and accounts before production deployment.

How to comply with this requirement