If your organisation processes, stores, or transmits cardholder data, meeting PCI DSS penetration testing requirements isn’t optional, it’s a core part of staying compliant. Yet many businesses struggle to pin down exactly what’s expected: which systems fall in scope, how often tests must run, and what methodology satisfies an assessor. Getting any of these wrong can mean a failed audit or, worse, a breach that could have been caught.
PCI DSS v4.0 raised the bar on penetration testing standards, introducing stricter segmentation checks and more clearly defined expectations for both internal and external testing. Understanding these changes matters, not just for passing your next assessment, but for genuinely reducing risk across your payment environment. The requirements are specific, and they demand a structured, documented approach from qualified testers.
At TrustedIA, we deliver penetration testing as part of our managed cybersecurity services, helping businesses across the UK meet compliance obligations including PCI DSS and ISO 27001. With over 30 years of experience and a solution-agnostic approach, we focus on what actually strengthens your security posture, not on ticking boxes. This guide breaks down the full scope, frequency, and technical standards you need to satisfy PCI DSS penetration testing requirements, so you know exactly what’s expected before your next assessment.
What PCI DSS requires from penetration testing
PCI DSS v4.0 places penetration testing under Requirement 11.4, which mandates that you actively test your systems against real-world exploitation techniques. The standard goes beyond automated vulnerability scanning: a scan detects known weaknesses, but a penetration test attempts to exploit them, demonstrating the actual risk an attacker could realise. Understanding this distinction is essential before you plan any assessment.
Requirement 11.4 in plain terms
Requirement 11.4 sets out several specific obligations you must meet. You must conduct both external and internal penetration tests against your cardholder data environment at least once every 12 months, and again after any significant infrastructure or application change. Tests must cover both the network layer and the application layer, ensuring no attack surface is ignored. Your organisation must also follow an industry-accepted methodology, such as those published by NIST or OWASP, to ensure tests are consistent and rigorous.
Auditors will expect you to show that your chosen methodology is documented, repeatable, and aligned with a recognised industry standard, not simply that a test occurred.
Who can perform the test
Your tester must be organisationally independent from the systems being assessed, meaning they must not manage or maintain anything within scope. You can use a qualified internal resource or an external specialist, but either option requires demonstrable expertise and no conflict of interest in the outcome. For most organisations, an external provider offers the clearest independence and the most credible evidence for assessors.
Qualifications your tester should be able to evidence include:
- Relevant certifications such as OSCP, CREST, or CHECK
- Documented methodology and testing approach
- Prior experience with PCI DSS scoped environments
Segmentation testing
If you use network segmentation to reduce your PCI DSS scope, Requirement 11.4.5 requires you to validate that segmentation actually works. You must confirm that systems outside your cardholder data environment cannot access cardholder data. This test must run at least annually and after any changes to segmentation controls, and assessors treat it as a distinct requirement from your main penetration test.
Define scope for your PCI DSS pen test
Scoping is the most consequential step in any PCI DSS penetration testing requirements exercise. Define it too narrowly and your assessor will question the validity of results; define it too broadly and you waste budget on systems that pose no risk to cardholder data. Getting scope right from the start saves time and produces test results your QSA will accept without challenge.
What falls inside scope
Your cardholder data environment (CDE) sits at the centre of your scope. Every system component that stores, processes, or transmits cardholder data falls in scope automatically, as does any system that can connect to those components. That typically includes:
- Network infrastructure and firewalls
- Web applications that handle payment data
- Databases and authentication systems connected to your CDE
How to tighten scope effectively
Segmentation is the primary tool you have to reduce scope. If you isolate your payment systems from the rest of your network using firewalls or VLANs, the components sitting outside that boundary may fall out of scope. Document each control clearly, because your tester will need to validate the boundary holds as part of their assessment.
Weak or undocumented segmentation expands your scope rather than limiting it, and assessors will test that boundary directly.
Set the right frequency and trigger events
PCI DSS penetration testing requirements set a clear minimum cadence, but the standard also recognises that your environment changes throughout the year. Sticking only to the annual schedule without accounting for those changes puts your compliance at risk between assessments.
Annual testing cycle
Your baseline obligation is to run both external and internal penetration tests at least once every 12 months. That 12-month clock does not reset from your QSA assessment date; it resets from the date the previous test concluded. Keep that distinction clear when you schedule your programme, otherwise you can drift out of compliance without realising it. Your assessor will check test dates against the evidence you submit, so maintain a clear testing calendar that your team reviews quarterly.
Events that trigger an additional test
Certain changes inside your environment require you to run a fresh penetration test regardless of when your last one occurred. PCI DSS v4.0 is explicit about this. The following events each constitute a significant change that triggers retesting:
- Adding or replacing network infrastructure within your cardholder data environment
- Deploying a new web application that handles payment data
- Changing firewall rules or segmentation controls
- Migrating systems to a new hosting environment or cloud platform
Waiting until your next scheduled test after a significant change is not compliant; the new test must specifically cover the changed components.
Build a process that flags these events to your security team automatically, so no trigger slips through unnoticed.
Run the test to meet PCI DSS standards
Once your scope and schedule are confirmed, the test itself must follow a structured methodology that satisfies PCI DSS penetration testing requirements. Your tester should begin with reconnaissance and threat modelling, mapping the attack surface before attempting any exploitation. This phase shapes the entire engagement, so treat it as foundational rather than optional.
Cover both network and application layers
PCI DSS Requirement 11.4 explicitly demands testing at both the network layer and the application layer. Network-layer testing examines your infrastructure, firewalls, and routing controls for exploitable weaknesses. Application-layer testing focuses on any web-facing system that handles payment data, checking for vulnerabilities such as injection flaws, broken authentication, and insecure data exposure.
Skipping application-layer testing is one of the most common reasons organisations fail a PCI DSS assessment, even when their network-layer results look clean.
Your tester should follow a recognised methodology such as OWASP for application testing or NIST SP 800-115 for technical guidance across both layers. This gives your QSA confidence that the approach is consistent and repeatable.
Validate and close findings
After testing concludes, your tester must provide a full findings report ranked by risk, with remediation guidance for each issue. You are then required to address identified vulnerabilities and confirm that fixes hold. Running a targeted retest after remediation gives auditors the evidence they need to verify your environment is secure, not just assessed.
Document evidence auditors expect to see
Passing your assessment depends as much on your documentation as on the test itself. Auditors reviewing PCI DSS penetration testing requirements compliance need a complete evidence trail showing what was tested, how findings were handled, and that your environment was validated after remediation.
The penetration test report
Your tester must deliver a detailed written report covering the full scope, methodology, and findings of the engagement. Auditors will look for risk-ranked vulnerabilities, clear evidence that both network and application layers were assessed, and confirmation that the tester meets the independence requirements under Requirement 11.4.
A report that simply lists tools used without demonstrating actual exploitation attempts will not satisfy a QSA.
Key items your report must include:
- Scope definition and system components tested
- Methodology reference (e.g., NIST or OWASP)
- Findings ranked by risk severity
- Evidence of tester qualifications and independence
Remediation records and retest results
Once you address findings, you need written evidence that each vulnerability was resolved. Your remediation records should map directly back to specific findings in the original report, referencing the issue and the fix applied.
Auditors also expect a retest report confirming that remediation held under renewed testing conditions. Keep both documents together so your QSA can trace the full lifecycle of each finding from discovery through to closure without having to chase your team for missing records.
Next steps to stay compliant
Meeting PCI DSS penetration testing requirements comes down to three things: a defined scope, a qualified tester, and complete documentation that holds up under QSA scrutiny. Start by mapping your cardholder data environment and confirming your segmentation controls are in place before you engage a tester. Without that groundwork, your test scope will shift mid-engagement and delay your results.
Once your test concludes, prioritise remediation based on risk severity and schedule a retest before your evidence pack goes to your QSA. Build a compliance calendar that tracks your annual test dates and trigger events, so nothing catches you off guard between assessments. Review that calendar every quarter and update it whenever your environment changes significantly.
TrustedIA delivers structured penetration testing aligned with PCI DSS standards, backed by over 30 years of cybersecurity experience across UK businesses. If you want expert support from scoping through to remediation, speak to our penetration testing team to plan your next assessment.
