PCI DSS Requirement 11.4: What Your Penetration Test Must Cover

Your assessor asks for penetration testing evidence. Do you have the method, the dates, the fix and the repeat test, or only the report?

PCI DSS requirement 11.4 reads like a chain of five links. The report is one of them. When the other links are missing, the gap tends to surface late in the assessment, and the cost is rework, a repeat test or a delayed sign-off. The way to avoid it is a decision made before testing: agree what evidence the test must produce, then plan the test to produce it.

What requirement 11.4 asks, in one table

PCI DSS is the security standard for organizations that store, process or transmit payment card data. The cardholder data environment is the set of systems and networks that handle that data, plus anything connected to them. Version 4.0 was retired on December 31, 2024. Version 4.0.1 is the only active version and adds or deletes no requirements. The requirements that were future-dated have been mandatory since March 31, 2025, so the next annual test should be planned against the current text.

Requirement What it asks Evidence to keep
11.4.1 Method A documented penetration testing methodology based on industry-accepted approaches The method document and the scope it covers
11.4.2 Internal testing Testing from inside the network at least every 12 months and after significant change Test dates, scope, the trigger for any extra test
11.4.3 External testing Testing from outside the network on the same cadence Same as above, for the external perimeter
11.4.4 Fix and repeat Exploitable findings corrected based on risk, then testing repeated to verify A closure record and the repeat test result
11.4.5 Segmentation Where segmentation isolates the cardholder data environment, it is tested at least every 12 months and after changes Segmentation test results and dates

Method (11.4.1)

The methodology must cover the perimeter of the cardholder data environment and its critical systems. It tests from inside and outside the network, at both the application and network layers, and the results are retained.

The standard asks for industry-accepted approaches but does not name a specific method. Ask your provider which published method it follows and to name it in the scope letter. Common choices are OWASP WSTG for web applications, PTES and NIST SP 800-115 for the overall process, and CVSS for rating severity. Naming the method lets your assessor check the work against a public reference.

Cadence and triggers (11.4.2 and 11.4.3)

Internal and external testing runs at least once every 12 months. It also runs after any significant upgrade or modification. The standard leaves the definition of “significant” to you, so write it down before the year starts.

For example, some teams treat a new payment channel, a move of card systems to a new hosting platform, or a major change to network architecture as significant. These are examples only. Your own documented definition is what governs, and your assessor will ask to see it.

Qualification and independence

The tester must be qualified and organizationally independent. The tester can be a qualified internal resource or a qualified external third party; ask your provider to describe how its independence applies to your engagement. The standard does not require a Qualified Security Assessor (QSA) or an Approved Scanning Vendor (ASV).

So the useful questions for a provider are about qualification and independence. File the scope letter, a short statement of how the tester is independent, and the tester’s role for the engagement.

Fix and repeat (11.4.4)

Requirement 11.4.4 asks that exploitable vulnerabilities and security weaknesses be corrected based on risk, and that testing be repeated to verify the corrections. A report without a repeat test shows the problem but not the repair.

A closure record for each finding holds the finding, the fix owner, the fix date, the retest date and the result. Book the retest when you book the test, so the proof of repair arrives before the assessment does.

Segmentation (11.4.5)

Segmentation is the network separation that keeps the cardholder data environment apart from other systems, which can reduce what falls in scope. Where you rely on it, it is tested at least every 12 months and after changes to the segmentation controls or methods. Service providers test segmentation more often.

A one-page evidence checklist

Use this list when you plan the next test:

  1. Scope statement, approved by the system owner.
  2. The named testing method.
  3. Test dates for internal and external testing.
  4. The tester’s qualification and a statement of independence.
  5. Findings with a CVSS score and proof that each one is real.
  6. A fix owner and a target date for every finding.
  7. The repeat test result for every exploitable finding.
  8. Segmentation test results, where segmentation is used.
  9. A one-page summary for leadership.
  10. Sign-off by the person who owns the evidence file.

For how the same evidence pack serves ISO/IEC 27001:2022 and SOC 2 reviews as well, read our guide to penetration testing evidence for audit.

What to decide this quarter

Name one owner for the evidence file. Write down what counts as a significant change at your organization. Then book the repeat test in the same schedule as the first test.

Questions about PCI DSS 11.4

Does PCI DSS name the testing method? No. Requirement 11.4.1 asks for a documented methodology based on industry-accepted approaches. It does not name a specific method, so ask your provider to name the one it follows.

Must the tester be a QSA? No. The tester must be qualified and organizationally independent. The standard does not require a Qualified Security Assessor (QSA) or an Approved Scanning Vendor (ASV).

How often is penetration testing required? At least once every 12 months and after any significant upgrade or modification, for both internal and external testing.

Next step

Snipeyes is a CREST Member and certified to ISO/IEC 27001:2022. We provide the testing and the evidence; your assessor decides what is accepted. Every finding we report is proven, and one report serves leadership, engineers and auditors, with findings mapped to PCI DSS, ISO/IEC 27001:2022, SOC 2, OWASP ASVS and your regulator’s rules. Report within 10 business days of testing. Retest included.

To plan your next annual or post-change test, book a free 90-minute scoping session. Already know your scope? Request a scoped proposal. See also our penetration testing services and banking security testing.