PCI DSS Penetration Testing Checklist: Everything You Need Before Your QSA Review

1. PCI DSS Requirement 11.3 — What It Says, Word for Word

PCI DSS v4.0 Requirement 11.3 is titled "External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected."

2. Who Is Qualified to Test? The Independence Requirement

PCI DSS Requirement 11.3 specifies that penetration testing must be performed by a qualified individual with organizational independence. This is one of the most frequently misunderstood requirements.

"Qualified" is also defined by PCI DSS: the tester must have specialized penetration testing expertise and skills. PCI DSS does not require QSA certification for the tester, but QSAs evaluating your testing evidence will look for:

• Demonstrated methodology and structured approach (not ad hoc testing)
• Relevant professional certifications (OSCP, CEH, GPEN, or equivalent)
• Experience specifically with PCI DSS environments and CDE scope
• Independence documentation — written attestation that the tester has no stake in the systems tested

3. Defining Your Cardholder Data Environment Scope

Your penetration testing scope must align exactly to your cardholder data environment (CDE) as defined in your Network Segmentation Diagram and your CDE scope documentation. Anything in scope for PCI DSS must be in scope for penetration testing.

• All systems that store, process, or transmit CHD. Primary Account Number (PAN), cardholder name, service code, expiration date — any system that touches these is CDE.
• All systems connected to CDE systems. If a system can communicate with a CDE system, it is in scope unless you can demonstrate effective segmentation.
• All systems that could impact CDE security. Authentication servers, log management systems, patch management systems — any system whose compromise could affect CDE security is in scope.
• All network paths into the CDE. Every ingress point into the CDE must be tested from the external perspective. This includes web applications, APIs, VPN gateways, and any other external connectivity.

4. External Penetration Testing Requirements (11.3.1)

External testing evaluates your CDE from the perspective of an attacker outside your network perimeter. It must cover:

• All network-layer components at the CDE perimeter. Firewalls, load balancers, web application firewalls, and any device that terminates external connections.
• All web-facing applications in CDE scope. Payment portals, checkout flows, card tokenization interfaces, and any customer-facing application that processes or transmits CHD.
• All external APIs. Payment APIs, webhooks that receive payment data, and any programmatic interface that handles CHD.
• OWASP Top 10 coverage. Per Requirement 11.3.1.2, web applications must be tested against the OWASP Top 10 as a minimum baseline. Your report must document this coverage explicitly.
• Application-layer testing, not just network scanning. PCI DSS requires application-layer testing, meaning authenticated functional testing of the application — not just port scanning or automated vulnerability scanning.

5. Internal Penetration Testing Requirements (11.3.2)

Internal testing evaluates your CDE from the perspective of an attacker who has already gained a foothold inside your network. This simulates the threat of a malicious insider, a compromised internal system, or an attacker who has breached your network perimeter.

• Internal network access to CDE systems. Testing from inside the internal network to confirm that non-CDE systems cannot reach CDE systems — or that if they can, that access is controlled and monitored.
• Operating system and application layer testing. CDE server configurations, OS hardening, privileged access controls, and lateral movement opportunities within the CDE.
• Database access controls. Direct database access from internal systems — can an internal system query the database that stores CHD without authorization?
• Privileged access escalation testing. Can a standard user escalate to administrator privileges? Can a compromised service account move laterally to CDE systems?
• Physical or logical network access simulation. Testing performed from the same network layer an internal attacker would occupy — not from outside the network.

6. Segmentation Testing — the Most Missed Requirement

If your organization uses network segmentation to reduce PCI DSS scope — isolating CDE systems from the rest of your infrastructure — you must test that segmentation as part of your penetration testing program. This is Requirement 11.4.1, and it is the most commonly missed element of PCI DSS penetration testing.

• Test from every non-CDE segment toward CDE systems. Start from each network zone that should not have CDE access and attempt to reach CDE systems. Every route must be blocked.
• Test application-layer segmentation, not just network-layer. If your CDE is "segmented" but a shared application component can be used to reach CDE data, the segmentation is not effective.
• Document that each attempted access path was blocked. Your QSA needs evidence that segmentation testing was performed and that the segmentation controls are effective, not just documented.
• Service providers: test every 6 months. If you are a service provider (you provide services to other PCI DSS entities), segmentation testing is required bi-annually per Requirement 11.4.2.

7. Accepted Methodologies and Coverage Requirements

PCI DSS v4.0 requires that penetration testing follow an industry-accepted methodology. The PCI Council does not mandate a specific methodology but requires the approach to be documented and structured. Accepted methodologies include:

• OWASP Testing Guide (OTG). Required for application testing per Requirement 11.3.1.2. Your report must document OWASP test case coverage.
• PTES (Penetration Testing Execution Standard). A widely accepted framework covering intelligence gathering, threat modeling, exploitation, and post-exploitation.
• NIST SP 800-115. The NIST Technical Guide to Information Security Testing — acceptable as a methodology reference for PCI QSA review.

The methodology section of your penetration test report must explicitly reference the framework used. "Ad hoc testing" or "manual review" without a named methodology framework will not satisfy a QSA's methodology documentation requirement.

8. Remediation and Retesting Requirements

PCI DSS Requirements 11.3.1.1 and 11.3.2.1 are explicit: all exploitable vulnerabilities and security weaknesses found during testing must be corrected, and the corrections must be confirmed through retesting. There is no exception for findings accepted as risk under PCI DSS — exploitable vulnerabilities in the CDE must be remediated, not accepted.

• All exploitable findings must be remediated. Unlike SOC 2 where risk acceptance is possible, PCI DSS requires remediation of all exploitable vulnerabilities — not just critical and high. Medium-severity exploitable findings must also be addressed.
• Retesting must be performed by the original tester or equivalent. The retest should confirm specific remediations — not just re-run the original test. Document which finding was retested, what remediation was applied, and whether the retest confirmed effectiveness.
• Retesting must complete before the QSA assessment closes. Evidence of retesting and confirmed remediation must be in hand before your QSA submits the ROC (Report on Compliance). Open findings with no confirmed remediation are a failed assessment.
• Compensating controls require QSA approval. If you cannot remediate a finding as specified, compensating controls are possible — but they require formal documentation and QSA approval, not unilateral acceptance by your team.

9. What Documentation Your QSA Will Request

QSAs conducting PCI DSS assessments will request specific documentation related to penetration testing. Have the following ready before the assessment begins:

• Penetration test scope document. A written scope agreement defining what was tested, what was excluded, and how the scope aligns to the defined CDE boundary.
• Tester qualifications and independence attestation. CV or profile of the tester(s), their certifications, and a written statement confirming organizational independence from the systems tested.
• Full penetration test report. The complete report including methodology, findings by severity, technical evidence, and remediation recommendations. The report header should clearly state the date of testing and the testing methodology used.
• OWASP Top 10 coverage documentation. For web applications, explicit documentation of which OWASP Top 10 categories were tested and what test cases were executed.
• Segmentation testing documentation. If segmentation is used to reduce scope, a documented record of segmentation testing including which paths were attempted and the result of each attempt.
• Remediation evidence. For each finding, evidence of remediation — code changes, configuration changes, or compensating control documentation. The retest report confirming remediation of all exploitable findings.
• Testing date confirmation. QSAs will confirm that testing occurred within the past 12 months and after any significant changes. Testing dates must be clearly stated in the report.

10. How NullStrike Delivers PCI DSS-Compliant Testing

• Explicit OWASP Top 10 coverage section. Every web application test report includes a dedicated OWASP Top 10 coverage table showing which test cases were executed against each category — satisfying Requirement 11.3.1.2 without supplemental documentation.
• Segmentation testing included by default. For clients with scope-reduction segmentation, we test segmentation as part of every engagement and document each attempted access path and result in the report.
• Methodology reference in every report. Our reports explicitly reference the methodology used (OWASP + PTES) and document the testing phases executed — satisfying the QSA's methodology documentation requirement.
• Tester qualification documentation. We provide tester CVs, certification documentation, and a signed independence attestation letter on request — everything your QSA needs to verify tester qualifications without back-and-forth.
• Mandatory retest of all exploitable findings. PCI DSS does not allow risk acceptance for exploitable vulnerabilities. Our retesting process confirms remediation of every exploitable finding before issuing the final attestation letter.
• QSA coordination. We have worked directly with QSAs from major PCI DSS assessment firms. If your QSA has questions about our engagement, we coordinate with them directly — at no additional charge.

11. The Complete Pre-QSA Checklist

Summary

PCI DSS v4.0 leaves no room for ambiguity: annual external testing, annual internal testing, segmentation testing if you use scope reduction, OWASP Top 10 coverage for web applications, by a qualified independent tester, with remediation of all exploitable findings confirmed via retest before your QSA assessment closes.

The companies that fail QSA reviews on penetration testing requirements are not failing because they did not test — they fail because their testing documentation does not satisfy the specific evidence requirements, or because segmentation testing was skipped, or because remediation was not confirmed within the assessment period. NullStrike engagements are designed to avoid all three of those failure modes.