WATCHUR6 // PCI DSS // AUDIT READINESS

v4.0.1 is the only version.
The future-dated requirements are already mandatory.

PCI DSS is a contractual standard enforced by the card brands (Visa, Mastercard, Amex, Discover, JCB) on every merchant, processor, acquirer, issuer, and service provider that touches cardholder data. The transition is complete: v3.2.1 retired March 31, 2024. v4.0 retired March 31, 2025. v4.0.1 is the only currently-active version.

The 51 future-dated requirements from v4.0 became mandatory March 31, 2025 with no grace period. The 64 new or updated requirements vs v3.2.1 are now all enforceable. The most consequential changes for e-commerce: Requirement 6.4.3 (payment-page script inventory and integrity monitoring) and Requirement 11.6.1 (page-change detection) — the Magecart-defense controls that apply even to SAQ A merchants embedding hosted iframes.

Your merchant level (1 through 4) determines whether you submit a Self-Assessment Questionnaire or undergo a Qualified Security Assessor-led Report on Compliance. The level is set by your annual transaction volume across all card brands and channels — aggregated, not channel-specific.

Book a PCI DSS Strategy Call
★ PCI DSS v4.0.1 ⌖ 12 REQUIREMENTS / 6 DOMAINS / 51 FUTURE-DATED LIVE ⚐ QSA-COORDINATED ✓ VETERAN-LED

// THE CARD BRAND ENFORCEMENT REALITY

PCI is just paperwork the acquirer wants.
It's the contract that keeps you connected to the card networks — and a breach without compliance can end your merchant account.

PCI DSS is not a regulatory framework. There is no PCI regulator and no government enforcement. It is a contractual standard embedded in every merchant agreement, processor agreement, and acquiring relationship in the card payment ecosystem. Compliance is enforced by the card brands (Visa, Mastercard, Amex, Discover, JCB) through the acquirers who issue your merchant ID and process your transactions.

The enforcement mechanics matter because the consequences of non-compliance are not regulatory fines — they are contractual. After a breach involving cardholder data, an acquirer can impose direct financial penalties (often $5,000 to $100,000 per month until remediated), increased transaction-processing fees, mandatory PCI Forensic Investigator (PFI) engagement at the merchant's expense (typical PFI engagements run $50,000 to $250,000), and ultimately termination of the merchant account — cutting the merchant off from the card networks entirely. Card brand fines can reach into the millions for large breaches.

The post-March 2025 reality is that the 51 future-dated requirements are now being assessed in every PCI DSS engagement. The most operationally significant for e-commerce: 6.4.3 (script inventory + integrity) and 11.6.1 (page-change detection) defend against Magecart-style payment-page skimming, and they apply to SAQ A merchants embedding hosted iframes — not just SAQ A-EP. 8.4.2 expands MFA to all CDE access, not just remote or admin. 10.4.1.1 and 10.4.2.1 require automated log review at scale.

The arithmetic is straightforward: an organization still operating under v3.2.1 or v4.0 (pre-future-dated) assumptions in 2026 is non-compliant today, not in the future. v4.0.1 SAQs have been mandatory since the v4.0 retirement on March 31, 2025; v4.0 documents will be rejected by acquirers.

// THE MERCHANT LEVEL PYRAMID

Four levels. Volume determines validation. Validation determines scope.

PCI DSS validation requirements scale with annual card transaction volume. Higher volume means more scrutiny: Level 1 merchants undergo a Qualified Security Assessor-led Report on Compliance; Levels 2 through 4 typically submit a Self-Assessment Questionnaire matched to their cardholder data flow. All four levels are bound by the same 12 core requirements — the level only determines how compliance is validated.

Two things shift level calculation in practice: a security breach automatically escalates to Level 1 regardless of volume, and acquirers can impose a higher validation tier than volume alone would dictate based on risk assessment. Each card brand publishes its own level criteria with minor threshold differences — Visa, Mastercard, and Amex are the most consequential.

// LEVEL 1 QSA REQUIRED

Level 1

Over 6 million card transactions per year across all channels. Also automatically assigned to any merchant that has experienced a security breach involving cardholder data, regardless of volume.

Validation: Annual Report on Compliance (RoC) by a Qualified Security Assessor (QSA) or Internal Security Assessor (ISA). Quarterly ASV scans by an Approved Scanning Vendor. Annual penetration testing.

Volume: >6M/year aggregated
Validation: QSA-led RoC
Scans: Quarterly ASV

// LEVEL 2

Level 2

1 to 6 million card transactions per year. Acquirers may require RoC at their discretion, particularly for merchants with elevated risk profiles or breach history.

Validation: Typically SAQ D-MER (Self-Assessment Questionnaire for merchants), or RoC at acquirer discretion. Quarterly ASV scans. Annual penetration testing.

Volume: 1M–6M/year
Validation: SAQ D-MER (or RoC)
Scans: Quarterly ASV

// LEVEL 3

Level 3

20,000 to 1 million e-commerce transactions per year. The most common level for mid-market online merchants — the band where SAQ A vs SAQ A-EP selection matters most.

Validation: SAQ matched to cardholder data flow (most common: SAQ A or SAQ A-EP). Quarterly ASV scans. Annual penetration testing for D-MER scope.

Volume: 20K–1M/year e-commerce
Validation: SAQ (A / A-EP / D-MER)
Scans: Quarterly ASV

// LEVEL 4

Level 4

Under 20,000 e-commerce transactions per year, or under 1 million transactions across all other channels. The largest level by merchant count and the most operationally fragmented.

Validation: SAQ matched to cardholder data flow. Quarterly ASV scans for e-commerce; acquirer-defined cadence for other channels. Often supported by acquirer-provided compliance programs.

Volume: <20K/year e-commerce
Validation: SAQ (matched type)
Scans: Quarterly ASV (if e-com)

// THE FOUR SAQ TYPES MOST ENGAGEMENTS TOUCH

SAQ A // ~24 REQUIREMENTS

E-commerce merchants who fully outsource all cardholder data functions to PCI DSS-validated third parties — merchant's web infrastructure genuinely isolated from cardholder data flow.

SAQ A-EP // ~140 REQUIREMENTS

E-commerce merchants where the website partially controls payment processing — including most iframe and hosted-field implementations. Roughly 6x SAQ A scope.

SAQ D-MER // FULL REQUIREMENTS

Merchants where none of the simpler SAQs fit — storing cardholder data, processing through multiple channels, or where acquirers mandate D-MER. Covers all 12 core requirements.

SAQ D-SP // SERVICE PROVIDERS

Service providers (TPSPs) at Level 2 (<300K transactions). Level 1 service providers (>300K) require a QSA-led RoC, not a SAQ.

⚐ // 6.4.3 SCRIPT INTEGRITY

Complete inventory of every script loaded on any page that initiates a payment, with documented justification and integrity assurance. Applies to SAQ A.

⚐ // 11.6.1 PAGE-CHANGE DETECTION

Change-detection mechanism on payment pages that alerts on unauthorized modifications. Magecart defense. Applies to SAQ A.

⚠ // BREACH ESCALATION

A security breach automatically escalates a merchant to Level 1 regardless of transaction volume — triggering QSA-led RoC and PFI engagement.

★ // CUSTOMIZED APPROACH

New under v4.0 — alternative compliance via documented security objective + targeted risk analysis. Available only via QSA or ISA assessment.

// THE PCI DSS COMPLIANCE LIFECYCLE

Six stages, annual cycle. From scope to sustained attestation.

PCI DSS compliance operates on an annual attestation cycle with quarterly external scan requirements built in. Unlike ISO 27001's three-year certification window, PCI DSS attestations are valid for one year and the quarterly ASV scan cadence runs continuously underneath. Amber milestones mark the two recurring external accountability moments: quarterly ASV scans by an Approved Scanning Vendor, and the annual validation (SAQ submission or QSA-led RoC).

SCOPE

CDE Scoping & Level Determination

WEEK 1–3

Cardholder Data Environment (CDE) defined. Merchant level set against transaction volume. Network segmentation strategy assessed. SAQ type selected.

GAP

Gap Assessment

WEEK 3–7

Full assessment against all 12 core requirements and ~300 sub-requirements. 51 future-dated requirements (including 6.4.3 and 11.6.1) triaged. Remediation roadmap built.

REMEDIATION

Control Implementation

MONTH 2–5

Controls implemented across the CDE. Payment-page script integrity (6.4.3) and page-change detection (11.6.1) deployed. MFA expansion (8.4.x). Automated log review for 10.4.1.1 / 10.4.2.1.

ASV SCANS

Quarterly ASV Vulnerability Scans

QUARTERLY

External vulnerability scan by an Approved Scanning Vendor (ASV) against all externally-facing CDE systems. Findings remediated; rescans until clean. Passing scans are a prerequisite for annual attestation.

VALIDATION

SAQ Submission / RoC

ANNUAL

Level 1: QSA-led Report on Compliance fieldwork. Levels 2–4: SAQ authored (v4.0.1 template), signed Attestation of Compliance (AoC) submitted to acquirer. Attestation valid 1 year.

MAINTAIN

Annual Maintenance

CONTINUOUS

Ongoing: monthly script inventory reviews, quarterly internal vulnerability scans, semi-annual access reviews, annual policy refresh, annual pen test. Cycle resets at next annual validation.

● BLUE NODES = scoping, remediation, and ongoing maintenance (WatchUr6-led)  ·  ● AMBER NODES = the two external accountability moments. ASV scans run quarterly — performed by an independent Approved Scanning Vendor. Validation runs annually — either QSA-led RoC fieldwork (Level 1) or SAQ-based attestation submitted to your acquirer (Levels 2–4).

// THE PCI DSS ENGAGEMENT MODEL

Six services. Three phases. Annual attestation, quarterly cadence.

PCI DSS engagements are structured around the annual cycle with the quarterly ASV scan rhythm built in. Scoping and gap come first; remediation and ASV scan coordination in the middle; SAQ-or-RoC validation and maintenance at the end. The post-March 2025 reality — especially payment-page script integrity (6.4.3) and page-change detection (11.6.1) — shapes every phase.

// PHASE 01

Scoping & Gap

CDE DEFINITION · LEVEL DETERMINATION · v4.0.1 GAP

// 01 // SCOPING

CDE Scoping & Merchant Level Determination

Cardholder Data Environment (CDE) defined: every system, network segment, and application that stores, processes, or transmits cardholder data — plus everything connected to those systems unless properly segmented.

Merchant level set against aggregated annual transaction volume across all card brands and channels. Service Provider level (1 or 2) set against transaction volume serviced. SAQ type selected against actual cardholder data flow (the SAQ A vs A-EP decision is often re-evaluated here).

Output: a defensible scoping document and a level/SAQ decision the acquirer will accept.

// INCLUDES

CDE MAPPING SEGMENTATION REVIEW LEVEL DETERMINATION SAQ SELECTION ACQUIRER ALIGNMENT

// 02 // GAP ASSESSMENT

v4.0.1 Gap Assessment & 6.4.3 / 11.6.1 Triage

Full assessment against all 12 core requirements and ~300 sub-requirements. The 51 future-dated requirements (now mandatory) triaged with focus on the highest-impact changes: payment-page script integrity (6.4.3), page-change detection (11.6.1), MFA expansion (8.4.x), automated log review (10.4.1.1 / 10.4.2.1), and targeted risk analysis (12.3.x).

For e-commerce: explicit payment-page inventory and Magecart-defense capability assessment. For service providers: TPSP responsibility matrix review against downstream merchant obligations.

Output: prioritized remediation roadmap with effort estimates and acquirer-credible timelines.

// INCLUDES

12-REQ ASSESSMENT FUTURE-DATED TRIAGE 6.4.3 INVENTORY 11.6.1 ASSESSMENT REMEDIATION PLAN
// PHASE 02

Remediation

CONTROL IMPLEMENTATION · ASV COORDINATION

// 03 // IMPLEMENTATION

Control Implementation & Payment-Page Hardening

Controls implemented across the CDE. The 2026 reality: payment-page hardening is the highest-effort work for most e-commerce merchants. Script inventory documented per 6.4.3; integrity controls deployed (Subresource Integrity, Content Security Policy, or commercial monitoring tools); change-detection mechanism (11.6.1) instrumented on every page that initiates a payment.

MFA expanded to all CDE access per 8.4.2 (not just remote/admin). Automated log review (10.4.1.1 / 10.4.2.1) implemented — SIEM or equivalent. Targeted risk analyses (12.3.x) authored for each periodic activity cycle. Network segmentation validated annually for non-CDE isolation.

// INCLUDES

PAYMENT-PAGE SI/CSP MFA EXPANSION AUTOMATED LOG REVIEW RISK ANALYSES SEGMENTATION TESTING

// 04 // ASV SCANS

Approved Scanning Vendor Coordination

Quarterly ASV vulnerability scans coordinated against all externally-facing CDE systems. ASV selection from the PCI SSC-approved list. Scope review and asset inventory provided to the ASV. Findings triaged: false positives challenged with evidence; true positives remediated; rescans coordinated until passing scans achieved.

Passing ASV scans are a prerequisite for annual attestation — merchants without recent passing scans cannot validate. Internal vulnerability scans (separate requirement) coordinated quarterly on internal segments.

// INCLUDES

ASV SELECTION SCAN SCOPING FINDINGS TRIAGE REMEDIATION RESCAN COORDINATION
// PHASE 03

Validation & Maintenance

SAQ-OR-ROC · AOC · ANNUAL CYCLE

// 05 // VALIDATION

SAQ Authoring or QSA-Led RoC Coordination

For Levels 2–4: Self-Assessment Questionnaire authored against the v4.0.1 template, signed by an officer of the company, submitted with the Attestation of Compliance (AoC) to the acquirer. v4.0 SAQs are rejected by acquirers post-March 2025; v4.0.1 SAQs are required.

For Level 1 (and Level 1 service providers): QSA selection from the PCI SSC Qualified Security Assessor list, RoC fieldwork coordination, walkthrough rehearsals, evidence trail preparation, finding response. Operator-led representation during fieldwork. Final RoC + AoC submitted to acquirer.

// INCLUDES

SAQ AUTHORING QSA SELECTION RoC COORDINATION AOC PREPARATION ACQUIRER SUBMISSION

// 06 // MAINTENANCE

Annual Maintenance & Quarterly Cadence

The operational discipline that keeps attestation valid year over year. Monthly: script inventory reviews (6.4.3), automated log review escalations, vendor risk reviews. Quarterly: ASV scans, internal scans, segmentation testing for D-MER. Semi-annual: access reviews. Annual: penetration test, policy refresh, full SAQ/RoC, targeted risk analyses (12.3.x).

Failure modes live here, not in the original implementation: expired ASV scans before annual validation, stale script inventories, MFA scope gaps as the CDE evolves, missed log review escalations, undocumented network segmentation changes.

// INCLUDES

SCRIPT INVENTORY QUARTERLY ASV ACCESS REVIEWS ANNUAL PEN TEST RoC/SAQ REFRESH

// CONNECTED INTELLIGENCE

PCI DSS is the contract gate, not the whole program.

PCI DSS is the contractual standard that keeps your merchant account connected to the card networks. But most card-handling organizations need broader security validation: SOC 2 for B2B customers asking for an attestation, HIPAA for healthcare organizations processing payments alongside PHI, and an operational security capability that actually keeps the CDE defensible day to day.

// PARENT SERVICE

Audit Readiness

PCI DSS is one framework inside Audit Readiness. Most card-handling organizations need at least one other framework alongside — SOC 2 for B2B contract scrutiny, HIPAA for healthcare-adjacent payments.

The operator who runs your PCI engagement is the same operator who would represent you in SOC 2, ISO 27001, or HIPAA work, with full crosswalk reuse across overlapping controls.

Audit Readiness Brief

// SIBLING FRAMEWORK

SOC 2

About 65% of PCI DSS operational controls overlap with SOC 2's Common Criteria (Security category). Most B2B card-handling companies need both: PCI DSS for the acquirer relationship, SOC 2 for the customer due-diligence process.

Sequencing varies: SOC 2 first if customer pressure is leading; PCI DSS first if acquirer pressure or merchant level escalation is the trigger.

SOC 2 Brief

// OPERATIONAL LAYER

Cybersecurity-as-a-Service

PCI DSS attestation is the qualifier. Sustained compliance is operational: monthly script inventory reviews, quarterly ASV scans, automated log review, MFA scope drift, segmentation validation.

Cybersecurity-as-a-Service runs the year-round operational cadence that keeps the CDE defensible and the attestation defensible.

Cybersecurity Brief

// THE NUMBERS

PCI DSS by the numbers.

3–5 MO

Cold-Start to Attestation

Scoping through SAQ submission. Faster (8–12 weeks) with existing SOC 2 program (~65% control overlap). Level 1 RoC engagements run 5–8 months from cold start.

v4.0.1 future-dated requirements add real engineering work to most engagements.

12 / 6 / 51

Requirements / Domains / Future-Dated Live

12 core requirements organized across 6 security domains, ~300 sub-requirements total.

51 future-dated requirements (6.4.3, 11.6.1, 8.4.x, 10.4.1.1/2.1, 12.3.x) became mandatory March 31, 2025.

ANNUAL

Attestation + Quarterly ASV

SAQ or RoC valid for 1 year. Quarterly ASV scans by an Approved Scanning Vendor run continuously underneath the annual cycle.

Annual penetration testing for D-MER scope; segmentation testing for non-CDE isolation.

// THE OPERATOR TEAM

Fortune 500 senior CISO leads CDE scoping strategy, merchant level determination, SAQ type selection, and QSA briefing for Level 1 RoC engagements. CISSP-credentialed cloud architect engineers control implementation across the CDE with payment-page integrity (6.4.3 / 11.6.1) as a specialization — the highest-impact 2026 requirement.

Army Special Forces communications sergeant (Green Beret, 18B/18C) leads ASV coordination, MFA expansion across the CDE, automated log review implementation, and acquirer AoC submission. Naval Special Warfare veteran runs the annual maintenance cadence: monthly script reviews, quarterly scans, semi-annual access reviews, annual pen test and SAQ/RoC refresh.

SDVOSB · DVBE · SBE · CMAS #3-25-06-1018 · CAGE 9CQZ9 · SAM-registered · veteran-led.

// SELF-QUALIFICATION CHECK

Does PCI DSS actually apply to you?

Three quick questions: whether PCI DSS applies at all, when you'd need attestation by, and how much of the work reuses from frameworks you already run.

// 01 // APPLICABILITY

Do you need PCI DSS?

PCI DSS is the contractual standard for cardholder data. It applies if your organization touches cards in any of these ways.

  • →You're a merchant accepting credit or debit card payments at any volume tier — e-commerce, brick-and-mortar, MOTO, or recurring billing.
  • →You're a third-party service provider (TPSP) handling cardholder data on behalf of merchants — gateways, processors, vault providers, fraud services.
  • →You're a SaaS platform that handles payments for downstream customers — even pass-through to a PCI-validated processor often requires SAQ A-EP scope.
  • →Your acquirer has imposed a PCI assessment requirement based on volume, breach history, or risk assessment.
  • →You've experienced a suspected or confirmed breach — automatic escalation to Level 1 regardless of volume.

If any of the above applies, PCI DSS is contractually binding. The only path out is to fully outsource cardholder data flow to a PCI-validated third party with proper segmentation (and even then, 6.4.3 / 11.6.1 still apply if you have a payment page).

// 02 // TIMING

When do you need attestation by?

PCI DSS attestation is annual. The deadline is whichever comes first from your acquirer relationship.

  • →Your annual SAQ or RoC renewal cycle — typically aligned to the fiscal year or acquirer onboarding anniversary.
  • →An acquirer-imposed assessment deadline following volume increase, breach response, or risk reassessment.
  • →A new acquirer relationship requiring a current AoC before merchant account activation.
  • →A v4.0.1 transition if you're still operating under v4.0 SAQs — acquirers reject pre-v4.0.1 attestations.
  • →A breach-triggered Level 1 escalation requiring QSA-led RoC and PCI Forensic Investigator engagement.

Work backward from that date. Cold-start SAQ: subtract 3–5 months. Level 1 RoC: subtract 5–8 months. With existing SOC 2: subtract 8–12 weeks.

// 03 // FRAMEWORK LEVERAGE

What if you already run another framework?

PCI DSS overlaps meaningfully with SOC 2 and ISO 27001 on operational controls. The work is the delta, not the whole standard.

  • →SOC 2 : ~65% operational control overlap. Net-new: payment-page script integrity (6.4.3), page-change detection (11.6.1), card-data-specific encryption requirements, ASV scan coordination.
  • →ISO 27001 : ~60% control overlap with SAQ D-MER scope. ISMS structure helps; payment-page controls are net-new for most ISMS scopes.
  • →HIPAA Security Rule : ~50% overlap on technical safeguards (access control, audit logging, transmission security). Net-new: card-specific scope, payment-page controls, quarterly ASV cadence.
  • →NIST CSF Tier 3+ : Maturity foundation translates to PCI program, but specific control mappings (PCI's prescriptive 12-req structure) are net-new.
  • →Nothing existing : cold start. 3–5 months for SAQ; 5–8 months for Level 1 RoC.

Existing framework makes PCI faster. Payment-page hardening (6.4.3 / 11.6.1) is net-new for almost everyone — that's where the time goes.

// FREQUENTLY ASKED

The PCI DSS questions teams keep asking.

Which version of PCI DSS applies to us right now?

PCI DSS v4.0.1 is the only currently-active version. The transition is complete: v3.2.1 was officially retired March 31, 2024, and v4.0 was retired March 31, 2025.

v4.0.1 was released as a limited revision in June 2024 with clarifications and minor wording updates — but importantly, v4.0.1 did not change the effective date of the future-dated requirements. The 51 future-dated requirements introduced in v4.0 became mandatory March 31, 2025 with no grace period.

PCI SSC republished all 10 SAQ types for v4.0.1 in October 2024, and the v4.0.1 Report on Compliance template was published in August 2024. If you are still using v4.0 documents in 2026 — v4.0 SAQs or the v4.0 ROC template — you are using the wrong documents and your acquirer will reject the attestation.

The card brands (Visa, Mastercard, Amex, Discover, JCB) all aligned with the March 31, 2025 deadline; some acquirers granted short additional grace periods for AoC submission during 2025 but the underlying control requirements were enforceable on the deadline.

What changed in the future-dated requirements that became mandatory March 31, 2025?

Fifty-one requirements moved from best-practice to mandatory. The highest-impact changes by domain:

For e-commerce merchants: Requirement 6.4.3 requires a complete inventory of all scripts loaded on payment pages with documented justification and integrity assurance. Requirement 11.6.1 requires a change-detection mechanism on payment pages that alerts on unauthorized modifications. Together these address Magecart-style payment-page skimming attacks and apply even to SAQ A merchants whose payment pages embed iframes or hosted payment fields.

For authentication: Requirement 8.3.6 sets minimum password length to 12 characters with alphanumeric combinations. Requirement 8.4.2 requires MFA for all access into the CDE (not just remote access or admin access). The v4.0.1 FAQs from PCI SSC clarify that FIDO2 passkeys satisfy 8.4.2 while not all phishing-resistant authentication is sufficient on its own for 8.4.1 and 8.4.3.

For monitoring and logging: Requirements 10.4.1.1 and 10.4.2.1 require automated mechanisms for log review — manual review is no longer sufficient at scale.

For risk management: Requirement 12.3.1 requires a targeted risk analysis to support most periodic activity cycles. The assessment of which changes materially affect your organization depends on your CDE architecture, payment-page implementation, and current control maturity.

Do the payment-page script requirements (6.4.3 and 11.6.1) apply to us if we just embed Stripe or a hosted iframe?

Yes — and this is the single most common misunderstanding among e-commerce merchants in 2026. The PCI SSC FAQ guidance is explicit: SAQ A merchants whose payment pages embed iframes, hosted payment fields, or any third-party scripts (Stripe Elements, Braintree Hosted Fields, Adyen drop-in, etc.) are still required to comply with 6.4.3 and 11.6.1.

The reason is straightforward: a malicious script injected into your payment page can siphon cardholder data before it ever reaches the embedded iframe, even if the iframe itself is hosted by a fully compliant processor. The Magecart attack family does exactly this — compromise the merchant's web infrastructure, inject a skimmer above or alongside the legitimate payment script, and exfiltrate card data from the form fields before submission.

Implementation typically requires three things: a documented inventory of every script loaded on every page that initiates a payment (Requirement 6.4.3), an integrity monitoring mechanism (Subresource Integrity, Content Security Policy, or a commercial payment-page monitoring tool), and a change-detection alerting mechanism on the payment page itself (Requirement 11.6.1).

Many SAQ A merchants who treated their PCI scope as "we just embed Stripe, we're fine" discovered in their 2025 assessments that they needed real engineering work to bring 6.4.3 and 11.6.1 into compliance — which is why this question dominates 2026 engagements.

How do we determine our PCI DSS merchant level?

Merchant level is determined by annual card transaction volume, calculated by aggregating across all card brands and channels.

Level 1: over 6 million transactions per year. Requires an annual Report on Compliance (RoC) performed by a Qualified Security Assessor (QSA), or an Internal Security Assessor (ISA) for organizations with formally trained internal staff.

Level 2: 1 million to 6 million transactions per year. Typically requires SAQ D-MER or, at the acquirer's discretion, a RoC.

Level 3: 20,000 to 1 million e-commerce transactions per year. Requires the appropriate SAQ.

Level 4: under 20,000 e-commerce transactions per year or under 1 million transactions across all other channels.

Each card brand maintains its own published level criteria with slight differences in thresholds — Visa, Mastercard, and Amex are the most consequential. Three things shift level calculation in practice: a security breach automatically escalates the merchant to Level 1 regardless of volume; aggregating subsidiary or franchise volumes may put an organization at a higher level than any single entity would be; and acquirers can impose a higher validation tier than the volume-based level if they assess heightened risk.

Which SAQ type do we need, and what's the difference between SAQ A and SAQ A-EP?

SAQ type selection is one of the most consequential PCI compliance decisions because it determines how many requirements you have to validate. There are 10 SAQ types under v4.0.1: A, A-EP, B, B-IP, C, C-VT, D-MER (for merchants), D-SP (for service providers), SPoC, and P2PE.

The two e-commerce SAQs that matter most are A and A-EP, and choosing the wrong one is a common compliance mistake.

SAQ A applies to e-commerce merchants who fully outsource all cardholder data functions to PCI DSS-validated third parties and whose websites do not receive, process, store, transmit, or impact the security of cardholder data in any way — meaning the merchant's web infrastructure is genuinely isolated from cardholder data flow. SAQ A contains approximately 24 requirements.

SAQ A-EP applies to e-commerce merchants who outsource cardholder data processing to a PCI DSS-validated third party but whose website partially controls how cardholder data is redirected or transmitted — meaning the merchant's web infrastructure can affect the security of the payment transaction (which includes most iframe and hosted-field implementations). SAQ A-EP contains approximately 140 requirements — roughly 6x SAQ A scope.

Most merchants who embed Stripe Elements, Braintree Hosted Fields, or similar third-party payment widgets directly on their site are properly SAQ A-EP, not SAQ A — and the new v4.0.1 6.4.3 and 11.6.1 requirements make this distinction sharper than it was under v3.2.1.

What is the Customized Approach in PCI DSS v4.0.1, and when does it make sense?

The Customized Approach is a new compliance mechanism introduced in PCI DSS v4.0 that allows organizations to demonstrate compliance through alternative controls when they meet the same security objective as the standard's Defined Approach.

Most organizations comply through the Defined Approach: the requirement is stated, the control is implemented as described, and the assessor validates against the specific control language.

The Customized Approach instead requires the organization to: document the security objective behind a requirement; design and implement an alternative control that meets that objective; perform a targeted risk analysis (Requirement 12.3.2); and submit the customized control documentation to the assessor (or QSA for RoC engagements) for review and validation.

The Customized Approach is only available for assessments performed by a QSA or ISA — it cannot be used in self-assessed SAQs except through specific provisions. It makes sense for organizations with mature, well-documented security programs that already meet the underlying security objective through controls that don't map cleanly to the Defined Approach language — for example, an organization using a sophisticated risk-based authentication system that exceeds the protection level of password complexity requirements but doesn't match the specific Defined Approach control language.

The Customized Approach significantly increases assessor scrutiny and documentation requirements, so it's not a shortcut — it's a precision instrument for organizations whose security programs are genuinely ahead of the standard's prescriptive language. Most engagements stay on the Defined Approach.

// THE NEXT MOVE

The card brands are enforcing. The future-dated requirements are already live.

Book a 30-minute PCI DSS strategy call with a WatchUr6 advisor. Bring the acquirer-imposed deadline, breach exposure, new merchant relationship, or v4.0.1 transition driving this — and any existing framework you run (SOC 2, ISO 27001, HIPAA, NIST CSF).

You'll walk away with a tactical read on your honest merchant level, the right SAQ type for your cardholder data flow, the realistic 6.4.3 / 11.6.1 effort estimate for your payment pages, and your crosswalk math from existing frameworks — whether you hire us or not.

Book a PCI DSS Strategy Call