Disclaimer: This guide has been created with reference to official documents on the PCI DSS published by relevant government authorities. It is intended to provide a clear and comprehensive explanation of PCI DSS Requirement 11. The contents are for informational purposes only and should not be considered as legal advice. Organizations should consult with a qualified PCI DSS consultant to ensure compliance.
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
| Requirement | Actions required | How the assessment is done |
|---|---|---|
| 11.1.1 | Examine documentation for security policies and operational procedures related to Requirement 11.Interview personnel to assess their awareness and understanding of these policies and procedures. | The assessor will review your documented security policies and procedures to ensure they cover all aspects of Requirement 11.They will also interview relevant personnel to verify they are aware of these policies, understand their content, and follow them in their daily work. |
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: 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
| Requirement | Actions required | How the assessment is done |
| 11.1.2.a | Examine documentation for roles and responsibilities related to Requirement 11 activities. | The assessor will review your documented roles and responsibilities to ensure they cover all activities within Requirement 11. They will verify that specific personnel are assigned to each role. |
| 11.1.2.b | Interview personnel responsible for Requirement 11 activities. | The assessor will interview personnel assigned to security testing activities. They will assess their understanding of their roles and responsibilities as documented. |
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
| Requirement | Actions required | How the assessment is done |
| 11.2.1.a | Examine policies and procedures for managing wireless access points. | The assessor will review your documented procedures to ensure they cover all elements of this requirement, including detection, identification, and frequency of testing for authorized and unauthorized access points. |
| 11.2.1.b | Examine the methodologies used for wireless assessments and review resulting documentation.Interview personnel involved in the process. | The assessor will review your chosen methods for detecting unauthorized access points (e.g., scans, inspections) and assess their effectiveness. They will also interview personnel to understand how they identify authorized devices and handle unauthorized ones. |
| 11.2.1.c | Examine results of wireless assessments.Interview personnel involved in assessments. | The assessor will review the documented results of your wireless assessments, focusing on the identified access points (authorized and unauthorized). They will also interview personnel to verify the assessments were conducted quarterly and addressed all elements of the requirement. |
| 11.2.1.d (if applicable) | Examine configuration settings of automated monitoring tools (NAC, WIDS/WIPS). | If you use automated monitoring, the assessor will review the configuration of these tools to ensure they are set up to generate alerts for potential unauthorized access points. |
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
| Requirement | Actions required | How the assessment is done |
| 11.2.2 | Examine documentation for the inventory of authorized wireless access points. | The assessor will review your documented inventory to ensure it includes all authorized access points and details like location, model, and MAC address. They will also verify documented business justifications for each access point. |
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.
- Delegate to 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
| Requirement | Actions required | How the assessment is done |
| 11.3.1.a | Examine internal vulnerability scan reports from the past 12 months. | The assessor will review your scan reports for the last year to verify scans were conducted at least quarterly (every 3 months). |
| 11.3.1.b | Examine internal scan reports for each scan and rescan conducted in the last 12 months. | The assessor will review scan reports to ensure all identified high-risk and critical vulnerabilities (as defined in Requirement 6.3.1) were addressed through remediation efforts. |
| 11.3.1.c | Examine scan tool configurations and interview personnel. | The assessor will review your scan tool configurations to verify they are updated with the latest vulnerability information. They will also interview personnel to understand how updates are managed. |
| 11.3.1.d | Interview personnel responsible for vulnerability scans. | The assessor will interview personnel involved in internal scans to verify they are qualified and possess the necessary expertise. The interview will also assess the organizational independence of the testers (internal staff or external vendor). |
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):
| Requirement | Actions required | How the assessment is done |
| 11.3.1.1.a | Examine your targeted risk analysis document. | The assessor will review your risk analysis to ensure it considers all elements specified in Requirement 12.3.1, including identification of assets, threats, and risk evaluation for vulnerabilities. They will verify that the risk analysis includes non-critical vulnerabilities. |
| 11.3.1.1.b | Interview personnel responsible for vulnerability management and examine relevant documentation (e.g., scan reports, remediation plans). | The assessor will interview personnel involved in vulnerability management to understand how they address non-critical vulnerabilities based on the risk analysis. They will also review scan reports and other documentation to verify that identified vulnerabilities are addressed based on assigned risk levels, and that rescans are conducted for verification. |
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 systems that cannot be authenticated: 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):
| Requirement | Actions required | How the assessment is done |
| 11.3.1.2.a | Examine scan tool configurations to verify authenticated scanning is used.For systems accepting credentials, verify sufficient privileges are assigned to the scan accounts. | The assessor will review your scan tool configurations to ensure they are set up for authenticated scans. They will also assess privilege levels for scan accounts used on systems accepting credentials. |
| 11.3.1.2.b | Examine scan reports and interview personnel to confirm authenticated scans were performed. | The assessor will review scan reports to verify they were conducted using authenticated methods. They will also interview personnel involved in scans to confirm the process. |
| 11.3.1.2.c (if applicable) | If accounts used for scans can also be used for interactive login, examine the accounts and interview personnel.Verify these accounts are managed following Requirement 8.2.2. | The assessor will examine scan accounts with interactive login capabilities (if applicable). They will interview personnel and review controls to ensure these accounts are managed according to Requirement 8.2.2 (secure password practices, restricted access, etc.). |
| 11.3.1.2.d | Examine documentation to verify documented systems that cannot accept credentials for scanning. | The assessor will review your documentation to ensure all systems that cannot undergo authenticated scans are clearly identified and justified. |
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
| Requirement | Actions required | How the assessment is done |
| 11.3.1.3.a | Examine change control documentation and internal scan reports. | The assessor will review your change control records and internal scan reports to verify that scans were performed after documented significant changes. They will ensure the scans covered all affected system components. |
| 11.3.1.3.b | Interview personnel and examine internal scan and rescan reports. | The assessor will interview personnel involved in the change and vulnerability management processes. They will review scan reports to verify scans were conducted after significant changes and that identified high-risk and critical vulnerabilities were addressed (as defined in Requirement 6.3.1). |
| 11.3.1.3.c | Interview personnel responsible for vulnerability scans. | The assessor will interview personnel involved in post-change vulnerability scans to verify they are qualified and possess the necessary expertise. The interview will also assess the organizational independence of the testers (internal staff or external vendor). |
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 Security Standards Counsil (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 ASV: A security vendor approved by the 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
| Requirement | Actions required | How the assessment is done |
| 11.3.2.a | Examine ASV scan reports from the past 12 months. | The assessor will review your ASV scan reports for the last year to verify scans were conducted at least quarterly (every three months). |
| 11.3.2.b | Examine ASV scan reports for each scan and rescan conducted in the last 12 months. | The assessor will review scan reports to ensure they identify vulnerabilities and demonstrate successful remediation efforts, meeting the passing criteria outlined in the ASV Program Guide. |
| 11.3.2.c | Examine ASV scan reports to verify they were performed by a PCI SSC ASV. | The assessor will review your scan reports to confirm they were conducted by a vendor listed on the PCI SSC ASV listing: https://www.pcisecuritystandards.org/assessors_and_solutions/approved_scanning_vendors |
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.
- Common Vulnerability Scoring System (CVSS): 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
| Requirement | Actions required | How the assessment is done |
| 11.3.2.1.a | Examine change control documentation and external scan reports. | The assessor will review your change control records and external scan reports to verify scans were performed after documented significant changes. They will ensure the scans covered all affected external system components. |
| 11.3.2.1.b | Interview personnel and examine external scan and rescan reports. | The assessor will interview personnel involved in the change and vulnerability management processes. They will review scan reports to verify scans were conducted after significant changes and that high-severity vulnerabilities (CVSS score 4.0 or higher) were addressed. |
| 11.3.2.1.c | Interview personnel responsible for external vulnerability scans. | The assessor will interview personnel involved in post-change external vulnerability scans to verify they are qualified and possess the necessary expertise in external assessments. The interview will also assess the organizational independence of the testers (internal staff or external vendor). |
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.
- 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 likeOpen Source Security Testing Methodology Manual(OSSTMM) or Open Web Application Security Project (OWASP) for penetration testing methodologies.
- Comprehensive coverage: Ensure your methodology covers the entire CDE perimeter and all 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.
- Applicationlayer testing: Include applicationlayer penetration testing to identify vulnerabilities listed in Requirement 6.2.4 (known exploitable vulnerabilities).
- Networklayer testing: Perform networklayer 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
| Requirement | Actions required | How the assessment is done |
| 11.4.1 | Examine documentation and interview personnel. | The assessor will review your penetration testing methodology document and interview personnel involved in penetration testing to verify it incorporates all elements specified in 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
| Requirement | Actions required | How the assessment is done |
| 11.4.2.a | Examine the scope of work and results from the most recent internal penetration test. | The assessor will review the scope and results of your latest internal penetration test report. They will verify that the testing was performed in accordance with your defined methodology and addressed all elements specified in Requirement 11.4.1 (refer to previous explanation for details on 11.4.1). |
| 11.4.2.b | Interview personnel involved in internal penetration testing. | The assessor will interview personnel responsible for internal penetration testing to verify:The tests were conducted by qualified internal staff or a qualified external vendor with expertise in penetration testing methodologies.Organizational independence of the testers exists (they are independent from the systems being tested). |
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
| Requirement | Actions required | How the assessment is done |
| 11.4.3.a | Examine the scope of work and results from the most recent external penetration test. | The assessor will review the scope and results of your latest external penetration test report. They will verify that the testing was performed in accordance with your defined methodology and addressed all elements specified in Requirement 11.4.1 (refer to previous explanation for details on 11.4.1). |
| 11.4.3.b | Interview personnel involved in external penetration testing. | The assessor will interview personnel responsible for external penetration testing to verify:The tests were conducted by qualified internal staff or a qualified external vendor with expertise in external penetration testing methodologies.Organizational independence of the testers exists (they are independent from the systems being tested). |
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
| Requirement | Actions required | How the assessment is done |
| 11.4.4 | Examine penetration testing results and review the entity's vulnerability risk assessment process. | The assessor will review your penetration testing report and vulnerability risk assessment documentation. They will verify that:Identified vulnerabilities are classified based on severity and potential impact, aligning with your risk assessment process.Remediation efforts prioritize addressing high-risk vulnerabilities. |
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
| Requirement | Actions required | How the assessment is done |
| 11.4.5.a | Examine segmentation controls and review penetration testing methodology. | The assessor will review your segmentation controls and your defined penetration testing methodology. They will verify that the methodology includes procedures to test all segmentation methods in accordance with the elements specified in this requirement. |
| 11.4.5.b | Examine the results from the most recent penetration test of segmentation controls. | The assessor will review the results of your latest penetration test specifically focused on segmentation controls. They will verify the test covered and addressed all elements specified in this requirement, including: * Confirmation of segmentation control effectiveness in isolating the CDE. * Verification of isolation between systems with different security levels (if applicable). |
| 11.4.5.c | Interview personnel involved in segmentation control penetration testing. | The assessor will interview personnel responsible for penetration testing of segmentation controls to verify: * The tests were conducted by qualified internal staff or a qualified external vendor with expertise in penetration testing methodologies. * Organizational independence of the testers exists (they are independent from the segmentation controls they are testing). |
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 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 the 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
| Requirement | Actions required | How the assessment is done |
| 11.4.6.a (Service providers only) | Examine the results from the most recent penetration test of segmentation controls. | The assessor will review the results of your latest penetration test, specifically focused on segmentation controls. They will verify the test covered and addressed all elements specified in Requirement 11.4.5 (refer to previous explanation for details on 11.4.5). The assessor will pay close attention to the test frequency, ensuring it is conducted at least every six months and after any segmentation control changes. |
| 11.4.6.b (Service providers only) | Interview personnel involved in segmentation control penetration testing. | The assessor will interview personnel responsible for penetration testing of segmentation controls to verify: *The tests were conducted by qualified internal staff or a qualified external vendor with expertise in penetration testing methodologies. *Organizational independence of the testers exists (they are independent from the segmentation controls they are testing). |
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
| Requirement | Actions required (Multi-Tenant Service Provider) | How the assessment is done |
| 11.4.7 | Examine evidence provided to customers regarding performed penetration testing (if this option is chosen). Or review your process for facilitating customer-conducted penetration testing (if this option is chosen). | The assessor will review the evidence provided to customers (redacted penetration testing reports) to verify they demonstrate testing was conducted according to Requirements 11.4.3 and 11.4.4 for the customer's environment.Alternatively, the assessor will review your process for facilitating customer-conducted penetration testing. They will ensure you have clear procedures for customers to request and conduct testing while maintaining security within the shared environment. |
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 systems (IDSs) and/or intrusion prevention systems (IPSs) to monitor network traffic within your CDE.
- IDS: A security system that monitors network traffic for suspicious activity and raises alerts when potential attacks are detected.
- 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 to which they connect.
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 IDSs/IPSs at the perimeter: Implement IDSs/IPSs 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
| Requirement | Actions required | How the assessment is done |
| 11.5.1.a | Examine system configurations and network diagrams. | The assessor will review your system configurations and network diagrams to verify IDSs/IPSs are deployed: *At the perimeter of the CDE. *At critical points within the CDE as defined by your security architecture. |
| 11.5.1.b | Examine system configurations and interview personnel. | The assessor will review system configurations and interview personnel responsible for the IDS/IPS to verify they are configured to send alerts for suspicious activity to designated security personnel. |
| 11.5.1.c | Examine system configurations and vendor documentation. | The assessor will review your IDS/IPS configurations and consult vendor documentation to verify the systems are configured to keep all engines, baselines, and signature databases updated following the vendor's recommendations. |
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 the 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):
| Requirement | Actions required | How the assessment is done |
| 11.5.1.1.a | Examine documentation and configuration settings of IDSs/IPSs or other relevant security tools. | The assessor will review your documentation and system configurations to verify that methods to detect and alert on potential covert malware communication channels are implemented and operational. |
| 11.5.1.1.b | Review your incident response plan (Requirement 12.10.1). | The assessor will ensure your incident response plan explicitly addresses the detection of covert malware communication channels and outlines response procedures for such situations. |
| 11.5.1.1.c | Interview security personnel and observe their processes. | The assessor will interview personnel responsible for security to assess their knowledge of covert malware communication techniques and their understanding of how to respond to suspected malware activity. The assessor may also observe your process for handling alerts generated by your detection mechanisms. |
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.
- Changedetection 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 regularly change 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 changedetection 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 changedetection 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 FIM tool or similar solution to monitor critical files within your environment.
- Identify critical files: Perform a risk assessment or leverage preconfigured lists from your FIM tool to identify critical files that require monitoring.
- Configure alerts: Configure your changedetection mechanism to generate alerts for any unauthorized modifications detected in critical files.
- Schedule weekly comparisons: Set up automated weekly comparisons within your changedetection tool to identify any changes since the last comparison.
- Review alerts and investigate: Establish a process to review and investigate alerts generated by the changedetection mechanism to determine the legitimacy of the changes and take appropriate action if unauthorized modifications are identified.
How to comply with this requirement
| Requirement | Actions required | How the assessment is done |
| 11.5.2.a | Examine the system settings of the change-detection mechanism.Review the list of monitored files.Analyze results from recent monitoring activities. | The assessor will review your system settings to verify the change-detection mechanism is operational and monitoring the designated critical files. They will also assess the results of recent monitoring activities to ensure they are reviewed and addressed appropriately. |
| 11.5.2.b | Examine the configuration settings of the change-detection mechanism. | The assessor will review the configuration settings of your change detection tool to verify it is configured to: * Alert personnel for unauthorized modifications (additions, changes, deletions) of critical files. * Perform critical file comparisons at least once a week. |
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 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 a changedetection 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 the 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 changedetection mechanism to determine the legitimacy of the changes and take appropriate action if unauthorized modifications are identified.
How to comply with this requirement
| Requirement | Actions required | How the assessment is done |
| 11.6.1.a | Examine system settings of the change-detection mechanism.Review the list of monitored payment pages.Analyze results from recent monitoring activities. | The assessor will review your system settings to verify the change-detection mechanism is operational and monitoring the designated payment pages. They will also assess the results of recent monitoring activities to ensure they are reviewed and addressed appropriately. |
| 11.6.1.b | Examine configuration settings of the change-detection mechanism. | The assessor will review the configuration settings of your change detection tool to verify it is configured to: * Alert personnel for unauthorized modifications (additions, changes, deletions) to HTTP headers and content of payment pages. * Evaluate the received HTTP headers and payment pages at the defined frequency (weekly minimum or as per your risk analysis |
| 11.6.1.c (if applicable) | If using a risk-based frequency, examine your targeted risk analysis for determining the monitoring frequency. | The assessor will review your targeted risk analysis (Requirement 12.3.1) to verify it was conducted properly and justifies the chosen monitoring frequency for change detection on payment pages. |
| 11.6.1.d | Examine configuration settings and interview personnel. | The assessor will review your configuration settings and interview relevant personnel to verify the mechanism functions are performed either: at least once every seven days, or at the frequency defined in your targeted risk analysis specifically for this requirement. |
Take the lead in data protection best practices with our unified SIEM solution!
