Does PCI Require a Penetration Test?

PCI requires a penetration test only for some merchants, not all of them. If you take cards only through a standalone terminal, or your online store fully hands off payment to a provider, PCI probably does not require you to buy a penetration test at all. If you store or directly handle card data, or you run an e-commerce site whose own pages touch the payment flow, then it does. The honest answer is “it depends on how you take cards,” and this guide shows you exactly where your business lands, so you neither skip a test you owe nor pay for one you do not. It is written for the business owner staring at a compliance questionnaire, not for an auditor.

The short version, by how you take cards

Which parts of PCI apply to you are decided by your Self-Assessment Questionnaire, or SAQ, and there are several. Your SAQ depends on how card data flows through your business. Here is the plain-English map of who owes a penetration test and who does not:

How you take cards (typical SAQ)	Penetration test?	Quarterly ASV scan?
Online store, payment fully outsourced to a redirect or hosted page (SAQ A)	No	Yes, if you have a payment webpage
Online store where your own page touches the payment fields (SAQ A-EP)	External only	Yes
Standalone dial-out or imprint terminals (SAQ B)	No	No
Standalone internet-connected terminals (SAQ B-IP)	No	Yes
Web-based virtual terminal, one card at a time (SAQ C-VT)	No	No
Payment application connected to the internet (SAQ C)	No	Yes
Validated P2PE terminal solution (SAQ P2PE)	No	No
You store or fully handle card data (SAQ D)	Internal and external	Yes

One honest caveat: your acquiring bank or payment brand has the final say on which SAQ you file, so treat this as “typically” rather than a guarantee. If you are not sure which row is you, confirm it with them before you spend a dollar. But for most small card-present businesses, the answer to “does PCI require a penetration test” is simply no, and no reputable tester should tell you otherwise to make a sale.

Why the requirement lands where it does

The logic is straightforward once you see it. Penetration testing lives in PCI DSS Requirement 11.4, and it exists to prove that the systems handling card data can stand up to a real attacker. So the requirement follows the risk. If your business keeps card data inside your own systems (SAQ D), you carry the most risk and you owe the most testing: internal and external penetration tests, plus testing of any segmentation you use to wall the card data off. If your e-commerce page itself is part of the payment path (SAQ A-EP), you owe an external test, because your public-facing site is in the line of fire. If you fully outsource payment or use standalone terminals, the sensitive handling is not on your systems, so PCI does not ask you to test what you do not run.

That last point matters, and it is where a lot of merchants get oversold. Having a website, an office network, or an internet connection is not, by itself, something PCI makes you penetration test. The requirement is tied to where card data actually flows, not to the mere fact that you exist online.

A penetration test is not an ASV scan

This is the single most common mix-up, so it is worth being clear. PCI has two different testing activities and they are not interchangeable:

• The ASV scan (Requirement 11.3) is an automated vulnerability scan of your internet-facing systems, run at least once every three months by a PCI-approved scanning vendor. It checks for known weaknesses. Many merchants who owe no penetration test still owe these quarterly scans, which is exactly why “my processor asked for a passing scan” gets misheard as “I need a pentest.” Usually it does not mean that.
• The penetration test (Requirement 11.4) is a hands-on exercise where a qualified tester actively tries to break in, chaining weaknesses together the way a real attacker would. The standard says it plainly: scanning for vulnerabilities alone is not a penetration test.

If you want the full picture of how these differ, we walk through it in penetration test vs vulnerability scan. The short version: a scan is a smoke detector, a penetration test is a fire drill.

How often, and after what

For the merchants who do owe a penetration test, the cadence is specific. PCI requires it “at least once every 12 months,” and also after any significant change to your infrastructure or applications. That second half is easy to forget and important: re-platforming your website, moving your payment environment, or a major network change can trigger a fresh test before the year is up. And when a test finds an exploitable weakness, Requirement 11.4.4 says you fix it and then test again to confirm the fix held. A finding is not closed until the retest proves it.

Who is allowed to perform it

PCI does not require your penetration tester to hold any particular certification, and specifically says the tester does not need to be a QSA or an ASV. What it does require is competence and organizational independence: the person testing your systems cannot be the same person who built and manages them, because you cannot meaningfully grade your own work. This is one honest argument for bringing in an outside tester rather than leaning on your internal IT team or your MSP. An independent external test, and an internal test where SAQ D applies, gives you both the required independence and a genuine second opinion. It is the same reason financial audits are not done by the company’s own bookkeeper.

A note for SaaS companies and service providers

If your business is a service provider rather than a merchant, meaning other companies rely on your systems as part of their card handling, the bar is higher. Service providers who use segmentation must test it every six months rather than every twelve. And since March 2025, multi-tenant providers must actively support their customers’ external penetration testing, either by supplying evidence that the shared infrastructure was tested or by giving customers a way to test their own slice. If you run a platform that other merchants plug into, those two obligations are easy to miss and worth confirming you meet.

Frequently asked questions

Does PCI DSS require a penetration test?

Only for some merchants. If you store or directly handle card data (SAQ D) you owe internal and external tests; if your e-commerce page is part of the payment flow (SAQ A-EP) you owe an external test. Terminal-only and fully outsourced merchants generally owe no penetration test, though many still owe quarterly ASV scans.

Which PCI SAQ types require penetration testing?

SAQ D (merchants and service providers) requires the full internal and external penetration test, and SAQ A-EP requires an external test. SAQ A, B, B-IP, C, C-VT, and P2PE do not include a penetration test requirement. Your acquiring bank confirms which SAQ applies to your business.

Is an ASV scan the same as a penetration test for PCI?

No. An ASV scan is an automated quarterly vulnerability scan of your internet-facing systems under Requirement 11.3. A penetration test is a hands-on manual exercise under Requirement 11.4. The PCI standard states directly that scanning alone is not a penetration test. Many merchants owe the scan but not the test.

How often does PCI require penetration testing?

At least once every 12 months, and again after any significant change to your infrastructure or applications. Service providers who rely on segmentation must test that segmentation every six months. Any exploitable finding must be fixed and then retested to confirm the fix.

Can we perform our own PCI penetration test?

PCI allows a qualified internal tester, but requires organizational independence: the tester cannot be someone who manages the systems being tested. In practice, most businesses use an independent outside tester to satisfy that cleanly and to get a genuine second opinion, and no certification such as QSA or ASV is required to perform it.

The bottom line

Whether PCI requires a penetration test comes down to how you take cards. Store or handle card data yourself and you owe one; run an e-commerce page that touches payments and you owe an external one; use terminals or fully outsource, and you very likely do not, even if you still owe quarterly scans. The goal is to meet exactly what your validation path requires, no less and no more. If you want a straight answer about which category you are in and what a right-sized test would cost, tell us how your business takes cards and we will lay it out plainly, with a fair, fixed quote and no upsell for testing you do not need. Request a quote, or see our transparent pricing first.