PCI DSS 4.0.1 Penetration Testing Requirements: QSA Evidence Guide

PCI DSS 4.0.1 penetration testing requirements go beyond a passing vulnerability scan. Requirement 11.4 calls for a documented testing method, internal and external testing, correction and repeat testing, and segmentation validation when segmentation reduces scope. An assessor needs to see what was in scope, how it was tested, who did the work, what testing found, whether weaknesses were corrected, and what the repeat test proved.

This guide is an evidence-planning tool for CISOs, compliance leads, CTOs and payment-product owners preparing an assessment. It separates the standard’s requirements from the practical documentation that makes a review easier. The exact requirements applicable to your entity depend on its payment flows, assessment instrument and scope; confirm them with the assessor or compliance-accepting entity. For help scoping the work, see our PCI DSS penetration testing and readiness service.

PCI DSS 4.0.1 penetration testing requirements: 11.3 versus 11.4

Older PCI DSS v3.2.1 material put penetration testing under 11.3. In v4.0.1, 11.3 is vulnerability scanning and 11.4 is penetration testing. A report or service page using “11.3 penetration test” as its current requirement label invites avoidable clarification. PCI SSC describes v4.0.1 as a limited revision without new or deleted requirements. Use the current PCI DSS v4.0.1 standard in the document library for the authoritative wording.

The applicable Self-Assessment Questionnaire does not always contain every requirement. Do not assume a merchant’s SAQ category, a hosted checkout or a third-party processor automatically removes all testing duties. Record the chosen assessment route and its scope decision before commissioning a test. Scanning and penetration testing can inform each other, but one set of reports cannot simply be relabeled as the other.

Start with a boundary an assessor can follow

Define the CDE, critical systems, connected networks and pathways that could affect its security. Identify the external perimeter, internal segments, hosted payment services, applications, APIs, authentication services, administrative access, cloud control paths and third-party dependencies. Then mark which components are included, excluded or covered by a provider’s evidence, with the reason for each decision. A diagram alone is a starting point; the test record must show that the defined boundary was actually exercised.

Ask the payment, infrastructure and product owners to sign off a current asset inventory and data-flow map. Include payment authorization and refund workflows, operator and support roles, credentials for each test role, test environments and approved hours. Where production testing could disrupt transactions, document limits and alternative procedures with the tester. A narrow rules-of-engagement document is useful only if it still covers the CDE perimeter and critical systems required by 11.4.1.

For SaaS payment products, enumerate tenant, role and object boundaries. A gateway admin, merchant operator and customer should not be treated as one generic authenticated account. Scope payment actions, exports, webhooks and background jobs where they affect the CDE. Our multi-tenant authorization testing guide shows how to build a role-by-object matrix. That article is about product authorization; network segmentation requires separate validation.

Keep a change log. If an application or infrastructure change is significant, 11.4.2 and 11.4.3 require testing after it. A change to segmentation controls also triggers 11.4.5 and, for applicable service providers, 11.4.6. Record the change, date, impacted boundary, decision, resulting test and reviewer. Do not substitute a calendar reminder for an after-change assessment.

Show the methodology and the tester’s independence

Requirement 11.4.1 calls for an entity-defined, documented and implemented methodology that uses industry-accepted approaches. It covers the full CDE perimeter and critical systems; testing from inside and outside the network; application and network layers; segmentation and scope-reduction controls; relevant threats and vulnerabilities from the prior 12 months; risk assessment and treatment; and retention of test and remediation results for at least 12 months. NIST SP 800-115 provides a useful testing-process reference. OWASP guidance can inform web and API cases, including object- and function-level authorization testing. Neither framework replaces the PCI DSS requirement text.

The tester may be a qualified internal resource or qualified external third party. The condition is organizational independence from the environment being tested; the tester is not required to be a QSA or ASV. An internal team should be able to demonstrate appropriate separation from the people who built or operate the systems, plus relevant competence. An external provider should show who tested, their qualifications, independence and the actual methodology. Procurement can ask for stronger separation, but should describe that as its own policy rather than a PCI DSS mandate.

Document test perspectives and limitations. External testing covers the exposed perimeter and critical connected systems; internal testing includes inside-CDE and routes into the CDE from relevant internal networks. Automated discovery helps, yet a scan alone does not demonstrate the logic of role transitions, chained access or business actions. The report should distinguish a proven path, a plausible but unverified exposure, and a control that was tested without a finding.

Make the test record reproducible without exposing secrets

For each meaningful test area, record an objective, the asset or trust boundary, the user role or network origin, the permitted and prohibited action, and the observation. A reproducible record does not need a dangerous step-by-step exploit published to every audit stakeholder. Keep sensitive requests, tokens and data samples in a restricted technical appendix, and give the assessor a redacted narrative that still shows why the conclusion follows. Use test accounts and synthetic transactions when feasible. If a finding depends on a production-only integration, identify what was safely verified and what remained out of bounds.

Distinguish a control that was never exercised from one that withstood the defined test. “No findings” is meaningful only alongside a clear target list, method, permissions and limitations. Conversely, a finding should show the affected path and plausible business impact without assuming that every weakness provides direct access to cardholder data. A broken merchant-to-merchant authorization rule can matter even if the tester intentionally stops short of viewing another merchant’s payment records. Preserve the bounded proof and the reason for stopping.

Separate requirement mapping from vulnerability taxonomy. A finding may be described with a CWE, OWASP category and severity score, but those tags do not by themselves show whether 11.4.1’s scope and method or 11.4.2’s internal perspective were satisfied. Add a small coverage matrix that points each applicable testing element to the actual report section or appendix. Where cloud platforms or payment processors own a layer, attach the relevant responsibility agreement or provider evidence and state which parts your entity still had to test. This prevents a vendor report from being mistaken for complete coverage of your own payment workflow.

Give segmentation its own result, not just a diagram

If segmentation is used to reduce PCI scope, test all controls and methods that isolate the CDE from out-of-scope systems. Requirement 11.4.5 calls for testing at least every 12 months and after any changes to the segmentation controls or methods. For service providers, 11.4.6 adds an at-least-six-month cadence and the after-change trigger. Both call for qualified, organizationally independent testing. If no segmentation is claimed, document that scoping position rather than presenting an empty validation section.

Translate each claimed boundary into a test case. Identify the originating out-of-scope network or system, the target in the CDE, the intended allow or deny rule, protocol and credential assumptions, the observed result, and the date. Include each relevant firewall, cloud security group, routing layer, private connection or other mechanism. Test from representative locations chosen to demonstrate isolation; explain the sampling rationale if there are many equivalent zones. Evidence should show negative paths as well as explicitly permitted business traffic.

Record failures separately from architecture intentions. A rule export saying “deny” does not prove traffic was denied, and a denied packet at one edge does not prove all routes are isolated. If an authorized access path exists, explain why it does not invalidate the scope boundary, or include its connected systems in scope as appropriate. Revisit the test when segmentation changes. A service provider should keep the six-month sequence visible, rather than treating an annual general pentest as a substitute.

QSA evidence checklist: one index, traceable artifacts

An assessor’s exact request varies. The following index is a practical way to make 11.4 evidence reviewable, rather than a prescribed PCI SSC report template. Give each item an owner, version, test date, covered environment and secure location. Redact secrets and cardholder data from shareable copies without obscuring the finding or outcome.

1. Assessment and scope record: entity type, chosen validation instrument, CDE and critical-system inventory, current network and data-flow diagrams, segmentation claim, provider responsibilities and scope approvals.
2. Rules of engagement: allowed targets and methods, internal/external vantage points, test accounts, exclusions, maintenance windows, safety contacts and the reason for any constraint.
3. Methodology and qualification: versioned 11.4.1 method, relevant threat review, team qualifications and evidence of organizational independence. Reference supporting NIST or OWASP methods where they genuinely informed the test.
4. Internal and external results: report date, tester, exact assets and roles tested, steps and observations, severity and risk treatment, evidence for successful paths, limitations and explicit coverage against 11.4.2 and 11.4.3.
5. Segmentation record: all controls and methods used, source/destination test matrix, expected and actual results, exceptions, change triggers and 11.4.5/11.4.6 dates where applicable.
6. Correction trail: stable finding ID, owner, risk assessment under 6.3.1, change or mitigation record, implementation date, and any documented decision requiring assessor discussion.
7. Repeat-test proof: retest date, method, tester, same exploit path or control condition, outcome and residual issue, linked to the original finding under 11.4.4.
8. Adjacent scan evidence: current 11.3 internal and external scan records, including ASV reports where applicable, stored separately but cross-referenced when they concern the same asset or weakness.
9. Service-provider customer support: if 11.4.7 applies, a usable evidence-sharing or prompt access process that lets customers establish coverage of their subscribed infrastructure.

Store test reports and remediation-activity results for at least 12 months as specified in 11.4.1. Other corporate or contractual retention periods may be longer. An executive summary helps leadership prioritize, while technical findings and the evidence index let the assessor trace the actual test. Our redacted sample report illustrates presentation; confirm each PCI-specific artifact in the engagement scope.

Before sharing, have the scope owner compare the report’s asset list with the current inventory, and have the remediation owner reconcile every open finding with a ticket and retest status. Add a short discrepancy note if the two sources differ. For example, a newly deployed API or a retired host may change what the test could prove. If the evidence index points to a report but the report excludes a live payment endpoint, the index is not complete. Treat this cross-check as a release gate for the evidence pack, with the reviewer’s name and date recorded.

A finding is closed when the correction has been tested

Requirement 11.4.4 ties correction to the entity’s assessment of risk under 6.3.1 and requires penetration testing to be repeated to verify corrections. That is more than a ticket marked complete. Capture the original path, the implemented change and a retest that challenges the same failure condition. If the original path involved role switching, alternate tenant access or a chained privilege path, a generic scan of the endpoint cannot establish that the authorization logic has changed.

A workable trail has a stable finding ID, affected system, owner, risk rationale, target date, change record, retest date and result. Preserve evidence of any residual exposure. Where a proposed fix alters a payment flow, agree a safe validation approach with engineering and the tester. If the test still succeeds, keep the finding open and repeat correction and validation. Link the technical result to the decision the business made, without treating acceptance language as evidence that 11.4.4 was met.

Compensating controls have formal conditions and documentation. A Compensating Controls Worksheet under the applicable PCI DSS appendix is not an automatic substitute for an uncorrected finding, nor is a routine “risk accepted” ticket proof of compliance. Escalate an unresolved issue to the QSA or compliance-accepting entity with the requirement, root cause, implemented measures, evidence and proposed remediation schedule. Do not promise an assessment outcome before that review. If an organization uses a specific reporting status such as “In Place with Remediation,” apply its formal eligibility and reporting instructions rather than using the phrase as a general grace period.

Our 30-day remediation ownership plan gives security and engineering a RACI and evidence gates. For implementation support, use the PCI DSS remediation service. Keep the person correcting a control and the independent person testing it identifiable in the record.

Plan the evidence cycle before the QSA request

A 30/60/90-day sequence from the older remediation article remains useful as a planning device, not a PCI DSS deadline. In the first 30 days, reconcile the CDE inventory and payment flows, select the assessment instrument, record segmentation claims and book qualified testers. Locate prior 11.3 scans, 11.4 reports, change logs and unresolved findings. Resolve scope questions with the assessor while there is still time to adjust the test plan.

During days 31–60, perform the appropriate internal, external and segmentation tests. Review preliminary results promptly, assign owners and reserve engineering time. Do not wait for the formatted final PDF to start correcting a confirmed high-risk issue. Keep the reporting boundary clear: a tester should document observations, limitations and impacted assets; the entity owns system changes and risk decisions.

During days 61–90, validate corrections with repeat testing, update the evidence index, and resolve gaps between scope diagrams, test records and actual production configuration. Capture timestamps and versions for changed controls. Check whether a significant change since the original test creates another testing trigger. If an assessment starts sooner, compress the planning cycle without pretending an incomplete correction trail is complete.

For recurring operations, calendar the at-least-12-month internal and external penetration tests, the conditional segmentation cycle, and the six-month segmentation cadence for applicable service providers. Maintain a separate 11.3 scanning cadence. Also maintain a change-trigger process: owners must know when a significant infrastructure/application change or a segmentation change calls for new testing. This makes the evidence current when the next request arrives.

Questions to ask before buying a PCI penetration test

• How will you map our CDE perimeter, critical systems, external and internal perspectives, and segmentation claims to the test plan?
• Who will test, how are they qualified and organizationally independent, and what work have they done on the environment being tested?
• Which application and network methods will you use, and how will you test payment workflows, APIs and distinct operator roles?
• What will the final report show about assets tested, exclusions, evidence, risk treatment and the link from each finding to retest?
• Does the scope include segmentation testing at the cadence our entity type requires, and what happens after a segmentation change?
• How is repeat testing scheduled when fixes land, and how are residual weaknesses reported?
• If we are a multi-tenant service provider, how will customers receive sufficient evidence or prompt testing access under 11.4.7?

Request a sample deliverable and review whether you can trace a finding from test case to outcome, correction and retest. Discuss exclusions before signing. A provider may help prepare an evidence index, but the entity remains responsible for defining its environment and presenting the appropriate assessment evidence. For a scoped engagement and deliverable list, request a PCI DSS testing quote.