PCI DSS Requirement 11: Explained

Requirement 11: Test security of systems and networks regularly

This PCI DSS requirement is divided into 11.1, 11.2, 11.3, 11.4, 11.5 and 11.6. Let's explore these in detail.

PCI DSS Requirement 11.1: Processes and mechanisms for regularly testing security of systems and networks are defined and understood

PCI DSS Requirement 11.1.1 : Management of Security Policies and Procedures

This requirement focuses on the proper management of all security policies and operational procedures mandated throughout PCI DSS Requirement 11 (Testing Security Systems and Processes). It ensures these policies and procedures are documented, up-to-date, actively used, and communicated effectively to relevant personnel.

• Security Policies: Formal documents outlining the organization's overall information security objectives and guiding principles for data protection.
• Operational Procedures: Detailed instructions that define how to perform specific security-related activities. These procedures translate security policies into practical actions.

Business Implication:

• Reduced Risk of Non-Compliance: Effectively managing security policies and procedures helps ensure everyone within the organization is aware of their security obligations and how to comply with PCI DSS requirements. This reduces the risk of non-compliance findings during PCI DSS assessments.

Best Practices to Meet this Requirement:

• Document All Policies and Procedures: Develop and maintain written documentation for all security policies and operational procedures relevant to Requirement 11.
• Maintain Up-to-Date Documentation: Regularly review and update your policies and procedures to reflect changes in technologies, regulations, or business practices. Don't wait for a specific review cycle; update them promptly after any relevant changes occur.
• Implement and Enforce Policies and Procedures: Ensure all documented policies and procedures are actively implemented and followed throughout the organization.
• Communicate Effectively: Distribute and communicate security policies and procedures to all relevant personnel, including employees, contractors, and third-party vendors who have access to cardholder data or security controls. Consider conducting training sessions to ensure everyone understands their roles and responsibilities.

How to Comply with this Requirement:

PCI DSS Requirement 11.1.2: Documented and Understood Roles and Responsibilities

This requirement emphasizes the importance of clearly defining and documenting roles and responsibilities for personnel involved in activities outlined within Requirement 11 (Testing Security Systems and Processes). It ensures everyone understands their part in maintaining secure systems and processes.

• Roles: Broad categories of security-related functions assigned within an organization (e.g., Security Administrator, System Administrator).
• Responsibilities: Specific tasks or duties associated with a particular role (e.g., performing vulnerability scans, reviewing security logs).

Business Implication:

• Improved Accountability and Efficiency: Clearly defined and documented roles and responsibilities ensure everyone understands their security obligations and how their actions contribute to overall security posture. This fosters accountability and leads to more efficient execution of security tasks.

Best Practices to Meet this Requirement:

• Develop a Role Assignment Matrix (RACI Matrix): Create a documented matrix that outlines roles, responsibilities, accountabilities, consulted parties, and informed parties (RACI) for each activity related to Requirement 11.
• Integrate with Security Policies: Consider incorporating roles and responsibilities into existing security policies or creating a separate document specifically for this purpose.
• Communicate and Obtain Acknowledgement: Effectively communicate assigned roles and responsibilities to relevant personnel. You may require personnel to acknowledge their understanding and acceptance of these responsibilities.

How to Comply with this Requirement:

PCI DSS Requirement 11.2: Wireless access points are identified and monitored, and unauthorized wireless access points are addressed

PCI DSS Requirement 11.2.1: Management of Authorized and Unauthorized Wireless Access Points

This requirement focuses on managing both authorized and unauthorized wireless access points (Wi-Fi) within your network environment. It mandates that you regularly test for their presence, identify them, and take appropriate actions to address any unauthorized devices.

• Authorized Wireless Access Points: Wi-Fi access points that are deliberately installed and approved for use within your network.
• Unauthorized Wireless Access Points (Rogue Access Points): Wi-Fi access points that are not authorized or approved for use within your network. These can be malicious devices installed by attackers or unauthorized personal devices brought in by employees.

Business Implication:

• Reduced Risk of Network Intrusion and Data Breaches: Identifying and removing unauthorized wireless access points helps mitigate the risk of attackers gaining access to your network and potentially compromising cardholder data. This translates to a reduced risk of data breaches and associated financial losses.

Best Practices to Meet this Requirement:

• Develop a Detection Strategy: Define procedures for identifying both authorized and unauthorized wireless access points within your network. This may involve a combination of methods, such as:
  • Wireless Network Scans: Regularly scanning your network for active Wi-Fi devices to identify both authorized and unauthorized access points.
  • Physical Inspections: Conducting periodic physical inspections of network devices and user equipment to ensure no unauthorized access points are attached.
  • Network Access Control (NAC): Implementing a system that automatically identifies and restricts unauthorized devices attempting to connect to your network.
  • Wireless Intrusion Detection/Prevention Systems (WIDS/WIPS): Deploying systems that detect and potentially prevent suspicious activity on your wireless network.
• Schedule Regular Testing: Perform thorough assessments for unauthorized access points at least quarterly (every three months).
• Utilize Automated Monitoring (Optional): If you use automated monitoring tools like NAC or WIDS/WIPS, ensure they are configured to generate alerts for potential unauthorized devices.
• Maintain Records: Document the results of your wireless access point assessments, including identified devices, actions taken, and remediation efforts.

How to Comply with this Requirement:

PCI DSS Requirement 11.2.2: Inventory of Authorized Wireless Access Points

This requirement mandates maintaining a comprehensive inventory of all authorized wireless access points (Wi-Fi) within your network environment. It also emphasizes the need for documented business justifications for each authorized access point.

• Authorized Wireless Access Points: Wi-Fi access points that are deliberately installed and approved for use within your network.

Business Implication:

• Improved Threat Detection and Response: Having a clear inventory of authorized access points allows you to quickly identify and address any unauthorized devices detected on your network. This reduces the window of opportunity for attackers to exploit vulnerabilities and potentially compromise your systems.

Best Practices to Meet this Requirement:

• Develop and Maintain an Inventory: Create a documented list of all authorized wireless access points within your network. This inventory should include details like:
  • Access Point Location
  • Access Point Model/Manufacturer
  • Unique Identifier (MAC Address)
  • Business Justification for Each Access Point
• Document Business Justifications: For each authorized access point, explain the specific business need or reason for its existence.
• Regularly Review and Update: Periodically review and update your wireless access point inventory to reflect any changes or additions to your network.

How to Comply with this Requirement:

PCI DSS Requirement 11.3: External and internal vulnerabilities are regularly identified, prioritized, and addressed

PCI DSS Requirement 11.3.1: Internal Vulnerability Scans

This requirement focuses on conducting regular internal vulnerability scans to identify and address weaknesses within your network systems and applications. It outlines specific steps to ensure these scans are performed effectively.

• Vulnerability Scan: An automated process that identifies potential weaknesses and security flaws within systems, applications, and network devices.
• High-Risk and Critical Vulnerabilities: These vulnerabilities pose the most significant security threats and require immediate attention. The specific risk classification is determined by your vulnerability risk rankings established in Requirement 6.3.1.

Business Implication:

• Reduced Risk of System Exploits and Data Breaches: Regular vulnerability scans help proactively identify potential security weaknesses before attackers can exploit them. This reduces the risk of system compromises and data breaches, protecting your organization from financial losses and reputational damage.

Best Practices to Meet this Requirement:

• Schedule Regular Scans: Perform internal vulnerability scans at least once every three months (quarterly). Consider more frequent scans based on your network complexity and the nature of your systems.
• Prioritize Remediation: Focus on resolving high-risk and critical vulnerabilities identified during scans as a top priority. These vulnerabilities pose the greatest threat and require immediate attention.
• Conduct Rescans for Resolved Vulnerabilities: After addressing vulnerabilities, perform rescans to verify their successful remediation.
• Maintain Up-to-date Scan Tools: Ensure your vulnerability scanning tools are updated with the latest vulnerability information to detect even recently discovered weaknesses.
• Qualified Personnel: Internal scans can be performed by qualified internal staff with appropriate independence from the systems being scanned. Alternatively, you can outsource scans to a qualified external vendor.

How to Comply with this Requirement:

PCI DSS Requirement 11.3.1.1 : Management of Non-Critical Vulnerabilities

This requirement (currently a best practice, becoming mandatory after March 31, 2025) focuses on addressing vulnerabilities identified during internal scans that are not classified as high-risk or critical according to your organization's risk rankings (defined in Requirement 6.3.1).

• Targeted Risk Analysis: A formal process that identifies and prioritizes security risks within your environment, considering the likelihood and potential impact of various threats.

Business Implication:

• Improved Overall Security Posture: By addressing all identified vulnerabilities, even those deemed less critical, you can proactively mitigate potential security risks and reduce the attack surface for malicious actors. This translates to a more robust security posture and enhanced protection for your organization's data.

Best Practices to Meet this Requirement:

• Prioritize Based on Risk Analysis: Evaluate all non-critical vulnerabilities identified during scans. Use your targeted risk analysis (performed as per Requirement 12.3.1) to determine the appropriate remediation timeframe for each vulnerability based on its associated risk (likelihood and impact).
• Address Based on Risk: Develop a plan to address non-critical vulnerabilities based on the assigned risk level. This may involve patching, implementing compensating controls, or accepting the risk with justification.
• Rescan for Verification: After addressing vulnerabilities, conduct rescans as needed to confirm their successful remediation.

How to Comply with this Requirement (Best Practice):

PCI DSS Requirement 11.3.1.2: Authenticated Internal Vulnerability Scans (New Requirement as of March 31, 2025)

This requirement (becoming mandatory after March 31, 2025) emphasizes the use of authenticated scans for internal vulnerability assessments. Authenticated scans provide a more thorough evaluation by accessing system resources with credentials, unlike unauthenticated scans with limited visibility.

• Authenticated Scan: A vulnerability scan that utilizes credentials to access system resources for a more in-depth analysis.
• Sufficient Privileges: Credentials used for authenticated scans must have appropriate access rights to conduct a comprehensive vulnerability assessment.

Business Implication:

• Enhanced Vulnerability Detection: Authenticated scans can identify a wider range of vulnerabilities compared to unauthenticated scans. This leads to a more complete understanding of your security posture and helps address potential weaknesses before attackers exploit them.

Best Practices to Meet this Requirement:

• Utilize Authenticated Scans: Configure your vulnerability scanning tools to perform authenticated scans whenever possible.
• Manage Credentials Securely: Credentials used for authenticated scans are considered highly privileged. Implement strict controls to protect them, following PCI DSS Requirements 7 and 8 (excluding multi-factor authentication and application/system account requirements).
• Document Unauthenticatable Systems: If any systems within your environment cannot accept credentials for scanning, document them clearly.

How to Comply with this Requirement (New Requirement as of March 31, 2025):

PCI DSS Requirement 11.3.1.3: Internal Vulnerability Scans after Significant Changes

This requirement mandates conducting internal vulnerability scans after any significant changes are made to your network or system components. It emphasizes identifying and resolving high-risk and critical vulnerabilities introduced by these changes.

• Significant Change: Any modification to your network environment or system components that could potentially impact security. This may include adding new devices, installing software updates, or modifying system configurations.

Business Implication:

• Reduced Risk after Changes: Changes within your network environment can introduce new vulnerabilities. Performing vulnerability scans after significant changes helps ensure these changes haven't compromised your security posture and allows you to address any identified weaknesses promptly. This translates to reduced risk of security breaches and data loss.

Best Practices to Meet this Requirement:

• Integrate with Change Management: Make vulnerability scanning after significant changes a mandatory step within your change control process (as defined in Requirement 6.5.2). This ensures scans are performed before considering a change complete.
• Identify Affected Systems: Clearly define which system components are impacted by the change. All affected components should be included in the post-change vulnerability scan.
• Prioritize Remediation: Focus on resolving high-risk and critical vulnerabilities identified during post-change scans as a top priority.
• Qualified Personnel: Scans can be conducted by qualified internal staff with appropriate independence from the systems being scanned. Alternatively, you can outsource scans to a qualified external vendor.

How to Comply with this Requirement:

PCI DSS Requirement 11.3.2 : External Vulnerability Scans

This requirement mandates conducting external vulnerability scans on your network environment at least once every three months. These scans must be performed by a PCI SSC Approved Scanning Vendor (ASV). The identified vulnerabilities need to be addressed, and the scans must meet the passing criteria outlined in the ASV Program Guide.

• External Vulnerability Scan: A security assessment that identifies potential weaknesses within systems and devices accessible from the public internet.
• PCI SSC Approved Scanning Vendor (ASV): A security vendor approved by the PCI Security Standards Council (PCI SSC) to perform external vulnerability scans in accordance with PCI DSS requirements.
• Passing Scan: An external vulnerability scan that meets the criteria defined in the ASV Program Guide, indicating a sufficiently secure external facing environment.

Business Implication:

• Reduced Risk of External Attacks: External vulnerability scans proactively identify weaknesses in your publicly accessible systems. Addressing these vulnerabilities helps minimize the attack surface and reduces the risk of attackers exploiting them to gain access to your network and sensitive data.

Best Practices to Meet this Requirement:

• Schedule Regular Scans: Perform external vulnerability scans at least quarterly (every 3 months) using a PCI SSC ASV.
• Remediate Identified Vulnerabilities: Prioritize and address vulnerabilities identified during scans. Ensure your remediation efforts meet the passing criteria established in the ASV Program Guide.
• Conduct Rescans for Verification: After addressing vulnerabilities, conduct rescans to confirm their successful remediation and achieve a passing scan result.
• More Frequent Scans (Optional): Consider conducting scans more frequently than quarterly based on your network complexity and the nature of your systems.

How to Comply with this Requirement:

PCI DSS Requirement 11.3.2.1: External Vulnerability Scans After Significant Changes

This requirement (introduced for PCI DSS v4.0) emphasizes conducting external vulnerability scans after any significant changes are made to your publicly facing systems or network. It focuses on resolving high-severity vulnerabilities (CVSS score of 4.0 or higher) identified during these scans.

• CVSS (Common Vulnerability Scoring System): An industry-standard scoring system that assigns a severity level (0.0-10.0) to computer security vulnerabilities. Higher scores indicate greater severity.

Business Implication:

• Minimized Risk After External Changes: Changes to your external environment can introduce new vulnerabilities. Performing external vulnerability scans after significant changes helps ensure these changes haven't weakened your security posture and allows you to address any critical vulnerabilities promptly. This translates to reduced risk of external attacks exploiting these weaknesses.

Best Practices to Meet this Requirement:

• Integrate with Change Management: Make external vulnerability scanning after significant changes a mandatory step within your change control process. This ensures scans are performed before considering a change complete.
• Identify Affected Systems: Clearly define which external system components are impacted by the change. All affected components should be included in the post-change external vulnerability scan.
• Prioritize High-Severity Vulnerabilities: Focus on resolving vulnerabilities with a CVSS score of 4.0 or higher (considered high severity) as a top priority following post-change scans.
• Qualified Personnel: Scans can be conducted by qualified internal staff with appropriate expertise in external vulnerability assessments. Alternatively, you can outsource scans to a qualified external vendor.

How to Comply with this Requirement:

PCI DSS Requirement 11.4: External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected

PCI DSS Requirement 11.4.1: Penetration Testing Methodology

This requirement mandates establishing, documenting, and implementing a comprehensive penetration testing methodology. Penetration testing simulates real-world attacks to identify security weaknesses within your Cardholder Data Environment (CDE) and critical systems.

• Penetration Testing: A simulated attack on a computer system or network to identify vulnerabilities that could be exploited by malicious actors.
• Cardholder Data Environment (CDE): The physical, logical, and procedural environment where cardholder data is processed, stored, or transmitted.

Business Implication:

• Proactive Security Posture: Penetration testing helps proactively identify and address security weaknesses in your environment before attackers can exploit them. This reduces the risk of data breaches and associated financial losses.

Best Practices to Meet this Requirement:

• Develop a Formal Methodology: Create a documented penetration testing methodology that incorporates all elements specified in this requirement.
• Industry-Accepted Approaches: Utilize established industry practices like OSSTMM or OWASP for penetration testing methodologies.
• Comprehensive Coverage: Ensure your methodology covers the entire CDE perimeter, critical systems, and includes testing from both internal and external perspectives.
• Validate Segmentation Controls: Design tests to validate the effectiveness of segmentation and scope-reduction controls implemented within your environment.
• Application-Layer Testing: Include application-layer penetration testing to identify vulnerabilities listed in Requirement 6.2.4 (known exploitable vulnerabilities).
• Network-Layer Testing: Perform network-layer penetration tests to assess the security of your network components and operating systems.
• Threat-Informed Testing: Consider past threats and vulnerabilities experienced within the last 12 months when designing your penetration testing approach.
• Vulnerability Assessment and Remediation: Establish a documented process to assess the risk posed by identified vulnerabilities and implement appropriate remediation plans.
• Retention of Results: Retain penetration testing results and remediation activities for at least 12 months for audit purposes.

How to Comply with this Requirement:

PCI DSS Requirement 11.4.2: Internal Penetration Testing

This requirement mandates conducting internal penetration testing on your Cardholder Data Environment (CDE) and critical systems. These tests simulate real-world attacks to identify security weaknesses within your internal environment.

• Frequency: Internal penetration testing must be performed:
  • At least annually: A minimum of once every 12 months.
  • After significant changes: Additional tests are required following any major infrastructure or application upgrades or changes within your CDE.
• Qualified Testers: These tests can be conducted by qualified internal staff with the necessary expertise or outsourced to a qualified external vendor.
• Organizational Independence: Regardless of whether you use internal staff or an external vendor, the testers must maintain organizational independence. This means they should not be responsible for managing or maintaining the systems they are testing.

Business Implication:

• Proactive Defense Against Insider Threats: Internal penetration testing helps proactively identify security weaknesses within your own systems and network that could be exploited by malicious insiders. This helps minimize the risk of internal attacks and data breaches.

Best Practices to Meet this Requirement:

• Schedule Regular Internal Pen Tests: Integrate internal penetration testing into your security program. Conduct tests at least annually as per your defined methodology.
• Test After Significant Changes: Don't wait for your annual test. Include internal penetration testing as part of your change control process. Perform additional tests after any significant infrastructure or application upgrades or changes to ensure they haven't introduced new vulnerabilities.
• Qualified Testers: Ensure internal penetration testing is conducted by qualified personnel with the necessary knowledge and experience in penetration testing methodologies. You can also outsource these tests to a qualified external vendor specializing in internal penetration testing.
• Maintain Tester Independence: Regardless of whether you use internal staff or an external vendor, ensure the testers are organizationally independent. This means they should have no conflicts of interest and should not be responsible for the day-to-day operations or maintenance of the systems they are testing.

How to Comply with this Requirement:

PCI DSS Requirement 11.4.3: External Penetration Testing

This requirement mandates conducting external penetration testing on your Cardholder Data Environment (CDE) and critical systems. These tests simulate attacks from an external perspective to identify vulnerabilities that could be exploited by malicious actors on the internet.

• Frequency: External penetration testing must be performed:
  • At least annually: A minimum of once every 12 months.
  • After significant changes: Additional tests are required following any major infrastructure or application upgrades or changes within your CDE.
• Qualified Testers: These tests can be conducted by qualified internal staff with the necessary expertise or outsourced to a qualified external vendor specializing in penetration testing.
• Organizational Independence: Regardless of whether you use internal staff or an external vendor, the testers must maintain organizational independence. This means they should not be a conflict of interest and should not be responsible for managing or maintaining the systems they are testing.

Business Implication:

• Proactive Defense Against External Threats: External penetration testing helps proactively identify security weaknesses that could be exploited by attackers on the internet. This minimizes the risk of external attacks and data breaches.

Best Practices to Meet this Requirement:

• Schedule Regular External Pen Tests: Integrate external penetration testing into your security program. Conduct tests at least annually as per your defined methodology.
• Test After Significant Changes: Don't wait for your annual test. Include external penetration testing as part of your change control process. Perform additional tests after any significant infrastructure or application upgrades or changes to ensure they haven't introduced new vulnerabilities.
• Choose Qualified Testers: Select qualified internal staff with expertise in external penetration testing methodologies or hire a qualified external vendor specializing in this area. Consider factors like relevant certifications and prior experience when choosing a vendor.
• Maintain Tester Independence: Ensure the testers, whether internal staff or external vendors, maintain organizational independence. This means they should have no conflicts of interest and should not be responsible for the day-to-day operations or maintenance of the systems they are testing.

How to Comply with this Requirement:

PCI DSS Requirement 11.4.4: Remediation of Penetration Testing Findings

This requirement mandates addressing exploitable vulnerabilities and security weaknesses identified during penetration testing.

• Risk-Based Remediation: Remediation efforts should be prioritized based on the severity of the vulnerability and the risk it poses to your environment. This aligns with Requirement 6.3.1 which outlines the vulnerability assessment process.
• Verification of Fixes: Following remediation efforts, penetration testing should be repeated (or vulnerability scanning can be used) to verify that the identified vulnerabilities have been effectively addressed.

Business Implication:

• Reduced Risk of Data Breaches: Addressing security weaknesses identified during penetration testing minimizes the likelihood of attackers exploiting them and compromising your systems or data.

Best Practices to Meet this Requirement:

• Prioritize Remediation: Classify identified vulnerabilities based on their severity and potential impact. Focus on remediating high-risk vulnerabilities first, as defined in your risk assessment process (Requirement 6.3.1).
• Implement Remediation Measures: Develop and implement appropriate remediation measures to address the identified vulnerabilities. This may involve patching systems, hardening configurations, or implementing additional security controls.
• Verification Testing: After remediating vulnerabilities, conduct follow-up testing (e.g., penetration retesting or vulnerability scanning) to ensure the vulnerabilities have been effectively addressed and are no longer exploitable.

How to Comply with this Requirement:

PCI DSS Requirement 11.4.5: Penetration Testing of Segmentation Controls

This requirement applies specifically to organizations that use network segmentation to isolate their Cardholder Data Environment (CDE) from other networks. It mandates conducting penetration testing specifically focused on validating the effectiveness of these segmentation controls.

• Frequency: Penetration testing of segmentation controls must be performed:
  • At least annually: A minimum of once every 12 months.
  • After changes: Additional testing is required whenever changes are made to the segmentation controls or methods used within your environment.
• Scope: The testing should cover all segmentation controls and methods in use within your network.
• Methodology: The testing should be conducted according to your defined penetration testing methodology (refer to Requirement 11.4.1 for details on defining a methodology).
• Effectiveness Confirmation: The testing should confirm that the segmentation controls are operational, effective, and successfully isolate the CDE from all out-of-scope systems (systems not processing cardholder data).
• Isolation of Different Security Levels: If you use segmentation to separate systems with varying security levels (as required by Requirement 2.2.3), the testing should also confirm the effectiveness of this isolation.
• Qualified Testers: These tests can be conducted by qualified internal staff with the necessary expertise or outsourced to a qualified external vendor specializing in penetration testing.
• Organizational Independence: Regardless of whether you use internal staff or an external vendor, the testers must maintain organizational independence. This means they should not be responsible for managing or maintaining the segmentation controls they are testing.

Business Implication:

• Reduced Risk of Lateral Movement in Attacks: Segmentation helps prevent attackers from moving laterally within your network and accessing the CDE. Penetration testing of segmentation controls verifies their effectiveness and minimizes the risk of attackers bypassing these controls and compromising your cardholder data.

Best Practices to Meet this Requirement:

• Schedule Regular Segmentation Pen Tests: Integrate penetration testing of segmentation controls into your security program. Conduct tests at least annually as per your defined methodology.
• Test After Segmentation Changes: Don't wait for your annual test. Include penetration testing of segmentation controls as part of your change control process. Perform additional tests whenever there are any changes to the segmentation controls or methods used within your network.
• Test All Segmentation Methods: Ensure your penetration testing methodology covers all segmentation controls and methods you have implemented to isolate the CDE.
• Verify Isolation Effectiveness: The testing should go beyond simply verifying the controls are operational. It should actively test whether attackers can bypass these controls and gain access to the CDE from untrusted or out-of-scope systems.
• Consider Isolation of Different Security Levels: If you use segmentation to separate systems with different security levels, include tests to verify the effectiveness of this isolation within your penetration testing procedures.

How to Comply with this Requirement:

PCI DSS Requirement 11.4.6: Additional Penetration Testing for Service Providers (Segmentation Controls)

This requirement applies specifically to service providers who use network segmentation to isolate their Cardholder Data Environment (CDE) from other networks. It mandates more frequent penetration testing of these segmentation controls compared to the general requirement (11.4.5).

• Applicability: This requirement only applies to organizations classified as service providers under PCI DSS.
• Frequency: Penetration testing of segmentation controls for service providers must be performed:
  • At least every six months: More frequent testing is required compared to the annual testing mandated for regular entities (Requirement 11.4.5).
  • After changes: Additional testing is required whenever changes are made to the segmentation controls or methods used within the service provider's network.
• Other Elements: The remaining elements of this requirement mirror those of Requirement 11.4.5. The testing should cover all segmentation methods, be conducted according to the defined methodology, verify control effectiveness, and be performed by qualified independent testers.

Business Implication:

• Enhanced Security for Cardholder Data: Service providers handle large volumes of cardholder data and may be a prime target for attackers. More frequent testing of segmentation controls helps ensure the CDE remains isolated and minimizes the risk of attackers bypassing these controls and compromising cardholder data.

Best Practices to Meet this Requirement:

• Schedule Frequent Segmentation Pen Tests: Integrate penetration testing of segmentation controls into your security program for service providers. Conduct tests at least every six months as per your defined methodology.
• Test After Segmentation Changes: Don't wait for the six-month mark. Include penetration testing of segmentation controls as part of your change control process. Perform additional tests whenever there are any changes to the segmentation controls or methods used within your network.
• Consider More Frequent Testing: While the requirement mandates testing every six months, consider conducting these tests even more frequently for enhanced security.

How to Comply with this Requirement:

PCI DSS Requirement 11.4.7: Support for Customer Penetration Testing (Multi-Tenant Service Providers)

This requirement applies specifically to multi-tenant service providers who offer shared or cloud environments to their customers. It mandates that these providers support their customers' efforts to conduct external penetration testing on their own systems within the shared environment.

• Applicability: This requirement only applies to organizations classified as multi-tenant service providers under PCI DSS.
• Support for Customer Pen Testing: Multi-tenant service providers must have a process in place to support their customers with external penetration testing required by PCI DSS (Requirements 11.4.3 and 11.4.4). There are two ways to achieve this:
  • Providing Evidence of Performed Testing: The service provider can provide documented evidence to its customers that penetration testing has already been performed on their subscribed infrastructure, meeting the requirements of 11.4.3 (frequency, methodology) and 11.4.4 (vulnerability remediation). This evidence can include redacted penetration testing reports but must contain enough detail to demonstrate all elements of these requirements were addressed for the customer's specific environment.
  • Providing Access for Customer Pen Testing: Alternatively, the service provider can provide its customers with direct access to conduct their own penetration testing on their subscribed infrastructure within the shared environment.

Business Implication:

• Shared Responsibility for Security in Cloud: In a shared or cloud environment, the security responsibility is shared between the service provider and the customer. This requirement ensures that customers have the ability to verify the security of their own environment within the provider's infrastructure.

Best Practices to Meet this Requirement:

• Develop a Customer Pen Testing Support Process: Establish a clear process for how you will support your customers with external penetration testing. This may involve offering options for them to receive evidence of performed testing or providing them with access to conduct their own testing.
• Provide Documented Evidence (if chosen): If you choose to provide evidence of performed testing, ensure the documentation includes enough detail while being redacted to protect sensitive information. It should clearly demonstrate that testing was conducted according to PCI DSS requirements (11.4.3 and 11.4.4) for the customer's specific environment.
• Facilitate Customer-Conducted Testing (if chosen): If you choose to provide access for customer-conducted testing, establish clear guidelines and procedures for how customers can request and conduct penetration testing within your shared environment. Ensure this process minimizes disruption to other customers and maintains the overall security posture.

How to Comply with this Requirement:

Important Notes:

• This requirement is currently a best practice but becomes mandatory after March 31, 2025.

Refer to Appendix A1 of the PCI DSS for additional details on requirements for multi-tenant service providers.

PCI DSS Requirement 11.5: Network intrusions and unexpected file changes are detected and responded to

PCI DSS Requirement 11.5.1: Intrusion Detection and Prevention

This requirement mandates implementing intrusion detection and/or intrusion prevention (IDS/IPS) techniques to monitor network traffic within your Cardholder Data Environment (CDE).

• Intrusion Detection System (IDS): A security system that monitors network traffic for suspicious activity and raises alerts when potential attacks are detected.
• Intrusion Prevention System (IPS): A security system that actively blocks or prevents malicious network traffic from entering or leaving a network.
• Critical Points: Locations within your network that are considered particularly sensitive and require additional monitoring due to the data or systems they connect to.

Business Implication:

• Early Detection of Network Intrusions: IDS/IPS systems help detect suspicious network activity and potential intrusions in real-time. This allows for faster response and minimizes the window of opportunity for attackers to exploit vulnerabilities and compromise your systems.

Best Practices to Meet this Requirement:

• Deploy IDS/IPS at the Perimeter: Implement intrusion detection/prevention systems at the perimeter of your CDE to monitor all incoming and outgoing network traffic.
• Monitor Critical Points: In addition to the perimeter, monitor critical points within your CDE where sensitive data resides or where systems communicate with each other. Examples include network segments separating the DMZ from internal networks or connections between high-risk and low-risk systems.
• Alert Personnel of Compromises: Configure your IDS/IPS to generate alerts for suspicious activity and ensure personnel responsible for security are notified promptly to investigate and respond.
• Maintain Updated Systems: Regularly update the engines, baselines, and signature databases within your IDS/IPS systems to ensure they can identify the latest threats and vulnerabilities.

How to Comply with this Requirement:

PCI DSS Requirement 11.5.1.1: Service Provider Detection of Covert Malware Communication Channels (Best Practice)

This requirement applies specifically to service providers under PCI DSS. It mandates the implementation of controls to detect, alert on, prevent, and address covert malware communication channels.Currently, this is a best practice, but it becomes mandatory after March 31, 2025.

• Covert Malware Communication: This refers to techniques used by malware to hide its communication with a command-and-control (C&C) server. Attackers may use various methods like DNS tunneling or steganography to establish communication channels that traditional security measures might miss.
• Detection and Prevention: Service providers must have mechanisms in place to detect these covert communication attempts. This may involve real-time endpoint scanning, egress traffic filtering, or network security monitoring tools like IDS/IPS. The goal is to identify and block such communication channels before they can be used for malicious purposes (data exfiltration, receiving instructions, etc.).
• Alerting and Response: The implemented mechanisms should also generate alerts when suspicious communication channels are detected. The service provider's incident response plan (Requirement 12.10.1) should define procedures for responding to these alerts, which may involve blocking the communication and investigating potential malware infections.
• Personnel Knowledge: Personnel responsible for security should be knowledgeable about covert malware communication techniques and how to respond to them when detected.

Business Implication:

• Reduced Risk of Data Breaches: By detecting and blocking covert communication channels, service providers can prevent malware from exfiltrating cardholder data or receiving instructions for further attacks. This helps minimize the risk of data breaches and associated financial losses.

Best Practices to Meet this Requirement:

• Implement Detection Techniques: Deploy endpoint scanning, egress traffic filtering, or network security monitoring tools to identify suspicious communication attempts.
• Maintain Updated Knowledge: Ensure your security personnel stay updated on the latest covert malware communication techniques to effectively identify and respond to them.
• Integrate with Incident Response: Include clear procedures for responding to alerts generated by your detection mechanisms within your incident response plan.

How to Comply with this Requirement (Service Providers Only):

PCI DSS Requirement 11.5.2: Change-Detection Mechanism

This requirement mandates the deployment of a change-detection mechanism to monitor critical files within your environment.

• Change-Detection Mechanism: This refers to a security tool, like File Integrity Monitoring (FIM), that tracks changes made to critical files on your systems.
• Critical Files: These are system, configuration, or content files that, if modified, could indicate a system compromise or increased risk. They typically don't change regularly but are essential for system operation or security. Examples include system executables, application executables, configuration files, and audit logs. The specific critical files will vary depending on your environment and can be identified through risk assessments.
• Alerting Personnel: The change-detection mechanism should be configured to alert personnel whenever unauthorized modifications (additions, changes, deletions) are detected in critical files. This allows for prompt investigation and potential remediation.
• Weekly Comparisons: At least once a week, the change-detection mechanism should perform a comparison of critical files to identify any changes that may have occurred since the last comparison. This helps ensure timely detection of unauthorized modifications.

Business Implication:

• Reduced Risk of Undetected Attacks: By monitoring critical files for unauthorized changes, you can identify potential attacks at an early stage. This helps prevent attackers from modifying system configurations or compromising security controls to steal cardholder data or conduct other malicious activities.

Best Practices to Meet this Requirement:

• Implement a Change-Detection Tool: Deploy a File Integrity Monitoring (FIM) tool or similar solution to monitor critical files within your environment.
• Identify Critical Files: Perform a risk assessment or leverage pre-configured lists from your FIM tool to identify critical files that require monitoring.
• Configure Alerts: Configure your change-detection mechanism to generate alerts for any unauthorized modifications detected in critical files.
• Schedule Weekly Comparisons: Set up automated weekly comparisons within your change-detection tool to identify any changes since the last comparison.
• Review Alerts and Investigate: Establish a process to review and investigate alerts generated by the change-detection mechanism to determine the legitimacy of the changes and take appropriate action if unauthorized modifications are identified.

How to Comply with this Requirement:

PCI DSS Requirement 11.6: Unauthorized changes on payment pages are detected and responded to

PCI DSS Requirement 11.6.1: Change and Tamper Detection for Payment Pages (Best Practice)

This requirement mandates the implementation of a change and tamper-detection mechanism specifically for payment pages.Currently, this is a best practice, but it becomes mandatory after March 31, 2025.

• Change and Tamper Detection: This refers to a mechanism that can identify unauthorized modifications (additions, changes, deletions) made to the content and HTTP headers of your payment pages as seen by the customer's browser. This helps detect techniques like Magecart attacks where malicious code is injected into payment pages to steal cardholder data.
• HTTP Headers: These are data packets containing information about the web page, like content type or encoding, sent before the actual page content. Attackers may manipulate headers to inject malicious scripts.
• Monitoring Frequency: The mechanism should be configured to evaluate the payment pages at least once every seven days. Alternatively, you can define a more frequent monitoring schedule based on your targeted risk analysis (Requirement 12.3.1).
• Alerting Personnel: The mechanism should generate alerts whenever it detects unauthorized changes to the payment pages or suspicious activity. This allows for prompt investigation and potential remediation.

Business Implication:

• Reduced Risk of Payment Card Data Theft: By detecting unauthorized modifications to your payment pages, you can prevent attackers from injecting skimming code to steal cardholder data during checkout. This helps safeguard your customers' financial information and protects your reputation.

Best Practices to Meet this Requirement:

• Implement Change-Detection Mechanism: Consider solutions like Content Security Policy (CSP) monitoring, synthetic user monitoring, or tamper-resistant scripts embedded in your payment pages to detect unauthorized changes.
• Define Monitoring Frequency: Establish a monitoring schedule based on your risk assessment. Weekly monitoring is the minimum requirement, but you can choose a more frequent approach based on your risk profile.
• Configure Alerts: Ensure your chosen mechanism generates alerts for any suspicious activity or unauthorized changes detected on your payment pages.
• Review and Investigate Alerts: Establish a process to review and investigate alerts generated by the change-detection mechanism to determine the legitimacy of the changes and take appropriate action if unauthorized modifications are identified.

How to Comply with this Requirement: