PCI DSS v4.0.1 Pentest Checklist — 12 Requirement-by-Requirement Tests

Published May 20, 2026 · 16 min read · By AxVeil Compliance

Hero: scope, CDE, and what this checklist covers

A PCI DSS v4.0.1 penetration test is not one test — it is a coordinated programme of external, internal, application-layer, and segmentation exercises whose combined output satisfies requirement 11.4 and feeds evidence into every other requirement family. This checklist walks the entire estate, requirement by requirement, showing the specific tests that prove each control is operating, the tooling that produces defensible artefacts, and the evidence a Qualified Security Assessor (QSA) expects to see during fieldwork. For background on the v4.0 changes that drove this checklist, read our earlier post on the v4.0 changes affecting your 2026 audit and pair this checklist with a structured VAPT engagement.

Scope first. The Cardholder Data Environment (CDE) is defined in the v4.0.1 glossary as the people, processes, and technology that store, process, or transmit cardholder data (CHD) or sensitive authentication data (SAD), and any system component that is connected to or has the ability to affect the security of the CDE. That second clause is where most engagements blow their budget: jump hosts, identity providers, DNS, log collectors, deployment pipelines, monitoring agents, and configuration management tools are all in scope by virtue of connectivity, not data handling. Build the cardholder data flow diagram before you write the pentest statement of work. Tokenisation, P2PE, and segmentation are the three levers that shrink scope — apply them before you scope the test, not after the QSA challenges your boundary.

The deliverables expected from a v4.0.1 pentest are: an executive summary mapped to PCI requirements, a technical report with reproducible findings, evidence of exploitation where successful, a segmentation assessment report, a remediation tracker with owners and dates, and a retest attestation closing the loop on every high and critical finding. Anything less and the QSA will reopen the engagement.

Requirement 11.4 — the pentest mandate (timing, segmentation, methodology)

Requirement 11.4 is the heart of this checklist. Its sub-requirements set the rules every other requirement-family test must obey:

• 11.4.1 — A documented penetration-testing methodology must exist, must reference an industry-accepted approach (PTES, OWASP WSTG, NIST SP 800-115, OSSTMM), and must define scope, retention, threat actor model, and tester independence rules.
• 11.4.2 — Internal penetration testing at least every 12 months and after significant change. Internal testing must demonstrate that an attacker with a foothold inside the corporate network cannot pivot into the CDE.
• 11.4.3 — External penetration testing at least every 12 months and after significant change, performed by a qualified internal resource or external party with organisational independence.
• 11.4.4 — Exploitable findings must be corrected and the relevant tests repeated to verify the correction. No "risk accepted" for any finding that exposes CHD.
• 11.4.5 — Segmentation controls separating the CDE from out-of-scope networks tested at least every 12 months (every 6 months for service providers) and after any change to segmentation controls.
• 11.4.6 — Service providers test segmentation every six months.
• 11.4.7 — Multi-tenant service providers support customer penetration testing or attest equivalent coverage.

Timing. The 12-month clock is calendar, not from-the-last-audit. Build the pentest into your change calendar so a major release does not trigger an unplanned re-test. Significant change is defined by the entity, in a written change-management policy, and the QSA will test that definition. A useful working definition: any change that introduces a new ingress path to the CDE, modifies authentication or authorisation logic, deploys a new payment flow, alters segmentation controls, or replaces a primary cryptographic library.

Methodology.Document tester qualifications (OSCP, CREST CRT, GIAC GPEN, GXPN, GWAPT, GMOB), independence (testers are not the engineers who built the system), tooling versions, time-bounding, and rules of engagement. The methodology should explicitly cover OWASP Top 10 2026, MITRE ATT&CK enterprise techniques, and CIS Controls IG3 procedures. See our OWASP Top 10 2026 checklist for the web-app procedures that belong in your methodology document.

Requirement 1 — Install and maintain network security controls

Network security controls (NSCs, formerly "firewalls") are the first layer of CDE protection. Pentest activities prove that ruleset, change management, and stateful inspection actually deliver the policy on paper.

• Tests: external port scanning against every advertised CDE-adjacent address (TCP 1-65535, top 1000 UDP); ruleset review against the dataflow diagram looking for any-any rules and stale rules; egress filtering tests from inside each segment to attacker-controlled C2 endpoints (HTTPS, DNS, ICMP, SMB); IPv6 dual-stack reachability tests; NAT traversal and split-tunnel exposure validation.
• Tooling: nmap with version probing and NSE, masscan for breadth, naabu, RouterSploit for vendor ruleset issues, FireMon or Tufin reports cross-checked, Burp Collaborator for egress beacons.
• Evidence: exported nmap XML, screenshots of allowed/blocked egress flows, ruleset diff against the previous review, list of NSCs in scope with version and last change date.

Requirement 2 — Apply secure configurations to all system components

Default credentials, default ports, and unhardened images are still the highest-velocity initial-access vectors on the 2026 threat landscape. Configuration testing under requirement 2 proves that golden images, baseline standards, and post-deployment hardening have all happened.

• Tests: default-credential sweeps against every administrative interface; CIS Benchmark drift assessment on a sampled host per OS family; unauthenticated service enumeration to detect debug interfaces, JMX, RMI, kubelet, Docker remote API; TLS configuration scan (cipher suites, certificate validity, HSTS); cloud workload baselines via CSPM.
• Tooling: Lynis, OpenSCAP, CIS-CAT Lite/Pro, ssh-audit, testssl.sh, Trivy for container images, kube-bench for Kubernetes, Prowler/ScoutSuite for cloud.
• Evidence: CIS benchmark scores per asset class with PASS/FAIL counts, list of administrative interfaces with authentication evidence, TLS scan output, hardening checklist sign-off per platform.

Requirement 3 — Protect stored account data

Requirement 3 is about cryptography at rest, PAN truncation, and SAD prohibition. The pentester verifies that stored data cannot be exfiltrated in clear form and that key custody actually works.

• Tests: attempt to retrieve PAN from application databases via SQLi, IDOR, and admin-panel pivots; inspect log files, backup buckets, and DLQs for unmasked PAN; verify SAD (track data, CVV2, PIN) is not stored anywhere post-authorisation; test key access controls (split-knowledge, dual-control for KEKs); attempt HSM key export through application APIs.
• Tooling: sqlmap, Burp Suite Pro, Trufflehog and gitleaks for cred/PAN in repos, ripgrep with PAN regex (with Luhn check) across log shippers, cloudsplaining for IAM key exposure, HSM client libraries with deliberate misuse.
• Evidence: proof of retrieval attempts (success or denial), regex scan results across logs/backups, list of key custodians with dual-control attestation, HSM access log sample.

Requirement 4 — Protect cardholder data with strong cryptography during transmission

• Tests: TLS version and cipher enumeration across every CDE endpoint and every supporting service (SMTP, IMAP, MQ); certificate trust chain validation; certificate pinning bypass attempts on mobile and thick clients; downgrade attacks (POODLE, LOGJAM, FREAK); MITM on internal transmission paths to prove encryption envelopes are end-to-end.
• Tooling: testssl.sh, sslyze, mitmproxy, Frida for mobile pinning, Wireshark for capture validation, Burp Suite for HTTPS interception.
• Evidence: sslyze JSON output per endpoint, list of TLS 1.0/1.1 endpoints (must be zero), certificate inventory with expiry, pinning bypass attempts logged.

Requirement 5 — Protect all systems and networks from malicious software

• Tests: drop benign EICAR and AMSI test payloads across endpoints and prove detection; submit Metasploit and Cobalt Strike beacon variants to confirm EDR catches both known and obfuscated samples; test bypass routes (script-block-logging disabled, AMSI patched, ETW disabled); validate periodic evaluation of systems not at risk (11.5 cross-references).
• Tooling: Atomic Red Team, Caldera, MalwareBazaar samples (in isolated lab), AMSI-Bypass test suites.
• Evidence: EDR alert IDs per test, MTTA and MTTR for the lab samples, list of exclusions reviewed and justified.

Requirement 6 — Develop and maintain secure systems and software (6.4.1, 6.4.2 web-app pentest)

Requirement 6 is the application-security family and contains two sub-requirements that depend explicitly on the pentest output: 6.4.1 (review public-facing web applications via manual or automated application vulnerability assessment tools or methods at least every 12 months, after significant change, by an organisation with the appropriate skills) and 6.4.2 (an automated technical solution like a web application firewall is installed in front of public-facing web applications and continually inspects all traffic). The pentest is what produces evidence for 6.4.1 and validates 6.4.2.

• Tests: full OWASP WSTG coverage with authenticated and unauthenticated sessions; injection (SQLi, NoSQLi, OS, LDAP, XXE, SSTI); broken access control across horizontal and vertical IDOR; SSRF with metadata endpoint access attempts; deserialisation across Java/.NET/Python; business-logic abuses (price tampering, coupon stacking, refund loops); WAF evasion to prove 6.4.2 holds against modern payloads.
• Tooling: Burp Suite Pro with custom extensions, ZAP, sqlmap, ffuf for content discovery, nuclei templates (see our nuclei templates explainer), Postman/Insomnia for API harnesses, OWASP CRS rule set as a sanity baseline.
• Evidence: per-finding HTTP request/response with markup, CVSS v4.0 score, WAF block-or-bypass screenshot, retest result, OWASP ASVS L2 mapping for every tested control.

For consumer-facing checkout flows, pair this pentest with the script-management testing from requirement 6.4.3 — your D2C estate is the most-attacked surface in PCI scope, and our D2C ecommerce playbook walks the additional controls.

Requirement 7 — Restrict access by business need to know

• Tests: least-privilege validation by enumerating effective permissions per role; attempt privilege escalation by impersonating a low-privilege role and accessing admin endpoints; test role-based access controls in the application, the database, the cloud account, and the directory service; review service-account scoping.
• Tooling: BloodHound for AD, Azure AD PIM reports, AWS IAM Access Analyzer, GCP Policy Analyzer, Burp Autorize plugin for application IDOR sweeps.
• Evidence: matrix of role → resource → permission with at-least-one violation noted (and remediated), BloodHound graph screenshots, IAM Access Analyzer findings with closure dates.

Requirement 8 — Identify users and authenticate access (8.3, 8.4 MFA, 8.6 application/system accounts)

v4.0 introduced 8.3.6 (12-character passwords), 8.4.2 (MFA for all CDE access), 8.4.3 (MFA for remote access), and 8.6 (application and system account access). The pentester is responsible for proving that the authentication implementation matches the policy.

• Tests: password-policy enforcement (length, complexity, history, reuse); MFA-bypass attempts (cookie reuse, MFA fatigue, recovery-flow abuse, session-fixation, downgrade to legacy auth); SSO assertion tampering (SAML signature wrapping, OIDC iss/aud confusion); service-account credential discovery (config files, CI variables, secrets managers); kerberoasting, AS-REP roasting where AD is in CDE-adjacent scope.
• Tooling: Hydra and Patator for online brute force (lab only, with strict throttling), hashcat for offline; CrackMapExec, Impacket, GoPhish for MFA-fatigue simulation; SAML Raider, jwt_tool for token testing; trufflehog for repo secrets.
• Evidence: account lockout proof, MFA bypass attempts (success or failure), list of accounts with MFA exempted and justification, service-account inventory with last rotation date.

Requirement 9 — Restrict physical access to cardholder data

• Tests: if the CDE has physical components (terminals, POS, on-prem servers, datacentre cages), perform a physical walk-through covering badge tailgating, visitor escort enforcement, server-cage locks, media disposal, surveillance retention; for fully-cloud CDEs, validate the cloud provider attestation (AOC) covers physical controls; test point-of-interaction (POI) tamper indicators.
• Tooling: physical assessment checklist, badge cloners (RFID/HID) under authorised RoE only, lock-picking kit for documented physical assessment, photographs as evidence.
• Evidence: physical assessment report, photograph package, list of POI devices with tamper-check records, cloud-provider AOC referenced.

Requirement 10 — Log and monitor all access

• Tests: generate detection-relevant events during the pentest (privilege escalation, credential brute force, lateral movement, data exfiltration to attacker C2) and verify each generates an alert with the correct severity in the SIEM; tamper with logs to test log-integrity controls; verify time synchronisation with documented NTP sources; check log retention covers 12 months online and 3 years archived.
• Tooling: Atomic Red Team for parametric attack simulation, the blue team's detection ruleset reviewed against MITRE ATT&CK coverage, chrony/ntpdate for time drift checks.
• Evidence: attack timeline aligned to SIEM alert timeline with MTTA, list of unalerted events (must be zero for critical TTPs), log retention attestation from storage admin.

Requirement 11 — Test security of systems and networks regularly (11.3 authenticated scans, 11.4 pentest, 11.4.5 segmentation)

This is the requirement-family that the entire checklist serves. Three sub-areas need pentest-quality evidence:

• 11.3.1.1 authenticated internal scans: internal vulnerability scans with valid credentials so the scanner sees every installed package, patch level, and misconfiguration. Tools: Tenable Nessus Professional, Qualys VMDR, Rapid7 InsightVM. Evidence: scan policy showing authenticated credentials, scan logs proving credential acceptance per asset, finding remediation tracker with rescan attestation for every CVSS ≥ 7.0 issue.
• 11.3.2 external ASV scans: quarterly external scans by a PCI-approved scanning vendor. Pentest validates the ASV scope matches the public attack surface (no shadow assets).
• 11.4.5 segmentation testing: from each non-CDE network segment, run the full L3-L7 reachability matrix against the CDE; document allowed and blocked flows; prove that segmentation policy on paper matches enforcement in fabric. Service providers repeat every six months under 11.4.6.

Segmentation-pentest deliverable. Build a reachability matrix with one row per non-CDE source segment and one column per CDE service. Each cell is colour-coded green (blocked at L3, expected), amber (allowed at L3 but blocked at L7), or red (reachable, unexpected). Red cells are findings; the QSA reads this matrix first.

Requirement 12 — Support information security with organisational policies and programmes

• Tests: social-engineering simulation (phishing, vishing, in-person impersonation) within the rules of engagement; tabletop incident response exercise covering a CHD breach scenario; review targeted risk analyses (12.3.1, 12.3.2) for completeness; verify customised-approach documentation matches deployed controls; sample contractor access against the same 8.x controls applied to employees.
• Tooling: GoPhish, Evilginx2 for phishing simulation; pretexting scripts with on-record consent; tabletop scenarios from our tabletop templates library.
• Evidence: phishing-campaign report with click-through, credential-entry, and reporting rates; tabletop minutes and action log; targeted risk analysis register with review dates; contractor access review evidence.

Authenticated scans under 11.3.1.1 — what changes for the pentest team

v4.0 explicitly requires internal vulnerability scans to be authenticated. That is a step-change for many organisations: it requires distributing scan credentials safely, ensuring credentials have read-only system inspection rights without administrative privilege, and proving the scanner used them. The pentester verifies the implementation by running unauthenticated and authenticated scans against the same sample of hosts and comparing finding counts — the authenticated scan must produce materially more depth (typically 5-20x more findings). Anything less and the credentials are not actually being used. Document credential rotation, vault integration, and the privileged-account audit trail in the evidence pack.

New v4.0/v4.0.1 requirements that affect pentest evidence

• Customised approach (12.3.2): any control implemented via the customised approach must have a targeted risk analysis, a customised approach objective, a description of the customised control, and the assessor testing procedure. The pentest must specifically exercise the customised control.
• Targeted risk analysis (12.3.1): any control performed at a frequency the standard does not prescribe — file-integrity-monitoring cadence, certain log reviews, password-change frequency — needs a written TRA. The pentest team should request the TRA register and confirm coverage.
• Authentication methods (8.3.6, 8.4.2, 8.4.3, 8.6.1): 12-character passwords, MFA on all CDE access including system and application accounts. Pentest evidence: every account class proven to require MFA, every service account scoped and audited.
• Payment-page script management (6.4.3) and tamper detection (11.6.1): covered in detail in our v4.0 changes article; the pentest validates SRI hashes, CSP enforcement, and weekly tamper-check coverage.

QSA evidence pack — what to hand over on day one

Build the evidence pack as a folder tree mirroring the requirements. Hand it to the QSA on the first day of fieldwork. A complete v4.0.1 pentest evidence pack contains:

• Executive summary (2-3 pages) mapping pentest findings to PCI requirements with risk ratings.
• Scope statement matching the cardholder data flow diagram and including every system in the CDE plus connected systems.
• Pentest methodology document referencing PTES / OWASP WSTG / NIST SP 800-115 with tester qualifications.
• Per-requirement test logs (request/response, screenshots, command output) named by requirement ID.
• Segmentation reachability matrix with target lists, source segments, and per-cell evidence.
• Authenticated scan reports with credential-acceptance proof and rescan attestation.
• Application pentest report with OWASP ASVS L2 mapping per finding.
• Remediation tracker (Jira/Linear export) with owner, severity, fix date, retest date, retest result.
• Targeted risk analysis register, customised approach documentation (if any), TRA review dates.
• Tester independence statement and rules of engagement (signed).
• Retest attestation signed by the test lead closing every high/critical finding.

For RFP-stage vendors, our pentest RFP template includes the evidence-pack contract terms that force vendors to deliver this on completion.

Scoping and applicability worksheet

Before kickoff, complete a one-page scoping worksheet so both pentester and QSA agree on the boundary. The worksheet asks five questions per asset class:

1. Does the asset store, process, or transmit CHD or SAD? (CDE-in if yes)
2. Is the asset connected to a CDE system at L3, L4, or L7? (CDE-connected if yes)
3. Does the asset provide security services to the CDE (logging, IAM, NTP, DNS, monitoring)? (CDE-supporting if yes)
4. What is the cardinality (1, sample of 10, sample of 25, all)? Sample-based testing follows the QSA sampling guidance for 25-40 instances per control.
5. Which test type applies (external, internal, application, segmentation, social engineering)?

The output is a single table that becomes the appendix of the pentest report. The QSA uses it to verify that no in-scope asset escaped testing. Pair the worksheet with our scoping checklist when scoping and our compliance advisory when you need a second pair of eyes on boundary decisions.

Common QSA findings on v4.0.1 pentest evidence

• Scope mismatch — the dataflow diagram lists more systems than the pentest covered.
• Authenticated-scan credentials present but unused — finding counts identical between auth and non-auth runs.
• Segmentation testing performed only at L3 — no L7 reachability proof.
• No retest attestation for high-severity application findings closed mid-engagement.
• Targeted risk analyses missing for every frequency-based control the entity chose.
• Customised-approach documentation citing the objective but no assessor testing procedure.
• Tester independence not documented — the same engineer who built the system performed the test.

Programme cadence — fitting the pentest into the year

A realistic v4.0.1 pentest cadence for a typical merchant-aggregator looks like: external pentest in Q1, internal pentest in Q2, segmentation pentest in Q2 and Q4 (service providers), application pentest tied to release cycles with at minimum one full assessment in Q3, authenticated scans every quarter with monthly patch-cycle rescans, and the QSA fieldwork in Q4. Add re-tests after every significant change. The cadence is heavy — automation, retainer-based testing, and a structured remediation workflow are what make it tractable. Our VAPT retainer programmes are designed around exactly this cadence.

Frequently asked questions