PCI DSS 4.0 Penetration Testing Requirements Explained
Unlike SOC 2 and ISO 27001, PCI DSS is explicit about penetration testing. If you store, process or transmit cardholder data, or can affect the security of the cardholder data environment (CDE), requirement 11.4 applies to you.
The core requirements in 11.4
PCI DSS v4.0 groups penetration testing under requirement 11.4. In summary:
- A defined methodology (11.4.1). You must document a penetration testing methodology that is based on industry-accepted approaches, covers the entire CDE perimeter and critical systems, includes application and network layer testing, and defines how findings are handled.
- Internal testing (11.4.2). At least once every 12 months and after any significant infrastructure or application change.
- External testing (11.4.3). At least once every 12 months and after significant change.
- Remediation (11.4.4). Exploitable vulnerabilities and security weaknesses must be corrected and the corrections verified by retesting.
- Segmentation testing (11.4.5 and 11.4.6). If you use segmentation to reduce PCI scope, test that it works at least every 12 months for merchants, and every six months for service providers, plus after changes to segmentation controls.
- Multi-tenant service providers (11.4.7). Support customers' ability to perform external penetration testing.
Testing must be performed by a qualified internal resource or a qualified external third party, and the tester must be organisationally independent.
What "significant change" means
PCI DSS leaves room for interpretation, but common examples include new internet-facing applications, changes to network architecture or firewall rules affecting the CDE, major application releases touching payment flows, and operating system or platform upgrades. Document your definition so your assessor can see you applied it consistently.
Application-layer testing matters
Many breaches of payment environments happen through the web application, not the network. Requirement 11.4.1 explicitly includes application-layer testing, which means covering at least the vulnerabilities listed in requirement 6.2.4: injection, attacks on data structures, cryptographic weaknesses, business logic abuse, access control bypass and others.
Reducing scope reduces testing
The simplest way to make PCI testing lighter is to reduce the CDE. Using a hosted payment page or tokenisation from a payment provider means card data never touches your servers, and your scope shrinks dramatically. You will still have obligations, particularly around the integrity of the page that loads the payment form, but far fewer systems to test.
Evidence your assessor will want
- Your documented testing methodology.
- Internal and external test reports from the last 12 months.
- Segmentation test results, if applicable.
- Evidence of remediation and retesting.
- Records showing testing followed significant changes.
Continuous testing between assessments
Twelve months is a long time in a codebase. Automated, continuous testing of your internet-facing applications and APIs catches issues introduced between formal tests, so your annual test confirms good hygiene instead of discovering a year of problems. SecurityInfinity runs OWASP Top 10 and API testing with verified findings and fixes. Start free.
Frequently asked questions
Does a vulnerability scan satisfy 11.4?
No. PCI DSS treats vulnerability scanning (11.3) and penetration testing (11.4) as separate requirements. You need both.
Do SAQ A merchants need a penetration test?
Merchants eligible for SAQ A, who fully outsource payment pages, generally do not have requirement 11.4 in scope, but rules differ by SAQ type. Confirm with your acquirer or QSA.
Who can perform PCI penetration tests?
A qualified internal resource or external third party that is organisationally independent of the systems being tested. PCI DSS does not mandate a specific certification.