PCI penetration testing: which tests you need, by SAQ or ROC

By The PenTest Index

PCI penetration testing is PCI DSS v4.0.1 Requirement 11.4: external and internal tests at least every 12 months and after significant changes, a retest of fixes, and a segmentation test if you segment. How much applies depends on your route: SAQ A includes none, SAQ A-EP has no internal test line, and SAQ D or a ROC carries the full set that applies to your entity.

Find your route in the table below. Then see what published offers charge for each piece, and six things to check before you sign.

Requirements and offer terms checked October 9, 2026. We read the standard, the questionnaires and each provider's own pages. We did not buy or run any test.

Which PCI penetration testing does your SAQ or ROC require?

It depends on the form you report with. A self-assessment questionnaire (SAQ) lists only the requirements for that kind of business. A Report on Compliance (ROC) is the reporting tool used to document detailed results from a PCI DSS assessment. Here is what each one carries from Requirement 11.4.

Sources: PCI SSC questionnaires for PCI DSS v4.0.1 (SAQ A revision 1, January 2025; SAQ A-EP, B-IP, C, C-VT and D for Merchants, October 2024; SAQ D for Service Providers revision 2, January 2025). Read October 9, 2026 from publicly hosted copies. Get the current forms from the PCI SSC document library.

Two cautions. First, do not pick your SAQ from this table. Your payment flow must meet the form's eligibility criteria, and the organization that accepts your PCI paperwork—often your acquirer or a payment brand—determines which reporting method it accepts. Second, the table shows what is printed in each form. If your contract or assessor asks for more, that still counts.

What this means for your purchase:

• SAQ A or SAQ C-VT. No penetration test is in your form. SAQ A still lists external scans at least once every three months by an Approved Scanning Vendor (ASV). If scans are the gap, use the PCI SSC's ASV list. You can stop here.
• SAQ B-IP or SAQ C. The only line is the segmentation test, and only if you use segmentation. Don't let anyone sell you the full bundle on the strength of that one line.
• SAQ A-EP. You need a written method, an external test that covers your website at the application layer, and a retest of what gets fixed. There is no internal test line. The written method still talks about testing from inside and outside, so ask your acquirer or assessor before you rule internal work out.
• SAQ D or a ROC. You need the full set that applies to your entity. Check what last year's report already covers before you buy all of it again.
• Service providers. Same set; if you use segmentation, test it twice a year, and if you are multi-tenant, support your customers' external testing.

Know your list? Turn it into a scope checklist you can send to every provider, so their quotes answer the same job. It is free, there is no sign-up, and nothing is sent to providers. A checklist is a buying aid. It is not permission to test.

Build your scope checklist

What if you don't know your route?

Ask before you buy anything. Send this to the organization that accepts your PCI paperwork (usually your acquirer), and to your assessor if you have one:

Which PCI DSS reporting route and version must we use? Which penetration testing and segmentation requirements apply to our environment? What evidence do you need from us, and by what date?

Until you hear back, use the full merchant set as a provisional planning assumption. If you are a service provider, 11.4.6 and 11.4.7 may add work, so confirm your route before you buy.

What does PCI DSS Requirement 11.4 ask for?

Seven parts. Requirements 11.4.6 and 11.4.7 apply only to service providers, and the segmentation parts apply only when you use segmentation.

Source: PCI DSS v4.0.1 (June 2024), Requirement 11.4, read October 9, 2026. The table is our summary, not the standard's text.

Three terms. The cardholder data environment (CDE) is made up of the system components, people and processes that store, process or transmit cardholder data or sensitive authentication data, plus system components with unrestricted connectivity to them. Segmentation means walling the CDE off from the rest of your network so the rest stays out of PCI scope. A service provider is a business other than a payment brand that is directly involved in storing, processing or transmitting card data for another entity, or whose services control or could affect its security.

One thing that trips people up: older pages and old reports cite "11.3" for penetration testing. That was the previous version's numbering. In v4.x, 11.3 is scanning and 11.4 is penetration testing.

Is an ASV scan the same as a PCI pen test?

No. Scans are Requirement 11.3. Penetration tests are Requirement 11.4. Passing one does not cover the other.

Sources: PCI DSS v4.0.1, 11.3.2 and 11.4; PCI SSC Penetration Testing Guidance, section 2.1.

Think of a scan as checking every door for a lock with a known fault. A penetration test is a person trying to get from the lobby to the vault. For more on the difference, see penetration testing vs vulnerability scanning.

How much does PCI penetration testing cost?

Among providers that publish prices, the pieces start at $4,200 for an external test, $6,000 for an internal test with segmentation, and $5,200 for one web application (Invadel). Automated tests start at $1,995 (Clone Systems). Most firms that sell PCI testing publish no price, and your scope sets the real number.

All amounts below use the dollar figures published by the providers and were read October 9, 2026 unless noted. Invadel identifies its figures as US dollars; the other inspected pages use dollar amounts without separately naming the currency, so confirm it in a written quote. They are starting or package prices, not quotes for your environment.

Sources: Invadel's PCI price list (updated September 26, 2026); Clone Systems linked pricing, its separate automated-package page and internal pricing; SecurityMetrics penetration testing; Astra and Pentest-Tools.com terms checked directly October 9, 2026. See Astra and Pentest-Tools.com.

Three sums from those published prices. These are our arithmetic on starting prices, not quotes.

• An SAQ A-EP-style set (external test plus one web application, Invadel): $4,200 + $5,200 = $9,400. If you segment, add a segmentation test. Invadel publishes no stand-alone price for one, so that total is incomplete until you ask.
• The full merchant set (external, internal with segmentation, one web application, Invadel): $4,200 + $6,000 + $5,200 = $15,400. Invadel publishes the same figure for a "typical merchant."
• The automated pair (Clone Systems, 1 external target and up to 25 internal hosts): $1,995 + $2,995 = $4,990. The Starter pair does not list segmentation testing, and the automated package alone does not establish the competent manual-attacker work described in PCI DSS v4.0.1. Clone Systems scopes engineer-led testing separately. More on that below.

Vendors also publish broad ranges. SecurityMetrics says its own tests "usually range from $15,000 to $30,000." That is one company describing its own work, not a market average, and we don't treat it as one. And when a quote gives you a day rate, remember that a day rate is not a total.

Holding a quote already? Check it line by line with Quote Check. For budgeting beyond PCI, see penetration testing cost.

Which offers fit which buyer?

No single published offer proves it covers a whole PCI scope. But the published terms do sort the offers. Here is what they support, what they rule out, and what to ask. "Supported" means that one condition is backed by the provider's own page. It is not a verdict on quality, and it does not mean your assessor will accept the report.

Our read:

• You need the full set and want to see prices before a sales call. Start with Invadel. It is the only offer we found that publishes starting prices for the main merchant pieces. Get the retest window and segment count in writing.
• You need the full set and prefer one custom quote. Ask SecurityMetrics for a single scope that names every piece.
• You are on SAQ A-EP with one website. A web application offer (Astra, Pentest-Tools.com or Invadel) can cover the application layer. Confirm in writing that the external test of the site's servers is included too, because the form asks for an external penetration test, not only an app test.
• You only need a segmentation test (SAQ B-IP or SAQ C). Nobody we checked publishes a stand-alone price. Ask for one line, one price.
• You are drawn to the $1,995 automated test. Confirm what competent manual-attacker work is included. If it is not included, ask for the separately scoped engineer-led service before relying on it for 11.4.2 or 11.4.3.
• You already have a provider. Put last year's report through the six checks below. Keeping them may be the right call.

See Invadel's PCI price list

Request a scoped SecurityMetrics quote

See Clone Systems' pen test prices

We have no paid relationship with any provider on this page. The links are plain links.

Six things to check in a PCI pen test quote

A PCI quote should answer these in writing before you sign.

1. Is each required test named? Internal, external, application layer, segmentation. If the quote doesn't say "segmentation," assume it isn't there. (11.4.1 to 11.4.5)
2. Who tests, and are they independent? The standard asks for "a qualified internal resource or qualified external third party" with "organizational independence." (11.4.2, 11.4.3, 11.4.5)
3. Is the retest included, and until when? The standard says testing "is repeated to verify the corrections." A free retest you can't use in time is not free. (11.4.4)
4. Is there a written method, and will results be kept 12 months? (11.4.1)
5. Does a competent manual attacker do the testing, with tools supporting the work rather than replacing it? PCI DSS v4.0.1 guidance describes penetration testing as highly manual; the 2017 supplement says an automated tool alone does not satisfy the requirement.
6. Does the report have what an assessor looks for? See the report section below.

Can the free retest run out before your fixes are ready?

Yes, and it is one way a cheap test turns expensive. "Retest included" means little until you turn it into a date.

Here is a made-up example. Say your report and findings are issued November 10, 2026, and your team can have fixes ready by December 15. That is 35 days.

Sources: Astra's rescan rules; Cobalt's retest documentation; SecurityMetrics' timeline checklist, a page dated September 15, 2021; Clone Systems and Invadel pages above. All read October 9, 2026. The dates are our arithmetic on invented inputs.

The Cobalt row shows why the contract date matters. A six-month allowance sounds safe. But if you run the test near the end of your contract, the contract date wins. See Cobalt's terms in full.

If a window doesn't fit, you have three moves: ask for a written extension and its price, start the test earlier, or choose an offer whose window fits. Send this:

Our report is due [date] and our fixes will be ready [date]. What is the last day we can request the included retest, when will we get the updated report, and what does a retest cost after that day?

Does an automated pen test count for PCI?

PCI DSS v4.0.1 does not require the tester to be a QSA or ASV, but its 11.4.1 guidance describes a "competent manual attacker" and calls penetration testing a highly manual process. Automated tools can support the work; an automated package by itself does not establish that the manual-attacker work described in the current guidance occurred.

The September 2017 PCI SSC guidance says the same point more directly: "simply running an automated tool does not satisfy the penetration testing requirement." It is supplemental and older, so it does not add a new rule; it explains the distinction between tool use and the required testing work.

So judge the work, not the label. Ask what is tested, who reviews it, what evidence you get, and whether a person tries to chain findings together. Then ask the provider, and show the answer to whoever accepts your evidence, before you pay:

We are considering an automated external and internal penetration test. Does the service include the competent manual-attacker work described in PCI DSS v4.0.1 for Requirements 11.4.2 and 11.4.3? If not, what engineer-led work must be added?

Can our own team do the test?

Yes, if they are qualified and independent. The standard allows "a qualified internal resource." It does not require a QSA or an ASV.

Independent means the tester doesn't manage the systems being tested. The engineer who manages the firewall can't be the one who assesses it. The PCI guidance gives a similar example for outside firms: an assessor company that installed or supports your systems can't also test them.

Qualified is not defined by a certificate. The guidance lists OSCP, CEH, GIAC and CREST certifications as examples and adds that the PCI SSC does not validate or endorse them. It says experience matters too: years of testing, and work on systems like yours.

If you go this route, write down four things: who will test, why they are independent, the method they will follow, and what the report will contain. Show that to whoever accepts your evidence before the test, not after.

How often is PCI penetration testing required, and do we have to test after every release?

Where Requirements 11.4.2 and 11.4.3 apply, testing is due at least once every 12 months and again after any significant infrastructure or application change. You do not automatically have to test after every release. You do have to evaluate whether each release is significant, and retest after the releases that are.

The standard doesn't define "significant" for you. It lists changes you must at least evaluate:

• new hardware, software or network equipment added to the CDE
• replacement or major upgrades of hardware or software in the CDE
• changes to how account data flows or where it is stored
• changes to the boundary of the CDE or to your PCI scope
• changes to supporting infrastructure, such as directory services, time servers, logging and monitoring
• changes to third-party providers that support the CDE

Two made-up examples. Fixing a typo on your product page is a change, and it should go through your change process, but nothing in that list is touched. Moving checkout to a new payment API changes how account data flows, so it needs a real decision and probably a test of what changed.

Segmentation is stricter. The segmentation test is due after any change to segmentation controls, significant or not.

When you plan the yearly test, work back from the date your SAQ or ROC is signed. Leave room for the report, the fixes and the retest. The 12-month clock runs from your last test, not from your last assessment.

What is a PCI segmentation test, and do you need one?

Only if you use segmentation to keep systems out of PCI scope. If you do, you must prove that the walled-off systems can't reach the CDE.

In practice, the test should attempt access from out-of-scope networks into the CDE and cover every segmentation method in use, using steps such as host discovery and port scanning. In very large networks with many internal LAN segments, the PCI guidance allows testing each type of segmentation method instead of every individual LAN segment, but the result still has to provide assurance that the method is effective wherever it is used. If a network that was supposed to be isolated can reach the CDE, you either fix the control or run a full network test from that network.

Segmentation itself is optional in PCI. Testing it is not, once you rely on it. That is why it should be its own named line in a quote, with the number of segments it starts from.

What should you send every provider?

The same request, so their answers line up. A scope request is like asking three builders to price the same drawing. Without it, each one prices a different house.

Copy this and fill in the brackets.

PCI testing scope request

Our PCI reporting route and version: [SAQ type or ROC; version; who confirmed it]
Who accepts our evidence, and the due date: [acquirer or other; assessor if any; date]
Tests we need: [internal / external / application layer / segmentation / retest], with the requirement number for each
Targets: [public IPs and domains; internal networks; applications; APIs; user roles; critical systems]
Segmentation: [methods in use; number of out-of-scope segments; recent or planned changes]
What we already have: [last report date; what it covered; changes since]
Test environment: [production, or a matching copy; any time windows or limits]
Dates we need: [test start; report; our fixes ready; retest; updated report]

Please state: your method; who will test and their qualifications; how they are independent of our systems; what is included and excluded; what the report contains.
Please price: the full scope; currency; any minimum or annual commitment; what is due now; extras; retest count, last request date and cost after that date.

This request is not permission to test. Testing needs written authorization and rules of engagement that cover the actual targets, activities and dates.

A filled-in example, invented for illustration: Route: SAQ D for merchants, v4.0.1, confirmed by our acquirer. Tests: internal (11.4.2), external (11.4.3), application layer on one payment web app and its API with two user roles (11.4.1), one segmentation boundary (11.4.5), retest (11.4.4). Last report: October 2025, before we changed our payment network. Dates: report by November 10, fixes ready December 15, updated report by January 15.

If you'd rather be walked through it, Find My PenTest Match asks a few questions and gives you a scope checklist to copy or print. For a longer worked example, see our penetration testing scope page.

Does last year's report already cover part of this?

It might. A past test counts toward a requirement when its targets, dates and method match what is being asked, and nothing significant has changed since. Line your old report up against your test list and mark each line covered, gap or unclear. Send your current provider the gaps and ask for a price to extend the work. A summary letter or a "PCI" label on the cover doesn't tell you what was tested. The scope section does.

What should a PCI penetration test report include?

PCI DSS doesn't prescribe a report format. The PCI SSC guidance offers a suggested outline and a checklist, and says plainly that these are suggestions.

The suggested outline covers:

• an executive summary
• a statement of scope that separates CDE systems from the rest and explains why each critical system was tested
• the method used, and any limits placed on testing
• a narrative of how testing went
• segmentation test results, where you segment
• findings, each with a risk ranking, the targets affected and whether it could be used to reach the CDE
• tools used, and cleanup steps

A retest report should show the date of the original test, the date of the retest, the original findings and the result for each.

When a provider sends a sample, read the scope statement and one finding first. If you can't tell exactly what was tested and how the tester proved the finding, the sample does not give your assessor a clear basis to tell either. The full checklist is in section 5.4 of the PCI SSC guidance. For what to look for in any report, see penetration testing report.

No provider can promise your report will be accepted. Your QSA, acquirer or customer decides that.

What do service providers have to do differently?

Two things, when applicable. If you use segmentation, test it every six months, not every twelve (11.4.6). And if you are multi-tenant, support your customers' external testing (11.4.7).

For 11.4.7, the standard gives you two ways to comply. You can give customers evidence that the external test and the retest were done on the infrastructure they use. Redacted results are fine if they still prove the point. Or you can give customers prompt access to test for themselves. This has been required since March 31, 2025.

The internal and external tests stay on the 12-month cycle. Only segmentation, where used, moves to six months.

If you host many customers in one application, the PCI guidance says to test with customer-level logins to confirm one customer can't reach another's card data. See SaaS penetration testing for how that scope is usually written.

Other questions

Can the test run on a staging copy and not on production?

The PCI guidance allows a separate environment if it is "identical to the production environment," with the same application and network controls. The tester needs to confirm the match. Anything exploitable still has to be fixed in production, and testing must be repeated to verify that the weakness has been addressed. Calling something "staging" doesn't make it identical, so agree on this with your assessor first.

Does PCI require social engineering in the test?

No. The guidance says PCI DSS does not require testing to include social engineering, such as phishing. You can add it if you want to test your security awareness program.

Black box, gray box or white box?

The guidance says PCI tests are typically gray box or white box, meaning the tester gets some or all of the details about your systems. It notes that a pure black-box test, with no details given, may take more time and money to meet the requirement.

Can our hosting provider's test cover us?

Partly, in one case. If your provider is a multi-tenant service provider, it must either show you evidence of external testing and remediation verification on the infrastructure you use or let you test it. That can cover the subscribed provider infrastructure for those requirements. What you build and manage on top is still yours to test. And none of this lets you test other customers' systems.

Can one test cover PCI and SOC 2?

It can, if the scope is written for both. See SOC 2 penetration testing.

How we checked

The PenTest Index is an independent buying resource for penetration testing. We don't perform tests, we aren't a QSA or an ASV, and nothing here is compliance advice.

For this page we read PCI DSS v4.0.1 Requirement 11.4, seven PCI SSC questionnaires, and the PCI SSC's Penetration Testing Guidance. We read each provider's own pricing and policy pages and did the sums ourselves. Everything about a provider is that provider's published statement. We did not buy a test, inspect a delivered report, or contact any provider. The PCI SSC document library and Council notices confirmed PCI DSS v4.0.1 as the current published standard and the release of v4.0.1 SAQs, but the licensed direct downloads did not expose their text to our reader, so we checked the standard and questionnaires against publicly hosted copies and link you to the official library for the current versions.

See how we compare offers. Found something out of date? Tell us.

Sources

Checked October 9, 2026 unless noted.

• PCI Security Standards Council, document library and v4.0.1 SAQ release bulletin: PCI DSS v4.0.1 (June 2024) and v4.0.1 self-assessment questionnaires. Requirement and questionnaire text checked against publicly hosted copies.
• PCI Security Standards Council, Information Supplement: Penetration Testing Guidance v1.1, September 2017.
• PCI Security Standards Council, glossary, FAQ 1604 and Approved Scanning Vendors list.
• Invadel, PCI penetration testing cost, updated September 26, 2026.
• Clone Systems, linked external pricing, separate automated-package page, internal pricing and Requirement 11.4 page.
• SecurityMetrics, penetration testing and timeline checklist (dated September 15, 2021).
• Cobalt, retest documentation.
• Astra, pricing and rescan rules; Pentest-Tools.com, managed web application testing. Checked October 9, 2026. See the Astra and Pentest-Tools.com profiles.