Penetration Testing for PCI Compliance: What Assessors Expect

PCI DSS requires penetration testing of your cardholder data environment (CDE) at least once a year and after any significant change. The test must cover internal and external attack paths, and it must also check the segmentation that keeps out-of-scope systems out of scope. It is separate from the quarterly vulnerability scans, and a tester who is independent of the systems under test must carry it out. This guide covers what that means in practice: scope, timing, who can test, how to handle scan results, and what to hand your assessor.

What PCI DSS actually asks for

The PCI Security Standards Council (PCI SSC) publishes the penetration testing requirement and a guidance document that explains how to read it. In that guidance, the test covers the entire CDE perimeter and critical systems, and it includes both external and internal testing. Segmentation and scope-reduction controls are tested as well.

In PCI DSS v4.x the pentest requirement sits under Requirement 11.4. Older write-ups still cite 11.3, which was the number in v3.2.1. If an article or vendor questionnaire uses the old number, the substance is the same but you should map it to the current version. Version 4.0.1 is a limited revision that clarifies some requirements and guidance without adding or deleting any, so the testing obligations did not change between 4.0 and 4.0.1.

Three questions decide what your test looks like:

1. What is in the CDE, and what connects to it?
2. Has anything significant changed since the last test?
3. Is anything relied on to take systems out of scope?

Everything below follows from those.

Scope: the CDE, connected systems and segmentation

The CDE is every system that stores, processes or transmits cardholder data, plus the systems that can affect its security. A pentest scoped only to the payment page misses the jump hosts, domain controllers, admin workstations and APIs that an attacker would use to reach it.

A workable scope list includes:

• External perimeter: public IPs, firewalls, VPN gateways, and internet-facing applications that touch the CDE.
• Internal network: the CDE segment and any system that has a route into it, including Active Directory if it authenticates CDE users.
• Applications: web, mobile and API components that handle card data or sit in the payment flow.
• Segmentation controls: the firewalls, VLANs and access rules you claim isolate the CDE.

Why segmentation testing matters

Segmentation is the main way companies shrink PCI scope and cost. If you tell the assessor that the corporate network is out of scope because it is segmented from the CDE, you need proof the segmentation works. The pentest provides it: the tester tries to reach the CDE from the out-of-scope networks. If they can, those networks are in scope after all.

Service providers are held to a tighter schedule for segmentation testing than merchants. Check the current requirement text in the standard for your entity type before you plan the year.

After a finding: look beyond the tested area

The guidance does not stop at fixing the exact flaw. When a test finds an exploitable weakness, the entity should look at systems beyond the initially tested area for the same development or configuration weakness, remediate what is exploitable, and retest to confirm the new controls address the original risk. A single SQL injection in one form is a reason to review every form that was built the same way.

How often: annual, plus after significant change

Penetration testing must happen at least annually and after significant changes, such as infrastructure or application upgrades or modifications, or the installation of new system components. What counts as significant is a judgment you should document. A reasonable internal rule is that any change to CDE network architecture, a new payment integration, or a major release of a CDE application triggers a scoping review and, usually, a targeted retest.

Plan the calendar around these anchors:

A tip from experience: schedule the pentest at least six to eight weeks before your assessment or self-assessment deadline. That leaves time to fix findings and retest. A report that arrives the week before the assessor does leaves findings open at the worst moment.

Penetration testing vs. vulnerability scanning

The two are often confused, and assessors check for both. The PCI SSC draws the line clearly: vulnerability scans identify and rank vulnerabilities, typically with automated tools and manual verification, whereas a penetration test is a manual process that may use automated tools to find ways to exploit those vulnerabilities.

In plain terms: a scan tells you a door might be unlocked. A pentest tries the door, walks in, and shows what an attacker could reach from there. Running nmap or a scanner and calling it a pentest will not satisfy the requirement.

The vulnerability scanning process under PCI DSS

Scanning has two halves, external and internal.

External scans by an ASV

Requirement 11.3.2 in v3.2.1 and its v4.x successor call for external vulnerability scans at least once every three months, performed by a PCI SSC Approved Scanning Vendor. The PCI SSC describes these scans as an indispensable tool when used alongside a vulnerability management program.

The typical cycle is:

1. Define the in-scope public IPs and domains and give them to the ASV.
2. Run the scan.
3. Review the report. A scan passes only if it has no urgent, critical or high vulnerabilities.
4. If it fails, correct the vulnerabilities and arrange a rescan to obtain a passing result.
5. File the passing report with your compliance records.

Internal scans in v4.x

Version 4.0 added two requirements to internal scanning: 11.3.1.1 for managing all applicable vulnerabilities and 11.3.1.2 for authenticated scanning. Authenticated scans log in to the host, so they see missing patches and misconfigurations that an outside-in scan cannot. Expect more findings the first time you switch to them, and budget remediation time accordingly.

Reading vulnerability scan results and acting on them

A scan report can run to hundreds of lines. The raw severity score is a starting point, not the answer. The OWASP DevSecOps Guideline recommends aggregating and deduplicating findings in one place and ranking them by genuine risk rather than CVSS score alone. Useful ranking inputs are whether the flaw is on a known exploited vulnerabilities list, how critical the asset is, and whether an attacker can actually reach it.

For each group of findings, choose one of three outcomes. The UK National Cyber Security Centre describes triage as fix, acknowledge or investigate, and says that accepting a risk should come with recorded reasons and a planned review date. That habit translates well to PCI: an assessor is far more comfortable with a documented, time-boxed exception than with a finding that quietly stays open.

Finally, verify. Marking a ticket closed proves action was taken, not that the hole is shut. Rescanning or checking the endpoint state shows whether the vulnerability is gone or still exploitable. For ASV scans, the passing rescan is the verification.

Who can perform the pentest

PCI DSS does not hand the work to a certified list the way it does for ASV scans. What it requires is independence and competence.

• Independence: testers must be organizationally independent of the management of the target systems. They cannot have been involved in installing, maintaining or supporting what they test. An internal team can qualify if it sits outside that management line, but many companies use an external provider to avoid the debate.
• Competence: no specific certification is required. The guidance suggests evaluating years of experience, relevant certifications such as OSCP or CEH, and a record of successful similar tests.
• Cardholder data handling: if a tester obtains cardholder data, it must be kept to a minimum, protected under PCI DSS storage requirements, and securely wiped after the engagement. Write this into the rules of engagement before the test starts.

When you choose a provider, ask for a sample report, the methodology they follow, who will actually do the testing, and whether retesting after fixes is included in the quote.

Evidence to keep for the assessor

A good pentest that you cannot document is hard to defend. Plan to keep:

• The scope statement and the rules of engagement
• The final report with methodology, findings and severity
• Remediation tickets showing owner, date and closure
• Retest results proving the fix
• Segmentation test results
• The tester’s qualification summary and independence statement
• ASV scan reports, including the failed ones and the passing rescan

Evidence is strongest when each item is dated, has a named owner, and links to the control it supports. A CERG audit procedure puts it this way: evidence should show the control or request, period, source, owner or approver, scope and result, and a ticket with approval, timestamp and closure usually beats a polished narrative. Treat that as good practice, and confirm the exact retention period your assessor or acquirer expects.

Common mistakes

• Scanning and calling it a pentest. A scan report alone does not meet the requirement.
• Scoping only the payment page. Connected systems and admin paths belong in scope.
• Skipping segmentation testing while claiming reduced scope.
• Forgetting significant change. A new payment provider integration in March does not wait for next year’s test.
• Closing findings without a retest.
• Letting the team that built the system test it. That fails the independence expectation.

Perspective: treat pentests as one input to a compliance system

We see the same pattern in companies preparing for PCI DSS, ISO 27001, SOC 2 or NIS2 at once. The pentest report is produced by one person, the vulnerability scans by another, the policies by a third, and then each framework asks for roughly the same evidence in a different format. The work is repeated, and the dates drift apart.

Our view is that a pentest is worth most when its findings flow straight into your risk register, your remediation tracking and your audit evidence, and when one finding can be mapped to every standard it touches. A fixed segmentation gap supports PCI DSS scope reduction and also serves access control requirements in ISO 27001. That is why we built Guardiso around mapping requirements across standards, so documentation and controls are written once and reused. Our own ISO 27001 certification was completed without any non-conformities, and the same discipline of dated, owned, linked evidence is what we recommend for a PCI assessment.

— the author

How Guardiso can help

If you need an independent test, our team delivers external and internal pentests, web, API and mobile application tests, and vulnerability assessments, and the findings can be tracked alongside your compliance work. For the standard itself, see our overview of PCI DSS and who it covers. If you want the platform to manage risks, evidence and audit preparation, plans start at 849 zł per month for Starter and 2149 zł per month for Professional, with Enterprise on request, all on the pricing page.

FAQ

Is a vulnerability scan enough to meet the PCI pentest requirement?

No. Scans are largely automated and rank vulnerabilities, while a penetration test is a manual process that attempts to exploit them. PCI DSS expects both, on different schedules.

How often do I need a penetration test for PCI DSS?

At least once a year and after any significant change to your infrastructure or applications. Quarterly external scans by an ASV run in parallel.

Can my internal team do the penetration test?

Possibly, if the testers are organizationally independent of the people who install, maintain or support the systems being tested and have the experience to do the work. Many companies hire an outside provider to make independence easy to show.

What happens if my ASV scan fails?

You fix the vulnerabilities and arrange a rescan. A scan passes only when it shows no urgent, critical or high vulnerabilities, so keep the failed report and the passing rescan together as evidence.

Sources

• PCI SSC Penetration Testing Guidance v1.1
• PCI SSC Penetration Testing Guidance v1.1 (listings copy)
• PCI SSC ASV Resource Guide v1.2
• PCI SSC ASV Program Guide
• PCI DSS v3.2.1 to v4.0 Summary of Changes
• PCI SSC press release on PCI DSS v4.0.1
• OWASP DevSecOps Guideline: Vulnerability Management
• NCSC: Carry out vulnerability assessments
• Tanium: What is vulnerability remediation
• CERG audit and evidence management procedure

Recommended

• PCI DSS: what it is, who it covers
• Pentests, ISO 27001, NIS2 and DORA audits, VISCO