Why Most Businesses Get PCI DSS Penetration Testing Requirements Wrong

Most businesses treat PCI DSS penetration testing requirements as a single line item: book a test once a year, file the report, move on. That reading misses most of what Requirement 11.4 actually obliges you to do. It’s the reason assessors keep finding the same gaps at renewal time. The requirement is not one test. It’s internal testing, external testing, segmentation testing, independent tester qualification and documented remediation, each with its own conditions.

Here’s where the checkbox approach usually falls short, and what actually satisfies the standard.

PCI DSS penetration testing requirements are more than one test

Requirement 11.4 splits penetration testing into internal (11.4.2) and external (11.4.3) obligations. Each is required at least once every twelve months, and again after any significant change. Businesses that commission a single external test and assume it covers the requirement are missing half of it. An external test tells you what an outsider on the internet can reach. It says nothing about what happens once someone, or something, already has a foothold inside the network, which is exactly what internal testing is designed to check. Internal and external penetration testing answer genuinely different questions, and treating one as a substitute for the other is where this gap usually starts.

Skipping segmentation testing because “the firewall handles it”

If segmentation is what keeps part of your network out of PCI DSS scope, 11.4.5 and 11.4.6 require you to prove that segmentation still holds. Merchants need this annually, service providers every six months. This is the sub-clause we see skipped most often, usually because a firewall configuration that looked correct at deployment is assumed to still be correct years later. Segmentation drifts. Rules get added for a one-off project and never removed. Testing the segmentation directly, rather than trusting the original design document, is the only way to catch that.

Assuming any tester will do

PCI DSS doesn’t demand a specific certification for your tester. It does demand independence: the person or team testing your systems cannot be the same one that manages or maintains them. Many organisations satisfy the letter of this by using a different internal team. Then, at audit, they find the assessor wants more evidence of genuine separation than a different reporting line provides. Bringing in an external, qualified tester avoids the argument entirely. Our buyer’s checklist for PCI DSS penetration testing covers what to check before you commit to one.

Buying a scan and calling it a test

11.4.1 requires a documented, industry-accepted methodology, referencing standards like NIST SP 800-115 or the OWASP testing guide. It has to cover the full perimeter of the cardholder data environment, at both network and application layer. A vulnerability scan with a report template wrapped around it does not meet that bar. It finds known issues, but it does not attempt to exploit them or chain findings together the way an actual attacker would. It rarely accounts for the specific application logic behind a payment flow either. A checkout, booking form or any page that touches card data needs a dedicated web application penetration test. Without one, the application layer of your cardholder data environment is probably still untested, no matter how thorough the network scan was.

Treating the report as the finish line

Requirement 11.4.4 doesn’t stop at finding vulnerabilities. It requires you to fix exploitable ones according to your own risk assessment, then retest to confirm the fix worked, with both steps documented. A report that sits unopened after delivery doesn’t satisfy the requirement, even if the original test was excellent. Neither does remediation with no follow-up retest. Budget time for this stage, not just money for the test itself. It’s usually the part that slips closest to the audit deadline.

Testing once and never again until next year

The twelve-month cycle in PCI DSS penetration testing requirements is a compliance minimum, not a target. A significant infrastructure change, a new payment integration or a major application release resets the clock. Fresh testing is needed regardless of when the last annual test happened. For a cardholder data environment that changes often, whether through new integrations or seasonal peaks in transaction volume, annual testing genuinely isn’t often enough, PCI DSS aside.

Guessing at scope instead of defining it

A surprising number of the gaps above trace back to one root cause: nobody sat down and properly defined the cardholder data environment before the test was booked. It isn’t just the payment page. Admin consoles, backup systems, logging infrastructure and any third-party integration that can reach card data all belong in scope too. A test built around a narrow, convenient definition of “the environment” will pass cleanly while leaving real exposure untested.

A tester who asks detailed questions about your architecture before quoting a price is doing the scoping work properly. One who quotes off a single call, without digging into how systems connect to each other, is often building that same narrow assumption into the price, and into the test.

Losing the evidence trail

Results, remediation records and retest confirmation need to be kept for at least twelve months, longer if a contract or local law says so. Assessors ask for the whole chain, not just the final report. A finding with no visible remediation ticket or retest sign-off reads, from the outside, exactly like a finding nobody fixed. Evidence retention is the part of PCI DSS penetration testing requirements that gets forgotten once the test itself is over.

What getting PCI DSS penetration testing requirements right looks like

Meeting PCI DSS penetration testing requirements in full means a properly scoped penetration test that covers internal, external and segmentation testing together. It’s run by an independent tester against a documented methodology, with a report built around what your assessor will actually check. If you want an honest read on what your environment needs before your next assessment, get in touch and we’ll tell you plainly, no upselling.

Frequently asked questions

Is one annual penetration test enough for PCI DSS?

Only if it covers internal, external and, where applicable, segmentation testing, and nothing significant has changed in your environment since. A single external-only test does not satisfy the full requirement.

Can we use the same test for internal and external requirements?

No. Internal and external penetration testing are distinct obligations under 11.4.2 and 11.4.3. Both need to be performed, even if they’re commissioned as part of the same engagement.

What counts as a “significant change” that triggers retesting?

Anything that meaningfully alters the cardholder data environment: a new payment processor integration, a major application release, or a firewall or segmentation change, among others. There’s no fixed list. The test is whether the change could plausibly affect the environment’s attack surface.

Do we need to retest after every fix, or just the critical ones?

Requirement 11.4.4 covers exploitable vulnerabilities and security weaknesses found during testing, corrected according to your risk assessment, with retesting to confirm the correction. Treat every exploitable finding as needing a documented retest.

How long do we need to keep penetration test reports?

A minimum of twelve months, along with the remediation and retest evidence, or longer if a contract or local law requires it.

Does a cloud-hosted payment system need the same PCI DSS penetration testing requirements?

Yes. If it stores, processes or transmits cardholder data, or connects to systems that do, it’s inside the cardholder data environment. What you can test directly depends on your cloud provider’s shared responsibility model, but the obligation itself doesn’t change.