PCI DSS penetration testing requirements sit under Requirement 11, and they ask for more than one test a year. You need external and internal testing of the cardholder data environment at both the network and application layers, repeated at least annually and after any significant infrastructure or application change, performed by a qualified party independent of the team that runs the tested systems, with exploitable findings corrected and the correction verified by retesting.
If you use segmentation to keep systems out of scope, those segmentation controls get their own test and their own written conclusion about isolation. That is a separate exercise, not a paragraph in the main report.
Most of the pain in an assessment is not the testing. It is the report — whether its stated scope matches the PCI DSS environment the assessor has defined, and whether it says what an assessor needs it to say.
What PCI DSS Penetration Testing Requirements Cover Under Requirement 11
PCI DSS penetration testing requirements live under Requirement 11, which covers testing the security of systems and networks regularly. The expectation is testing at least annually, plus an out-of-cycle test after any significant infrastructure or application change.
Scope is the cardholder data environment: its perimeter from the outside, and the critical systems within it from the inside. Both layers — network and application — are in play, and recognised industry methodologies are expected as the basis for the approach. NIST and OWASP are the two most commonly accepted sources of that guidance, and a report that names the methodology it followed removes an entire line of questioning.
Current version is v4.0.1, and the official text lives on the PCI Security Standards Council site. Read the requirement before you write the statement of work, because the statement of work is what the test will actually deliver.
External Versus Internal Penetration Testing
An internal and external penetration test under PCI are 2 distinct engagements, each expected at least annually, and buying only one is the most common procurement mistake. External testing attacks the perimeter of the cardholder data environment from outside your network. Internal testing starts from a position inside it and goes after the critical systems that handle or can reach cardholder data.
Teams skip internal testing because external feels like the real threat. Assessors do not accept that reasoning. The internal test is what tells you whether a foothold — a compromised workstation, a stolen VPN credential, a vulnerable internal service — turns into access to card data.
Where you start the internal test matters, and the report should say. "Internal test from the corporate network" and "internal test from a host inside the CDE" answer different questions. Agree the starting positions in writing before the engagement, and make sure they cover the paths into the environment you defined when you did your scope reduction work.
Network-Layer and Application-Layer Testing
Network-layer and application-layer testing are both expected under v4.0.1, and a single engagement that covers only one of the two layers leaves a gap an assessor will find. Network-layer work covers hosts, services, firewall rules, segmentation enforcement points, and the configuration of what is reachable. Application-layer work covers the payment pages, APIs, and administrative interfaces that touch cardholder data.
The gap usually appears on the application side. A network test that enumerates open ports on the payment application's host has not tested the application. Authentication, authorisation, session handling, injection and business-logic abuse in the payment flow are application-layer findings, and they need a tester working at that layer with credentials and documentation.
If your card flow is a hosted payment page or an iframe from a provider, say so in the scope statement and explain what remains yours to test: the page that loads the provider's component, your redirect handling, and your administrative interfaces — not the provider's form.
Not sure your pen test report will survive the assessment?
Send your work email and we'll review your statement of work and last report against what an assessor asks for — scope statement, segmentation conclusion, independence and retest evidence.
PCI Segmentation Testing and Its Separate Conclusion
PCI segmentation testing is a separate exercise with a separate conclusion, and this is the single most skipped item on the list. Where segmentation is used to reduce scope, the segmentation controls themselves must be tested to confirm they are operational and effective, and the test has to explicitly conclude on isolation.
That word "explicitly" is doing work. An assessor is not looking for a report that happens to contain no cross-segment findings. They want a statement that the tester attempted to reach the cardholder data environment from out-of-scope networks and either could not, or could and here is how. Silence is not a conclusion.
Segmentation testing is expected at least annually — so at minimum 1 test a year — and more frequently for service providers. If you are a service provider, build that cadence into the budget from the start rather than discovering it when the assessor asks for the second test.
The logic is uncomfortable but simple: every system you excluded from scope was excluded on the strength of those segmentation controls. If the controls are not demonstrably effective, the excluded systems come back into scope. Segmentation testing is what keeps the scope you argued for.
What Counts as a Significant Change
A significant change triggers an out-of-cycle penetration test, and the standard leaves the definition to you — which means you have to define it in writing before you need it. Infrastructure and application changes both count.
In practice, 5 categories of change should trigger a test, and they are the ones that alter what is reachable or what handles card data:
- A new or materially rearchitected payment application, or a new payment flow
- A change to the segmentation controls, firewall architecture, or network topology around the cardholder data environment
- Adding or moving the environment to a new cloud account, region, or hosting provider
- A new system or component brought into the cardholder data environment
- An acquisition or new business line that brings card data into a previously out-of-scope environment
Write that list into a policy, apply it to your change process, and record the decision each time. The failure mode is not an untested change; it is an untested change nobody evaluated. An assessor can work with a documented decision that a change was not significant. They cannot work with a blank.
Scanning and Penetration Testing Are Different Obligations
A penetration test is not a vulnerability scan, and the two get conflated constantly. A scan is automated, runs against known signatures, and produces a list of candidate issues. A penetration test is performed by a human who chains issues, exploits them, and reports on actual impact.
ASV scanning is a third, separate obligation: quarterly external scanning performed by an Approved Scanning Vendor against external-facing systems. Passing ASV scans do not substitute for a penetration test. A penetration test does not satisfy the scanning obligation either. You need both, on their own schedules, with their own evidence. Our guide to ASV scanning covers that side in detail.
The practical consequence is budget and calendar. The floor is 4 ASV scans a year, 1 external penetration test, 1 internal penetration test and segmentation testing — and teams planning PCI DSS cost for the first time routinely budget for one of those and get surprised by the other three.
Tester Independence and Demonstrable Qualification
Tester independence means organisational independence from the team that manages the tested systems. The tester can be internal or external — there is no requirement to buy the test from a third party — but the internal option only works if the tester does not report into, and is not part of, the group that builds and operates the environment under test.
There is no PCI-specific tester certification. That surprises people who expect a named credential on the list. What the standard does expect is that the tester's qualification is demonstrable, which means the report should carry enough about the tester's experience, training, or credentials for an assessor to form a view.
There are 2 things to get into the report at engagement time, because retrofitting them later is awkward: a short statement of the tester's qualifications, and a statement of their independence from the operating team. Ask for both in the statement of work.
What an Assessor Asks For From the Report
This is the part nobody tells you until the assessment. An assessor reads the penetration test report looking for 7 specific things, and a technically excellent test can still fail to produce usable evidence. They ask for:
- A scope statement that matches the defined cardholder data environment — named systems, IP ranges, applications and URLs, reconciled against the scope the assessment is working from.
- The methodology followed, named and referenced to recognised industry guidance.
- The dates the testing was performed, not just the report date — these are often months apart and the gap gets questioned.
- Tester independence and qualification, stated in the report rather than asserted in a meeting.
- Findings with severity ratings, so remediation priority can be assessed.
- Retest evidence closing the exploitable findings — the correction verified, with dates, not a remediation plan.
- The segmentation testing conclusion, stated explicitly, confirming whether isolation held.
Exploitable findings must be corrected and the correction verified by retesting, which means the retest is part of the engagement and part of the evidence. If your statement of work does not include a retest, you will be buying one under time pressure.
Where Penetration Test Scope and Assessment Scope Diverge
Penetration test scope under PCI has to match the assessment's scope, and the most common failure in the whole exercise is that it does not. The test was scoped in March against last year's architecture. The assessment runs in October against an environment that gained two services, a new region, and a reporting database with a copy of the transaction table.
The divergence is rarely dramatic, and 3 shapes recur. A subnet added after the statement of work was signed. An API gateway that moved. A system that came into scope because a connection to it was never documented. Each one is a line the assessor cannot tick.
The fix is procedural. Reconcile the penetration test scope against the current scope documentation immediately before the engagement starts, not when it was sold, and again when the report arrives. Your PCI DSS compliance checklist should carry that reconciliation as its own step, with the differences resolved in writing.
PCI Penetration Testing Questions Teams Ask
These are the 5 PCI penetration testing questions teams ask most often once they realise one annual test will not cover the requirement.
At least annually, and after any significant infrastructure or application change. That applies to both external and internal testing. Segmentation testing, where segmentation is used to reduce scope, is also expected at least annually and more frequently for service providers. Because "significant change" is defined by you, write the definition into your change management policy and record the evaluation for each change, so an assessor can see the decision rather than a gap.
No. ASV scanning is a separate quarterly obligation performed by an Approved Scanning Vendor against external-facing systems, and passing scans do not substitute for a penetration test. The reverse also holds — a penetration test does not satisfy the scanning obligation. They are different activities with different evidence, and you need both running on their own schedules.
Yes, if they have organisational independence from the team that manages the tested systems and their qualification is demonstrable. There is no PCI-specific tester certification requirement. The practical constraint is independence: a tester who builds and operates the environment cannot test it for this purpose. Where an internal team is genuinely separate, document both the independence and the qualifications in the report.
They must be corrected and the correction verified by retesting. A remediation plan is not evidence of closure; the retest is. Build the retest into the original statement of work with its own dates, and make sure the retest results appear in the report or in a clearly linked addendum. An assessor reading findings with no retest evidence has an open item regardless of what your ticketing system says.
If you do not rely on segmentation to reduce scope, there are no segmentation controls to test — but say that explicitly in the scope statement rather than leaving it unaddressed. Where you do segment, the report must conclude explicitly on isolation. Ambiguity is read as an absent test, and the consequence is that the systems you excluded come back into scope.
Keep penetration test scope aligned with your PCI scope
Book a demo and we'll show how Konfirmity tracks your cardholder data environment, flags changes that should trigger an out-of-cycle test, and holds the report evidence an assessor asks for.
Book a demo
Plan the Test Backwards From the Assessment Date
Work backwards from the assessment date, not forwards from the last test. Testing needs to happen, findings need remediating, and the retest needs to close them — all before the assessor reads the report. A test scheduled 6 weeks before the assessment leaves no room for a serious finding, and serious findings are the point of testing.
The statement of work is where this is won or lost. Specify external and internal testing, name the network and application layers, include segmentation testing with an explicit isolation conclusion, require the methodology and the tester's independence and qualifications in the report, and include the retest.
Next step: pull your last penetration test report and check it against the 7 items an assessor asks for. If the scope statement does not name the same systems as your current scope documentation, fix that before you book anything else, and read the full PCI DSS requirements to see where Requirement 11 sits relative to the rest of your obligations.
