PCI DSS Penetration Testing: A Buyer’s Checklist

4

PCI DSS penetration testing requirements mean that if your business stores, processes or transmits cardholder data, you’re on the hook for an annual internal and external test of that environment, under Requirement 11.4. A retest is also due whenever findings surface or systems change significantly. For a business commissioning its first test, or reviewing an existing supplier, the practical question isn’t “do we need this.” It’s “are we buying the right thing.”

That second question trips people up more often. A cut-price vulnerability scan rebadged as a penetration test won’t satisfy a QSA at audit time. Neither will a test that quietly skips application-layer coverage or segmentation verification. The problem rarely shows up in the sales conversation. It shows up months later, when the report lands on a QSA’s desk and turns out to be missing exactly the evidence Requirement 11.4 expects.

What PCI DSS Penetration Testing Actually Requires You to Buy

Requirement 11.4.1 sets the baseline. It calls for a documented methodology based on an industry-accepted approach, such as NIST Special Publication 800-115, covering the full perimeter of the cardholder data environment (CDE) and critical systems, from both an external and internal perspective. Crucially, it has to include application-layer testing, not just network-layer scanning. If a proposal only mentions infrastructure or network testing, ask what’s covering your payment application.

Requirement 11.4.3 sets the clock: external testing at least every 12 months, and again after any significant change. The tester has to be organisationally independent of the team managing what’s being tested, and demonstrably qualified. A formal QSA or ASV credential isn’t mandatory. That independence requirement is worth checking closely if you’re considering an in-house team rather than an external provider.

The Part Most Businesses Underbudget: Remediation and Retesting

Requirement 11.4.4 doesn’t stop at the report. It requires you to fix exploitable vulnerabilities and the wider category of security weaknesses the test finds, then retest to confirm the fix actually worked. Some providers price the initial test attractively and treat the retest as a separate, additional cost. Ask upfront whether one retest cycle is included, because that’s where a cheap quote often stops being cheap.

How fast a finding needs fixing depends on your own documented risk treatment policy under Requirement 6.3.1. It’s worth having that policy settled before the test lands, rather than inventing remediation timelines under audit pressure.

What “Qualified” Actually Means When You’re Vetting a Provider

You don’t need a provider holding a formal QSA or ASV designation for PCI DSS penetration testing, since the standard doesn’t require it. What you do need is organisational independence from whoever manages your environment, and demonstrable, current skill. Recognised offensive security certifications, such as those from OffSec, Zero Point Security and PortSwigger, are a reasonable proxy compliance advisors point to when judging a provider’s competency. Ask to see the credentials of the specific testers who’ll work on your engagement, not just the company’s marketing page.

Ask What Documentation You’ll Actually Receive

Requirement 11.4.1 expects more from PCI DSS penetration testing than a final PDF. It expects a documented methodology, remediation steps for each finding, and retention of testing results and supporting evidence for a minimum of 12 months. A provider who hands over a thin summary report without that underlying evidence trail is setting you up for an awkward conversation with your QSA later. Ask exactly what documentation is included before you sign.

Don’t Forget Segmentation Testing

If network segmentation reduces your PCI scope, that segmentation needs its own verification: annually for merchants, every six months for service providers. This is easy to miss when scoping a quote. It’s a distinct piece of work from the main penetration test, checking that your segmentation controls genuinely isolate the cardholder data environment rather than assuming a firewall rule does the job.

Questions to Ask Before You Sign

Before committing to a PCI DSS penetration testing quote, run it past this checklist:

How PCI DSS Penetration Testing Differs From Cyber Essentials

Businesses that already hold Cyber Essentials sometimes assume it covers this. It doesn’t. Cyber Essentials checks baseline technical controls. At the Plus level, it uses vulnerability scanning rather than adversarial testing. PCI DSS Requirement 11.4 specifically demands a human tester actively trying to exploit weaknesses in your cardholder data environment, which is a materially different, and more thorough, piece of work.

Watch for Scope Creep in the Wrong Direction

Some proposals narrow the CDE definition aggressively to shrink the quoted price. That can leave systems that genuinely touch cardholder data outside the tested scope. Walk through your actual card data flow with the provider before agreeing final scope, rather than accepting their first assumption about what’s in and out. A cheaper quote built on an understated CDE is a false saving if a QSA later disagrees with the boundary.

If you’re weighing up providers for PCI DSS penetration testing, Aardwolf Security’s penetration testing service scopes engagements against the actual requirement text rather than a generic checklist, covering application-layer, network-layer and segmentation testing where needed. Get in touch through our contact page if you want to talk through what your PCI scope actually requires before you compare quotes.

Frequently Asked Questions

How far ahead of our PCI audit should we book the test?

Leave enough time for remediation and a retest cycle to finish before the audit deadline, not just for the test itself. A few weeks of buffer tends to produce rushed fixes rather than resolved findings. The same logic behind how often a business should test more broadly applies here too.

Is a vulnerability scan good enough if it’s thorough?

No. As covered in our guide to penetration testing versus vulnerability scanning, a scan checks for known flaws automatically. Requirement 11.4 specifically requires a human tester attempting to exploit weaknesses and chain them together, which a scan cannot replicate however comprehensive its signature list.

Can we use the same provider every year?

Yes. There’s no requirement to rotate providers, though some organisations do so periodically to get a fresh perspective. A familiar tester isn’t a compliance problem in itself; the independence requirement is about organisational separation, not unfamiliarity.

What should the final report include?

Findings mapped clearly to exploitability and business impact, evidence of methodology used, and confirmation of what was and wasn’t in scope, so you can demonstrate coverage to a QSA without ambiguity. Our breakdown of what a good penetration test report looks like covers the red flags that indicate a weaker one.

Does this apply if we use a third-party payment gateway?

It reduces your CDE footprint but rarely eliminates the requirement entirely. What’s still in your scope depends on exactly how card data flows through your systems, which is worth confirming with a QSA directly.

Should we get a proposal reviewed before we sign it?

If you’re not confident reading a scope document for PCI DSS penetration testing, get someone who understands both the standard and testing methodology to review it before you commit. A vague scope is far easier to fix on paper than after the test has already run and left gaps a QSA later flags.