PCI Penetration Test Requirements: A Compliance Officer's Guide

Yes, PCI DSS requires regular penetration testing of the cardholder data environment. Requirement 11.4 mandates regular testing including routine tests and tests after significant changes to the network or applications that handle cardholder data, and the PCI Security Standards Council's penetration testing guidance makes clear that segmentation controls must be validated as part of that testing, not assumed.

The single biggest mistake compliance officers make is treating this as a scan-and-check exercise. It isn't.

Scope the cardholder data environment (CDE) precisely, including systems that could affect its security even if they don't touch card data directly.
Require authenticated, human-driven application testing, not just automated discovery.
Validate segmentation separately from the network penetration test.
Keep remediation evidence and retest documentation ready for your Qualified Security Assessor (QSA).

For the underlying methodology standards, NIST SP 800-115 remains the reference framework auditors expect testers to follow.

Key Takeaways

PCI DSS requires annual, change-triggered penetration testing of the CDE with independent segmentation validation, and reports must include exploitation evidence mapped to specific PCI requirements.

Point	Details
Annual plus event-driven testing	Retest after any significant infrastructure, application, or network change, not just once a year.
Segmentation is a separate test	Validate segmentation independently of the network pentest, using representative sampling for complex environments.
Scans are not pentests	Automated vulnerability scanning satisfies Requirement 11.3, not the manual exploitation required by Requirement 11.4.
Evidence quality decides audit outcomes	Reports need screenshots, logs, and command output mapped to specific PCI requirements, not narrative summaries.
Manage it as a program, not an event	CisoSafe's vCISO advisory and platform coordinate scoping, vendor vetting, evidence collection, and retest scheduling year-round.

What a PCI Penetration Test Actually Is
PCI DSS 4.0 Rules That Govern Your Testing Program
How to Scope a PCI Penetration Test Correctly
Which Test Types Satisfy Requirement 11.4?
Setting Rules of Engagement Before Testing Begins
Who Is Qualified to Run Your PCI Pentest?
What Belongs in a PCI-Ready Pentest Report
Remediation and Retesting: Closing the Loop
A PCI SSC-Aligned Checklist for Your Next Pentest
The Gap Between What Vendors Promise and What Auditors Accept
How CisoSafe Supports Your PCI Penetration Testing Program
Sources

What a PCI Penetration Test Actually Is

A PCI penetration test is a simulated, human-directed attack against your CDE designed to prove whether a real adversary could exploit a weakness, not just detect that one exists. Testers manually chain vulnerabilities together, attempt privilege escalation, and demonstrate actual business impact. That's a fundamentally different exercise from a scan.

Vulnerability scanning, by contrast, is automated and largely passive. It flags known CVEs and misconfigurations but stops short of proving exploitability. PCI DSS treats these as two separate, independent obligations. Automated tools are useful for baseline discovery, but a tester still has to interpret the results and attempt manual exploitation before the work counts as a penetration test under Requirement 11.4.

Here's the distinction that trips up most first-time compliance leads: a clean vulnerability scan report is not evidence of penetration testing, no matter how thorough it looks.

Penetration testing proves impact through manual exploitation and produces audit-ready evidence of what an attacker could actually do.
Vulnerability scanning identifies known weaknesses through automated tools and requires no exploitation.
PCI DSS Requirement 11.4 governs penetration testing; Requirement 11.3 governs vulnerability scanning. They are graded and scheduled separately.

Testers commonly draw on PCI SSC's own penetration testing guidance, NIST SP 800-115, and the OWASP Top Ten for application-layer work. Citing a recognized methodology in your scope of work isn't optional decoration. QSAs look for it specifically.

PCI DSS 4.0 Rules That Govern Your Testing Program

Three requirement families drive most of what a compliance officer needs to plan for. Get these mapped correctly and the rest of the program falls into place.

Requirement 11.4 covers penetration testing itself, internal and external, network and application layer.
Requirement 11.3 covers vulnerability scanning, internal and external, on a quarterly cadence separate from your annual pentest.
Requirement 6.4 covers application-layer testing obligations for public-facing web applications, which can be satisfied through either a web application firewall or ongoing application-layer penetration testing.

The frequency rules matter more than most teams budget for. PCI DSS v4.0.1 requires penetration testing at least annually, plus after any significant change to infrastructure, applications, or network architecture. A significant change isn't limited to a full platform migration. Adding a new payment integration, moving a system into the cloud, or restructuring your network segmentation can all trigger a retest.

Service providers face a stricter cadence than merchants on segmentation testing. Merchants typically validate segmentation once a year, while service providers often validate it more frequently. That distinction catches a lot of mid-market companies off guard when they scale from a merchant relationship into a service provider role.

It's worth restating plainly because so many teams get this wrong: vulnerability scanning and penetration testing are not substitutes for one another under any circumstance. A QSA reviewing your Attestation of Compliance (AOC) will ask for both, on their own separate schedules, with separate evidence trails.

Not every organization needs a penetration test to complete their compliance validation, though. SAQ D and SAQ A-EP typically require it; several of the lighter self-assessment questionnaire types do not, depending on how card data flows through your environment.

PCI DSS 4.0 Rules That Govern Your Testing Program — overview diagram

How to Scope a PCI Penetration Test Correctly

Bad scoping is the single most common reason QSAs kick a pentest report back. Get the CDE boundary wrong and everything downstream, the report, the AOC, the remediation plan, is built on a flawed foundation.

Start by mapping every system, process, and person that stores, processes, or transmits cardholder data. Then go one layer further: include systems that don't touch card data directly but could affect the security of systems that do. A jump box, an authentication server, or a shared logging platform can all sit inside scope even without a single PAN passing through them.

Inventory every system that stores, processes, or transmits cardholder data, and document data flows end to end.
Identify connected and adjacent systems that could impact CDE security, even without direct card data exposure.
Confirm which segmentation controls, if any, are being used to reduce scope, and document the methodology behind each one.
Define external testing scope (internet-facing assets) separately from internal testing scope (internal network and adjacent systems).
For large or highly segmented environments, select a representative sample of segments that reflects each distinct segmentation methodology in use.

Representative sampling is explicitly allowed for segmentation testing in complex environments, but PCI SSC guidance is specific that you need to cover every unique segmentation approach, not just the largest or easiest segments to test.

External scope generally covers internet-facing systems and perimeter defenses.
Internal scope covers the internal network, lateral movement paths, and privilege escalation routes.
Segmentation validation is a distinct exercise from both, aimed specifically at proving that out-of-scope systems truly have no path into the CDE.

Pro Tip: Document your CDE map before you ever call a testing vendor. A tester who has to build your scope from scratch on day one is billing you for discovery work that should have been a compliance deliverable months earlier.

For sector-specific scoping challenges, energy retail operators managing distributed point-of-sale environments face particular complexity in mapping the CDE across retail operations.

Which Test Types Satisfy Requirement 11.4?

PCI DSS doesn't prescribe a single test type. It expects a combination that reflects your actual attack surface.

External network testing targets internet-facing assets: firewalls, VPN gateways, public web servers.
Internal network testing simulates an attacker who already has a foothold inside your network, checking lateral movement and privilege escalation.
Authenticated application and API testing examines payment applications and APIs from the perspective of a logged-in user, not just an anonymous outsider.
Segmentation checks verify that controls separating the CDE from the rest of your network actually hold under active testing.
Targeted social engineering applies where phishing or physical access represents a realistic path into the CDE, though it's not universally required.

Methodology matters as much as test type. PCI SSC expects testers to follow an industry-accepted framework: NIST SP 800-115 for general technical testing, the OWASP testing guides for web applications, or comparable frameworks like PTES and OSSTMM. Citing one of these by name in your statement of work isn't bureaucratic box-checking. It's often the deciding factor when a QSA reviews whether a report meets Requirement 11.4's intent.

Grey-box testing, where testers get partial knowledge of the environment (network diagrams, some credentials), is the most common approach for PCI engagements because it balances realism against efficiency. White-box testing, with full access to source code and architecture, tends to surface deeper application flaws faster. Pure black-box testing, where testers get nothing but a target IP range, can demonstrate real-world attacker conditions but often burns testing hours on reconnaissance that adds little compliance value.

Pro Tip: If your testing vendor proposes pure black-box testing for your entire CDE without discussing grey-box options, ask why. For most PCI engagements, that's a sign they're optimizing for a lower bid, not a better result.

Setting Rules of Engagement Before Testing Begins

A penetration test without a signed rules of engagement (RoE) document is a liability, not a compliance activity. This is where a surprising number of engagements go sideways, usually because nobody wrote down what happens if a tester accidentally knocks over a production payment system.

Your RoE should specify the authorized target list down to IP ranges and hostnames, the approved testing windows, and named escalation contacts on both sides who can be reached in real time. If testers might encounter live primary account numbers (PAN) during the engagement, the RoE needs explicit data-handling rules covering how that data gets logged, stored, and destroyed.

Authorized target list with explicit exclusions for anything out of scope.
Testing windows agreed in advance, especially for systems tied to production payment flows.
Named escalation contacts available during all testing hours.
Data-handling rules for any PAN encountered mid-engagement.
Approved tool list and any restrictions on exploitation techniques.

Executive sign-off matters more here than in most IT projects. A signed statement of work should carry explicit authorization from someone with the authority to accept operational risk, not just a security manager checking a procurement box. Build in a kill switch and a communication plan so testing can stop immediately if something unexpected happens, and loop your change management and business continuity teams in ahead of time so a scheduled test doesn't collide with a maintenance window.

Pro Tip: Ask your vendor for their incident escalation SLA before signing the SOW. If they can't tell you how fast they'll call you when something breaks, that's your answer about how the engagement will go.

Who Is Qualified to Run Your PCI Pentest?

PCI DSS doesn't hand you a certification checklist, but QSAs expect to see evidence that whoever ran your test knew what they were doing and had no conflict of interest in the outcome.

Look for testers with a documented track record of PCI-specific engagements, not just general IT security testing. Relevant certifications (OSCP, GPEN, GWAPT, and similar) signal technical competence, but ask for examples of prior PCI engagements and a sample of their methodology documentation before you sign anything.

Independence is the part compliance officers underestimate most. External, third-party testers are generally preferred specifically because they have no stake in downplaying findings. Internal testers can perform the work in some cases, but only with clear separation of duties. The person who configured a firewall shouldn't be the person testing whether it holds.

Before hiring, put these questions in front of any vendor:

What methodology do you follow, and can you name it specifically (NIST SP 800-115, OWASP, PTES)?
What evidence artifacts do you provide: screenshots, command logs, raw output?
What's your retest policy after we remediate findings, and is it included in the original price?
What's your specific experience testing segmentation controls, not just general network pentesting?
Do you have cloud and container testing expertise if our CDE includes AWS, Azure, or containerized workloads?

A vendor who hesitates on the segmentation question specifically is worth a second look. It's a specialized skill that a lot of generalist pentest shops haven't invested in. For a broader framework on vetting any third-party security provider, see CisoSafe's guide to vendor cybersecurity assessments.

What Belongs in a PCI-Ready Pentest Report

Your QSA doesn't just want to know that a test happened. They want to see, in writing, exactly what was tested, how, and what it found.

A report that will actually hold up under audit review needs an executive summary written for non-technical stakeholders, a clearly stated scope matching your CDE map, the signed rules of engagement, and the named methodology followed. Beyond that, PCI SSC's guidance is explicit that findings need proof-of-exploitation evidence, screenshots, command output, log excerpts, not just a narrative description of what was found.

Executive summary, scope statement, and signed RoE.
Named testing methodology (NIST SP 800-115, OWASP, or equivalent).
Evidence of exploitation: screenshots, logs, command-line output.
Risk ratings for each finding, mapped explicitly to the PCI requirement it affects.
Remediation status and retest results, once available.

QSAs use this report to validate the claims in your Attestation of Compliance or your Self-Assessment Questionnaire. A report missing evidence artifacts, or one that describes findings in vague terms without technical proof, tends to trigger follow-up questions that delay your compliance window.

If testers encounter live PAN data during the engagement, that data needs to be redacted in the final report and handled according to the data retention rules in your RoE. Store the full report securely, and expect your QSA to want it retained for at least the length of your compliance cycle, often longer depending on your organization's own record-retention policy.

Remediation and Retesting: Closing the Loop

Findings without remediation are just a longer list of known risks. Triage critical and high-severity findings first, and don't wait for your next annual cycle to fix them if they represent active exploit paths into the CDE.

Retesting timing depends on what changed. A patch to a specific vulnerability usually needs a targeted retest of that finding alone. A significant infrastructure change, a new payment integration or a network redesign, triggers a broader retest that may cover the full scope again.

Build a remediation register that tracks each finding, owner, deadline, and current status.
Retest and document evidence (patches applied, configuration changes, retest output) before your QSA review.
Treat any segmentation failure as scope-expanding until proven otherwise. If segments the test showed as breachable were assumed out of scope, that assumption is now void.

Pro Tip: Negotiate your retest terms into the original statement of work, not as a separate billable engagement later. Vendors who bundle one round of retesting into the base price are signaling confidence in their own findings.

A PCI SSC-Aligned Checklist for Your Next Pentest

Use this before you scope your next engagement, and again when a vendor's deliverable lands on your desk.

Confirm CDE scope is documented and current, including adjacent systems.
Verify segmentation controls will be validated independently of the general network test.
Require authenticated testing for all payment applications and APIs, not anonymous-only access.
Confirm the RoE is signed, with executive authorization and named escalation contacts.
Confirm the tester's methodology is named explicitly (NIST SP 800-115, OWASP, PTES, or equivalent).
Confirm evidence requirements: screenshots, logs, and command output for every material finding.
Confirm retest terms and timing are defined before the engagement starts, not after.

Before kickoff, gather your network diagrams, current data flow maps, prior test reports, and a list of any changes made to the environment since the last test. Missing documentation here is the number one reason engagements slip their scheduled start date.

Reference NIST SP 800-115 when evaluating a vendor's stated methodology for technical rigor.
Reference OWASP resources specifically when your CDE includes custom web applications or APIs.
Reference PCI SSC's scoping and segmentation guidance whenever segmentation reduces your compliance scope.

The Gap Between What Vendors Promise and What Auditors Accept

Most PCI pentest failures I see aren't technical. They're procedural, and they're avoidable.

The most common one: a company treats an annual vulnerability scan report as a substitute for a penetration test, then gets blindsided when a QSA rejects it outright. The second most common: segmentation gets assumed rather than tested, and a finding that a supposedly isolated network segment can reach the CDE turns into a scope-expansion emergency two weeks before an audit deadline.

Both are preventable with the same fix: treat penetration testing as an ongoing program rather than an annual checkbox. That doesn't mean running full manual pentests every month. It means building retest windows into vendor contracts up front, keeping your CDE map current between engagements, and getting segmentation validated on its own schedule instead of bundling it as an afterthought inside the network test.

The compliance teams that struggle least are the ones who stopped viewing the pentest as an event and started managing it as a governance process with its own owner, its own calendar, and its own evidence trail.

How CisoSafe Supports Your PCI Penetration Testing Program

Coordinating a PCI-compliant penetration test across scoping, vendor selection, evidence collection, and remediation tracking is a full-time job most compliance teams are running alongside a dozen other priorities. CisoSafe's vCISO advisory and AI-powered compliance platform manage that full lifecycle for you, from CDE scoping and vendor vetting through automated evidence collection, remediation tracking, and retest coordination, so your team isn't chasing spreadsheets during audit season.

CisoSafe

Where a generalist consultancy hands you a report and disappears until next year, CisoSafe keeps the pentest program active between engagements: tracking remediation deadlines, flagging significant changes that trigger a retest, and keeping your AOC evidence organized before your QSA ever asks for it. For law firms, energy operators, and regulated mid-market companies juggling PCI DSS alongside frameworks like SOC 2 or HIPAA, that continuity is what actually prevents a failed audit.

If your next PCI penetration test is on the calendar, or overdue, request a scoping consultation with CisoSafe to review your CDE, vet your testing vendor, and get a remediation plan in place before your compliance deadline arrives.