PCI DSS Penetration Testing Requirements in 2026

Penetration testing has been a PCI DSS requirement since version 1.0, but with the transition to PCI DSS v4.0 now fully enforced since March 31, 2025 the requirements have become significantly more prescriptive about what constitutes an acceptable penetration test.

The days of running an automated vulnerability scanner, exporting its output with a cover page, and calling it a penetration test are over. Requirement 11.4 in PCI DSS v4.0.1 now specifies detailed expectations for penetration testing methodology, scope, frequency, tester qualifications, and evidence documentation. QSAs (Qualified Security Assessors) are trained to identify programmes that check boxes rather than actually test security.

This guide explains exactly what PCI DSS Requirement 11.4 demands, what a "qualified tester" means in practice, what the documented methodology must include, and what your penetration test report must contain for a QSA to accept it as compliance evidence in 2026.

1. What Requirement 11.4 Actually Says — The Sub-Requirements Broken Down
2. What "Qualified Tester" Means — What QSAs Actually Look For
3. The Documented Methodology Requirement — What It Must Include
4. Internal vs External Penetration Testing — What Both Must Cover
5. Segmentation Testing — The Most Commonly Missed Requirement
6. What the Pentest Report Must Contain for a QSA to Accept It
7. When Annual Testing Isn't Enough — Post-Significant-Change Testing
8. How SecurityWall Delivers PCI DSS-Aligned Penetration Testing

What Requirement 11.4 Actually Says — The Sub-Requirements Broken Down

PCI DSS v4.0.1 Requirement 11.4 states: "External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected."

This high-level statement is operationalised through seven sub-requirements. Here is what each one actually means in plain language:

Requirement 11.4.1 — Documented Penetration Testing Methodology

What it says: A penetration testing methodology is defined, documented, and implemented, and includes industry-accepted approaches to penetration testing, coverage of the entire CDE perimeter and critical systems, testing from both inside and outside the network, testing to validate segmentation controls, application-layer testing to identify vulnerabilities listed in Requirement 6.2.4, network-layer testing that encompasses all components supporting network functions, and review of threats and vulnerabilities experienced in the last 12 months.

What it means: You must have a written penetration testing methodology document that is specific to your environment. This is not a generic "how to do pentesting" guide it is a document that describes how penetration testing will be conducted in your organisation, what will be tested, what methodology framework you are using (such as NIST SP 800-115, OWASP Testing Guide, PTES, or OSSTMM), and how the testing will cover all the components listed above.

This is new in v4.0. Under v3.2.1, the methodology requirement was implicit. Under v4.0, it must be documented, maintained, and available for QSA review. Many organisations were caught off guard by this requirement during their first v4.0 assessment.

Requirement 11.4.2 — Internal Penetration Testing

What it says: Internal penetration testing is performed as follows: per the defined methodology, at least once every 12 months, after any significant infrastructure or application upgrade or modification, by a qualified internal resource or qualified external third party, and with organizational independence of the tester (the tester cannot test systems they are responsible for managing or maintaining).

What it means: You must conduct penetration testing of your internal network and systems at least annually and after any significant change. The test simulates an attacker who has already gained access to your internal network (for example, through phishing, a compromised workstation, or physical access) and is attempting to reach the Cardholder Data Environment (CDE) from inside your organisation.

Requirement 11.4.3 — External Penetration Testing

What it says: External penetration testing is performed as follows: per the defined methodology, at least once every 12 months, after any significant infrastructure or application upgrade or modification, by a qualified internal resource or qualified external third party, and with organizational independence of the tester.

What it means: You must conduct penetration testing of all internet-facing systems that are part of or could affect the CDE. This includes web applications, APIs, remote access infrastructure (VPNs, remote desktop gateways), firewalls, and any other externally accessible systems.

External penetration testing is distinct from the quarterly external vulnerability scan required by Requirement 11.3. The ASV scan is automated and identifies known vulnerabilities. Penetration testing actively attempts to exploit those vulnerabilities to demonstrate real-world risk.

Requirement 11.4.4 — Exploitable Vulnerabilities Corrected and Retested

What it says: Exploitable vulnerabilities and security weaknesses found during penetration testing are corrected, and testing is repeated to verify the corrections.

What it means: You cannot simply document the findings and file the report. You must remediate the vulnerabilities the penetration tester was able to exploit, and then have the tester retest those specific issues to confirm they have been fixed. The retest results must be included in the final report or provided as a separate attestation.

For critical and high-severity findings, retest verification is mandatory. For medium and low findings, retesting is recommended but QSAs typically accept risk-acceptance documentation if remediation is not feasible.

Requirement 11.4.5 — Segmentation Testing (If Segmentation Is Used)

What it says: If segmentation is used to isolate the CDE from other networks, penetration tests are performed on segmentation controls as follows: at least once every 12 months and after any changes to segmentation controls/methods, confirming that the segmentation controls are operational and effective and isolate the CDE from all out-of-scope systems, confirming effectiveness of any use of isolation to separate systems with differing security levels, and performed by a qualified internal resource or qualified external third party with organizational independence.

What it means: If your organisation uses network segmentation to reduce PCI DSS scope (i.e., you claim that certain systems are out of scope because they are separated from the CDE by firewalls, VLANs, or other segmentation methods), the penetration tester must actively attempt to breach those segmentation controls to verify they are effective.

This is not the same as vulnerability scanning across VLANs. Segmentation testing requires the tester to attempt to traverse segmentation boundaries, bypass firewall rules, tunnel through access controls, or exploit misconfigurations that would allow access from out-of-scope systems into the CDE.

Requirement 11.4.6 — Service Provider Segmentation Testing (Every Six Months)

What it says: Additional requirement for service providers only: If segmentation is used to isolate the CDE from other networks, penetration tests are performed on segmentation controls at least once every six months and after any changes to segmentation controls/methods.

What it means: Service providers (payment processors, gateways, hosting providers, managed service providers) must test segmentation twice as frequently as merchants every six months instead of annually. This recognises that service providers typically have more complex, multi-tenant environments where segmentation failures could affect multiple customers.

Requirement 11.4.7 — Multi-Tenant Service Provider Support for Customer Pen Testing

What it says: Additional requirement for multi-tenant service providers only: Multi-tenant service providers support their customers for external penetration testing per Requirements 11.4.3 and 11.4.4.

What it means: If you are a service provider that hosts multiple customers on shared infrastructure (such as a SaaS platform or hosting provider), you must allow your customers to conduct their own external penetration tests or perform testing on their behalf. This ensures that customers can validate their own compliance obligations without being blocked by your infrastructure policies.

What "Qualified Tester" Means — What QSAs Actually Look For

PCI DSS v4.0.1 requires that penetration testing be performed by a "qualified internal resource or qualified external third party" with "organizational independence." The standard does not define "qualified" through specific certifications, but QSAs consistently evaluate tester qualifications as a proxy for competence during assessments.

In practice, QSAs look for three things when evaluating whether a penetration tester is "qualified":

1. Organizational Independence

The tester must be independent of the systems being tested. An internal tester cannot test their own work. If the same team that built the payment application also penetration tests it, the QSA will flag this as a conflict of interest.

For internal testers, organizational independence typically means:

• The tester reports to a different manager or department than the teams responsible for the systems being tested
• The tester was not involved in designing, configuring, or maintaining the systems in scope
• The tester has no vested interest in the test results (such as performance reviews tied to security posture)

For external third-party testers, organizational independence is automatically satisfied because they are not part of the organisation.

2. Demonstrated Competence Through Certifications and Experience

While PCI DSS does not mandate specific certifications, QSAs consistently look for industry-recognized credentials that demonstrate hands-on penetration testing skill. The certifications that most effectively satisfy QSA scrutiny are:

OSCP (Offensive Security Certified Professional) — The industry-standard certification for practical penetration testing competence. OSCP requires candidates to compromise multiple systems in a 24-hour hands-on exam with no multiple-choice questions. QSAs recognise OSCP as evidence of genuine exploitation capability, not just theoretical knowledge.

CREST CRT (CREST Registered Tester) or CREST CCT (CREST Certified Tester) — UK-based certifications that demonstrate professional penetration testing competence. CREST certifications are particularly valued in Europe and by organisations with international compliance obligations.

GPEN (GIAC Penetration Tester) or GXPN (GIAC Exploit Researcher and Advanced Penetration Tester) — SANS Institute certifications that demonstrate penetration testing knowledge and capability. GXPN in particular is recognised as a senior-level credential.

CEH (Certified Ethical Hacker) — While less rigorous than OSCP or CREST, CEH is still recognised by QSAs as evidence of baseline penetration testing knowledge. However, QSAs may ask follow-up questions about practical experience if CEH is the only credential presented.

OSWE (Offensive Security Web Expert) — A specialised credential for web application penetration testing. Particularly relevant for e-commerce merchants and SaaS providers where application-layer testing is a significant portion of the scope.

SecurityWall's penetration testing team proudly holds OSCP, OSWE, and CREST CRT certifications, which are exactly the credentials QSAs look for when evaluating whether a penetration tester meets the "qualified" standard under Requirement 11.4.2 and 11.4.3.

3. Methodology Adherence and Evidence of Thoroughness

The tester must follow the organisation's documented methodology (per Requirement 11.4.1) and produce evidence that all required testing areas were covered. This is assessed by reviewing the penetration test report, which should document:

• The methodology framework used (NIST SP 800-115, OWASP, PTES, OSSTMM)
• The scope of testing (which systems, networks, and applications were tested)
• The attack chains attempted (not just a list of vulnerabilities, but what the tester actually tried to exploit)
• The evidence of exploitation (screenshots, command outputs, proof-of-concept code)
• The remediation guidance provided

A penetration test report that is clearly the output of an automated vulnerability scanner with a cover page will be rejected by a QSA, regardless of the tester's certifications. The report must demonstrate manual analysis, creative exploitation, and evidence that the tester went beyond running tools.

The Documented Methodology Requirement — What It Must Include

Requirement 11.4.1 is the most commonly overlooked new requirement in PCI DSS v4.0. Under v3.2.1, the methodology was implicit organisations could simply conduct penetration tests without formally documenting their approach. Under v4.0, the methodology must be defined, documented, and available for QSA review.

The documented methodology must include the following elements:

1. Industry-Accepted Approach to Penetration Testing

The methodology must reference a recognised framework. Acceptable frameworks include:

• NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment (U.S. National Institute of Standards and Technology)
• OWASP Testing Guide — Web Application Security Testing methodology from the Open Web Application Security Project
• PTES (Penetration Testing Execution Standard) — A comprehensive methodology covering all phases of penetration testing
• OSSTMM (Open Source Security Testing Methodology Manual) — A peer-reviewed methodology for security testing

You do not need to follow all of these — you need to follow one consistently and reference it in your methodology document. The framework provides the structure; your methodology document explains how you apply it to your specific environment.

2. Coverage of the Entire CDE Perimeter and Critical Systems

The methodology must specify that testing will cover:

• All internet-facing systems that are part of or could affect the CDE
• All internal systems within the CDE
• All network paths that could be used to reach the CDE from out-of-scope systems
• Critical systems supporting the CDE (such as authentication systems, database servers, and backup infrastructure)

3. Testing from Both Inside and Outside the Network

The methodology must specify that both internal penetration testing (simulating an insider threat or compromised workstation) and external penetration testing (simulating an internet-based attacker) will be conducted.

4. Testing to Validate Segmentation Controls (If Segmentation Is Used)

If network segmentation is used to reduce PCI DSS scope, the methodology must specify how segmentation testing will be conducted. This includes:

• Testing whether systems outside the CDE can access systems inside the CDE
• Testing whether segmentation controls (firewalls, VLANs, ACLs) are correctly configured
• Testing whether there are unintended network paths that bypass segmentation

5. Application-Layer Testing to Identify Vulnerabilities in Requirement 6.2.4

The methodology must specify that application-layer testing will be conducted to identify at minimum the vulnerabilities listed in Requirement 6.2.4. These include:

• Injection flaws (SQL injection, command injection, LDAP injection)
• Authentication and session management flaws
• Cross-site scripting (XSS)
• Insecure direct object references
• Security misconfigurations
• Sensitive data exposure
• Broken access control
• Cross-site request forgery (CSRF)
• Use of components with known vulnerabilities
• Insufficient logging and monitoring

This is aligned with the OWASP Top 10 but specifically covers the vulnerabilities most relevant to payment applications.

6. Network-Layer Testing Covering All Components

The methodology must specify that network-layer testing will cover:

• Firewalls, routers, switches, and other network infrastructure
• Operating systems and services running on servers within the CDE
• Remote access infrastructure (VPNs, jump hosts, remote desktop gateways)
• Wireless access points (if wireless is used within or connected to the CDE)

7. Review of Threats and Vulnerabilities Experienced in the Last 12 Months

The methodology must specify that the penetration test will consider any threats or vulnerabilities that the organisation has experienced or observed in the past year. This ensures the test is tailored to the organisation's threat landscape, not just a generic template.

For example, if the organisation was targeted by phishing attacks in the past year, the penetration test should include scenarios where the attacker has already compromised a workstation via phishing and is attempting lateral movement to the CDE.

Internal vs External Penetration Testing — What Both Must Cover

PCI DSS v4.0.1 requires both internal and external penetration testing, and they serve different purposes. Understanding the distinction is critical to scoping your testing correctly.

External Penetration Testing (Requirement 11.4.3)

What it simulates: An attacker on the internet with no internal access, attempting to compromise your organisation through internet-facing systems.

What must be tested:

• All web applications that process, store, or transmit cardholder data (e-commerce sites, payment portals, customer account management systems)
• All APIs that interact with payment data or the CDE (payment processing APIs, reporting APIs, webhooks)
• All remote access infrastructure (VPN endpoints, SSH/RDP gateways, remote administration portals)
• All internet-facing network infrastructure in the CDE (firewalls, load balancers, edge routers)
• Any other externally accessible system that could affect the security of the CDE

What the tester will attempt:

• Exploiting vulnerabilities in web applications to gain unauthorised access or steal data
• Testing for authentication bypass, session hijacking, and privilege escalation
• Attempting to exploit misconfigurations in firewalls or VPNs to gain internal network access
• Testing for information disclosure that could aid further attacks (such as software version exposure, directory listing, error messages)
• Fuzzing APIs to identify injection vulnerabilities, broken authentication, or insecure data exposure

External penetration testing is distinct from the quarterly ASV scan. The ASV scan is automated and identifies known vulnerabilities. Penetration testing actively attempts to exploit those vulnerabilities, chain multiple vulnerabilities together, and demonstrate the actual business impact of a successful attack.

Internal Penetration Testing (Requirement 11.4.2)

What it simulates: An attacker who has already gained access to your internal network (for example, through a phishing attack, a compromised workstation, or physical access) and is attempting to reach the CDE.

What must be tested:

• All systems within the CDE (application servers, database servers, payment processing infrastructure)
• Network segmentation controls that separate the CDE from other internal networks
• Internal authentication systems (Active Directory, LDAP, SSO providers)
• Internal network paths and trust relationships that could be exploited for lateral movement
• Privileged access controls and administrative interfaces

What the tester will attempt:

• Lateral movement from a compromised workstation to the CDE
• Privilege escalation from a standard user account to administrative access
• Exploiting trust relationships between systems (such as service accounts with excessive privileges)
• Testing whether segmentation controls prevent access from out-of-scope networks to the CDE
• Attempting to extract credentials from memory, registry, or configuration files
• Testing for misconfigurations that would allow an insider to access cardholder data without authorisation

Internal penetration testing must assume the attacker has some level of internal access. The starting point is typically a standard user account on a workstation within the corporate network, and the tester attempts to escalate from there.

Segmentation Testing — The Most Commonly Missed Requirement

If your organisation uses network segmentation to reduce PCI DSS scope meaning you claim that certain systems are out of scope because they are isolated from the CDE by firewalls, VLANs, or other network controls segmentation testing is mandatory under Requirement 11.4.5.

Segmentation testing is the most commonly missed or incorrectly implemented penetration testing requirement. Many organisations conduct annual penetration tests but never specifically validate that segmentation controls are effective under attack.

What Segmentation Testing Must Validate

Segmentation testing must confirm that:

1. Out-of-scope systems cannot reach the CDE. The tester must attempt to connect from systems outside the CDE (such as corporate workstations, development environments, or guest networks) to systems inside the CDE and verify that the segmentation controls block unauthorised access.
2. Segmentation controls are operational and correctly configured. The tester must verify that the firewall rules, VLANs, ACLs, or other segmentation methods are configured as intended and have not been inadvertently misconfigured or bypassed.
3. There are no unintended network paths that bypass segmentation. The tester must look for alternative paths that could circumvent the segmentation controls, such as:
   • Backup networks or out-of-band management interfaces that are not subject to firewall rules
   • VPN tunnels or remote access connections that bypass segmentation
   • Wi-Fi networks that bridge segmented network zones
   • Trust relationships or routing misconfigurations that allow traffic flow between zones
4. Systems at different security levels are properly isolated (per Requirement 2.2.3). If your organisation uses isolation to separate development, staging, and production environments — or corporate networks from the CDE — the segmentation test must verify that lower-security systems cannot access higher-security systems.

What Segmentation Testing Is Not

Segmentation testing is not the same as:

• Running a port scan from one network to another and confirming that ports are blocked
• Reviewing firewall rules in a configuration audit and confirming they match the documented design
• Assuming segmentation works because it was tested during initial implementation

Segmentation testing requires active attempts to bypass, tunnel through, or circumvent the controls. This may include:

• Exploiting misconfigurations to pivot through an intermediary system that has access to both networks
• Using tunnelling techniques (DNS tunneling, ICMP tunneling, HTTP encapsulation) to bypass firewall rules
• Testing whether firewall rules correctly handle fragmented packets, unusual protocols, or out-of-state connections
• Attempting to establish reverse connections from the CDE to out-of-scope systems

Frequency of Segmentation Testing

For merchants: Segmentation testing must be conducted at least once every 12 months and after any changes to segmentation controls or methods (Requirement 11.4.5).

For service providers: Segmentation testing must be conducted at least once every six months and after any changes to segmentation controls or methods (Requirement 11.4.6).

A "change to segmentation controls" includes:

• Firewall rule changes that affect traffic between network zones
• VLAN or subnet changes
• Routing or gateway changes
• Changes to network hardware that enforces segmentation (replacing firewalls, switches, routers)

What the Pentest Report Must Contain for a QSA to Accept It

The penetration test report is the primary evidence artifact that a QSA will review during your PCI DSS assessment. A report that lacks required elements will generate a QSA finding and delay your certification.

Here is what the penetration test report must contain:

1. Test Scope and Boundaries

The report must clearly document:

• Which systems, networks, and applications were tested
• Which systems were explicitly excluded from testing
• The testing period (start date and end date)
• Whether the test was internal, external, or both
• Whether segmentation testing was included

The scope must be precise enough that a QSA can verify all required systems were tested. A scope statement like "the CDE was tested" is insufficient — the report must list specific IP ranges, hostnames, and application URLs.

2. Tester Credentials and Qualifications

The report must include:

• The name and certifications of the lead tester (OSCP, CREST, GPEN, etc.)
• Evidence of organisational independence (confirmation that the tester is not responsible for the systems being tested)
• The name of the organisation that conducted the test (if an external third party)

3. Methodology Used

The report must reference the methodology framework used (NIST SP 800-115, OWASP, PTES, OSSTMM) and confirm that the test followed the organisation's documented methodology per Requirement 11.4.1.

4. Findings with CVSS Scores and Exploitation Evidence

Every vulnerability identified during the test must be documented with:

• A CVSS v3.1 score (critical, high, medium, low) — this is the industry-standard scoring system and is what QSAs expect
• A description of the vulnerability
• Proof-of-concept evidence showing the vulnerability was exploited (screenshots, command outputs, exploit code)
• The business impact of successful exploitation (what data could be accessed, what systems could be compromised)

A report that lists vulnerabilities without demonstrating that they were successfully exploited will be questioned by a QSA. The distinction between "this vulnerability exists" and "this vulnerability was exploited and here is what we obtained" is critical.

5. Remediation Guidance

For each finding, the report must include specific, actionable remediation recommendations. Generic advice like "apply patches" or "improve configuration" is insufficient. The guidance should specify:

• Which patch or configuration change will remediate the vulnerability
• How to verify the remediation was effective
• Any compensating controls that could be applied if direct remediation is not feasible

6. Retest Results for Critical and High Findings

The report must include evidence that all critical and high-severity findings were remediated and retested. This can be provided in two ways:

• A retest section in the main report that documents the retest results for each finding
• A separate retest attestation letter signed by the tester confirming that the findings were retested and confirmed as resolved

For medium and low findings, retesting is recommended but not always mandatory. However, if those findings are not remediated, the organisation should document the risk acceptance decision.

7. Segmentation Testing Results (If Applicable)

If segmentation is used to reduce PCI DSS scope, the report must include a dedicated section documenting segmentation testing results, including:

• Which segmentation controls were tested (firewalls, VLANs, ACLs)
• What attempts were made to bypass or traverse the segmentation
• Evidence that segmentation controls are operational and effective
• Any weaknesses or misconfigurations identified in the segmentation design

What a QSA Will Reject

QSAs will reject penetration test reports that:

• Are clearly the output of an automated vulnerability scanner (Nessus, Qualys, OpenVAS) with a cover page and no evidence of manual exploitation
• Do not reference a documented methodology or framework
• List vulnerabilities but provide no evidence they were exploited
• Do not include tester credentials or certifications
• Do not include retest results for critical and high findings
• Exclude segmentation testing when segmentation is used to reduce scope
• Are outdated (more than 12 months old or conducted before the most recent significant infrastructure change)

When Annual Testing Isn't Enough — Post-Significant-Change Testing

PCI DSS v4.0.1 requires penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or modification. The phrase "significant change" is deliberately broad, and organisations must apply judgment to determine when a change is significant enough to trigger a retest.

PCI DSS v4.0.1 provides guidance on what constitutes a significant change. Changes that require penetration testing include:

New system components added to the CDE

• New application servers, database servers, or payment processing systems deployed into production
• New cloud infrastructure or SaaS services that store, process, or transmit cardholder data
• New APIs or integrations that interact with payment data

Major application changes

• Significant code changes to payment applications or web applications that accept cardholder data
• Platform upgrades (such as migrating an e-commerce site from one platform to another)
• Changes to authentication or session management mechanisms
• Changes to how cardholder data is stored, encrypted, or transmitted

Changes to network architecture or segmentation

• Firewall rule changes that affect traffic between network zones
• Changes to VLAN or subnet configurations
• Routing changes that alter network paths to the CDE
• Addition or removal of network segmentation controls

Encryption changes

• Changes to encryption methods, key management, or certificate infrastructure
• Migration from one encryption algorithm to another
• Changes to TLS/SSL configurations on payment pages or APIs

Changes to remote access infrastructure

• Deployment of new VPN endpoints or remote desktop gateways
• Changes to multi-factor authentication mechanisms
• Changes to privileged access management systems

Cloud migrations or infrastructure changes

• Migration from on-premises infrastructure to cloud (AWS, Azure, GCP)
• Migration from one cloud provider to another
• Changes to cloud security configurations (IAM policies, security groups, network ACLs)

What Is Not Considered a Significant Change

Minor updates that do not typically trigger a retest obligation include:

• Routine security patching (OS patches, application patches that do not change functionality)
• Configuration changes that do not affect the CDE or segmentation
• Non-payment-related application updates (such as updating a marketing page or adding a blog post)
• Hardware replacements where the configuration remains identical (replacing a failed server with an identically configured server)

When in doubt, organisations should document the change and assess whether it could affect the security posture of the CDE. If the answer is yes, a retest should be conducted.

Timing of Post-Change Testing

PCI DSS does not specify exactly how soon after a change the retest must be conducted, but the expectation is that testing occurs before or shortly after the change enters production, not months later.

Best practice is to conduct penetration testing as part of the change management process:

1. Significant change is proposed and approved through change management
2. Change is implemented in a staging or pre-production environment
3. Penetration testing is conducted in staging (if possible) or immediately after production deployment
4. Testing results are reviewed, findings are remediated, and the change is validated

This ensures that security weaknesses introduced by the change are identified and remediated before attackers can exploit them.

How SecurityWall Delivers PCI DSS-Aligned Penetration Testing

SecurityWall provides end-to-end penetration testing services specifically scoped and structured to satisfy PCI DSS Requirement 11.4. Our engagements are designed to meet QSA expectations from day one not just to check a compliance box, but to genuinely test the security of your cardholder data environment.

OSCP, OSWE, and CREST-Certified Testers

Our penetration testing team holds the industry-standard certifications that QSAs look for when evaluating tester qualifications:

• OSCP (Offensive Security Certified Professional) — Hands-on certification demonstrating practical exploitation capability
• OSWE (Offensive Security Web Expert) — Specialised certification for web application and API security testing
• CREST CRT (CREST Registered Tester) — Internationally recognised certification for professional penetration testing competence

These certifications satisfy the "qualified tester" standard under Requirements 11.4.2 and 11.4.3 and provide QSAs with confidence that the testing was conducted by practitioners with demonstrated competence.

Complete PCI DSS Testing Solution: Penetration Testing + ASV Scanning

SecurityWall is both an OSCP/OSWE/CREST-certified penetration testing provider and a PCI SSC-certified Approved Scanning Vendor (ASV). This means we can deliver both the annual penetration testing (Requirement 11.4) and the quarterly external vulnerability scans (Requirement 11.3.2) required for full PCI DSS compliance — eliminating the need to coordinate with multiple vendors.

Our combined service offering includes:

• Annual penetration testing with internal, external, and segmentation testing scoped to Requirement 11.4
• Quarterly ASV scans of all internet-facing systems with unlimited remediation scans
• Post-change testing for both penetration tests and ASV scans when infrastructure changes
• Coordinated reporting that maps penetration test findings to ASV scan results
• Single point of contact for all PCI DSS testing requirements

Related reading:

• What Is PCI DSS Compliance? A Plain-Language Guide for 2026
• PCI DSS Penetration Testing Requirements: What Assessors Check
• How to Choose the Right PCI DSS SAQ for Your Business (coming soon)
• PCI DSS v4.0 Compliance Checklist for E-Commerce Merchants (coming soon)
• PCI DSS v4.0 & v4.0.1: Everything That Changed and What You Must Do by 2026
• PCI DSS Gap Assessment: What It Covers and How to Prepare in 2026
• PCI DSS for Cloud and SaaS: What's Different in AWS, Azure, and GCP (coming soon)

Frequently Asked Questions

Do we need both internal and external penetration testing?

Yes. PCI DSS v4.0.1 requires both internal testing (Requirement 11.4.2) and external testing (Requirement 11.4.3) at least annually and after significant changes. They test different attack scenarios and cannot be substituted for each other.

Is penetration testing the same as the quarterly ASV scan?

No. ASV scans (Requirement 11.3.2) are quarterly automated vulnerability scans conducted by a PCI SSC-certified Approved Scanning Vendor. Penetration testing (Requirement 11.4) is annual manual testing that actively exploits vulnerabilities and demonstrates real-world impact. Both are mandatory they serve different purposes and cannot substitute for each other. QSAs distinguish sharply between the two.

Can we use internal staff to conduct penetration testing?

Yes, if they meet the "qualified" standard (certifications such as OSCP, CREST, or GPEN; hands-on experience; and organizational independence from the systems being tested). However, many organisations use external third parties to eliminate any questions about independence during QSA assessment.

What certifications do penetration testers need for PCI DSS?

PCI DSS does not mandate specific certifications, but QSAs consistently look for OSCP, CREST CRT/CCT, GPEN, GXPN, or OSWE. These demonstrate hands-on capability rather than just theoretical knowledge.

How long does a PCI DSS penetration test take?

It depends on the scope. A typical engagement for a mid-sized e-commerce merchant (external web application and API testing, internal network testing, segmentation validation) takes 2–4 weeks of active testing. Post-remediation retesting adds another 1–2 weeks.

Do we need segmentation testing if we don't use segmentation?

No. Segmentation testing (Requirement 11.4.5) is only required if you use network segmentation to reduce PCI DSS scope. If your entire network is in scope, segmentation testing is not applicable.

What happens if we fail the penetration test?

Findings are documented, remediation guidance is provided, and you remediate the vulnerabilities. After remediation, the tester retests to confirm the fixes are effective. The final report (including retest results) is what you submit to your QSA. PCI DSS expects that findings will be identified and remediated that is the purpose of the test.