1. Home
  2. Solutions
  3. PCI DSS

Solutions · Compliance · PCI DSS

PCI DSS penetration testing that meets Requirement 11.4 and stands up to your QSA

PCI compliance depends on proof that your cardholder data environment holds up to an attacker. ioSENTRIX runs the internal, external and segmentation tests PCI DSS v4.0.1 Requirement 11.4 calls for, maps each result to the requirement, and includes a retest of your fixes so your QSA sees findings tracked to closure.

StandardPCI DSS v4.0.1 · Requirement 11.4 penetration testing
Who asksYour QSA, acquiring bank and card brands
What you getInternal, external and segmentation results, retest included, mapped to 11.4
Reviewed by Omair Manzoor, Founder & CEO, ioSENTRIX · Updated November 2026Key terms: PCI DSS, Network segmentation, Penetration testing
Trusted by security teams at

01The requirement

Is penetration testing required for PCI DSS?

Yes. PCI DSS v4.0.1 Requirement 11.4 requires internal and external penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or change. If you use segmentation to reduce scope, the segmentation controls are tested every 12 months, or every six months for service providers.

Mandatory?Yes, under Requirement 11.4

For entities that store, process or transmit cardholder data, or can affect its security.

How often?Every 12 months and after change

Segmentation every 12 months; every six months for service providers (11.4.6).

Who tests?Qualified and independent

Internal or external, organizationally independent; not required to be a QSA or ASV.

What is PCI penetration testing?

PCI penetration testing is a penetration test of your cardholder data environment (CDE) and the systems connected to it, performed to a documented methodology so the results can be presented to your QSA as evidence for Requirement 11.4. It proves which weaknesses an attacker could exploit to reach card data, then confirms the fixes with a retest.

What does PCI DSS Requirement 11.4 cover?

A defined methodology (11.4.1), internal testing (11.4.2), external testing (11.4.3), correcting exploitable vulnerabilities and repeating the test (11.4.4), and segmentation testing (11.4.5, plus 11.4.6 for service providers). Read PCI DSS 4.0 penetration testing requirements.

02See it in action

From segmentation test to QSA evidence

How one segmentation control is tested like an attacker would, fixed, retested and handed to your QSA as evidence for Requirement 11.4.

Segmentation, proven

We test every segmentation control you rely on to reduce scope, from the networks that should not reach the CDE, so the result shows whether isolation actually holds.

Proof your QSA can follow

Each finding carries evidence, risk ranking and the 11.4 requirement it supports, written so a QSA can trace it without a tester in the room.

Corrected, then retested

A retest of your fixes is included, so the report shows exploitable findings corrected and the test repeated, as 11.4.4 expects.

Illustrative example. The network, host and statuses are a composite for explanation only and do not describe any client. Acceptance of evidence is your QSA's decision.

Text version of the exhibit
  1. Control: your network diagram says the cardholder data environment is isolated from the corporate network. The test supports Requirements 11.4.1, 11.4.5, 11.4.2 and 11.4.3.
  2. Test: from a host on the corporate VLAN, testers probe every CDE address range.
  3. Finding: a database port on a CDE host answers, so segmentation fails. The finding is rated High, with evidence of the route.
  4. Fix: we describe a firewall access control list for your network team.
  5. Retest: the same probes are blocked and isolation is confirmed, as Requirement 11.4.4 expects. Service providers repeat this every six months (11.4.6).
  6. Ready for your QSA: the evidence folder (methodology, scope, finding, fix, retest and 11.4 mapping) goes in the report your QSA reviews.

03Requirement to evidence

How does penetration testing map to PCI DSS Requirement 11.4?

This is the mapping we put in your report, so your QSA can trace each piece of evidence back to the requirement it supports.

RequirementWhat it asksWhat ioSENTRIX testsEvidence for your QSA
11.4.1MethodologyA defined, documented methodology: industry-accepted approach, whole CDE perimeter and critical systems, inside and outside, segmentation, application and network layers.Our written penetration testing methodology, aligned with NIST SP 800-115 and the OWASP testing guides, applied to your scope.Methodology document and scope
11.4.2Internal testInternal penetration testing at least once every 12 months and after significant change.Internal network penetration test of CDE and connected systems.Internal results with proof
11.4.3External testExternal penetration testing at least once every 12 months and after significant change.External perimeter, exposed services and payment web apps and APIs.External results with proof
11.4.4Correct and retestExploitable vulnerabilities corrected according to your risk ranking, and testing repeated to verify the corrections.Retest of your fixes, included in the engagement.Retest results per finding
11.4.5SegmentationIf segmentation isolates the CDE, test it at least once every 12 months and after changes, covering every control in use.Tests from each out-of-scope network that confirm the CDE is isolated. See network segmentation.Segmentation results by network
11.4.6Service providersService providers only: segmentation tests at least once every six months and after changes.The same segmentation tests on a six-month cadence, or through PTaaS.Six-monthly segmentation results
6.4.3 · 11.6.1Payment page scriptsManage scripts loaded on payment pages, and detect unauthorized changes to those scripts and to security-impacting HTTP headers.Payment page review during web app testing: third-party scripts, injection paths and headers an attacker could abuse.Script and header findings (your inventory and detection stay yours)
11.3.2External scansExternal vulnerability scans at least once every three months by a PCI SSC Approved Scanning Vendor.Not performed by ioSENTRIX. We can review and validate scan findings during the pentest.ASV only; ioSENTRIX is not an ASV

Requirement wording summarized from PCI DSS v4.0.1. ioSENTRIX is not a PCI Approved Scanning Vendor (ASV) or Qualified Security Assessor (QSA): we perform the penetration testing and write reports your QSA can review. Your QSA decides what evidence is sufficient.

04Timing

When should you run a PCI DSS penetration test?

Early enough to fix and retest before your assessment, then again every 12 months and after significant change.

  1. Scope the CDE

    Confirm the cardholder data environment, connected systems and critical systems.

    Written scope
  2. Map segmentation

    List every control that isolates the CDE and each network that should not reach it.

    Segmentation map
  3. Test

    Internal, external, application and segmentation testing by certified engineers.

    Manual testing
  4. Fix and retest

    Fix guidance for each finding, then a retest of your fixes (11.4.4).

    Retest included
  5. QSA review

    We answer your QSA's questions about the report and method.

    Evidence pack
  6. Repeat

    Every 12 months and after any significant infrastructure or application change.

    Next cycle
MerchantsEvery 12 months

Internal, external and segmentation tests at least once every 12 months and after significant changes or changes to segmentation.

Service providersSegmentation every six months

The same internal and external cadence, plus segmentation tests at least once every six months and after changes (11.4.6).

05Evidence pack

What's in a PCI DSS penetration test evidence pack?

What your QSA, acquiring bank and customers' security teams ask for, in one place.

  1. Methodology

    The documented approach Requirement 11.4.1 asks for, matched to your environment.

    NIST SP 800-115OWASP
  2. Scope and CDE reference

    Systems, networks, dates and testers, tied to your CDE and network diagrams.

  3. Findings with proof

    Each finding with evidence, risk ranking, business impact and the steps to reproduce it.

  4. Retest letter

    Fixes retested and recorded, so exploitable findings are shown corrected (11.4.4).

  5. Segmentation results

    Results from each out-of-scope network, every 12 months or six for service providers.

    11.4.511.4.6
  6. Requirement mapping

    Each result mapped to the 11.4 requirement it supports.

    11.4.111.4.211.4.311.4.4

06Independently verified

★★★★★
“Unlike other providers, Omair and his team truly dive deep into our infrastructure, delivering findings that go well beyond the surface level.”
Jesus B.Cybersecurity Manager, Banking · Verified G2 review ↗
★★★★★
“The team at ioSENTRIX is professional and highly skilled at their craft.”
Awwab A.SVP, Chief Information Security Officer · Verified G2 review ↗

08Insights

Read before you scope your PCI test

09FAQ

PCI DSS penetration testing questions

Short answers to what merchants, service providers and QSAs ask us most.

Ask us something else

Is penetration testing required for PCI DSS?

Yes. PCI DSS v4.0.1 Requirement 11.4 requires internal (11.4.2) and external (11.4.3) penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or change, following a documented methodology (11.4.1). Exploitable vulnerabilities found must be corrected and the testing repeated to verify the corrections (11.4.4).

How often is PCI DSS segmentation testing required?

If you use segmentation to isolate the cardholder data environment (CDE), Requirement 11.4.5 requires penetration tests of the segmentation controls at least once every 12 months and after any changes to segmentation controls or methods. Service providers must test them at least once every six months and after any changes (11.4.6).

Is ioSENTRIX a PCI ASV or QSA?

No. ioSENTRIX is not a PCI Approved Scanning Vendor (ASV) or Qualified Security Assessor (QSA). We perform the penetration testing required by PCI DSS v4.0.1 Requirement 11.4 and write reports your QSA can review. Quarterly external scans under Requirement 11.3.2 must come from an ASV.

Does a PCI penetration tester have to be a QSA?

No. Requirements 11.4.2, 11.4.3 and 11.4.5 allow a qualified internal resource or a qualified external third party, as long as the tester is organizationally independent. The tester is not required to be a QSA or ASV.

What is the difference between an ASV scan and a PCI penetration test?

An ASV scan (Requirement 11.3.2) is an external vulnerability scan performed at least once every three months by a PCI SSC Approved Scanning Vendor. A penetration test (Requirement 11.4) follows a documented methodology, covers the CDE perimeter and critical systems from inside and outside the network, tests segmentation, and includes application-layer and network-layer testing. Most entities need both.

What should a PCI DSS penetration test report include?

Enough for your QSA to trace each test back to Requirement 11.4: the methodology, scope and CDE boundary, dates and testers, findings with evidence and risk ranking, segmentation results, and the remediation and retest results that Requirement 11.4.1 asks you to retain.

How long does a PCI penetration test take?

A web application penetration test typically takes 1–2 weeks. Internal, external and segmentation testing depends on the size of your CDE. After a short scoping call you receive a written scope and timeline before testing starts, so you can plan it before your assessment.

Ready when you are

Get Requirement 11.4 evidence your QSA can review

Tell us whether you are a merchant or service provider, how your CDE is segmented and when your assessment is due. We will help you scope the right test.

  • Written scope and timeline before testing starts
  • Retest of fixes included
  • Report mapped to PCI DSS v4.0.1 Requirement 11.4
Scope your PCI DSS penetration test

Takes about a minute.