Compliance and Standards

PCI-DSS Penetration Testing: Evidence for Requirement 11.4

The PCI-DSS penetration test covers the cardholder data environment and is structured for QSA review; retesting of remediated findings is included.

What is tested and why it matters

Validating the controls that protect cardholder data.

Organisations that process, store, or transmit payment card data are required to demonstrate that their cardholder data environment (CDE) is protected against compromise. A vulnerability scan alone does not satisfy this requirement. PCI DSS v4.0 Requirement 11.4 requires penetration testing that evaluates segmentation effectiveness, access control boundaries, and the exploitability of identified vulnerabilities. Without this testing, compliance gaps remain invisible until an assessor or an attacker finds them first. A failed PCI assessment delays certification, increases acquirer scrutiny, and exposes the organisation to fines and reputational damage.

Standards PCI-DSS v4.0, PA-DSS, OWASP Top 10

Attack surface CDE systems, segmentation boundaries, payment applications, encryption controls

Approach Segmentation validation and manual penetration testing by senior ethical hackers

Who needs this assessment

Organisations that benefit most.

This assessment is designed for organisations that process, store, or transmit payment card data and must demonstrate PCI DSS compliance to acquirers, card brands, or regulators.

Retailers and e-commerce platforms that process card-present or card-not-present transactions

Payment service providers and payment facilitators

Financial institutions and card issuers

Hospitality businesses handling credit or debit card payments

Any organisation preparing for PCI DSS certification or annual revalidation

Healthcare providers and government agencies processing payment data through regulated service delivery channels

Where compliance-focused assessments apply

Financial services: PCI-DSS validation for cardholder data environments and payment processing systems.
Government and public administration: DigiD assessments and alignment with BIO and NIS2 requirements.
Healthcare: demonstrating security controls for patient data systems under NIS2 and ISO 27001.
Critical infrastructure: energy, transport, and water supply organisations subject to NIS2 Article 21.

What the assessment produces

The insight and evidence delivered at the conclusion of the assessment.

Every assessment concludes with a structured report covering technical findings, severity ratings, evidence, and remediation guidance mapped to PCI DSS requirements. Reports are delivered through the Pentrox Portal and are available for download at any time.

Independent validation that the CDE meets PCI DSS v4.0 penetration testing requirements
Reporting structured for QSA review and audit evidence
Identified segmentation failures and access control weaknesses before the formal assessment
Remediation guidance prioritised by exploitability and compliance impact
Portal access with real-time findings, retest workflow, and report downloads for the lifetime of the client account

How an assessment runs

Scope and Intake
Planning
Assessment
Reporting
Findings & Retest

Retesting of remediated findings is included as standard with every assessment.

Assessment methodology

Five phases from CDE mapping through verified remediation.

Each phase builds on the previous one. CDE mapping defines the testing boundary, segmentation validation confirms isolation, and manual testing verifies exploitability of identified weaknesses.

Scoping and CDE mapping

The cardholder data environment is mapped. Systems that store, process, or transmit cardholder data, segmentation boundaries, and data flows are documented.

PCI DSS v4.0 Requirement 11.4, PCI SSC Penetration Testing Guidance

Segmentation validation

Network segmentation controls are tested to confirm that non-CDE systems cannot reach cardholder data. Firewall rules and VLAN boundaries are validated.

PCI DSS v4.0 Requirement 11.4.6 (segmentation testing)

Vulnerability discovery and exploitation

Nessus and Burp Suite identify vulnerabilities across CDE components. Results are manually verified to confirm exploitability and remove false positives.

PCI DSS v4.0 Requirement 11.4, PTES, OWASP WSTG

Access control and encryption review

Authentication mechanisms, privilege models, and encryption at rest and in transit are assessed. Weak credentials and misconfigured encryption are documented.

PCI DSS v4.0 Requirements 7, 8, and 3 (access control, authentication, stored data)

Reporting and QSA alignment

Findings are documented with evidence, a CVSS score, and PCI DSS mapping. Critical findings are escalated immediately. Reports support QSA review.

PCI SSC Penetration Testing Guidance, PCI DSS v4.0 reporting expectations

Scope and deliverables

What is included, what is excluded, and what is delivered.

The statement of work defines the exact CDE systems, segmentation boundaries, and testing approach before the assessment begins. The lists below reflect the standard scope for a PCI-DSS penetration test.

In scope

Cardholder data environment (CDE) systems and applications
Network segmentation controls between CDE and non-CDE zones
Payment applications and web interfaces handling card data
Access control and authentication mechanisms for CDE access
Encryption of cardholder data at rest and in transit
Key management processes and configuration
Logging and monitoring within the CDE
Supporting infrastructure connected to the CDE

Out of scope

Systems confirmed as out-of-scope through validated segmentation
Third-party payment processor infrastructure (unless explicitly included)
QSA certification decisions (Pentrox provides testing evidence, not the compliance verdict)
Denial-of-service testing against production payment systems

What you receive

Executive summary Compliance posture overview, severity distribution, and remediation priorities written for leadership and QSA stakeholders.
Detailed findings Each vulnerability documented with evidence, reproduction steps, CVSS severity rating, and PCI DSS requirement mapping.
Segmentation validation results Pass/fail outcomes per segmentation boundary, confirming CDE isolation effectiveness.
Remediation plan Prioritised by exploitability and compliance impact for efficient resolution.
Portal access Real-time findings, report downloads, retest workflow, and team management through a dedicated platform.
Findings meeting A scheduled session to align on risks, priorities, and the remediation approach.
Retest report Verification results after remediation, documenting each finding with its updated status.

Pentrox Portal report library showing the four report types available for download

See what a Pentrox report looks like before you decide

How often should you have a penetration test?

At least yearly and after every major change; what the standards require and a cadence that fits.

Retesting: how a fix is proven

What a retest checks, the three outcomes, and why the record matters in an audit.

NIS2 penetration testing

Where an organisation is in scope of the Cyberbeveiligingswet as well, the same penetration test provides the evidence for the Article 21 measures.

When independent assessment is the right step

An independent assessment is required ahead of an audit, a product launch, or a funding round, and the organisation needs documented evidence from a third party.

Digital platforms handle revenue, customer data, or service delivery, and the security of those platforms has not been validated by an external party.

Existing security controls have been implemented but have not been tested from an attacker perspective to confirm they work as intended.

Request a scoping call

Timeline

Illustrative durations to support planning. Confirmed in the statement of work.

The duration of a PCI-DSS penetration test depends on the size of the cardholder data environment, the number of segmentation boundaries, and the complexity of payment applications in scope. The calibration bands below are indicative. Exact duration is confirmed in the statement of work.

Small scope 3 to 5 testing days Single payment application with one CDE zone and limited segmentation boundaries

Core scope 5 to 8 testing days Two or more payment applications across distinct CDE zones with segmentation validation

Complex scope 8+ testing days Large CDE with distributed payment infrastructure, third-party integrations, and extensive segmentation

Report delivery 5 business days Initial report and management report are delivered shortly after testing is completed.

Retest Included as standard Retesting within 90 days after report delivery is included at no additional cost.

What determines duration

Number of systems within the cardholder data environment
Number and complexity of segmentation boundaries
Number of payment applications and web interfaces in scope
Whether source code or architecture documentation is available
Whether testing is performed in a production or non-production environment

Actual duration is confirmed during scoping and depends on CDE complexity and segmentation architecture. A statement of work confirms the exact scope and timeline before the assessment begins. The final report is delivered within five business days after completion of testing.

Why Pentrox

The operational standards behind every PCI-DSS assessment.

These operational standards apply to every PCI-DSS assessment Pentrox delivers, regardless of CDE size or payment architecture.

CDE-scoped testing

Boundaries validated, not assumed.

Segmentation controls are tested from both sides of the boundary. Ineffective segmentation is identified before it expands the compliance scope.

QSA-ready reporting

Findings mapped to requirements.

Every finding references the specific PCI DSS v4.0 requirement it relates to. Reports are structured for direct use during QSA review.

Senior-led assessment

Every assessment is performed or supervised by experienced ethical hackers.

Pentrox does not delegate assessments to junior testers. Pentesters hold industry-standard certifications (OSCP, OSCE, OSWE, eWPTX, eMAPT, CPTS, CWES, BSCP) and every report passes internal quality review.

Portal-delivered results

Findings visible in real time, not buried in a PDF delivered weeks later.

The Pentrox Portal provides remediation tracking, retest requests, report downloads, and team access management. Role-based access control is enforced on every account.

Retest included

Verify fixes before the QSA returns.

Remediated findings are flagged through the Portal and scheduled for verification. Each finding is re-evaluated individually. Retest cycles repeat until all findings are resolved.

Frequently asked questions

Practical answers for security teams and procurement officers.

Is this assessment aligned with PCI DSS v4.0?

The assessment follows PCI DSS v4.0 Requirement 11.4 and the PCI SSC Penetration Testing Guidance (Information Supplement). Scope, methodology, and reporting are structured to satisfy the penetration testing requirements of the standard.

Can the report be used as evidence during QSA review?

The report is structured for QSA review. Each finding maps to the relevant PCI DSS requirement, and segmentation testing results are documented with pass/fail outcomes per boundary. It is worth noting that Pentrox provides penetration testing evidence, not the compliance certification itself.

Is retesting included, and at what cost?

Retesting of remediated findings is included as standard with every assessment. There are no additional charges for verifying that fixes have been implemented correctly. The retest process is managed through the Pentrox Portal, where the client can flag remediated findings and request a retest.

What clearances do the testers hold?

All Pentrox employees undergo PES (Personnel Screening) background checks upon commencement of employment. Team members hold one or more industry-standard certifications such as OSCP, OSCE, OSWE, eWPTX, eMAPT, CPTS, CWES and BSCP. Every assessment is performed or supervised by senior penetration testers with extensive hands-on experience.

How is production impact managed during testing?

All testing is performed in a controlled, non-destructive manner. Denial-of-service testing against production payment systems is excluded unless explicitly agreed. Testing is preferably conducted in a non-production environment where feasible.

Is reporting delivered in English or Dutch?

Reports are delivered in English by default. Dutch-language reporting can be arranged when required. The statement of work confirms the reporting language before the assessment begins.

How is assessment data handled and who has access to findings?

Findings, reports, and project data are stored in the Pentrox Portal, hosted on a dedicated VPS in a datacenter in the European Union. Access is controlled through mandatory two-factor authentication and role-based permissions. The client manages team membership. Data remains accessible for the lifetime of the client account and is removed only on explicit request.

What happens when a critical vulnerability is found during testing?

Critical or blocking vulnerabilities are communicated immediately through the channel agreed at kickoff. Findings are published in the Pentrox Portal as they are confirmed, so remediation can begin before the final report is delivered. The escalation path is documented in the statement of work.

What does PCI DSS Requirement 11.4 require, and what happened to 11.3?

Requirement 11.4 of PCI DSS v4.0 replaced Requirement 11.3 of v3.2.1. It asks for a documented methodology (11.4.1), an internal penetration test at least once every 12 months and after significant changes (11.4.2), an external test on the same cycle (11.4.3), remediation and retesting of exploitable findings (11.4.4), a segmentation test at least every 12 months (11.4.5) and every six months for service providers (11.4.6). Multi-tenant providers also support testing by their customers (11.4.7).

How is a segmentation test performed?

From every network segment that is out of scope, the tester tries to reach the cardholder data environment: port scans, protocol checks and attempts to use existing connections such as jump hosts or shared services. The test confirms that only the documented paths exist. If segmentation is used to reduce the PCI scope, this test is what proves the reduced scope to the assessor.