Skip to main content

The engagement

PCI DSS penetration testing, requirement by requirement

PCI DSS v4.0.1 puts penetration testing in Requirement 11.4, in seven parts. Each part has its own clock and its own evidence. This page walks them in order, so you can check any proposal, ours included, against the standard instead of against another proposal.

The standard asks for a qualified tester whose organisational independence exists, and says so in its own words: "not required to be a QSA or ASV". The work is delivered by Security Brigade, CERT-In empanelled since 2008.

What Requirement 11.4 has you test

Internal testing under 11.4.2 and external testing under 11.4.3, each at least once every twelve months and after any significant infrastructure or application change. Both follow the methodology 11.4.1 has you hold. It includes:

  • An industry-accepted approach, documented and followed.
  • The whole CDE perimeter and the systems critical to it.
  • Testing from inside the network and from outside it.
  • Testing of every segmentation and scope-reduction control.
  • Both the application layer and the network layer.
  • The threats and vulnerabilities you met in the last twelve months.
  • Results and remediation kept for at least twelve months.

An ASV scan answers a different requirement and cannot stand in for this one. Requirement 11.4 in full and the three tests that get confused go further.

Segmentation, on two clocks

If segmentation keeps systems out of your CDE, 11.4.5 has every segmentation control tested at least once every twelve months and after any change to it, confirming that each one works and actually isolates the CDE. A service provider tests the same controls at least once every six months under 11.4.6.

Until it is tested, segmentation is a claim, and an untested claim puts everything it was meant to exclude back in scope. How a segmentation test is run.

When your customers test you: 11.4.7

A multi-tenant service provider supports its customers' external penetration testing under 11.4.3 and 11.4.4. It was a best practice until 31 March 2025 and has been required since. For a hosting, cloud or SaaS provider that means a way for a customer's tester to work against your platform, and evidence that you gave it. What your customers may now ask of you.

The retest that closes a finding

Requirement 11.4.4 has exploitable vulnerabilities corrected according to the risk ranking your 6.3.1 process assigns, then has the penetration test repeated to verify the corrections. A report with findings and no retest leaves 11.4.4 open, and is one of the reasons a report gets sent back. The retest is part of the engagement, scoped with it.

Code review, where your software is bespoke

Requirement 6.2.3 has bespoke and custom software reviewed before it is released to production or to customers, to find and correct coding vulnerabilities. Where you write your own payment software, the review sits naturally beside the penetration test: the test shows what can be reached, and the review shows the line of code that let it. Code review inside a PCI DSS programme.

What your QSA reads in the report

The report has two readers: the engineers who fix what it found, and the assessor who checks that 11.4 was met. For the second, it carries:

  • The methodology it followed, so it can be set against your 11.4.1 document.
  • The scope, drawn against your CDE, with anything excluded named and explained.
  • Each segmentation control tested, and whether it isolated the CDE.
  • Every exploitable finding, ranked by the risk method your 6.3.1 process uses.
  • The retest, dated, showing which findings were corrected and how that was confirmed.
  • Who did the work, and how their independence from the systems tested is established.

Who does what in a PCI DSS engagement sets out which party produces which artefact.

What decides how long it takes

  • How many systems sit in or connect to the CDE, and how many of them face the internet.
  • How many segmentation controls separate the CDE from everything else.
  • How many payment applications are in scope, and how many user roles each one has.
  • Whether you are a service provider, which puts segmentation on a six-month clock.
  • Whether you host other merchants, which brings 11.4.7 into the engagement.

A payment aggregator regulated by the RBI runs a second clock beside this one: why it tests twice a year. The Requirement 11.4 evidence checklist lists what to have ready before a test is scoped.

Tell us what sits in your CDE

The systems, the segmentation that bounds them, and whether you are a merchant or a service provider. Those three answers scope the engagement.

Request a PCI penetration test