PCI DSS Penetration Testing Services
Requirement 11.4 of PCI-DSS 4.0 mandates penetration testing at least annually and after any significant infrastructure or application change. External and internal testing. Segmentation validation if you’re claiming cardholder data environment isolation. A report that documents methodology, findings, and remediation evidence. These aren’t interpretive guidelines, they’re specific requirements with a specific auditor, your QSA, checking them off.
The question isn’t whether to do a penetration test. It’s whether the one you do will actually satisfy your QSA and hold up if a payment brand or acquiring bank takes a closer look.
What PCI Actually Requires
The standard expects manual penetration testing, not just automated scanning. It expects internal and external coverage of systems in scope. It expects exploitation attempts, not just enumeration. And it expects a report that shows real methodology and real effort, not scanner output reformatted into a PDF.
If you’re claiming network segmentation to reduce your cardholder data environment scope, which most organizations do because a smaller CDE means a smaller compliance footprint, segmentation testing is required to prove that isolation is real. That means attempting to pivot between segmented zones, testing firewall rules and routing boundaries, and producing results your QSA can use to validate the claim. A lot of organizations skip this or treat it as an afterthought. QSAs have started pushing back on that.
Web Application Scope
Web application testing isn’t always required under PCI, but it frequently is and the determination happens during scoping. If your application directly accepts cardholder data, connects to systems in the CDE, or manages session state around payment flows, it’s likely in scope. Even if you use a third-party processor, the integration points matter.
When web application testing is in scope, Asteros uses the OWASP Application Security Verification Standard to evaluate authentication, access controls, session management, input validation, and business logic, the same structured assessment that makes the report useful to your QSA, your engineers, and any enterprise customers conducting vendor security reviews.
How the Engagement Works
Scoping starts with your environment, your payment flows, and your segmentation strategy. We define what’s in scope, what the testing needs to cover to satisfy your QSA, and whether web application testing is required. Everything is agreed upfront with a flat-fee service agreement.
Testing runs on a timeline that fits your audit schedule. The report documents methodology, validated findings with proof of concept, segmentation test results, and remediation guidance written for your engineering team. Your QSA gets what they need to close the penetration testing requirement. Your engineers get a clear path to remediation. After fixes are made, a free retest validates the results and produces the closure evidence Requirement 11.4.4 expects.
What Makes the Difference
A lot of PCI penetration tests are vulnerability scans with a cover page. They clear a lenient QSA and produce nothing useful. The problem surfaces when a payment brand audit goes deeper, when an enterprise customer’s procurement team asks to see the methodology, or when an incident raises questions about whether the testing program was real.
Asteros engagements are manual-first, validated, and documented to a standard that holds up under scrutiny. Findings are exploited where possible, chained where relevant, and written up with the business impact narrative that makes the risk legible to someone who isn’t reading CVE descriptions for fun. No filler, no recycled boilerplate, no scanner dumps dressed up as analysis.
PCI penetration testing FAQs
Does PCI DSS require penetration testing?
Yes. Requirement 11.4 of PCI DSS 4.0 mandates penetration testing at least annually and after any significant infrastructure or application change, covering both external and internal testing.
How often is PCI penetration testing required?
At least once every 12 months, and again after any significant change to your infrastructure or applications. Segmentation controls must also be tested at least every 12 months, or every six months if you are a service provider.
Is a vulnerability scan enough for PCI?
No. The standard expects manual penetration testing, not just automated scanning. It expects internal and external coverage of systems in scope, exploitation attempts rather than enumeration, and a report that shows real methodology and real effort.
Does our web application need to be tested?
Not always, but frequently, and the determination happens during scoping. If your application directly accepts cardholder data, connects to systems in the CDE, or manages session state around payment flows, it’s likely in scope. Even if you use a third-party processor, the integration points matter.
Do we need segmentation testing?
If you’re claiming network segmentation to reduce your cardholder data environment scope, yes. Segmentation testing is required to prove the isolation is real, and it produces results your QSA can use to validate the claim.
How much does it cost?
It depends on scope: the size of your cardholder data environment, how many networks and hosts are involved, and whether segmentation or web application testing is needed. After a scoping call you get a flat-fee service agreement, so the price is agreed up front and doesn’t move once work starts.
How long does it take?
Testing runs on a timeline that fits your audit schedule. Tell us your assessment date during scoping and the engagement is planned back from it, with time left for remediation and the free retest.
Schedule a Consultation
If you’re heading into a PCI audit and want to make sure the penetration testing requirement is satisfied cleanly, the scoping call is where we figure out what the engagement needs to cover.
Or if you’re evaluating vendors, our free guide covers what a rigorous pentest report looks like and what to ask before you sign.
Download the free guide: Audit-Proof Your Pentest →