PCI DSS 11.4 pentesting in practice: internal, external, segmentation and retest

Why "we had a pentest" still fails the PCI audit

Almost every company that handles card data knows it needs a penetration test. The surprise comes at the audit: the QSA opens Requirement 11.4 of PCI DSS 4.0.1 and does not ask "did you run a pentest?". They walk a list of sub-requirements, each needing its own evidence: methodology, internal test, external test, remediation and retest, segmentation. A report that covers four of them and leaves two open is common, and the company ends up paying twice.

This guide complements our article on what the auditor actually expects from your report. The focus here is the requirement itself: what each sub-requirement says, what evidence a QSA typically asks for, how to scope the test, and where companies trip.

11.4 at a glance

Item	What it requires	Evidence a QSA typically asks for
11.4.1	A defined, documented and implemented pentest methodology	Methodology document, reference to NIST SP 800-115, PTES or OWASP WSTG, record of how it was applied
11.4.2	Internal pentest at least every 12 months and after significant change, by a qualified and independent tester	Report with dates, scope, credentials used and tester qualifications
11.4.3	External pentest with the same frequency and triggers	Report separate from the internal one, covering the perimeter and exposed systems
11.4.4	Exploitable vulnerabilities corrected according to risk, and testing repeated to confirm	Status per finding after retest, with date and evidence
11.4.5	Segmentation controls tested at least every 12 months and after changes to those controls	An explicit section listing every segment tested and the result
11.4.6	Service providers only: segmentation tested every 6 months and after changes	Two cycles a year, each with evidence
11.4.7	Multi-tenant service providers only: support customers’ external testing (11.4.3 and 11.4.4)	Evidence (redacted if needed) that testing was done on the customer’s infrastructure, or customer access to test it themselves

Always check the wording against the current text published by the PCI SSC. The numbering above follows PCI DSS 4.0.1, and 11.4.7 moved from best practice to mandatory after 31 March 2025.

11.4.1: the methodology has to be written down

The standard asks for an industry-accepted approach. In practice the report cites NIST SP 800-115, PTES or OWASP WSTG and explains how it was applied. It should cover:

• the full perimeter of the CDE and critical systems;
• testing from inside and outside the network;
• validation of segmentation and scope-reduction controls;
• application-layer testing (at minimum the vulnerabilities listed in Requirement 6.2.4) and network-layer testing;
• a review of threats and vulnerabilities seen in the last 12 months;
• a documented approach for handling the risk of what is found;
• retention of results and remediation records for at least 12 months.

Keep the methodology as a company document, not only as a page in the vendor’s report. A QSA may ask for the procedure even if the PDF already cites a standard.

Scope: the CDE and everything that talks to it

The biggest cause of failure is not technical, it is scope. The CDE includes systems that store, process or transmit cardholder data, plus those that connect to them or could affect their security. Typically that means:

• payment applications, APIs and admin panels;
• databases and queues holding the PAN;
• jump hosts, VPNs and admin accounts that reach the CDE;
• cloud environments (VPCs, security groups, accounts) connected to the CDE;
• integrations with acquirers, gateways and anti-fraud services.

The pentest scope has to match the network diagram and the cardholder data flow you give the QSA. If the diagram shows five subnets and the report tested two, the requirement stays open.

Worked scoping example: an e-commerce store with its own checkout

Picture a store that takes the card on its own checkout page. It has a corporate network, a production VPC running the application, and an isolated VPC with the database that holds encrypted PAN, reachable only through a jump host. The company claims the corporate network and the application VPC are "out of" the CDE because of segmentation.

A defensible pentest scope would look like this:

1. External (11.4.3): the website, APIs, admin panel, VPN, DNS and anything discovered in the public IP inventory.
2. Internal (11.4.2): starting from the corporate network as an ordinary user, and from inside the application VPC, trying to reach the database and the jump host.
3. Segmentation (11.4.5): from every segment declared "out of the CDE" (corporate, application, staging and third-party networks) into the CDE, on every port and path.
4. Application: authenticated testing of the checkout and the admin panel with different roles.

Note that "out of the CDE because of segmentation" only holds if the segmentation test proves it. If one server in the application VPC reaches the database, that server comes into PCI scope.

11.4.2 and 11.4.3: internal and external are different tests

The external test starts from the internet against what is exposed: sites, APIs, VPN, email, DNS, forgotten services. The internal test starts from inside: the corporate network, an untrusted segment or the CDE itself, simulating an attacker who already passed the perimeter, a malicious employee or a compromised device.

An external vulnerability scan (ASV) replaces neither. The ASV scan satisfies Requirement 11.3.2; a pentest is run by a person, proves exploitation and chains weaknesses together. Both coexist.

Significant change is the trigger many companies forget. A new payment application, a cloud migration, a change of acquirer, or a topology or firewall change inside the scope all call for a new test, even if the annual one ran in March. Define internally what counts as a significant change and record the decision with a date.

11.4.4: retest is not optional

Exploitable vulnerabilities must be corrected according to the risk assigned to them, and testing repeated to confirm. The final report shows, per finding, the status: fixed and validated, pending with a deadline, or risk accepted with a formal justification. A PDF without a retest section leaves 11.4.4 without evidence.

Plan the calendar with slack: pentest in October, fixes in November and retest in December fit inside the year. A pentest in December does not.

11.4.5 and 11.4.6: segmentation, the most failed point

Segmenting the network reduces PCI scope, but only if someone proves the segmentation works. The test tries, from networks outside the CDE, to reach the CDE on every port and path the controls should block: VLANs, firewalls, ACLs, security group rules and Kubernetes network policies.

• Test every segment outside the CDE toward the CDE, not a sample.
• Cover all segmentation controls, including cloud and container ones.
• Repeat after any change to those controls.
• Service providers repeat every 6 months (11.4.6), not once a year.
• The result must be explicit: "no path found", with evidence, or the paths that were found.

Where companies trip

1. Segmentation declared, never tested. The diagram shows isolation but nobody tried to cross it. This is the most common audit finding on this requirement.
2. Unauthenticated testing only. The pentest hits the login page and stops. The real risk sits behind it, under ordinary and admin roles.
3. Retest with no date or no evidence. The finding "disappeared" from the new report but there is no proof it was fixed.
4. Scope smaller than the diagram. The vendor tests the IPs the client listed, and the staging environment holding real data is left out.
5. No independence. The people who run the environment also test it.
6. Significant change ignored. The cloud migration happened after the annual pentest and triggered no new test.
7. Tool instead of a person. A report that is scanner output proves neither exploitation nor methodology.

Who may test: qualification and independence

The standard requires the tester to be qualified and organizationally independent from whoever manages the tested environment. The tester does not need to be a QSA or an ASV. The infrastructure team that runs the CDE should not be the one testing it. A separate internal security team can qualify if the organizational independence is real, and an external vendor usually simplifies the conversation with the QSA.

Ask the vendor for the testers’ résumés and certifications and include their identification in the report. See also 10 questions to ask before hiring a pentest.

How to pick a vendor for 11.4

• Ask for an anonymized sample report and check that it has a methodology, reproducible evidence, a segmentation section and a retest.
• Ask whether the retest is included and how many rounds you get.
• Confirm the same team covers network and application, or that they coordinate.
• Check that the vendor will test segment by segment and deliver the segmentation result separately.
• Agree the delivery format with your QSA before signing, to avoid rework.

Pre-engagement checklist

• [ ] Network diagram and cardholder data flow up to date
• [ ] List of every "out of the CDE" segment that relies on segmentation
• [ ] Inventory of exposed IPs, domains and APIs
• [ ] Test accounts for each role (ordinary user, admin, partner)
• [ ] Internal definition of "significant change" and the last year’s history
• [ ] Test windows agreed with operations and the NOC
• [ ] Emergency contacts during execution
• [ ] Planned retest date and an owner for the fixes

A year in sequence

• Quarter 1: scope and network diagram updated; vendor hired.
• Quarter 2: external, internal and segmentation testing.
• Quarter 3: fixes and retest; evidence archived.
• Ongoing: significant-change trigger and, for service providers, segmentation every 6 months.

For what to expect on price and timeline, see how much a pentest costs.

Frequently asked questions

Does a vulnerability scan replace the 11.4 pentest?

No. Automated scanning satisfies other requirements, such as 11.3. Requirement 11.4 asks for testing run by a qualified person, with a methodology and proof of exploitation.

How often does the PCI pentest have to be done?

At least every 12 months, both internal and external, and also after any significant change to the infrastructure or applications in scope.

When is segmentation testing mandatory?

If you rely on segmentation to reduce PCI scope, it must be tested at least every 12 months and after changes to the controls. Service providers test every 6 months.

Can the internal team run the pentest?

Yes, provided the tester is qualified and organizationally independent from whoever operates the tested environment. Many companies hire an external vendor to make the QSA’s assessment simpler.

Does the retest have to be in the report?

Yes. The requirement asks for exploitable vulnerabilities to be corrected and testing repeated, and the report should show the status of each finding after the retest.

Must the pentest be done by a QSA or ASV?

No. The standard requires a qualified, independent tester, not a QSA or ASV. The QSA is the one who evaluates the evidence during the audit.

Do I need to test staging environments?

If they connect to the CDE or hold real card data, yes, they are in scope. Isolated environments with no real data can be left out, as long as the segmentation is demonstrated.

I am a multi-tenant service provider. What changes?

On top of 11.4.6, Requirement 11.4.7 asks you to support customers’ external testing, either with evidence that testing was done on their infrastructure or with access so they can test themselves.

Next step

If your PCI audit is on the calendar, the best time to align scope and diagram is before the test. Request a quote and get a proposal with scope, segmentation and retest included.