By requirement
PCI DSS penetration testing built around Requirement 11.4
PCI DSS v4.0.1 expects a documented methodology, internal and external tests at least every 12 months and after significant change, segmentation testing and retests of fixes. We run that test and give you evidence your assessor can trace.
What it asks for
What Requirement 11.4 actually asks for
Requirement 11.4.1 starts with method, not tools. You need a documented penetration testing methodology based on industry-accepted approaches that covers the whole CDE perimeter and critical systems, tests from inside and outside the network, validates segmentation and scope-reduction controls, includes application-layer testing for at least the vulnerabilities listed in Requirement 6.2.4, and covers network components and operating systems. It must also consider threats and vulnerabilities seen in the last 12 months, define how exploitable findings are risk-assessed and addressed, and keep results and remediation records for at least 12 months.
Requirements 11.4.2 and 11.4.3 then set the cadence: internal and external tests at least once every 12 months and after any significant infrastructure or application upgrade or change, run by a qualified internal resource or qualified third party with organisational independence. The tester does not have to be a QSA or ASV. Requirement 11.4.4 requires exploitable findings to be corrected according to your risk ranking and the test repeated to verify the fixes. Quarterly vulnerability scanning under 11.3 is a separate obligation and does not satisfy 11.4.
11.3.1 and 11.3.2 Vulnerability scanning
Internal scans and external ASV scans are each required at least once every three months. Scans detect known weaknesses automatically; they sit alongside, and never replace, the manual exploitation-led testing required by 11.4.
11.4.1 Penetration testing methodology
Your methodology must be written down and followed, covering the CDE perimeter, critical systems, network and application layers, segmentation, recent threats, a risk-based approach to findings, and 12-month retention of results.
11.4.2 and 11.4.3 Internal and external testing
Test from inside the CDE, into it from internal networks, and against the exposed external perimeter, at least every 12 months and after significant change, using a qualified, organisationally independent tester.
11.4.4 Correction and retesting
Exploitable vulnerabilities and security weaknesses are fixed in line with your risk rankings under 6.3.1, then the penetration test is repeated to confirm the corrections actually work.
11.4.5 and 11.4.6 Segmentation testing
If segmentation reduces scope, test every segmentation control to prove the CDE is isolated from out-of-scope systems: every 12 months for all entities, every six months for service providers, and after changes.
6.4.3 and 11.6.1 Payment page scripts
Payment page scripts must be authorised, integrity-checked and inventoried, and unauthorised changes to scripts and security-impacting HTTP headers detected weekly or per a targeted risk analysis. Testing can check these controls hold up.
What to test
What a Requirement 11.4 test should cover
External perimeter
Every internet-facing system connected to or able to reach the CDE, including remote access, payment pages, APIs and the hosting or cloud services that sit in front of them.
Internal and inside the CDE
Testing from within the CDE and into it from trusted and untrusted internal networks, covering network devices, operating systems, directory services and the paths an attacker would use to reach account data.
Segmentation controls
Each firewall rule set, VLAN, cloud security group or other control you rely on for scope reduction, tested from each out-of-scope segment to confirm it cannot reach the CDE.
Applications and payment flows
Application-layer testing of payment and account-data handling for at least the vulnerability classes in Requirement 6.2.4, plus review of how payment page scripts and headers are controlled.
What you receive
What you receive, and how it supports your assessment
Methodology mapped to 11.4.1
A written methodology showing how each 11.4.1 element is met, which you can adopt or reference so your assessor sees a defined approach rather than an ad hoc test.
Assessor-ready report
Scope, dates, tester details and independence, test approach, and each finding with severity, evidence and reproduction steps, so your QSA or internal assessor can follow what was tested and found.
Retest report
A separate retest documenting which findings were verified as fixed and which remain open, giving you the record 11.4.4 asks for and a clean trail for remediation.
Segmentation results
A statement of each segmentation control tested, from which segments, by which technique and with what outcome, supporting 11.4.5 or 11.4.6 and your scoping decisions.
Common pitfalls
Where PCI DSS penetration testing goes wrong
Mistakes that cost time at audit, and how to avoid them.
Treating a scan as a pentest
A passing ASV scan supports 11.3.2, not 11.4.3. Assessors expect manual testing that attempts exploitation, and a scan-only report rarely demonstrates the methodology 11.4.1 requires.
Partial segmentation testing
Testing a sample of segments or a single firewall leaves scope reduction unproven. Every segmentation control in use needs testing, and service providers must repeat it every six months.
Ignoring significant change
The annual test is a minimum. Testing is also required after any significant infrastructure or application upgrade or change, and new payment flows, cloud migrations or network redesigns may well qualify, so define what counts as significant change before the assessment, not during it.
Findings with no retest
A report full of open findings and no verification of fixes does not meet 11.4.4. Plan remediation time and the retest into the schedule before the assessment window.
Who decides what counts
PXL Security is an independent offensive-security firm, not an auditor, assessor, certification body or regulator. We deliver the testing and the evidence; your auditor, assessor or competent authority decides what they accept. This page is general guidance, not legal advice. We summarise these requirements in our own words from publicly available guidance; always check the exact wording against the official standard before relying on it.
FAQ
Questions we're often asked
Is quarterly vulnerability scanning enough for PCI DSS?
No. Requirement 11.3 covers internal scans and external ASV scans every three months, while Requirement 11.4 separately requires penetration testing to a defined methodology. Scanning identifies known weaknesses automatically; penetration testing attempts to exploit them and chains issues together the way an attacker would.
How often do we need a PCI DSS penetration test?
Internal and external penetration tests are required at least once every 12 months and after any significant infrastructure or application upgrade or change. If you use segmentation, it must be tested every 12 months, or every six months for service providers, and after any change to segmentation controls.
Can our own team perform the test?
PCI DSS v4.0.1 allows a qualified internal resource or a qualified external third party, provided the tester is organisationally independent of the systems being tested. The tester does not have to be a QSA or ASV. Many organisations use an external tester to make independence easy to demonstrate.
We use an embedded payment form and SAQ A. Do payment page scripts still matter?
The January 2025 revision of SAQ A removed Requirements 6.4.3 and 11.6.1 but added an eligibility criterion that your site is not susceptible to script attacks that could affect your e-commerce systems. PCI SSC guidance says merchants with embedded forms can meet this by applying those protections themselves or obtaining confirmation from their PCI DSS compliant payment provider. Confirm your approach with your acquirer.
Is PXL our QSA or ASV?
No. PXL Security is not a QSA, an ASV or any kind of PCI assessor, and we do not validate or certify compliance. We perform the penetration testing that Requirement 11.4 calls for and document it so that your QSA, internal assessor or acquirer can evaluate it.
Is this page compliance or legal advice?
No. It is guidance based on our reading of PCI DSS v4.0.1 and PCI SSC publications. Your QSA, acquirer or payment brand decides how the requirements apply to your environment, so confirm scope and frequency with them before relying on any test.
Services that deliver this
Official sources
- PCI SSC: PCI DSS standard overview
- PCI SSC Document Library (PCI DSS v4.0.1)
- PCI SSC: Request for comments on PCI DSS v4.0.1 (June 2026)
- PCI SSC: Important updates for merchants validating to SAQ A
- PCI SSC: FAQ clarifies new SAQ A eligibility criteria
- PCI SSC: Payment page security and preventing e-skimming
Scope your PCI DSS test.
Send a short description of your environment and goals. A senior tester, not a salesperson, will reply with questions, a proposed approach and a quote.