Skip to content
Invadel

Compliance

PCI DSS
Penetration Testing

Component tests from $4,200, free retest. See all pricing →

Last reviewed

Get a fixed quote

Reply in one business day

Full scoping questionnaire 
Senior certified testers, manual-first185+ years combined experienceOnboarding within 24 hoursFree retest includedOur methodology

When you need it

When you need PCI DSS penetration testing

The situations that bring teams to this engagement, and where it fits alongside the rest of your program.

  • Your ROC or SAQ D is due and Requirement 11.4 needs an internal, external, and segmentation test inside the last twelve months.
  • You are a service provider and the six-month segmentation testing clock in 11.4.6 is running.
  • A significant change happened: a new payment flow, a re-platformed storefront, a CDE migration, or new segmentation.
  • Your QSA flagged that last year’s test was a scanner report, not a penetration test, or that the methodology was undocumented.
  • You are reducing PCI scope through segmentation or tokenization and need proof that the boundary actually holds.

Requirement 11.4

What PCI DSS v4.0 requires: 11.4.1 through 11.4.7

Requirement 11.4 is seven sub-requirements, not one line item. This is what each demands and how the engagement satisfies it.

What it requires

11.4.1
A documented penetration testing methodology based on industry-accepted approaches, covering the entire CDE perimeter and critical systems, both application and network layers, and reviewing threats from the last 12 months.
11.4.2
Internal penetration testing at least once every 12 months and after any significant infrastructure or application change, by a qualified, organizationally independent tester.
11.4.3
External penetration testing on the same cadence and with the same tester qualifications.
11.4.4
Exploitable vulnerabilities and security weaknesses found during testing are corrected and testing is repeated to verify the corrections.
11.4.5
Where segmentation is used to isolate the CDE, penetration testing on segmentation controls at least once every 12 months and after changes, confirming they are operational and effective.
11.4.6
Service providers only: segmentation testing at least once every six months and after any change to segmentation controls.
11.4.7
Multi-tenant service providers support their customers’ external penetration testing.

How we cover it

11.4.1
Our methodology is documented against the PCI SSC Penetration Testing Guidance and PTES, and the statement is included in the report for your QSA.
11.4.2
An internal penetration test from inside the network, scoped to the CDE and the systems that can reach it.
11.4.3
An external penetration test of the internet-facing CDE perimeter, including payment pages and APIs.
11.4.4
A free retest of every remediated finding, with the report updated to show it closed.
11.4.5
Network segmentation testing from every out-of-scope network segment toward the CDE, with evidence of what was reachable.
11.4.6
A six-month segmentation cadence scheduled into your program, so the evidence is never stale at assessment time.
11.4.7
Testing coordinated with your provider under their customer-testing policy, with the evidence you need for your own assessment.

Each sub-requirement, with what the QSA checks in the evidence, is explained in our guide to PCI DSS penetration testing requirements.

Terms

PCI compliance test vs PCI penetration test

A “PCI compliance test” can mean four different things; only one is the Requirement 11.4 penetration test.

Who does it

External ASV scan (11.3.2)
A PCI SSC Approved Scanning Vendor
Internal vulnerability scan (11.3.1)
You, or a scanning provider
SAQ or ROC
You (SAQ) or a QSA (ROC)
Penetration test (11.4)
A qualified, organizationally independent tester

How often

External ASV scan (11.3.2)
At least every three months
Internal vulnerability scan (11.3.1)
At least every three months and after significant change
SAQ or ROC
Annually
Penetration test (11.4)
At least every 12 months and after significant change; segmentation on its own clock

What it proves

External ASV scan (11.3.2)
No known high-risk vulnerabilities on internet-facing systems
Internal vulnerability scan (11.3.1)
Known vulnerabilities inside the CDE are found and fixed
SAQ or ROC
Which requirements apply and whether you meet them
Penetration test (11.4)
Whether an attacker can actually reach cardholder data, and whether segmentation holds

We deliver the ASV scans, the internal scans, the penetration test, and, for organizations that validate with a Report on Compliance, the ROC assessment. Scans and tests are not interchangeable: a clean ASV scan does not satisfy 11.4, and a penetration test does not replace the ASV scan. Our comparison of an ASV scan vs a penetration test shows what each finds, and the PCI compliance checklist covers the other requirements.

Cadence

How often: merchants vs service providers

Merchants

Internal penetration test (11.4.2)
At least every 12 months and after significant change
External penetration test (11.4.3)
At least every 12 months and after significant change
Segmentation testing (11.4.5 / 11.4.6)
At least every 12 months and after changes to segmentation
Internal vulnerability scans (11.3.1)
At least every three months
External ASV scans (11.3.2)
At least every three months, by an Approved Scanning Vendor

Service providers

Internal penetration test (11.4.2)
At least every 12 months and after significant change
External penetration test (11.4.3)
At least every 12 months and after significant change
Segmentation testing (11.4.5 / 11.4.6)
At least every six months and after changes to segmentation
Internal vulnerability scans (11.3.1)
At least every three months
External ASV scans (11.3.2)
At least every three months, by an Approved Scanning Vendor

“Significant change” is defined by your own change-management process and your QSA, but new payment channels, re-platformed applications, CDE cloud migrations, and firewall or segmentation redesigns almost always qualify. Ask us before assuming a change is minor.

What we assess

What your PCI DSS test covers

PCI penetration testing starts with your cardholder data environment. We scope it, then test to the standard the council’s Penetration Testing Guidance describes, handing your QSA evidence they accept rather than a raw scan.

Requirement 11.4: Testing

The penetration testing and segmentation testing PCI DSS v4.0 mandates, done to the standard your QSA expects.

We test for

  • External and internal penetration testing (11.4.2, 11.4.3)
  • Segmentation penetration testing (11.4.5 / 11.4.6)
  • Quarterly scan support (11.3)
  • Remediation and retest (11.4.4)

Cardholder Data Environment

Whether your CDE is correctly scoped and isolated from the rest of your network.

We test for

  • CDE scope validation
  • Segmentation and isolation
  • Data flow verification
  • Out-of-scope confirmation

Access & Authentication

Controls over who can reach cardholder data and how they prove identity.

We test for

  • Access control and least privilege
  • Multi-factor authentication
  • Default and weak credentials
  • Account management

Secure Configuration

Whether systems handling card data are hardened against known weaknesses.

We test for

  • System hardening baselines
  • Patch and vulnerability status
  • Insecure services and protocols
  • Logging and monitoring

Validation route

Do you need it for your SAQ or ROC?

Your validation route follows from your merchant or service provider level and how you take payments. Our guide to PCI compliance levels and SAQ types explains how each is assigned; the table shows what each route asks of Requirement 11.4.

Requirement 11.4 penetration testing

Report on Compliance (ROC)
Required in full: internal, external, and segmentation testing.
SAQ D (merchants and service providers)
Required in full.
SAQ A-EP
Required, except the internal test. SAQ A-EP includes 11.4.1, 11.4.3, 11.4.4, and 11.4.5: a documented methodology, external penetration testing, correction and retest of findings, and segmentation testing where segmentation is used. It does not include the internal test of 11.4.2.
SAQ A
Not included. Fully outsourced payment pages carry no 11.4 obligation, but the acquirer or a customer may still ask for testing.
SAQ B-IP and SAQ C
Segmentation testing only (11.4.5), and only if you use segmentation to isolate the CDE.
SAQ B, C-VT, P2PE
Not included. Confirm the SAQ version with your acquirer or QSA, and we will match the scope to it.

Sample scopes

What a PCI penetration test looks like for three common environments

Requirement 11.4 reads the same for everyone; the scope it produces does not. These are the three shapes we see most often, priced from the published tiers.

E-commerce merchant, SAQ A-EP

A checkout hosted on your own site with a payment page you control. Scope: a web application test of the storefront and checkout flow, an external test of the hosting perimeter, and segmentation evidence if the CDE is isolated from the rest of the estate.

Service provider handling card data

A payment processor, gateway, or hosting provider with a segmented CDE. Scope: external and internal testing annually, segmentation testing every six months under 11.4.6, and application-layer testing of the APIs that carry cardholder data. It is the usual shape for payment processors in Atlanta and elsewhere.

Retailer or restaurant group with POS

Point-of-sale terminals and back-office systems on a store network. Scope: an internal test from the store and corporate networks toward the CDE, segmentation testing between them, and an external test of the remote-access and vendor connections into the environment. Hotel and resort groups add the booking and loyalty systems around the CDE, a common scope for hospitality groups in Florida; our page on hotel cybersecurity covers the property side.

Every scope is confirmed against your network diagram and data-flow documentation before we quote, and the price is fixed in writing. Where the CDE spans the perimeter and the internal network, the two are scoped together as one network penetration testing engagement. Our breakdown of PCI penetration testing cost prices each component.

Payment pages

Payment page scripts: Requirements 6.4.3 and 11.6.1

Two requirements aimed at e-skimming were best practice until 31 March 2025 and are mandatory now. Most e-commerce merchants have to show both.

6.4.3: manage every script on the payment page

Every script that loads and runs in the customer’s browser on the payment page must be authorized, have its integrity assured, and sit on an inventory with a written reason for being there.

11.6.1: detect unauthorized changes

A change- and tamper-detection mechanism must alert your team to unauthorized changes to the payment page’s security-impacting HTTP headers and script contents as the browser receives them, checked at least weekly or on the cadence your targeted risk analysis sets.

Where the penetration test fits

A test does not replace the script inventory or the detection mechanism. It checks whether they work: a web application test of the checkout looks for ways to inject or swap script on the payment page, weak Content Security Policy, and third-party scripts loaded without integrity checks. Our e-commerce penetration testing guide covers the storefront side.

SAQ A merchants: the current SAQ A drops 6.4.3 and 11.6.1 from the questionnaire and adds an eligibility criterion instead. If your checkout embeds the payment provider’s form, for example in an iframe, you must confirm your site is not susceptible to attacks from scripts that could affect your e-commerce systems, either with techniques like those in 6.4.3 and 11.6.1 or with written confirmation from your PCI DSS compliant payment provider. The criterion does not apply when your site redirects the customer to the provider’s own payment page.

Who tests

Who can perform a PCI penetration test

PCI DSS does not require a specific certification, but it does require that the tester is qualified and organizationally independent of the systems under test. An internal team can qualify if it is genuinely independent, which is why most merchants and service providers buy an independent third-party penetration test. Your QSA will ask how the tester is qualified, and our report documents tester qualifications, experience, and independence for exactly that question.

The QSA also checks four things about the test itself: that the methodology is documented (11.4.1), that the scope covered the whole CDE perimeter and every in-scope segment, that exploitable findings were fixed and retested (11.4.4), and that segmentation evidence shows what each out-of-scope segment could reach. The report is structured around exactly those checks.

Timeline

Timeline and the report

Before testing: about a week

CDE scoping call, network and segmentation diagrams, data-flow confirmation, test accounts, and rules of engagement. Most delays in PCI testing happen here, so we start it the day the proposal is signed.

Testing: one to three weeks

External, internal, and segmentation testing run in sequence or in parallel depending on scope, with critical findings escalated the day they are confirmed.

After testing: one to two weeks

Report delivery, remediation support, and the free retest. The final report shows findings closed and is retained for your next assessment, which QSAs expect to see alongside the prior year’s report.

The report contains the methodology statement, scope and segmentation evidence, findings rated by severity with exploited paths, retest results, and tester qualifications. Our penetration testing report template shows the full structure.

Methodology

How we test

Full methodology →

Every engagement follows the Penetration Testing Execution Standard and the relevant OWASP guides.

These are the phases your compliance test runs through.

  1. 01

    Scope the boundary

    The systems your framework actually covers, and nothing you would pay to test twice.

  2. 02

    Test

    The component penetration tests run to PTES and OWASP standards by senior testers.

  3. 03

    Map to controls

    Every finding tied to the requirement or control it evidences.

  4. 04

    Report for the auditor

    Evidence formatted the way your assessor, examiner, or QSA expects to read it.

  5. 05

    Fix & retest

    A free retest so the audit shows closed findings, not open ones.

How it works

How your engagement runs

From scope through the final retest, your team stays in the loop at every step, with findings tracked live in our platform.

  1. 01

    Scope the CDE

    We validate your cardholder data environment and segmentation for PCI scope.

  2. 02

    Req 11 testing

    Internal, external, and segmentation testing to the standard QSAs expect.

  3. 03

    QSA report

    Findings aligned to PCI requirements, given as evidence your QSA accepts.

  4. 04

    Fix & retest

    Close the findings, then run a free retest before your assessment window.

Component tests

The tests behind your PCI DSS evidence

Compliance testing is built from our standard fixed-scope engagements. Each one is scoped to your boundary and reported against the framework.

External penetration testThe internet-facing CDE perimeter, for Requirement 11.4.3. From $4,200.Internal penetration testThe internal CDE and segmentation testing, for 11.4.2, 11.4.5, and 11.4.6. From $6,000.Network segmentation testingProof the CDE boundary holds from every out-of-scope segment, for 11.4.5 and 11.4.6. Included in the internal test from $6,000; standalone six-month re-validation is quoted.Web application penetration testPayment pages, checkout flows, and merchant portals, for the application-layer coverage 11.4.1 expects and Requirement 6.4. From $5,200.Vulnerability scanningQuarterly internal scans for 11.3.1, from $1,500 per scan, and the quarterly ASV scans of 11.3.2.Secure code reviewReview of custom payment software before release, for Requirement 6.2.3. From $4,800.
Industries that need thisFintechHealthcare & MedTechE-commerce & RetailMedia & AdTechSmall BusinessBanks & Credit UnionsHotels & HospitalityNonprofitsAll industries

Proof

Proof in the field

Every engagement is confidential, so the work below is anonymized to sector and engagement type.

All case studies →

Free

Retest on every penetration test

185+

Years combined experience

14

Senior in-house specialists

24h

Onboarding after signing

Fintech · Payments

Web Application Penetration Test

High risk

Critical: a remote code execution flaw in the application’s web framework that could have given an attacker full control of the server. We escalated it to the development team while the test was still running.

Outcome. The critical RCE was reported and remediated during the engagement via an emergency framework upgrade, which also closed the server-side request forgery, and the remaining findings were retested to confirmation.

1

Critical (RCE)

Mid-test

Critical remediated

2

High

Read the case study

Fintech · Payments

Post-Incident Web App Assessment

Medium risk

Excessive data exposure: API responses leaked transaction metadata, including precise geolocation, enabling real-world tracking of users.

Outcome. Surfaced the exposure and hardening gaps, prioritized by how readily an attacker could chain them, and delivered fixes plus a retest to confirm closure.

8

Findings

3

Medium

Post-incident

Engagement

Read the case study
LatentPerygeeCity National BankAubaDesteiaDTCC
Request a reference 

Resources

Field notes from the offensive side

All articles →

PCI DSS Penetration Testing Requirements: Requirement 11.4 Explained Line by Line

PCI DSS v4.0.1 Requirement 11.4 explained: internal and external tests, segmentation testing, retesting, methodology, tester qualifications, QSA evidence.

PCI Compliance Levels and SAQ Types: Which One Applies, and When You Need a Pentest

PCI compliance levels by card brand, what each level submits, the SAQ types and who qualifies, and which SAQs require ASV scans or a penetration test.

PCI Penetration Testing Cost in 2026: What Requirement 11.4 Costs, Component by Component

PCI penetration testing cost in 2026 by component: external from $4,200, internal with segmentation from $6,000, typical merchant from $15,400, retest included.

Want to see a report first?

Read a sample report for a fictional client, or request a redacted one from a real engagement. Our guide explains what a penetration testing report should contain.

See the sample report

FAQ

Frequently asked questions

What teams most often ask before PCI DSS testing.

Still have questions? 
01What does PCI DSS require for penetration testing?

Under PCI DSS v4.0, Requirement 11.4 calls for internal and external penetration testing at least annually and after significant changes, following a defined methodology (11.4.1). Where segmentation isolates your cardholder data environment, segmentation testing is also required. Separately, Requirement 11.3 requires quarterly internal and external (ASV) vulnerability scans. We cover all of it to the standard your QSA expects.

02How often is segmentation testing required?

It depends on your role. Merchants must validate segmentation with penetration testing at least annually (11.4.5). Service providers must do so at least every six months and after any change to segmentation controls (11.4.6). We schedule testing to match whichever applies to you.

03Do I need a penetration test for my SAQ or ROC?

If your validation route requires Requirement 11.4 (a Report on Compliance, or SAQ types that include it, such as SAQ D), then yes. Simpler self-assessment questionnaires may not. Tell us your merchant level and validation route during scoping and we will confirm exactly what testing applies.

04Will your report satisfy our QSA?

Yes. We deliver a report aligned to PCI requirements with the evidence your QSA needs, not a raw scanner dump.

05Do you deliver the ROC assessment and the ASV scans too?

Yes. Invadel delivers PCI DSS Report on Compliance (ROC) assessments and the quarterly ASV scans of Requirement 11.3.2, alongside the Requirement 11.4 penetration test. You get scanning, testing, and the assessment from one provider, on one calendar. The penetration test is still scoped and reported on its own, as 11.4 requires, at a fixed price with a free retest.

06What methodology should a PCI pen test follow?

Requirement 11.4.1 says your penetration testing methodology must be defined, documented, and based on industry-accepted approaches. The PCI Security Standards Council publishes a Penetration Testing Guidance information supplement that QSAs treat as the benchmark: it expects coverage of the entire CDE perimeter and critical systems, testing from inside and outside the network, application-layer and network-layer testing, and review of threats from the last 12 months. Our methodology is documented against that guidance and PTES, so the methodology question on your ROC is already answered.

07How do we choose a PCI penetration testing vendor?

PCI DSS requires the tester to be qualified and organizationally independent of the systems being tested, so ask any vendor three things: how tester qualifications, experience, and independence are documented in the report, whether testing is manual or mostly a scanner run (11.4 testing must go beyond scanning), and whether the report maps findings to PCI requirements with segmentation evidence a QSA can act on. Fixed pricing and a free retest of remediated findings are how we answer the last two. Our list of PCI penetration testing companies compares vendors on those points.

08How much does a PCI DSS penetration test cost?

A PCI penetration test is priced like any other engagement, typically combining external and internal testing (from $4,200 and $6,000 respectively) plus segmentation testing, quoted as a fixed scope after we confirm your cardholder data environment. Our breakdown of PCI penetration testing cost prices each component and a typical merchant total, and starting prices for every service are on our pricing page.

09What is a PCI pen test, and how often is it required?

A PCI pen test is the manual penetration test Requirement 11.4 calls for: internal and external testing of the cardholder data environment at least once every 12 months and after any significant change, plus segmentation testing where segmentation reduces scope (every 12 months for merchants, every six months for service providers). It is not the quarterly ASV scan, which is a separate requirement (11.3.2).

10Is a PCI pen test different from a regular penetration test?

The technical work is the same; the scope and the evidence are not. A PCI pentest, or PCI DSS pentest, has to cover the entire cardholder data environment perimeter and the critical systems connected to it, from inside and outside, at the application and network layers, following a documented methodology (11.4.1). It also has to include segmentation testing where segmentation reduces scope, a retest of exploitable findings (11.4.4), and a report that a QSA can map to the sub-requirements. A generic test that skips any of those does not satisfy Requirement 11.4, however good it is.

Ready to test your defenses?

Talk to our team about what your PCI DSS compliance requires.

Prefer the full scoping questionnaire? 
RelatedSOC 2 HIPAA Cyber Essentials+

Get a Fixed-Scope Quote

Tell us what you need tested. We reply within one business day.