PCI DSS Requirement 11.4: What Your Penetration Test Must Cover
The penetration test report is the part everyone remembers to keep. Requirement 11.4 of PCI DSS asks for more than the report. It wants a written method, a tester who is qualified and independent, tests that repeat every year and after big changes, fixes that someone verified, and a separate test of your segmentation if you rely on it. That is five records. The report is one of them.
A quick word on versions, because it changes what you plan against. PCI DSS v4.0 was retired on December 31, 2024. Version 4.0.1, published June 11, 2024, is the only active one, and it adds or deletes no requirements. The requirements that were future-dated have been mandatory since March 31, 2025, so plan against the full current text (PCI Security Standards Council).
We test and write the evidence. We are not a QSA and we don’t assess PCI DSS, so read what follows as how we would keep the file. Your assessor decides what is enough.
The five records in one table
The cardholder data environment (CDE) is the people, processes and systems that store, process or transmit card data, along with any system that has unrestricted connectivity to them. Segmentation means the controls that keep the rest of your network away from it.
| Requirement | What it asks | What we would keep in the file |
|---|---|---|
| 11.4.1 | A written penetration testing method based on industry-accepted approaches, covering the CDE perimeter and critical systems, from inside and outside the network, at the application and network layers | The method document; the name of the approach followed; a scope that lists the CDE perimeter and critical systems; a note that the last 12 months of threats were reviewed; the rule for handling exploitable findings |
| 11.4.2 and 11.4.3 | Internal and external tests, at least every 12 months and after any significant upgrade or change, by a qualified, organizationally independent tester | Test dates for each; the change record behind any extra test; the tester’s name, employer and role; a short statement of independence |
| 11.4.4 | Exploitable findings corrected based on risk, then testing repeated to verify the correction | For each finding: fix owner, fix date, retest date and the retest result |
| 11.4.5 | If segmentation isolates the CDE, it is tested at least every 12 months and after changes to it, and the test confirms the controls are operational, effective and keep the CDE apart from out-of-scope systems | The list of segmentation controls in use; test date; result; the date of any change to those controls |
| Across all of them | Test results and remediation results kept for at least 12 months (stated in 11.4.1) | One folder with one named owner, and a leadership summary someone has signed off |
Name the method before the test starts
11.4.1 says “industry-accepted approaches” and stops there. It doesn’t name one, so the choice and the paperwork are yours. In practice that means a line in the scope letter such as OWASP WSTG for web applications, PTES for the engagement process, or NIST SP 800-115, with CVSS for rating severity. Whichever you pick, ask the provider to put it in writing and to describe how it covers both the application layer and the network layer. A method that exists only in the tester’s head is hard to show later.
The same clause asks you to review the threats of the last 12 months. A short, dated paragraph in the scope document is a simple way to show the review happened. Your assessor will tell you if they want more.
Annual, plus whenever something big changes
Internal and external testing each run at least every 12 months. They also run after a significant upgrade or change to the infrastructure or applications. Write down what you treat as a significant change, and agree it with your assessor before you need it. A new payment page, a changed API version that handles card data, or a firewall rule that touches the CDE boundary would be reasonable candidates.
Then keep the change ticket and whether it led to a test. That record shows you looked.
Who is allowed to test
The tester can be a qualified internal resource or a qualified external third party. The tester doesn’t have to be a QSA or an ASV. The standard asks that the tester’s organizational independence exists but doesn’t spell out how. Write down how you meet it, for example who the tester reports to, and keep that next to the scope letter.
So skip the question of whether a provider holds a PCI badge. Ask who is doing the testing, what makes them qualified, and who they answer to.
A fix isn’t closed until someone repeats the test
11.4.4 has two halves: exploitable weaknesses are corrected according to your assessment of the risk, and testing is repeated to verify the correction. The second half is the one that’s easy to leave undocumented: a fix gets made, but nobody records when it was retested or what the result was.
Here is an example from outside a card environment, where the loop is the same. On a digital bank’s payment module we tested 23 endpoints. The critical issues were fixed in 3 days, a retest confirmed the fixes, and the module launched on the planned date. A fix isn’t closed when the developer says so. It’s closed when the retest result is on file, and that is the loop 11.4.4 describes.
Segmentation gets its own test
If segmentation is what keeps the CDE separate from the rest of the network, 11.4.5 asks you to test that it works, at least every 12 months and after changes to the controls or methods you use. The test covers all the controls in use and confirms they are operational and effective. Service providers have to test segmentation more often, so check the current text for the interval that applies to you. If your network diagram changed this year, this is the record most likely to be out of date.
Before the next test
Start with ownership: one person holds the evidence file, so it isn’t scattered across audit, security and engineering. Then settle your definition of a significant change. The retest date is the last of the three, and it still has to be set before the test begins.
Questions readers ask
Does PCI DSS say which testing method to use? No. Requirement 11.4.1 asks for a documented method based on industry-accepted approaches. It is up to you to choose one, write it down and follow it.
Does the penetration tester have to be a QSA? No. The tester must be qualified and organizationally independent. Being a QSA or an ASV is not required.
How often does PCI DSS require penetration testing? At least once every 12 months, and after any significant infrastructure or application upgrade or change, for both internal and external testing.
Next step
If you’re planning an annual or post-change test, book a free 90-minute scoping session and we’ll build the 11.4.4 retest into the plan from day one. Retest is included, and a scoped proposal follows within 24 hours. Snipeyes is a CREST Member and certified to ISO/IEC 27001:2022.
Book a scoping session or request a scoped proposal.
For how the same test serves other audits, see penetration testing evidence for audit. For what we run and how, see our penetration testing services. Banks and payment companies can read how we work with banking and financial services.