● Talk to a security engineer: +92 323 8295031info@protonyte.com  ·  PCSF batch enrolling now

PCI DSS penetration testing to requirement 11.4, and no QSA needed

This is a hard requirement with numbers attached, which makes it one of the easier ones to scope honestly. Requirement 11.4 asks for a documented methodology, external and internal testing at least every twelve months and after any significant change, segmentation testing, and the correction and retesting of exploitable findings. The part people do not know: the standard says the tester must be qualified and organisationally independent, and states that they need not be a QSA.

the clause your report

ENGAGEMENT SCOPEannual, or six-monthly for service providers

External testing - 11.4.3IN SCOPE
Internal testing - 11.4.2IN SCOPE
Segmentation testing - 11.4.5IN SCOPE
Application layer, to 6.2.4IN SCOPE
Correction and retest - 11.4.4IN SCOPE
Six-monthly segmentation - 11.4.6OPTIONAL
// the basics

The clause, and what it actually asks

11.4.1 requires a documented methodology, and it is specific enough to be used as a checklist: industry-accepted approaches, coverage of the cardholder data environment perimeter and critical systems, testing from both inside and outside the network, validation of segmentation and scope-reduction controls, application-layer testing covering at least the vulnerabilities in requirement 6.2.4, network-layer testing across all components, review of threats from the last twelve months, and retention of results.

11.4.2 and 11.4.3 then require internal and external penetration testing at least once every twelve months and after any significant change. 11.4.4 requires exploitable findings to be corrected and the testing repeated to verify the correction. 11.4.5 requires segmentation controls to be tested at least annually. And 11.4.6 tightens that to every six months for service providers, which is the deadline most often missed because it does not line up with the annual assessment.

  • 01Written to the methodologyThe report is laid out against 11.4.1 so your assessor can tick it rather than hunt for it.
  • 02Both directions11.4.2 and 11.4.3 are separate requirements and need separate testing. A quote covering only one is covering half.
  • 03Segmentation provedWe try to cross from out-of-scope into the cardholder data environment and write down what stopped us.
  • 04Retest is the requirement11.4.4 is not optional and not an upsell. It is in the price.
// coverage

What the engagement covers

Laid out in the order requirement 11.4.1 lists it, so your assessor can read the report against the clause.

// 11.4.3

External testing

From the internet, against the perimeter of the cardholder data environment.

  • Every exposed service and interface
  • Perimeter devices and remote access
  • Public-facing applications
  • Exploitation proved, not inferred
// 11.4.2

Internal testing

From inside the network, which is a separate requirement.

  • Internal hosts and services in scope
  • Privilege escalation and lateral movement
  • Critical systems supporting the environment
  • Credential and directory weaknesses
// 11.4.5 and 11.4.6

Segmentation

Proving the boundary that is reducing your scope actually exists.

  • Attempts to cross from out-of-scope networks
  • Every segmentation control tested
  • Isolation of connected entities
  • Six-monthly cycle for service providers
// 6.2.4

Application layer

At minimum the vulnerabilities named in requirement 6.2.4.

  • Injection and input handling
  • Access control and session flaws
  • Business logic in the payment path
  • Known-vulnerable components
// 11.4.4

Correction and retest

A requirement, not a courtesy.

  • Exploitable findings corrected by you
  • Testing repeated to verify
  • Evidence retained for the assessment
  • Closure summary for your QSA
// 11.4.1

The methodology

Documented, followed and handed over.

  • Industry-accepted approach named
  • Coverage stated against the clause
  • Last twelve months of threats reviewed
  • Results and evidence retained
// methodology

How the work runs

  1. 1

    Define the environment

    The scope of the test follows the scope of your cardholder data environment, not the other way round.

    • Cardholder data flows and storage
    • In-scope and connected systems
    • Segmentation controls in place
    • Merchant level or service provider status
  2. 2

    Agree the methodology

    In writing, against 11.4.1, before testing starts.

    • Approach and coverage
    • External, internal and segmentation
    • Application layer against 6.2.4
    • Threats from the last twelve months
  3. 3

    Test

    All three parts, with exploitation proved rather than inferred.

    • External from the internet
    • Internal from inside the network
    • Segmentation crossed or confirmed
    • Application layer by hand
  4. 4

    Correct and retest

    Required by 11.4.4, included in the price.

    • Exploitable findings listed clearly
    • You fix, we re-attack
    • Verification evidence produced
    • Nothing closed on your word alone
  5. 5

    Hand to your assessor

    A report laid out against the clause, with the evidence retained.

    • Methodology, scope and dates
    • Findings with evidence
    • Retest verification
    • Independence statement for the tester
// the deliverable

What you are left holding

Two documents and a conversation. Written so the person who signs the invoice and the person who writes the fix can both use them.

  • Executive summary in plain language, with the business risk first
  • Technical findings with the evidence that proves each one
  • CVSS score and a risk rating that reflects your business, not a template
  • Remediation written for the stack you actually run
  • A free retest, and a closure summary you can hand to a customer
  • A debrief call with the tester who did the work, not an account manager
Ask for a sample report
// the standards

Measured against something

The work follows PCI DSS v4.0.1 requirement 11.4, OWASP Web Security Testing Guide, NIST SP 800-115 and PTES, so the coverage can be checked rather than taken on trust, and the report maps to what your auditor or your enterprise customer already recognises.

This page is one part of our compliance and audit service. Where a finding needs a different kind of engagement to answer properly, we say so in the report rather than selling you the test we happen to be running.

// faq

Common questions

Do we need a QSA to run the penetration test?

No. PCI DSS requires the tester to be qualified and organisationally independent, and states explicitly that they need not be a QSA or ASV. What your assessor will ask to see is the methodology, the scope, the findings and the evidence that exploitable findings were corrected and retested.

How often do service providers have to test segmentation?

Every six months, and after any change to segmentation controls - requirement 11.4.6. That is twice as often as the annual requirement under 11.4.5 that applies to everyone, and it is the deadline most often missed because it does not line up with the annual assessment cycle.

What counts as a significant change?

The standard ties the retest to significant changes without giving you a list, which means your assessor’s view is what counts. In practice: a new or substantially rebuilt application in the environment, a network or infrastructure change affecting scope, a move of hosting, or a new connected entity. Ask your assessor in writing rather than deciding alone.

Is an external test on its own enough?

No. 11.4.2 and 11.4.3 are separate requirements for internal and external testing and both apply. A quote covering only the external side is covering half the requirement, and that is a common way for a cheap price to be reached.

We are on SAQ A. Does this apply?

The SAQ A eligibility and requirement text changed with v4.x, so the safest course is to confirm your current obligations with your acquirer in writing rather than relying on what was true at your last assessment. We have written up what changed.

// start here

Let's protect your business together.

Tell us what you need tested. Our team will reply with a clear scope and quote.

By submitting, you agree to our Terms of Use and Privacy Statement.