If you handle, process, or store credit card data, you’re probably familiar with the Payment Card Industry Data Security Standard (PCI DSS). And if you’ve dug into the requirements, you know that Requirement 11.4 mandates regular penetration testing. This isn’t a suggestion or best practice buried in footnotes. It’s a hard requirement that every merchant and service provider must satisfy to maintain compliance.

But what exactly does PCI DSS require from a penetration test? What changed in version 4.0? And how can you make sure your pen test actually passes muster with your Qualified Security Assessor (QSA)?

Let’s walk through everything you need to know about penetration testing for PCI DSS compliance, from the letter of the law to practical implementation.

What PCI DSS Requires for Penetration Testing

Requirement 11.4 of PCI DSS focuses specifically on penetration testing. The standard requires organizations to perform both external and internal penetration testing at least annually and after any significant infrastructure or application upgrade or modification.

Here’s what that means in practice. You need to test both your internet-facing systems (external pen testing) and your internal network (internal pen testing). The external test simulates an attacker on the internet trying to break into your cardholder data environment (CDE). The internal test simulates a threat actor who has already gained access to your internal network, perhaps through phishing or a compromised employee account.

The “significant change” trigger is important. If you deploy a new payment gateway, migrate to a new data center, or make major architectural changes to your CDE, you can’t wait until your next annual test. You need to conduct penetration testing immediately after the change goes live.

PCI DSS also requires network segmentation testing if you use segmentation to isolate your CDE from other parts of your network. This is separate from the general penetration testing requirement, and we’ll cover it in detail below.

Praetorian Guard goes beyond these minimum requirements by providing continuous penetration testing instead of once-yearly assessments. This means you’re not just meeting compliance, you’re maintaining ongoing visibility into your security posture as your environment evolves.

What Changed in PCI DSS v4.0

PCI DSS version 4.0, which became active in March 2022 with a transition period extending to March 2025, introduced several important changes to penetration testing requirements.

The most significant change is the explicit requirement for penetration testing methodology to be defined and documented. Previously, QSAs had some discretion in evaluating whether a pen test was sufficient. Now, organizations must document their penetration testing methodology and ensure it covers specific elements.

Version 4.0 also clarified expectations around authenticated testing. While version 3.2.1 was somewhat vague, version 4.0 explicitly states that penetration tests must include both authenticated and unauthenticated testing where appropriate. This means testers need legitimate credentials to test what an authenticated attacker could accomplish, not just what an outsider can do.

Another key change involves the definition of “qualified” testers. PCI DSS v4.0 strengthens the requirements for who can perform your penetration tests. The tester must be organizationally independent from the function being tested and must possess sufficient knowledge, skills, and ability. This means you can’t have your developers pen test their own code, and you can’t have someone with entry-level security knowledge running your compliance pen tests.

The segmentation testing requirements also got more specific. Version 4.0 requires that segmentation controls be tested at least annually and after any changes to segmentation controls or methods. The testing must confirm that segmentation is working as intended to isolate the CDE from out-of-scope systems.

Internal vs External Testing Requirements

PCI DSS distinguishes clearly between internal and external penetration testing because they simulate different threat models and require different approaches.

External penetration testing focuses on internet-facing systems that process, store, or transmit cardholder data. This includes web applications, payment gateways, e-commerce platforms, and any public-facing APIs. The tester approaches these systems as an external attacker would, with no inside knowledge beyond what can be gathered through reconnaissance.

The goal of external testing is to identify vulnerabilities that could allow an attacker to breach your perimeter defenses. Testers look for issues like SQL injection in payment forms, authentication bypasses in customer portals, exposed administrative interfaces, misconfigured cloud storage, and vulnerable third-party components.

Internal penetration testing assumes the attacker has already gained some level of access to your internal network. This could happen through phishing, physical access, compromised credentials, or a malicious insider. The tester operates from within your network and attempts to move laterally, escalate privileges, and ultimately access cardholder data.

Internal tests typically uncover different vulnerability classes than external tests. Common findings include weak Active Directory security, unpatched internal systems, exposed database servers, insufficient network segmentation, and privilege escalation paths through misconfigured services.

Both types of testing are mandatory. You can’t substitute one for the other because they address fundamentally different attack scenarios. Organizations that only perform external testing are missing the insider threat and post-compromise scenarios that represent a significant portion of real-world breaches.

Praetorian’s managed penetration testing service covers both internal and external testing as part of a unified engagement, ensuring you meet all PCI DSS requirements without managing multiple vendors or testing schedules.

Network Segmentation Testing

If you use network segmentation to limit the scope of your PCI DSS assessment, you must prove that your segmentation controls actually work. This is where network segmentation testing comes in.

Segmentation testing verifies that systems outside your CDE cannot access systems inside your CDE. The goal is to confirm that your firewall rules, network access controls, and security groups are configured correctly and that there are no unexpected paths into the cardholder data environment.

The test must be performed at least annually and whenever you make changes to segmentation controls or methods. This includes firewall rule changes, network topology changes, or modifications to network access control lists.

During segmentation testing, the tester attempts to access in-scope systems from out-of-scope systems using various protocols and techniques. They might try to SSH from a corporate workstation to a database server in the CDE, or attempt to access payment application APIs from a marketing web server.

Proper segmentation testing documents all attempted connections and confirms that unauthorized connections are blocked. The deliverable typically includes a network diagram showing tested paths and the results of each connection attempt.

Many organizations underestimate the importance of segmentation testing. If your segmentation controls fail, your entire network may be in scope for PCI DSS, dramatically increasing your compliance burden. Regular testing ensures your segmentation strategy remains effective as your network evolves.

Praetorian Guard includes automated segmentation verification as part of its continuous attack surface management capabilities, alerting you immediately if segmentation controls degrade.

Penetration Testing Methodology Requirements

PCI DSS v4.0 introduced specific requirements for penetration testing methodology. Your methodology must be defined, documented, and followed consistently.

The methodology must include both network-layer and application-layer testing. Network-layer testing examines infrastructure components like firewalls, routers, switches, and servers. Application-layer testing focuses on web applications, APIs, and custom payment applications.

Testing must cover the entire CDE and all systems connected to or affecting the CDE. This means you can’t cherry-pick a few systems to test and ignore the rest. Your scope must be comprehensive.

The methodology must include both authenticated and unauthenticated testing. Unauthenticated testing simulates an external attacker with no credentials. Authenticated testing uses valid credentials to evaluate what an authenticated user or compromised account could accomplish.

Your methodology should follow industry-standard frameworks like OWASP Testing Guide, PTES (Penetration Testing Execution Standard), or NIST SP 800-115. QSAs expect to see a structured approach that includes reconnaissance, vulnerability scanning, exploitation, post-exploitation, and reporting.

Manual testing is critical. Automated vulnerability scanners (required separately under PCI DSS Requirement 11.3) are not sufficient for penetration testing. Your methodology must include manual testing techniques that can identify business logic flaws, complex authentication issues, and chained vulnerabilities that automated tools miss.

The methodology should also specify how findings are classified, reported, and remediated. This includes severity ratings, detailed remediation guidance, and retesting procedures.

Praetorian follows a comprehensive penetration testing methodology that exceeds PCI DSS requirements, combining automated reconnaissance with deep manual testing by experienced security engineers. Every finding is verified by human analysts to eliminate false positives.

Qualified Tester Requirements

Not everyone can perform PCI DSS penetration testing. The standard requires that testers be “qualified” and “organizationally independent.”

Organizational independence means the tester cannot be part of the same organizational unit that manages or maintains the systems being tested. You can use internal security teams for pen testing, but they must report to a different part of the organization than IT operations. Most organizations satisfy this requirement by hiring external penetration testing firms like Praetorian.

The “qualified” requirement is more nuanced. PCI DSS v4.0 requires that individuals performing penetration testing possess sufficient knowledge, skills, and ability. The Council doesn’t mandate specific certifications, but they do expect demonstrated competence.

In practice, QSAs look for evidence of qualification such as industry certifications (OSCP, OSCE, GPEN, GWAPT), relevant work experience, training history, and successful completion of prior penetration tests. Your penetration testing report should include tester qualifications as an appendix.

Many organizations make the mistake of hiring the cheapest penetration testing provider without vetting tester qualifications. This often results in superficial testing that misses critical vulnerabilities and fails to satisfy QSA expectations during audit.

Praetorian’s penetration testing team includes former NSA operators, security researchers who have discovered critical vulnerabilities in major platforms, and engineers with decades of offensive security experience. When you engage Praetorian for PCI DSS pen testing, you get consultants who have compromised some of the world’s most secure environments.

Testing Frequency and Triggers

The baseline requirement is clear: penetration testing must be performed at least once every 12 months. But that’s not the only time you need to test.

You must also perform penetration testing after any significant infrastructure or application upgrade or modification. The key word here is “significant.” PCI DSS doesn’t provide an exhaustive definition, but the intent is clear. Changes that could affect the security of your CDE require immediate testing.

Examples of significant changes include deploying a new payment application, upgrading your e-commerce platform, migrating to a new hosting environment, implementing major network architecture changes, or adding new payment channels.

Minor changes like patching, routine configuration updates, or small feature additions typically don’t trigger the pen testing requirement, but you should document your rationale for why a change is considered non-significant.

Segmentation testing follows the same schedule: at least annually and after any changes to segmentation controls or methods.

Many organizations struggle with the “significant change” requirement because modern DevOps practices involve frequent deployments. You can’t feasibly run a full penetration test after every code release.

This is where continuous security testing becomes valuable. Praetorian Guard provides ongoing penetration testing that automatically adapts as your environment changes, ensuring you’re always meeting PCI DSS requirements without manual scheduling or scope negotiation.

Penetration Testing Report Requirements

Your penetration testing report is a critical compliance artifact. QSAs will review it in detail during your assessment, and inadequate documentation can result in compliance failures even if the testing itself was thorough.

The report must document the methodology used, the scope of testing, the findings discovered, and the remediation recommendations. It should include sufficient technical detail that your engineering team can reproduce and fix each vulnerability.

For each finding, the report should include a description of the vulnerability, the systems affected, the risk rating, the steps to reproduce, the potential impact, and detailed remediation guidance. Screenshots, proof-of-concept code, and network diagrams add credibility and clarity.

The report must clearly identify which systems were tested, which were excluded from scope, and why. If you excluded systems, document the business justification and ensure your QSA agrees with the scoping decision.

Tester qualifications should be documented, including certifications, relevant experience, and training. This proves to your QSA that the testing was performed by qualified individuals.

Retesting results must also be documented. When you remediate findings, the penetration testing team should verify that the fixes are effective. The report should indicate which findings were retested and confirmed closed.

Many organizations make the mistake of treating the pen test report as a one-time deliverable. In reality, it’s a living document that demonstrates your ongoing commitment to security. You should retain reports for at least three years and be prepared to present them during QSA audits.

Praetorian delivers detailed, QSA-ready penetration testing reports that include everything your auditor needs to see. We also provide retesting at no additional cost to verify that remediation efforts are successful.

Common PCI DSS Penetration Testing Failures

Even organizations that commission penetration tests sometimes fail to meet PCI DSS requirements. Here are the most common mistakes.

First, insufficient scope. Some organizations test only their web applications and ignore backend systems, databases, and internal networks. PCI DSS requires comprehensive testing of the entire CDE. If your payment processing involves multiple systems, all of them must be tested.

Second, relying solely on automated scans. Vulnerability scanning (Requirement 11.3) is not the same as penetration testing (Requirement 11.4). Automated tools are part of a good pen test, but they can’t replace manual exploitation and post-exploitation activities. QSAs will reject pen tests that amount to nothing more than Nessus or Qualys scan reports.

Third, using unqualified testers. Hiring a junior security consultant or a generalist IT firm that doesn’t specialize in offensive security often results in superficial testing that misses critical vulnerabilities. Your QSA will scrutinize tester qualifications, and inadequate qualifications can invalidate the entire engagement.

Fourth, testing too early in the year. Some organizations perform penetration testing in January and then make significant infrastructure changes in November. By the time their QSA arrives for the annual assessment in December, the pen test is no longer representative of the current environment. Remember, you must test after significant changes, not just once per year.

Fifth, inadequate documentation. A verbal readout or a PowerPoint presentation is not sufficient. You need a detailed technical report that documents methodology, findings, and remediation. QSAs expect to see proof that testing was thorough and professional.

Sixth, ignoring segmentation testing. Organizations that use network segmentation to reduce PCI scope sometimes forget that segmentation testing is a separate requirement. You can’t assume your firewall rules are working correctly. You must prove it through testing.

Finally, failing to remediate findings. Penetration testing identifies vulnerabilities, but it doesn’t fix them. Some organizations treat the pen test as a checkbox exercise and never address the findings. During the QSA audit, unresolved high-risk vulnerabilities can result in compliance failures.

Going Beyond Compliance with Continuous Testing

Meeting PCI DSS penetration testing requirements is important, but annual testing has significant limitations. Your attack surface changes constantly. New vulnerabilities are discovered. Configurations drift. Code gets deployed. An attacker doesn’t wait for your annual pen test to launch an attack.

Continuous security testing addresses this gap by providing ongoing visibility into your security posture. Instead of a once-yearly snapshot, you get real-time monitoring, regular vulnerability assessments, and on-demand penetration testing when changes occur.

Praetorian Guard is a unified managed service that combines attack surface management, vulnerability management, breach and attack simulation, continuous penetration testing, threat intelligence, and attack path mapping. It’s designed specifically for organizations that want to exceed compliance requirements and build genuinely resilient security programs.

The platform continuously monitors your external attack surface, identifying new assets as they appear and testing them automatically. When critical vulnerabilities are discovered, human security engineers verify the findings and provide detailed remediation guidance. This approach delivers zero false positives because every alert has been validated by a real person.

Guard also includes attack path mapping, which shows you how an attacker could chain multiple vulnerabilities together to reach critical assets. This goes far beyond traditional vulnerability scanning by modeling actual attacker behavior and prioritizing risks based on realistic attack scenarios.

For PCI DSS compliance specifically, Guard satisfies 100% of annual penetration testing requirements while also providing continuous monitoring between formal assessments. You can demonstrate to your QSA that you’re not just meeting the minimum standard, you’re maintaining security awareness year-round.

The managed service model means you don’t need to hire and retain a full offensive security team internally. Praetorian provides the expertise, tools, and processes, and you get the results. This is especially valuable for organizations with limited security resources or those that need to focus their internal teams on remediation rather than testing.

Frequently Asked Questions