Scoping a PCI DSS penetration test for a Level 1 merchant means mapping the entire cardholder data environment (CDE) — every system, network segment, and application that stores, processes, or transmits card data — then testing external attack surface, internal segments, segmentation controls, and application layer under PCI DSS Requirement 11.4. Miss the CDE boundary and the test produces a report a Qualified Security Assessor (QSA) will reject at audit time, forcing a costly re-test cycle.
TL;DR
- Level 1 merchants (6M+ transactions annually) require PCI DSS 4.0 penetration testing across the full CDE, not a generic web app scan.
- External and internal tests are mandatory at least once every 12 months and after any significant change, per Requirement 11.4.
- Segmentation testing follows the same 12-month cycle for merchants, but service providers must retest every 6 months.
- Testers must be qualified and organizationally independent — internal red teams rarely satisfy this alone.
- AppSecure Security scopes CDE boundaries, segmentation controls, and payment application layers together to close 11.4 gaps before a QSA finds them.
Why Scoping Correctly Matters for Level 1 Merchants
Level 1 status is not a badge — it is a compliance tier that carries a mandatory annual Report on Compliance (RoC) signed by a QSA, not a self-assessment questionnaire. A scoping error at the start of the engagement cascades into every downstream deliverable: the RoC, the Attestation of Compliance, and any acquiring-bank remediation timeline.
Under-scoping is the most common finding AppSecure Security sees during PCI DSS penetration testing engagements in 2026: merchants exclude a segment because "it doesn't touch card data," then discover during the test that the segment routes to a payment API through a shared jump host. That single oversight can invalidate the whole assessment.
Over-scoping carries its own cost. Testing systems outside the CDE burns engagement hours a Level 1 merchant needs for the mandatory external, internal, and segmentation components — and it inflates the invoice without reducing audit risk.
How Do You Scope a PCI DSS Penetration Test for Level 1 Merchants?
Scope starts with a data-flow diagram, not a network diagram. Every location where a Primary Account Number (PAN) is stored, processed, or transmitted defines the CDE boundary, and every system with connectivity into that boundary is in scope by association unless segmentation controls prove otherwise.
The table below breaks down what PCI DSS 4.0 actually requires, mapped to the four testing components a Level 1 scope must include.
External network & application
- PCI DSS Requirement: 11.4.3
- Frequency: Annual + after significant change
- Standard Methodology: PTES / OWASP
Internal network & application
- PCI DSS Requirement: 11.4.2
- Frequency: Annual + after significant change
- Standard Methodology: PTES
Segmentation validation
- PCI DSS Requirement: 11.4.5 (11.4.6 for service providers)
- Frequency: Annual; 6 months for service providers
- Standard Methodology: NIST SP 800-115
Payment application layer (in-CDE apps)
- PCI DSS Requirement: 11.4.2/11.4.3 combined with 6.4.1
- Frequency: Annual + after major release
- Standard Methodology: OWASP ASVS
A scope document for a Level 1 merchant should name every in-scope IP range, every application URL, every third-party connection point (payment gateway, tokenization service, PSP integration), and every segmentation control claimed to reduce scope. Anything not named is either explicitly out or silently missed — there is no middle ground a QSA will accept.
Requirement 11.4.2: Internal Penetration Testing Scope
Internal testing covers every network segment inside the CDE plus any segment with a documented trust relationship to it — domain controllers, jump hosts, backup systems, and monitoring infrastructure included. Testers need valid internal network access, not just external footholds, because lateral movement from a compromised workstation to a payment processing server is exactly the attack path Requirement 11.4.2 exists to catch.
For Level 1 merchants running hybrid environments, internal scope frequently spans data centers and cloud VPCs simultaneously. A test that only covers the data center misses the cloud-hosted payment microservice that talks to the same database.
Requirement 11.4.3: External Penetration Testing Scope
External scope covers every internet-facing IP address, domain, and API endpoint connected to the CDE — public web checkout flows, payment APIs, admin portals, and any exposed management interface. Level 1 e-commerce merchants typically carry the largest external footprint because checkout, cart, and account systems all sit adjacent to card data flows even when tokenization removes raw PAN storage.
External testing under 11.4.3 must simulate an unauthenticated attacker with no internal knowledge, and findings need to demonstrate real exploitability — not just an open port. A payment gateway penetration test run in isolation from the broader CDE external scope leaves gaps a QSA will flag during evidence review.
Requirement 11.4.5: Segmentation Testing Scope
Segmentation testing exists to validate a specific claim: that firewalls, VLANs, or network access controls actually isolate out-of-scope systems from the CDE. If a merchant relies on segmentation to reduce PCI DSS scope, that segmentation must be independently tested at least once every 12 months and after any change to firewall rules, routing, or network architecture.
Service providers face a stricter cadence under 11.4.6 — segmentation testing every 6 months, not 12 — because a failure in a service provider's segmentation exposes every downstream merchant relying on that isolation.
Application-Layer Testing Inside the CDE
Application-layer testing targets the software that actually handles PAN data: checkout forms, tokenization services, payment APIs, and admin consoles. This is where business-logic flaws live — price manipulation, authorization bypass on refund flows, IDOR on order records — and automated scanners consistently miss these because they require understanding what the application is supposed to do, not just what inputs it accepts. Manual testing following an API penetration testing methodology catches privilege-boundary abuse between merchant-tier and admin-tier API roles that a scanner reports as "normal" 200 responses.
Why PCI DSS Scope Varies Between Level 1 Merchants
No two Level 1 scopes look identical. The drivers below explain why one merchant's engagement runs two weeks and another's runs six.
- Transaction channel mix — card-present, e-commerce, and mail/telephone order (MOTO) merchants each carry different CDE topologies, and hybrid merchants combine all three.
- Segmentation architecture maturity — flat networks force full-CDE testing of every connected system; well-segmented networks narrow scope but add mandatory segmentation validation.
- Number of third-party service providers — payment gateways, tokenization vendors, and PSP integrations each introduce a scope boundary that needs to be explicitly tested or explicitly excluded with evidence.
- Cloud vs. on-premises infrastructure — cloud-hosted CDE components add cloud configuration review requirements on top of standard network and application testing.
- E-commerce platform and hosting model — merchants running Magento storefronts face different segmentation math depending on whether their PCI-compliant Magento hosting isolates the payment processing tier from the public web tier, which directly changes how much of the storefront falls inside the CDE.
- Prior audit findings — a Level 1 merchant remediating a prior year's RoC exceptions typically needs targeted retesting on those specific controls in addition to the standard annual cycle.
Who Needs to Be Involved in Scoping?
Scoping a Level 1 engagement is not a security-team-only exercise. The table below maps the stakeholders whose input changes the scope document.
QSA / Internal Compliance Lead
- What They Confirm: CDE boundary, prior RoC exceptions
- Why It Matters: Prevents scope disputes at audit time
Network/Infrastructure Team
- What They Confirm: Segmentation controls, firewall rules
- Why It Matters: Confirms what segmentation testing needs to validate
Application/Engineering Team
- What They Confirm: API endpoints, admin interfaces, release cadence
- Why It Matters: Ensures application-layer scope reflects current architecture
Payment/Finance Team
- What They Confirm: Third-party processors, tokenization vendors
- Why It Matters: Identifies scope boundaries at vendor connection points
Penetration Testing Provider
- What They Confirm: Methodology, evidence format, retest terms
- Why It Matters: Aligns deliverables with what the QSA will accept
How Long Does a Level 1 PCI DSS Penetration Test Take?
Most Level 1 engagements run two to six weeks depending on CDE size, with segmentation validation and application-layer testing typically running in parallel workstreams rather than sequentially. Merchants with multiple data centers, cloud environments, and third-party processor connections sit at the longer end of that range.
Common Scoping Mistakes That Trigger QSA Findings
- Assuming tokenization removes all scope — tokenization reduces PAN storage but the systems that generate, transmit, or reverse tokens usually remain in scope.
- Treating segmentation as permanent — a segmentation control tested last year and never retested after a firewall change does not satisfy 11.4.5.
- Excluding shared infrastructure — jump hosts, backup systems, and monitoring tools connected to the CDE are in scope even if they never touch a PAN directly.
- Using generic web app testers without PCI context — a tester unfamiliar with 11.4.2 through 11.4.6 will miss the segmentation and frequency requirements a QSA specifically checks for.
- Skipping the retest — Requirement 11.4.4 requires that exploitable vulnerabilities found during testing be corrected and the affected test repeated; a report full of open critical findings is not audit-ready.
Scope your PCI DSS Level 1 pentest correctly
Talk to AppSecure about CDE boundaries, segmentation, and 11.4 evidence before your next audit cycle.
Related Questions
Is a PCI DSS Penetration Test Different from a Regular Web App Pentest?
Yes — a PCI DSS penetration test must explicitly cover segmentation validation and follow the 12-month (or 6-month for service providers) retest cadence defined in Requirement 11.4, which a generic web application pentest does not address. It also requires evidence formatted for QSA review, not just a technical findings report.
Can Internal Teams Perform PCI DSS Penetration Testing?
Internal teams can perform some testing only if they meet the organizational independence bar PCI DSS 4.0 requires — the tester cannot report to the team responsible for the systems under test. Most Level 1 merchants use an external, independent provider for at least the required annual assessment to remove any independence question at audit time.
Does PCI DSS 4.0 Change Penetration Testing Requirements from 3.2.1?
Yes — PCI DSS 4.0 restructured penetration testing into Requirements 11.4.1 through 11.4.7, adding explicit segmentation retest cadence for service providers (11.4.6) and multi-tenant provider support obligations (11.4.7) that were less defined under 3.2.1. Merchants migrating from 3.2.1 scoping documents need to re-map against the new sub-requirement numbering.
What Happens If Testing Finds Exploitable Vulnerabilities Before an Audit?
Requirement 11.4.4 requires exploitable vulnerabilities found during testing to be corrected and the affected component retested before the assessment is considered complete. Merchants that treat this as optional typically face a QSA rejecting the RoC until the retest evidence is provided.
FAQ
What counts as a PCI DSS Level 1 merchant in 2026?
A Level 1 merchant processes more than 6 million card transactions annually across a payment brand, or has been designated Level 1 by an acquiring bank following a breach or compliance issue. Level 1 status requires an annual Report on Compliance from a QSA rather than a self-assessment questionnaire.
How often does PCI DSS require penetration testing for Level 1 merchants?
PCI DSS 4.0 requires external and internal penetration testing at least once every 12 months and after any significant change to the environment. Segmentation testing follows the same annual cycle for merchants, but service providers must retest segmentation every 6 months.
Does segmentation testing need to happen every 6 months?
Only service providers face the 6-month segmentation retest cycle under Requirement 11.4.6. Merchants, including Level 1 merchants, follow the standard 12-month cycle under 11.4.5 unless a significant change to segmentation controls triggers an earlier retest.
Can an internal security team perform the required penetration test?
Internal teams can perform testing only if they are organizationally independent from the systems and staff being tested, which is difficult for smaller security teams to demonstrate. Most Level 1 merchants use an external provider for the mandatory annual assessment to avoid independence disputes during the QSA review.
What is the difference between a vulnerability scan and a PCI DSS penetration test?
A vulnerability scan identifies known weaknesses through automated signature matching, while a PCI DSS penetration test requires manual exploitation attempts, segmentation validation, and evidence that findings were actually exploitable. PCI DSS requires both quarterly scans and annual penetration testing as separate, non-substitutable controls.
Does PCI DSS 4.0 change penetration testing requirements from 3.2.1?
PCI DSS 4.0 restructured testing requirements into 11.4.1 through 11.4.7, adding explicit segmentation retest cadence for service providers and clearer multi-tenant provider obligations. Merchants working from older 3.2.1 scope documents need to remap their testing plan against the new numbering.
How long does a Level 1 PCI DSS penetration test take to complete?
Most Level 1 engagements take two to six weeks depending on CDE size, number of segments, and whether cloud and on-premises environments both need coverage. Segmentation and application-layer testing typically run as parallel workstreams to keep the timeline shorter.
What happens if a penetration test finds exploitable vulnerabilities before an audit?
Requirement 11.4.4 requires exploitable vulnerabilities to be corrected and the affected systems retested before the assessment counts as complete. A QSA will not sign a Report on Compliance against a test report showing unresolved critical findings.
One Last Thing
The segmentation test is the component Level 1 merchants underestimate most. It is easy to assume a firewall rule written two years ago still isolates the CDE — but network teams change routing, add VPN tunnels, and provision new VLANs constantly, and none of those changes automatically trigger a segmentation retest unless someone flags it. Build the segmentation retest trigger into your change-management process, not just your annual compliance calendar, and 2026's audit cycle stops being a scramble.
Related Guides
Tejas K. Dhokane is a marketing associate at AppSecure Security, driving initiatives across strategy, communication, and brand positioning. He works closely with security and engineering teams to translate technical depth into clear value propositions, build campaigns that resonate with CISOs and risk leaders, and strengthen AppSecure’s presence across digital channels. His work spans content, GTM, messaging architecture, and narrative development supporting AppSecure’s mission to bring disciplined, expert-led security testing to global enterprises.
.webp)
