PCI DSS 4.0 Penetration Testing Requirements: Requirement 11.4 (v4.0.1) for Cyprus EMIs

PCI DSS 4.0.1 requires a documented penetration testing methodology, internal and external tests of the whole cardholder data environment (CDE) every 12 months and after significant changes, verified fixes, and segmentation testing every 12 months, or every six months for service providers. For a Cyprus EMI or payment firm, a weak 11.4 package is a common reason a Report on Compliance stalls.

What do the PCI DSS 4.0 penetration testing requirements actually say?

PCI DSS 4.0.1 requires a defined, documented and implemented penetration testing program that covers the entire cardholder data environment (CDE) from inside and outside, validates any segmentation, and proves that exploitable findings were fixed and retested. All of it sits in Requirement 11.4, separate from vulnerability scanning (11.3) and change-and-tamper detection (11.5).

The PCI Security Standards Council (PCI SSC) published v4.0 in March 2022 and the v4.0.1 limited revision in June 2024. Version 3.2.1 retired on 31 March 2024 and v4.0 on 31 December 2024, so assessments conducted now run against v4.0.1. The future-dated requirements, including 11.4.7, became mandatory on 31 March 2025.

A QSA checks each sub-requirement in turn:

Sub-requirement	What it demands	Frequency	Applies to
11.4.1	Documented, industry-accepted methodology with defined scope and coverage	Maintained continuously	All entities
11.4.2	Internal penetration test	Every 12 months and after significant change	All entities
11.4.3	External penetration test	Every 12 months and after significant change	All entities
11.4.4	Exploitable findings corrected and testing repeated to verify	After each test	All entities
11.4.5	Segmentation controls tested	Every 12 months and after segmentation changes	Entities using segmentation
11.4.6	Segmentation controls tested	Every 6 months and after segmentation changes	Service providers using segmentation
11.4.7	Support customers’ external penetration testing	Ongoing	Multi-tenant service providers

The numbering matters. In the v4.0.1 text, 11.4.4 covers remediation and retest, 11.4.5 covers segmentation for every entity that uses it, and 11.4.6 adds the six-month interval for service providers. Some vendor material still quotes v3.2.1 numbers (11.3.x). A report built on those tells the QSA the work was scoped against a retired standard.

How often must internal and external penetration tests run, and do scans count?

Internal and external penetration tests must each run at least once every 12 months and after any significant infrastructure or application upgrade or modification. The 12-month interval is a maximum, not a fixed annual date: a change in March can trigger a test long before the anniversary.

• External (11.4.3) tests what an internet attacker reaches: public web apps, card-acceptance APIs, VPN gateways, mail and DNS, cloud load balancers, exposed admin panels.
• Internal (11.4.2) starts inside the network and asks how far a compromised workstation or vendor account gets toward card data: lateral movement, privilege escalation, Active Directory paths, database access from application servers.

Under 11.4.2 and 11.4.3, the tester can be a qualified internal resource or a qualified external third party, but organizational independence must exist. The people testing cannot be the people who built or run the systems. The tester does not need to be a QSA or an ASV.

Scans are a separate control. A vulnerability scan lists known weaknesses automatically. A penetration test proves which of them, plus logic flaws no scanner sees, actually lead to cardholder data. Neither internal scans nor ASV scans count toward 11.4.

Activity	Requirement	Performed by	Frequency	What it proves
Internal vulnerability scan	11.3.1	Qualified internal or external staff	Every 3 months, plus after significant change	Known CVEs and misconfigurations inside the network
ASV scan	11.3.2	PCI SSC Approved Scanning Vendor	Every 3 months	External exposure meets ASV pass criteria
Penetration test	11.4.2, 11.4.3	Qualified, independent tester	Every 12 months, plus after significant change	Exploitable paths to the CDE, manually validated
Segmentation test	11.4.5, 11.4.6	Qualified, independent tester	Every 12 or 6 months	Out-of-scope networks cannot reach the CDE

A Nessus or Qualys export with a cover page is not a penetration test, whatever the vendor calls it. QSAs look for manual test cases, chained exploitation, authenticated testing and evidence such as captured Burp Suite requests or screenshots of reached data.

What counts as a significant change?

PCI DSS leaves the definition to you, so write it into your methodology or change policy. Typical triggers:

• New CDE infrastructure, cloud accounts or Kubernetes clusters
• A new card-facing app, API version or mobile release that changes authentication or data handling
• Major operating system, database or framework upgrades
• New card data flows, such as tokenization or a new acquirer integration
• Cloud migration, or acquisitions that connect networks
• Any change to firewalls, VLANs or security groups protecting the CDE

Log why each change was or was not classed as significant. QSAs ask for that log.

How does PCI DSS segmentation testing work, and who must test every six months?

Segmentation testing proves that the controls separating the CDE from out-of-scope systems actually block traffic, on every path and in every relevant direction. Under 11.4.5, any entity that uses segmentation to reduce scope must test it at least every 12 months and after any change to segmentation controls or methods.

If you claim the corporate LAN, the marketing site or a developer VPC is out of scope, you must prove nothing there reaches card data. If you cannot, the QSA pulls those networks back into scope, along with every requirement that applies to them.

A real segmentation test works from each out-of-scope segment toward CDE hosts and ports, then repeats the exercise from the CDE outward. The paths go well beyond one firewall:

• Firewall rule bases, VLANs and router ACLs
• AWS security groups, Azure network security groups, VPC peering and transit gateways
• Kubernetes NetworkPolicy and service mesh rules
• Remote access and jump hosts, including vendor connections
• Wireless networks, MPLS and SD-WAN links between offices or data centers

11.4.5 also asks the tester to confirm that any isolation separating systems of differing security levels is effective. That links back to Requirement 2.2.3, which governs primary functions with different security levels on the same system component.

The six-month rule for service providers

Under 11.4.6, a service provider that uses segmentation must test those controls at least once every six months and after any change. That doubles the annual frequency most merchants follow.

A service provider stores, processes or transmits cardholder data on behalf of another entity, or can affect the security of another entity’s CDE. Whether an EMI is a service provider depends on its business model and contracts. One that runs a payment gateway for merchants, processes card transactions for program managers or hosts card data for partners is almost certainly one.

An EMI acting purely as a card issuer for its own customers may be assessed differently. Confirm your status with your acquirer or card scheme and your QSA before building the testing calendar, because a wrong assumption leaves a test missing at assessment time.

Multi-tenant service providers also carry 11.4.7: they must support customers’ external penetration testing, either through documented access or by providing evidence of their own testing.

Does PCI DSS require retesting after remediation?

Yes. Requirement 11.4.4 says exploitable vulnerabilities and security weaknesses found during penetration testing must be corrected in line with the entity’s risk ranking under Requirement 6.3.1, and the testing repeated to verify the corrections. A fix nobody has retested does not satisfy the control.

For each finding, the QSA expects the original evidence, the change that fixed it, the retest date, who performed the retest and the result. The retest should reproduce the original attack path, not just confirm that a version number changed.

Findings marked ‘accepted’ or ‘in progress’ are where packages fail. If a critical or high issue cannot be fixed before the assessment, expect close scrutiny of your risk ranking and any compensating control. Plan retest time honestly: code changes in a card API can take longer than a two-week window allows.

What makes a QSA accept or reject a penetration test report?

A QSA accepts a report when it can confirm, from the documents alone, that every in-scope CDE asset was tested by a qualified, independent person using the documented method, and that exploitable findings were fixed and retested. That starts with the 11.4.1 methodology, which must cover:

• The entire CDE perimeter and critical systems, tested from inside and outside
• Validation of segmentation and scope-reduction controls
• Application-layer testing covering at least the vulnerabilities listed in Requirement 6.2.4
• Network-layer testing of components that support network functions and operating systems
• A review of threats and vulnerabilities experienced in the last 12 months
• A documented approach to assessing and addressing exploitable findings
• Retention of results and remediation evidence for at least 12 months

NIST SP 800-115, PTES, the OWASP Web Security Testing Guide and OSSTMM are the references QSAs see most. A one-page method statement attached to a proposal will not pass. The document should name tools, manual techniques, rules of engagement, the risk-rating method and retest criteria.

The report itself should carry test dates, the PCI DSS version and the agreed scope; the exact assets tested (IP ranges, hostnames, URLs, API endpoints, cloud accounts); tester names, qualifications and an independence statement; authenticated and unauthenticated test cases; evidence for each finding; risk ratings tied to assets and requirements; and retest results.

Segmentation results should be listed per path and direction, with blocked and allowed attempts both recorded.

The usual reasons for rejection

• Scanner output presented as a pentest: no manual validation, no exploitation, no chaining.
• Partial scope: one web server tested while the card API, admin portal and second office were skipped.
• No application layer: ports tested, payment app and APIs untouched.
• Thin segmentation testing: one VLAN, one direction, cloud security groups ignored.
• No independence: the network team tested the firewall rules it wrote.
• Stale reports: older than 12 months, or a significant change happened afterward with no new test.
• No retest evidence for critical and high findings.
• Wrong standard: v3.2.1 numbering in a v4.0.1 assessment.
• One segmentation test in a year where 11.4.6 required two.

What is in scope for a Cyprus EMI or payment firm's PCI DSS penetration test?

Everything that stores, processes or transmits card data, plus every system that connects to those components or can affect their security.

For a typical Limassol or Nicosia EMI that means the card issuing or processing platform, customer web and mobile apps, card APIs and webhooks, admin and back-office portals, the database tier, HSM interfaces, identity systems such as Active Directory or Entra ID, CI/CD pipelines that deploy to the CDE, and staff and vendor remote access.

Moving to cloud does not reduce the testing obligation. Under the shared-responsibility model your provider covers the physical and hypervisor layers, but you must test your own security groups, IAM, network policies and workloads, and obtain the provider’s attestation for its part. QSAs ask for a responsibility matrix and configuration evidence.

Third-party connections, such as a processor link or a card-manufacturing bureau, must be mapped and included in segmentation paths. For API-heavy platforms, our EMI penetration testing in Cyprus combines CDE network testing with card API authorization testing in one scoped engagement.

How does PCI DSS 11.4 fit with DORA TLPT and NIS2 in one testing calendar?

The three overlap in technique but differ in legal basis, scope and frequency, so one does not satisfy another. PCI DSS is not EU law: Cyprus firms are bound to it by contract through card schemes, acquirers and processors. DORA and NIS2 are supervisory obligations.

• DORA has applied since 17 January 2025 to EU financial entities, including EMIs and payment institutions. Every in-scope entity needs a resilience testing program. Entities selected by the competent authority (for Cyprus EMIs and payment institutions, the Central Bank of Cyprus) also need threat-led penetration testing (TLPT) at least every three years, run against live production systems. TLPT does not deliver CDE-wide annual coverage or segmentation proof.
• NIS2 requires risk-based testing and assessment of control effectiveness but sets no fixed interval. For financial entities in DORA scope, DORA’s ICT rules take precedence as sector-specific law, so NIS2 matters most for group companies outside DORA. PCI reports are useful evidence, not a safe harbor.
• CySEC supervises investment firms and CASPs, not EMIs. A group holding both kinds of license should expect separate ICT testing expectations.

The practical move is to scope one annual internal, external and segmentation test cycle aligned to PCI DSS, layer DORA testing and NIS2 evidence on top of it, and keep a single testing calendar. Build it backward from your ROC or AOC date so every test is under 12 months old and every retest is closed before the QSA arrives. For a service provider:

1. Month 1: confirm service-provider status, refresh the CDE data-flow diagram and the 11.4.1 methodology, and agree scope and evidence format with the QSA.
2. Months 2-3: external and internal tests, including application and API layers, plus the first segmentation test.
3. Months 3-4: remediate, then retest every exploitable finding under 11.4.4.
4. Month 8: second segmentation test under 11.4.6, plus tests triggered by significant changes since month 2.
5. Months 10-12: assemble the evidence pack: methodology, reports, retest results, change log, cloud responsibility matrix, independence statements.

Merchants that are not service providers can drop the month-8 segmentation test, but not the change-triggered ones. We cover the regulatory side in DORA, NIS2 and CySEC testing for Cyprus financial firms, and our DORA threat-led penetration testing service runs alongside PCI work, not instead of it.

FAQ

Can our internal security team perform the PCI DSS penetration test?

Yes, if the testers are qualified and organizationally independent of the systems they test, as 11.4.2 and 11.4.3 require. They do not need to be a QSA or an ASV, but the network team cannot test the firewall rules it manages.

Does a quarterly ASV scan count toward Requirement 11.4?

No. ASV scans satisfy 11.3.2 only. Requirement 11.4 needs manual, exploitation-led testing of the internal and external CDE, plus segmentation testing where segmentation reduces scope.

Is a Cyprus EMI automatically a PCI DSS service provider?

No. It depends on the business model and contracts. EMIs that run gateways, process transactions for program managers or host card data for partners usually are; pure issuers for their own customers may not be. Confirm with your acquirer or card scheme and your QSA.

How long must penetration test results be kept?

The 11.4.1 methodology must provide for retaining penetration test results and remediation evidence for at least 12 months.

Does DORA TLPT replace PCI DSS penetration testing?

No. TLPT is a threat-led exercise on live production systems at least every three years for selected entities. It does not provide annual CDE-wide coverage or the segmentation proof PCI DSS 11.4 requires.

If your next ROC is within a year, a scoped review of your 11.4 evidence now is cheaper than a failed one later. Our PCI DSS penetration testing covers internal, external and segmentation testing with QSA-ready reporting and retest included.