PCI DSS v4.0.1 Penetration Testing Requirements Guide

Scope	Frequency	What's Required
All systems storing, processing, or transmitting cardholder data — servers, databases, APIs, network devices, and any component with indirect CDE access.	Annual minimum, and after every significant change to infrastructure, applications, or network segmentation.	External network pentest | Internal network pentest | Segmentation testing | Authenticated application testing | Retesting after remediation

PCI DSS compliance level is determined by annual transaction volume. Penetration testing requirements under Req. 11.4 are scope-driven, not level-driven — but compliance level determines assessment format (ROC vs. SAQ) and how testing is validated and enforced.

Criteria	>6M transactions/year or card-brand designated
Validation	Annual on-site QSA-led Report on Compliance (ROC).
Pentest	Mandatory — full Req. 11.4 enforcement. Annual external and internal pentests, segmentation validation, retesting after significant changes. All results reviewed during on-site audit.

Criteria	1M–6M transactions/year
Validation	SAQ D or ROC if required by acquiring bank.
Pentest	Required. SAQ D mandates full Req. 11.4 compliance — same obligations as Level 1. Less enforcement oversight, but liability rests entirely with the merchant.

Criteria	20K–1M e-commerce transactions/year
Validation	Typically SAQ D or SAQ A-EP.
Pentest	SAQ D: full Req. 11.4 testing required. SAQ A-EP: external testing required for components affecting payment page behavior; reduced scope versus SAQ D.

Criteria	<20K e-commerce OR up to 1M non-e-commerce transactions/year
Validation	SAQ A / B / B-IP / C / C-VT, or SAQ D.
Pentest	Only required if using SAQ D or SAQ A-EP. Other SAQs require quarterly vulnerability scans only.

Level	Pentest Required?	Triggering Form	Notes
Level 1	Yes	ROC (QSA-led)	Full Req. 11.4 enforcement
Level 2	Yes	SAQ D or ROC	Same obligations as Level 1
Level 3	Depends	SAQ D or A-EP	A-EP = limited scope; D = full
Level 4	Often not	SAQ A/B/C or D	Only SAQ D or A-EP trigger pentests

For e-commerce merchants that do not directly receive cardholder data but whose website can affect the security of the payment transaction — for example, by loading third-party scripts or iframes on the checkout page.

Applies to merchants that store, process, or transmit cardholder data on systems they control; all service providers; and e-commerce merchants that fully host their own payment pages.

Feature	SAQ A-EP	SAQ D
Cardholder data stored	No	Yes or potentially yes
Cardholder data processed	No	Yes
Payment page hosted by merchant	Yes (affects page / loads scripts)	Yes or full environment
Applies to e-commerce only?	Yes	No — all merchant types
Number of controls	~140+	~300+
Penetration testing required?	Yes (relevant systems)	Yes — full Req. 11.4
Req. 6.4.3 / 11.6.1 apply?	Yes	Yes
Best for	E-commerce using a third-party processor where your site still loads payment scripts or hosts the payment page.	Merchants or service providers handling cardholder data directly, or SaaS platforms processing payments on behalf of clients.

Requirement 11.3 governs automated vulnerability scanning. It is a distinct and separate obligation from penetration testing (Req. 11.4). Both are mandatory; neither substitutes for the other.

Frequency	Quarterly + after any significant environment change.
Performed By	Approved Scanning Vendor (ASV) only — must appear on the PCI SSC ASV list.
Scope	All internet-facing CDE systems. No High-severity findings permitted. Passing ASV report required before assessment closes.

Frequency	Quarterly + after any significant environment change.
Performed By	Qualified internal staff or a third-party provider.
Scope	All in-scope internal systems. Authenticated scanning required per Req. 11.3.3 unless formally documented otherwise.

Applies To	All internal scans under Req. 11.3.2.
Requirement	Scanners must authenticate to target systems. Unauthenticated internal scans do not satisfy Req. 11.3.2 without documented justification. This is a standing requirement.

Frequency	Applied to every scan cycle.
Requirement	Each finding must be assigned a risk rank (High / Medium / Low) based on business impact. The risk-ranking methodology must be documented and consistently applied.

Frequency	As needed after each scan cycle.
Requirement	Vulnerabilities must be remediated and re-scanned to confirm resolution within the same quarter or before assessment closure for High findings.

Req. 11.4 mandates active exploitation testing across all systems in the CDE. All sub-requirements are currently mandatory with no exceptions.

The change-triggered retest requirement is the strongest operational argument for a PTaaS model. Traditional annual pentests work well for baseline compliance, but they create a coverage gap every time engineering ships a significant change between assessment cycles.

Application-layer testing is required under Req. 11.4 for any web application or API that stores, processes, or transmits cardholder data, or that can affect the security of the payment environment. Unauthenticated surface testing does not satisfy this requirement.

Test Area	What Gets Tested	PCI Relevance
Auth and Session Management	Login flows, MFA bypass, session fixation, token expiry, password policy.	Weak auth is the most common initial CDE access vector.
Authorization and Access Control	Horizontal escalation, vertical escalation, IDOR.	Access control failures directly violate Req. 7.
Payment Page and Form Handling	Input validation, SQLi, XSS, form tampering, PAN/CVV leakage in logs.	Any flaw exposing raw cardholder data is a critical PCI finding.
API Security	Auth on all endpoints, rate limiting, mass assignment, IDOR, overly permissive responses.	APIs are the primary attack surface for card data theft in SaaS.
Business Logic Flaws	Price manipulation, checkout bypass, coupon abuse, transaction replay.	Invisible to automated scanners; frequently exploited in e-commerce breaches.
Third-Party Integrations	Script injection via CDN, insecure iframe handling, payment SDK misconfiguration.	Critical for SAQ A-EP — any page loading third-party scripts is in scope.

Approach	Coverage	Meets Req. 11.4?	Best For
Unauthenticated (Black Box)	Public surface only — login page, exposed endpoints.	Not on its own	Initial recon only
Authenticated (Grey Box)	Full app functionality for all logged-in roles.	Yes — required	Standard PCI web app pentest
Authenticated + Source Code (White Box)	Code-level review combined with active exploitation.	Yes — exceeds minimum	Apps that directly store PANs

The Report on Compliance (ROC) is the formal output of a QSA-led on-site assessment. The Self-Assessment Questionnaire (SAQ) is completed by the merchant for lower-volume entities. Both require the same underlying security controls — they differ only in how compliance is validated.

Entity Type	ROC Required?
Merchants — Level 1 (>6M transactions/year)	Yes, required annually
Service Providers — Level 1 (>300K transactions/year or high-risk)	Yes, required annually
Merchants — Levels 2–4	No — SAQ permitted unless acquirer or card brand mandates ROC

Feature	ROC	SAQ
Who completes it	QSA or certified internal auditor	Merchant or service provider
Assessment depth	Comprehensive — all controls with documented evidence	Questionnaire — yes/no responses
Evidence requirement	Documented proof for every tested control	Less evidence required
Pentest validation	Results reviewed by QSA during on-site audit	Merchant self-attests; no QSA review
Who requires it	Card brands and acquiring banks (Level 1)	All other merchants (Levels 2–4)

The PCI SSC requires QSAs to conduct on-site assessments as the default for PCI DSS validation. Remote assessment is permitted only under specific, documented circumstances.