PCI DSS penetration testing requirements: Requirement 11.4 explained

PCI DSS Requirement 11.4 covers penetration testing. In PCI DSS v4.0.1 it has seven sub-requirements, 11.4.1 to 11.4.7. This page lists the frequency and tester rules for each, then the questions to take to your assessor.

Which version applies, and what changed?#

PCI DSS v4.0.1 is the only active version. PCI SSC published it on 11 June 2024 as a "limited revision" with no added or deleted requirements, and retired v4.0 on 31 December 2024. Requirements that v4.0 marked as best practice only became mandatory on 31 March 2025. PCI SSC still called v4.0.1 "the currently published" version on 3 June 2026, when it opened a request for comments on the next iteration. No new version date was given.

Old pages and articles use v3.2.1 numbering, where pentests sat under 11.3. In v4.0 and later, the number is 11.4.

What do Requirements 11.4.1 to 11.4.7 say?#

The table paraphrases each sub-requirement and gives the frequencies the standard sets. We confirmed 11.4.1, 11.4.4 and 11.4.7 against the PCI SSC Summary of Changes. Confirm the rest in the standard.

Some blog pages swap 11.4.2 and 11.4.3, place the six-month interval under 11.4.5, or say 11.4.1 requires independence. Check the standard, not a summary.

Who may perform the test?#

The tester must be a "qualified internal resource or qualified external third party", with organizational independence. Independence means the tester is not part of the team that manages the systems under test. The tester does not have to be a QSA or an ASV.

PCI SSC's Penetration Testing Guidance v1.1 (September 2017) adds:

• "The penetration tester must be organizationally separate from the management of the target systems."
• A third party doing your PCI DSS assessment cannot also do the pentest if it installed, maintained or supported the target systems.
• Certifications such as OSCP, CEH, GIAC and CREST are "not required". PCI SSC does not validate or endorse them.
• Qualifications "cannot be met by certifications alone". Check actual engagement experience.

What does "significant change" mean?#

The standard asks for a test after any "significant" upgrade or change but does not list the cases. Your methodology and your assessor define it. Common triggers are a new payment page, a new authentication flow, a new public API, a change to network segmentation and a move to a new hosting setup. Write your definition into the methodology under 11.4.1, then apply it.

For web and API teams, the trigger list in how often should you pentest is a starting point.

How does segmentation testing work?#

Segmentation testing tries to cross the boundary between the CDE and the rest of the network. If your assessor reduces PCI scope because of segmentation, the tests must show the boundary holds. The test covers every segmentation control, not a sample. Service providers repeat it at least every six months (11.4.6).

Segmentation tests are network-level work, and a web application pentest has a different scope. Agree the split in the written scope; the penetration testing rules of engagement guide lists the scope items.

What should the report contain?#

PCI DSS sets no report format. PCI SSC guidance says its report outlines "are only suggested outlines and do not define specific reporting requirements for PCI DSS penetration tests." Your QSA will want evidence that the test followed your methodology, covered the agreed scope, and had qualified, independent testers. They will also want proof that you fixed findings and retested (11.4.4).

A useful report has:

• Dates, scope and the CDE boundary tested.
• Method and how it maps to your 11.4.1 methodology.
• Tester name, qualifications and independence statement.
• Findings with severity, evidence and fix advice.
• Retest dates and results.

To read such a report, see how to read a penetration testing report.

Where does a web application pentest fit?#

A web or API pentest can support the application-layer part of 11.4.2 and 11.4.3. The methodology under 11.4.1 asks for application-layer tests that find, at minimum, the vulnerability types in Requirement 6.2.4. Your QSA decides whether a given web test satisfies your scope. Our web application penetration testing page lists what we test. We make no claim that any assessor accepts it.

What is a practical test plan for a web team?#

A web or API team can map 11.4 to the short plan below. Treat it as a draft for your QSA to review.

1. Write the methodology (11.4.1). One page that names your approach, scope rules, tester qualifications, retention and risk rating method.
2. Set the schedule (11.4.2, 11.4.3). Once every 12 months, plus a trigger list for significant change.
3. Pick the tester. Document qualifications and independence. Keep this with the report.
4. Run the test and fix. Track each finding to closure with the dates (11.4.4).
5. Retest. Keep the retest result with the original report. Keep both for at least 12 months (11.4.1).
6. Test segmentation if you use it (11.4.5, 11.4.6). Include the control list and results.
7. Service providers: support customers (11.4.7). Have a process to answer customer test requests.

What mistakes weaken an 11.4 program?#

Each of these weakens an 11.4 program:

• A test that covers the website but not the payment page or the API behind it.
• No written definition of "significant change", so no test after a major release.
• An internal tester who also manages the systems tested.
• A report with findings but no retest evidence.
• Old v3.2.1 language in the methodology, such as references to 11.3.
• Results not retained for 12 months.

Questions to take to your QSA#

• Which of our systems are in the CDE, and which tests do you expect on each?
• What is our definition of a "significant change"?
• Does our internal team meet your view of organizational independence?
• What proof of tester qualification do you want?
• Do you want the full report, or is a summary enough?
• Which retest evidence closes 11.4.4?