PCI DSS v4.0.1:
what testing it actually requires

Which version applies, and who enforces it#

PCI DSS is the security standard for anyone who stores, processes or transmits card data. The version in force is v4.0.1, published on 11 June 2024 as a limited revision with no added or deleted requirements; v3.2.1 was retired on 31 March 2024 and v4.0 on 31 December 2024 ²³. In 2026, PCI SSC held a public consultation for a future revision, with no date announced; until then, v4.0.1 remains the only active version ¹¹².

PCI SSC writes the standard but does not enforce it. Who must validate, at what level, through an SAQ or a ROC, and what penalties apply is decided by the card brands, each through its own programme; practical questions go to your acquiring bank ¹¹.

Vulnerability scans (11.3)#

An ASV scan “passes” when no component has vulnerabilities with a CVSS base score of 4.0 or higher; some findings fail automatically regardless of score ⁶. At the first assessment four passing scans are not required if the latest one passed and a documented quarterly procedure exists; in later years they are ⁴.

Penetration tests (11.4)#

Requirement 11.4.1 calls for a defined, documented and implemented methodology that includes ⁴⁵:

• industry-accepted approaches;
• coverage of the entire CDE perimeter and critical systems;
• testing from both inside and outside the network;
• validation of segmentation and scope-reduction controls;
• application-layer testing, at least for the vulnerabilities in 6.2.4;
• network-layer testing of all network components and operating systems;
• review of threats and vulnerabilities from the last 12 months;
• retention of results and remediation for at least 12 months.

Segmentation: where scope is won or lost#

Segmentation takes systems that do not touch card data out of scope. But only if it holds: if a network “out of scope” can reach the CDE, it is in scope, with all its requirements. That is why 11.4.5 requires testing all segmentation methods, at least every 12 months and after any change to them, confirming that the CDE is isolated from all out-of-scope systems ⁴.

Web applications and the payment page#

Bespoke and custom software must be protected against common attacks — requirement 6.2.4 lists injection, attacks on data and buffers, weak cryptography, business logic (including XSS and CSRF), access control and authentication ⁴. The application penetration test verifies them in practice (11.4.1).

SAQ A, in its January 2025 revision, no longer includes 6.4.3 and 11.6.1, but added an eligibility condition: the merchant’s site must not be susceptible to script attacks ¹⁰.

Which tests apply to you, by SAQ#

The self-assessment questionnaire (SAQ) depends on how you accept payments, and it determines which tests are required. We counted the testing requirements in each v4.0.1 SAQ ⁴⁹¹⁰:

What the report must contain#

The PCI SSC penetration testing guidance proposes a report structure — “suggested”, not mandatory — that assessors recognise ⁷. Note: the guidance dates from 2017 and uses v3.2.1 numbering (pentesting was 11.3; today it is 11.4).

1. Executive summary

   Purpose and major findings, briefly.

2. Scope

   Networks and systems tested, the CDE / non-CDE separation, and why each critical system was included.

3. Methodology and limitations

   How testing was done and what limited it: time windows, bandwidth, legacy systems.

4. Narrative and segmentation

   How the test went, including interference, and the segmentation test results.

5. Findings

   Whether and how the CDE can be reached, severity, target, CVE/CWE references and description; then tools used and clean-up instructions.

6. Retest report

   Dates of the initial test and the retest, the initial findings and the retest result ⁷.

PCI DSS in the Republic of Moldova#

The National Bank does not impose PCI DSS directly, but asks for it in reporting. The NBM ICT regulation (Executive Board Decision No. 29 of 12.02.2025, in force since 20.03.2025) applies to payment service providers — banks, payment companies, e-money issuers — and requires the annual report to the NBM to include the PCI DSS assessment report, where the institution is subject to one, together with penetration test and scan results (point 82) ¹³.

How we run a PCI DSS test#

1. CDE scope

   We start from the cardholder data flow diagram and the SAQ or ROC; we agree what is in scope and what the segmentation relies on.

2. External and internal

   The exposed perimeter, then the CDE from inside and into it from internal networks, at network and application layers (11.4.2, 11.4.3).

3. Segmentation

   From every zone declared “out of scope”, we try to reach the CDE (11.4.5).

4. Report on the PCI structure

   With the scope, methodology, limitations, findings and evidence the assessor asks for.

5. Retest

   After the fixes, the retest confirms each exploitable vulnerability is closed (11.4.4).

Frequently asked questions