On this page
- Requirement 11.4 at a glance
- 11.4.1: the methodology document
- 11.4.2 and 11.4.3: internal and external tests
- Who may perform the test
- 11.4.4: fix and retest
- 11.4.5 and 11.4.6: segmentation testing
- How the penetration test fits with other testing
- Evidence a QSA will ask for
- How Summit helps with PCI DSS penetration testing
- Frequently asked questions
Preparing for a PCI DSS assessment? We run the full engagement for you and route the formal assessment through our local partner firms, so you deal with one team and get all your work done.
PCI DSS has asked for penetration testing for years, but version 4.0 made the expectations far more specific. Assessors now check the methodology document as closely as the report. This guide walks through each part of Requirement 11.4 and the evidence a Qualified Security Assessor (QSA) will ask to see.
Requirement 11.4 at a glance
| Requirement | What it asks for | Minimum frequency |
|---|---|---|
| 11.4.1 | A defined, documented and implemented penetration testing methodology | Maintained and followed |
| 11.4.2 | Internal penetration testing | Every 12 months and after significant change |
| 11.4.3 | External penetration testing | Every 12 months and after significant change |
| 11.4.4 | Exploitable vulnerabilities corrected and testing repeated to verify | After each test |
| 11.4.5 | Segmentation controls tested (all entities using segmentation) | Every 12 months and after segmentation change |
| 11.4.6 | Segmentation controls tested (service providers) | Every six months and after segmentation change |
| 11.4.7 | Multi-tenant service providers support customers’ external testing | Mandatory since 31 March 2025 |
11.4.1: the methodology document
This is where many organisations fail without realising it. The methodology must be written down and followed, and it must include:
- Industry-accepted penetration testing approaches
- Coverage of the entire cardholder data environment (CDE) perimeter and critical systems
- Testing from both inside and outside the network
- Testing to validate segmentation and scope-reduction controls
- Application-layer testing that covers at least the vulnerability types in Requirement 6.2.4
- Network-layer testing of all components that support network functions, and operating systems
- Review of threats and vulnerabilities experienced in the last 12 months
- A documented approach for assessing and addressing the risk of exploitable vulnerabilities
- Retention of test results and remediation activities for at least 12 months
Ask your testing provider for its methodology and keep it with your PCI evidence. If you test in-house, write your own and keep it under version control.
11.4.2 and 11.4.3: internal and external tests
External testing targets the CDE perimeter from the internet: public IP ranges, web applications, APIs, VPN endpoints and anything else exposed that could lead to cardholder data.
Internal testing assumes an attacker is already on your network, for example through a phished laptop, and tries to reach the CDE. It tests network paths, Active Directory, servers holding or processing card data and management interfaces.
Both are required at least once every 12 months and after any significant upgrade or change. “Significant” is for you to define in advance, and assessors will check you followed your own definition. Typical triggers include a new payment flow, a new internet-facing application, a cloud migration, network redesign or major OS upgrades in the CDE.
The 12 months is a floor
A test 14 months after the last one is a finding, even if nothing changed. Schedule the next test when you close the current one, and add change-driven tests on top.
Who may perform the test
The test can be done by a qualified internal resource or a qualified external third party. In both cases the tester must be organisationally independent of the systems being tested. A system administrator testing their own servers does not qualify. The tester does not have to be a QSA or an ASV, but you should be able to show their qualifications and experience: certifications, prior work and the methodology they follow.
11.4.4: fix and retest
Exploitable vulnerabilities must be corrected according to your risk assessment, and the penetration test must be repeated to verify the corrections. In an assessment this means three artefacts: the original report, the remediation records and a retest report showing each exploitable finding closed. A report full of open highs with no retest is one of the most common reasons for a delayed Report on Compliance.
11.4.5 and 11.4.6: segmentation testing
Segmentation is optional in PCI DSS, but if you use it to shrink your scope you must prove it works. Testing checks that systems outside the CDE cannot reach the CDE, using every network path and protocol, and that the CDE is isolated as your scope documents claim.
- Merchants and other entities: at least every 12 months and after any change to segmentation controls or methods.
- Service providers: at least every six months and after any change.
If the test finds a path, your scope just grew. That is far better to discover in a test than during the assessment.
How the penetration test fits with other testing
Internal vulnerability scans (11.3.1)
Quarterly authenticated scans of internal systems, with high-risk and critical findings fixed and rescanned.
ASV scans (11.3.2)
Quarterly external scans by an Approved Scanning Vendor, with passing results.
Penetration testing (11.4)
Annual and change-driven manual exploitation of internal and external attack surfaces, plus segmentation tests.
Public-facing web apps (6.4.1, 6.4.2)
Ongoing protection or review of internet-facing applications, which application-layer pentesting supports.
Scanning tells you what might be wrong. Penetration testing shows what an attacker can actually do with it. PCI DSS requires both, and our VAPT vs vulnerability scan guide explains the difference in detail.
Evidence a QSA will ask for
- The written penetration testing methodology, matching 11.4.1.
- Scope documents showing the CDE, connected systems and segmentation boundaries.
- Internal and external test reports from the last 12 months, plus any change-driven tests.
- Tester qualifications and a statement of independence.
- Remediation records and retest reports for exploitable findings.
- Segmentation test results at the right frequency for your entity type.
- Retained results and remediation records covering at least 12 months.
How Summit helps with PCI DSS penetration testing
Summit runs PCI DSS penetration testing that is built around Requirement 11.4: a documented methodology you can hand to your assessor, internal and external testing of your network, web applications and APIs, segmentation testing, and retests until exploitable findings are closed. Our testers are independent of your environment and every finding is verified by hand. For the formal assessment, we coordinate with our local partner firms so the testing evidence and the assessment fit together.
Getting ready for your next PCI assessment?
We can scope your 11.4 testing against your CDE and segmentation design and plan retests before your assessor arrives. Read our PCI DSS compliance guide or get a quote.
Related reading: Types of penetration testing · API penetration testing checklist · Which compliance frameworks require penetration testing
Frequently asked questions
How often is penetration testing required by PCI DSS?
Internal and external penetration tests are required at least once every 12 months and after any significant infrastructure or application upgrade or change (Requirements 11.4.2 and 11.4.3). Segmentation controls must be tested at least every 12 months, or every six months for service providers (11.4.5 and 11.4.6).
Who can perform a PCI DSS penetration test?
A qualified internal resource or a qualified external third party, as long as the tester is organisationally independent of the systems being tested. The tester does not need to be a QSA or an ASV.
Is an ASV scan the same as a PCI penetration test?
No. ASV scans are quarterly external vulnerability scans under Requirement 11.3.2. A penetration test under 11.4 is a manual attempt to exploit weaknesses, including from inside the network and through applications. You need both.
What is PCI segmentation testing?
Testing that proves the network controls separating the cardholder data environment from out-of-scope systems actually work. If you use segmentation to reduce PCI scope, it must be tested at least annually, every six months for service providers, and after any change to segmentation.
What happens if the penetration test finds vulnerabilities?
Requirement 11.4.4 requires exploitable vulnerabilities to be corrected according to your risk assessment, and the test to be repeated to verify the corrections. Assessors expect to see the retest evidence, not just the original report.
Which PCI DSS version is current?
PCI DSS v4.0.1. Version 3.2.1 was retired in 2024, and the requirements that were future-dated in v4.0 became mandatory on 31 March 2025.
