PCI DSS (Payment Card Industry Data Security Standard)

PCI DSS is the global payment security standard created and maintained by the PCI Security Standards Council (PCI SSC) — a body founded by Visa, Mastercard, American Express, Discover, and JCB. It applies to every organisation that stores, processes, or transmits payment cardholder data. For ecommerce merchants, accepting any card payment on a website triggers the standard — even if the transaction is handed off immediately to a payment processor (Foregenix, as-of 2025-12-18). The primary goal is protecting the Cardholder Data Environment (CDE): every system component that stores, processes, or transmits Primary Account Numbers (PANs).

Current version — v4.0.1

PCI DSS v4.0.1 was released 11 June 2024 as a limited revision of v4.0, which was itself published April 2022 (Adyen docs PRIMARY, as-of 2026-07-09). The transition timeline was:

• 31 December 2024: PCI DSS v3.2.1 retired; v4.0 also retired; v4.0.1 becomes the sole operative standard
• 31 March 2025: All formerly "best-practice / future-dated" requirements in v4.0 became mandatory; any assessment with a report date on or after 1 April 2025 must treat the full requirement set as in force (Checkout.com Blog, 2024-03-05; Adyen docs PRIMARY)

PCI DSS v4.0 introduced 64 new or updated requirements relative to v3.2.1; 51 of these were future-dated until March 2025 (episki.com, 2026-03-24). In June 2026, the PCI SSC also opened a Request for Comments period (June 3–July 20, 2026) on the PCI DSS v4.0.1 standard, though the precise scope of any forthcoming revision was unclear at time of writing (PCI SSC Perspectives Blog, 2026-06-03).

What changed structurally in v4.x

• Continuous security model: v4.x rejects the annual compliance event model of v3.2.1; security must be a continuous, business-as-usual process (episki.com, 2026-03-24)
• Customized Approach: organisations with mature risk management may now meet control objectives using their own methods instead of prescribed requirements, documenting a Targeted Risk Analysis (TRA) (petronellatech.com, 2025-12-21). Distinct from "compensating controls" which apply only where a defined requirement genuinely cannot be met due to a legitimate constraint — the PCI SSC published guidance on both in June 2026 (PCI SSC Blog, 2026-06-10 PRIMARY)
• Mobile, cloud, and third-party service expansion: v4.0.1 explicitly added expanded requirements for mobile payments, cloud environments, and new software development practices (Adyen docs PRIMARY)

Merchant levels and assessment types

Card networks classify merchants into four levels by annual transaction volume, with the level determining the type of compliance validation required (episki.com, 2026-03-24):

Level	Volume	Validation required
1	>6M transactions/year	Full Report on Compliance (RoC) by QSA
2	1M–6M/year	Self-Assessment Questionnaire + ASV scans
3	20K–1M ecommerce/year	SAQ + ASV scans
4	<20K ecommerce/year	SAQ (type varies by integration)

A significant data breach can escalate a merchant to Level 1 regardless of volume; acquirers can also require Level 1 treatment for any merchant they consider high-risk (episki.com, 2026-03-24).

SAQ types for ecommerce

Self-Assessment Questionnaires differ dramatically in scope. For ecommerce merchants, three are relevant:

SAQ A (~22 controls) — the minimum scope. Applies when: all elements of the payment page delivered to the customer's browser originate only and directly from a PCI DSS-compliant Third-Party Service Provider (TPSP), and the merchant's site is not susceptible to attacks from scripts that could affect ecommerce systems (Adyen docs PRIMARY, as-of 2026-07-09). Typical integrations qualifying: Stripe Checkout (redirect), Adyen Hosted Payment Page, Shopify Checkout, BigCommerce Checkout. A new mandatory requirement under v4.0.1 (not present in v3.2.1) is ASV quarterly external vulnerability scanning (Req 11.3.2) (Foregenix, 2025-12-18; Stripe docs PRIMARY).

SAQ A-EP (~190 controls) — for merchants who control the checkout page but whose servers do not receive cardholder data directly. Applies to Direct Post and JavaScript widget integrations where card data flows through third-party scripts on the merchant's own page. The merchant's infrastructure affects the security or integrity of the payment transmission even though no PAN is stored server-side (Foregenix, 2025-12-18; SecurityMetrics video, 2024-12-09).

SAQ D (~330 controls) — for merchants that store, process, or transmit cardholder data on their own systems, or who do not qualify for a lighter SAQ. Storing any cardholder data in an own database automatically triggers SAQ D; this is a common error where merchants assume SAQ A-EP applies to them (r/SaaS, Reddit, 2025).

[!note] Service providers (e.g. a platform hosting payment pages on behalf of multiple merchants) cannot use SAQ A or SAQ A-EP — they require SAQ D for Service Providers (r/pcicompliance, 2025). A service provider's PCI DSS Level 1 compliance is what enables their merchant clients to qualify for SAQ A.

Scope reduction strategies

The guiding principle, repeated across practitioners and vendors: "the best PCI environment is the smallest PCI environment" (r/cybersecurity, 2025).

Redirect / hosted payment page (best reduction): The merchant links or redirects to a payment page fully hosted by the PSP. No card data ever touches the merchant's systems. SAQ A eligibility. Stripe Checkout (redirect) and Adyen's standalone Hosted Payment Page both qualify (Stripe docs PRIMARY; Adyen docs PRIMARY).

iFrame integration: The PSP renders a payment form inside an iFrame on the merchant's domain. For SAQ A eligibility, the merchant must confirm the entire site is not susceptible to script-based attacks — either by implementing script-management and tamper-detection controls themselves, or by obtaining written confirmation from their PCI DSS-compliant payment provider that their embedded form already includes those protections (YouTube — URM Consulting, 2025-03-18 / SAQ A Updates video 2025-03-18).

Tokenisation: Replaces the PAN with a surrogate value (token) so that systems handling only the token fall outside the CDE, directly shrinking scope (Checkout.com Blog, 2024-03-05). Three types exist (petronellatech.com, 2025-12-21):

• Vault-based tokens: PSP or in-house vault stores the PAN and returns a token
• Network Tokenisation|Network tokens: issued by card networks (Visa VTS, Mastercard MDES); device- or merchant-bound; also improve authorisation rates and support Card Account Updater|card lifecycle management
• Format-preserving tokens: retain PAN-like formatting; generally still in scope unless independently validated

A correctly implemented tokenisation arrangement — where the real PAN is vaulted by a Level 1 provider and all merchant systems handle only tokens — can reduce assessment scope from SAQ D (300+ questions) to SAQ A (approximately 22 questions) (URM Consulting / InfoSec Insider, YouTube, 2025-03-20).

Network segmentation: Not mandatory under PCI DSS but strongly recommended for scope reduction. Where applied, its effectiveness must be tested at least annually (every six months for service providers) (URM Consulting, YouTube, 2025-03-20).

[!note] Many merchants incorrectly claim SAQ A eligibility. Any non-iFrame third-party JavaScript on a payment or checkout page that could affect checkout behaviour typically disqualifies a merchant from SAQ A and forces SAQ A-EP or higher (episki.com, 2026-03-24). Sharing a processor's Attestation of Compliance (AOC) is not the same as the merchant's own compliance — each merchant must complete their own SAQ and AOC (r/cybersecurity, 2025).

Ecommerce-specific requirements 6.4.3 and 11.6.1

Two requirements introduced in v4.0 specifically target Magecart-style e-skimming attacks — malicious JavaScript injected into or alongside payment pages to capture card data in the consumer's browser. Around 2020, forensic analysts began finding cardholder data skimmed from inside iFrames via malicious or compromised third-party scripts on the merchant's page (SecurityMetrics, YouTube, 2024-12-09). High-profile Magecart victims include British Airways, Ticketmaster, NewEgg, and Macy's (episki.com, 2026-03-24).

Requirement 6.4.3: All scripts loaded on payment or checkout pages must be inventoried, business-justified, and integrity-checked (e.g. via Subresource Integrity or behaviour monitoring) to prevent unauthorised scripts executing in the consumer's browser (PCI SSC Blog, 2024-11-06 PRIMARY; YouTube — SAQ A script changes video, 2025-03-28).

Requirement 11.6.1: A change- and tamper-detection mechanism must alert personnel to unauthorised modifications to HTTP headers and payment page contents — assessed at minimum once every seven days (or per a Targeted Risk Analysis) (PCI SSC Blog, 2024-11-06 PRIMARY; YouTube, 2025-03-28).

Both requirements became mandatory on 31 March 2025. The PCI SSC formed a dedicated E-commerce Guidance Task Force — including payment brand representatives, QSAs, and small merchant representatives — to produce practical implementation guidance because stakeholders found them "complex for many entities to implement" (PCI SSC Blog, 2024-11-06 PRIMARY). The resulting Information Supplement on Payment Page Security and Preventing E-Skimming was published March 2025 (PCI SSC Blog / report-radar, 2025-03-10).

Common scripts triggering 6.4.3/11.6.1 obligations include: analytics (Google Analytics, Meta Pixel, TikTok Pixel), A/B testing (Optimizely, VWO), support chat widgets, heat mapping (Hotjar, FullStory), fraud screening tools, and retargeting pixels (episki.com, 2026-03-24). A scan of 100,000 ecommerce domains post-March 2025 found 37% showing active browser-layer security exposure relevant to 6.4.3/11.6.1 — most common gap: no CSP with a script-src directive on payment pages (r/pcicompliance, 2025, as-of mid-2025).

The dominant DIY implementation pattern: Content Security Policy (CSP) with nonce + Subresource Integrity (SRI) for script integrity checks, combined with SIEM monitoring for alert-based detection (r/pcicompliance, 2025). Commercial tools: Akamai CSM, PerimeterX, Feroot, Jscrambler, c/side (episki.com, 2026-03-24, volatile — as-of 2026-03-24).

Practitioner pain points

• Alert fatigue: "Alert fatigue is real. Most teams already have 27 other tools giving them alerts for different things" — change management tie-ins are required so expected releases map to expected page changes (r/pcicompliance, 2025)
• Organisational ownership: Marketing teams commonly own payment pages with no security awareness; staff departures during compliance projects are common; "I uncovered a bunch of poor practices, multiplicity of payment pages and scripts" (r/pcicompliance, 2025)
• Code repository scope: Whether the code repository deploying an iframe-embedding payment page is in PCI scope under SAQ A is QSA-dependent and unsettled — requirements 8 and 12.5.2 logical access controls are cited as potentially bringing the repo in scope (r/pcicompliance, 2025)
• SMB monetisation: "In the SMB world, it often turns into a revenue play through non-compliance fees" — acquirer non-compliance fees are the primary enforcement mechanism for small merchants (r/MerchantServices, 2025)
• Legacy OS trap: Any system running end-of-life OS (e.g. CentOS 7) is automatically non-compliant with Req 6.3.3 (timely patching) regardless of integration type (r/pcicompliance, 2024–2025)

Compliance costs (as-of 2026-03-24, volatile)

Merchant type	Typical annual cost
Level 4 / SAQ A	$1,000–$10,000 (SAQ completion, ASV scans, script monitoring, internal time)
Level 2 / SAQ A-EP	$10,000–$50,000 (consulting, ASV, penetration testing, script monitoring)
Level 1 / RoC	$50,000–$250,000 (QSA assessment, pen testing, internal staffing)

Non-compliance penalties from payment networks: $500–$500,000 (as-of 2026-03-24, volatile). Acquirer monthly non-compliance fees: $10,000–$100,000/month (as-of 2026-03-24, volatile). Average cost of a data breach: $4.4 million (as-of 2025, volatile) (Stripe Resources, 2025-11-25; episki.com, 2026-03-24).

Only 14.3% of organisations maintained full PCI DSS compliance in 2023, per the Verizon Payment Security Report (cited via Stripe Resources, 2025-11-25).

Intersection with European regulation

Strong Customer Authentication (SCA - PSD2) and PCI DSS operate in parallel: SCA governs who authenticates a customer for a transaction; PCI DSS governs how card data is secured at every other stage. They are complementary rather than substitutable — meeting SCA does not reduce PCI DSS scope (PCI SSC / EBA, 2023). The EBA clarified in January 2023 that enrolling a payment card into a digital wallet requires SCA under Article 97(1)(c) of PSD2 (EBA, 2023-01-31 — as-of 2023, stale-risk; PSD3/PSR1 expected to extend/replace).

Key terms

Term	Meaning
CDE	Cardholder Data Environment — all system components that store, process, or transmit PANs
PAN	Primary Account Number — the 16-digit card number
SAQ	Self-Assessment Questionnaire — the compliance validation tool for merchants below Level 1
QSA	Qualified Security Assessor — a PCI SSC-certified auditor who can issue an RoC
RoC	Report on Compliance — required for Level 1 merchants, issued by a QSA
ASV	Approved Scanning Vendor — performs external vulnerability scans required at least quarterly
AOC	Attestation of Compliance — the document a merchant (or PSP) signs after passing assessment
TPSP	Third-Party Service Provider — PSP or other vendor handling card data on the merchant's behalf
TRA	Targeted Risk Analysis — the documentation required for the Customized Approach

Frontier links

Magecart · Point-to-Point Encryption (P2PE) · PCI P2PE · Scope Reduction · Compensating Controls · Subresource Integrity (SRI) · Content Security Policy (CSP) · QSA (Qualified Security Assessor) · Verizon Payment Security Report