PCI-DSS v4.0 Requirements for a Small E-Commerce Business: A Practical Compliance Guide

PCI-DSS v4.0 requires small e-commerce businesses to complete either a SAQ A or SAQ D self-assessment questionnaire, implement multi-factor authentication, maintain an updated inventory of payment system components, and meet 12 core security requirements. Most small merchants qualify for the lighter SAQ A path if they fully outsource card processing.

PCI-DSS v4.0 became the mandatory standard on March 31, 2024, replacing version 3.2.1. For small e-commerce businesses, the transition introduced new requirements around authentication, targeted risk analysis, and software security practices that did not exist in the previous version. Understanding exactly which requirements apply to your business depends on how your checkout process is structured and how cardholder data flows through your systems.

Most small e-commerce merchants fall into one of two categories: those who redirect customers entirely to a hosted payment page operated by a third party (such as Stripe, Square, or PayPal), and those who collect card data directly on their own website before passing it to a processor. The first group typically qualifies for SAQ A, the simplest self-assessment path. The second group faces SAQ D, which carries over 200 controls and significantly more compliance overhead.

This guide walks through the 12 PCI-DSS v4.0 requirement domains, clarifies which apply at each merchant level, identifies the new v4.0-specific controls that small businesses must address by March 31, 2025, and helps you evaluate security vendors through Value Aligners' curated SMB marketplace.

What Are the 12 PCI-DSS v4.0 Requirements and Which Apply to Small E-Commerce Businesses?

PCI-DSS v4.0 is organized into 12 high-level requirements grouped under six control objectives. Every merchant who accepts, stores, transmits, or processes payment card data must demonstrate compliance against requirements relevant to their cardholder data environment (CDE).

**Requirement 1: Install and Maintain Network Security Controls** Businesses that host any part of their payment infrastructure must maintain properly configured firewalls and network segmentation. For SAQ A merchants using fully hosted payment pages, this requirement is largely handled by the payment service provider. SAQ D merchants must document and test their own network controls.

**Requirement 2: Apply Secure Configurations to All System Components** All systems in the CDE must be hardened before deployment. Default passwords must be changed and unnecessary services disabled. V4.0 adds a formal requirement to maintain a documented inventory of all bespoke and custom software.

**Requirement 3: Protect Stored Account Data** Small merchants should avoid storing cardholder data entirely. If any storage occurs, strong cryptography (AES-256 or equivalent) is mandatory. V4.0 introduces new requirements around data discovery tools to confirm cardholder data is not stored in unexpected locations.

**Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission** All payment data transmitted over open networks must use TLS 1.2 or higher. TLS 1.0 and 1.1 are explicitly prohibited under v4.0. Small businesses should audit their hosting provider's TLS configuration.

**Requirement 5: Protect All Systems and Networks from Malicious Software** Anti-malware must be deployed on all applicable systems, with regular scans and updated definitions. V4.0 adds a requirement to evaluate systems not typically targeted by malware and document the risk analysis behind that conclusion.

**Requirement 6: Develop and Maintain Secure Systems and Software** This is one of the most significant areas of change in v4.0. New controls require web-facing applications to be protected by either a web application firewall (WAF) or automated technical controls. All payment page scripts loaded by the browser must be authorized and their integrity monitored - a new v4.0 requirement (6.4.3 and 11.6.1) that applies to SAQ A merchants as of March 31, 2025.

**Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know** Access to payment systems must be granted on a least-privilege basis. V4.0 formalizes role-based access control documentation.

**Requirement 8: Identify Users and Authenticate Access to System Components** Multi-factor authentication (MFA) is now required for all access into the CDE, including for administrative access to the hosting control panel. This applies even to very small teams.

**Requirement 9: Restrict Physical Access to Cardholder Data** For pure e-commerce merchants with no physical point-of-sale environment, this requirement has limited applicability but still covers server room access and device media disposal.

**Requirement 10: Log and Monitor All Access to System Components and Cardholder Data** Audit logs must be retained for at least 12 months, with three months immediately available for analysis. Automated log review tools are expected under v4.0.

**Requirement 11: Test Security of Systems and Networks Regularly** Internal and external vulnerability scans are required quarterly. External scans must be performed by a PCI-approved scanning vendor (ASV). Penetration testing is required at least annually for SAQ D merchants.

**Requirement 12: Support Information Security with Organizational Policies and Programs** A formal information security policy must exist, be reviewed annually, and be communicated to all personnel. V4.0 introduces the targeted risk analysis (TRA) process, requiring merchants to document why their chosen control frequencies and approaches are appropriate for their specific environment.

What Changed in PCI-DSS v4.0 That Small E-Commerce Merchants Must Act On Before March 31, 2025?

PCI-DSS v4.0 introduced 64 new requirements compared to v3.2.1. The Payment Card Industry Security Standards Council (PCI SSC) designated some of these as 'best practices' until March 31, 2025, at which point they become mandatory. Small e-commerce businesses need to prioritize these transition items.

**Script Integrity on Payment Pages (Requirements 6.4.3 and 11.6.1)** This is the single most impactful new requirement for small e-commerce businesses using hosted payment pages. Requirement 6.4.3 mandates that all JavaScript executed in the consumer's browser on a payment page must be authorized, with a documented justification for each script's presence and an integrity verification method. Requirement 11.6.1 requires a change-detection mechanism that alerts on unauthorized modifications to HTTP headers and script contents on payment pages. These requirements apply even to SAQ A merchants. A third-party tag management audit and a client-side security solution (often called 'page integrity monitoring') are the primary technical responses.

**Targeted Risk Analysis (Requirement 12.3.1 and 12.3.2)** V4.0 moves away from prescribing fixed control frequencies and instead allows merchants to define their own frequencies - provided they conduct a documented targeted risk analysis. For example, if you choose to run anti-malware scans weekly rather than daily, you must document why that frequency is appropriate given your specific risk environment. This adds a documentation burden but also gives small businesses meaningful flexibility.

**Multi-Factor Authentication Expansion (Requirement 8.4)** MFA is now required for all accounts that can access the CDE, not just remote access accounts as in v3.2.1. This includes local administrator accounts on servers within the CDE and cloud console access to any hosting environment that touches payment data.

**Password and Authentication Policy Updates (Requirement 8.3.6)** Passwords for user accounts must be a minimum of 12 characters (increased from 8) or, alternatively, use a passphrase of at least four words. Systems that cannot technically support 12-character passwords must use compensating controls.

**Phishing-Resistant Authentication (Requirement 8.4.1 - new for 2025)** Personnel with administrative access to the CDE must use phishing-resistant MFA, such as FIDO2 hardware keys or certificate-based authentication. Software-based TOTP apps may not meet this bar for the highest-privileged accounts, depending on your QSA's interpretation.

**Ecommerce-Specific Skimming Protections** The PCI SSC has published supplemental guidance on e-commerce skimming (Magecart-style attacks). Requirement 11.6.1 is the primary technical control, but merchants should also review their content security policy (CSP) headers and evaluate whether their payment page is truly isolated from other site functionality.

**What SAQ A Merchants Specifically Must Do** Prior to v4.0, SAQ A merchants had a very limited control scope because all card data processing occurred on the third-party hosted page. V4.0 closes a loophole by recognizing that malicious scripts injected into the merchant's checkout page - even a redirect page - can intercept card data before it reaches the processor. SAQ A merchants must now: (1) document all scripts on their payment pages; (2) implement a mechanism to detect unauthorized changes to payment page content; (3) maintain an inventory of all third-party service providers with access to their payment environment; and (4) ensure those providers are PCI-DSS compliant.

How Should a Small E-Commerce Business Choose a PCI-DSS v4.0 Compliance Vendor or Partner?

Selecting the right compliance partner is a practical business decision, not just a technical one. Small e-commerce businesses typically need one or more of the following: a Qualified Security Assessor (QSA) or Internal Security Assessor (ISA) for formal assessment, an Approved Scanning Vendor (ASV) for quarterly external scans, a WAF or page integrity monitoring tool, and potentially a managed security service provider (MSSP) to handle ongoing log monitoring.

**Understand Your Scope First** Before engaging any vendor, map your cardholder data environment. Draw a simple diagram showing where payment data enters your website, where it goes, what systems it touches, and what third-party services receive it. This scoping exercise determines which SAQ you must complete and which controls are actually in-scope for your business. Vendors who skip this step or propose a one-size-fits-all solution are a risk.

**QSA vs. SAQ Self-Assessment** Level 4 merchants (fewer than 20,000 Visa or Mastercard e-commerce transactions per year and fewer than 1 million transactions across all channels) are typically allowed to self-assess using the appropriate SAQ rather than engaging a QSA. However, QSA guidance can be valuable even when not mandatory, particularly for the first v4.0 assessment cycle. Some QSA firms offer fixed-fee SAQ advisory services priced for SMBs.

**ASV for Quarterly Scans** External vulnerability scans must be performed by a PCI SSC-approved ASV. The PCI SSC maintains a public list of approved ASVs. Pricing for quarterly external scanning typically ranges from $100 to $500 per quarter for small environments with a limited number of IP addresses. Ensure the vendor's scope covers all public-facing IP addresses associated with your CDE.

**Page Integrity Monitoring Tools** For SAQ A merchants addressing Requirements 6.4.3 and 11.6.1, purpose-built tools that inventory and monitor JavaScript on payment pages are available from vendors including Source Defense, Jscrambler, PerimeterX (now HUMAN Security), and others. These tools typically use a combination of script inventory dashboards, integrity hashing, and real-time alerts. Pricing for SMBs generally ranges from $200 to $800 per month depending on traffic volume and feature set.

**What to Ask a Compliance Vendor** Before signing a contract with any compliance vendor, ask: (1) Are you familiar with the v4.0 transition requirements and the March 2025 deadlines? (2) Can you provide a gap assessment against my current SAQ type? (3) Do you have references from merchants of similar size and transaction volume? (4) What does your reporting output look like and is it acceptable to my acquiring bank? (5) How do you handle re-scans if a vulnerability is discovered?

**Using Value Aligners to Find Pre-Vetted PCI-DSS Vendors** Value Aligners' marketplace surfaces security vendors who have been evaluated for SMB fit, transparent pricing, and specific compliance specialties including PCI-DSS v4.0. You can filter by service type - ASV scanning, QSA advisory, WAF, or MSSP - and compare vendors side by side without filling out sales forms. This is particularly useful for SMBs that do not have a dedicated IT security team and need to evaluate vendors efficiently.

Top Vendors Compared

VendorSpecialtySMB FitPricing (Est.)PCI-DSS v4.0 Cert Support
TrustwaveQSA assessments, ASV scanning, managed complianceMid-market to enterprise; SMB packages availableASV scans from ~$300/qtr; QSA advisory variesFull SAQ advisory, ROC, AOC, v4.0 gap analysis
SecurityMetricsSAQ guidance, ASV scanning, SMB-focused compliance programsStrong SMB focus; purpose-built for Level 3/4 merchantsBundled compliance programs from ~$199/yr; scans includedSAQ A, A-EP, B, C, D; v4.0 updated questionnaires
CoalfireQSA, penetration testing, cloud complianceBetter suited for upper SMB or growth-stage companiesPentest from ~$10K; QSA advisory project-basedFull ROC, SAQ advisory, v4.0 readiness assessments
HUMAN Security (PerimeterX)Client-side page integrity, bot defense, Req. 6.4.3/11.6.1Scales to SMB; SaaS deploymentFrom ~$400/mo depending on page viewsSpecifically addresses v4.0 script inventory requirements
QualysASV scanning, vulnerability management, cloud agentsModerate; self-service portal accessible for SMBsASV scans from ~$200/qtr for small IP rangesExternal scans, internal scanning, PCI reporting module

Key Statistics

  • PCI-DSS v4.0 introduced 64 new requirements compared to version 3.2.1, with 13 new requirements effective immediately upon the March 31, 2024 mandatory adoption date and 51 designated as future-dated best practices until March 31, 2025.
  • 43 percent of cyberattacks target small businesses, and the average cost of a data breach for a small business ranges from $120,000 to $1.24 million when accounting for fines, forensics, and customer notification.
  • E-commerce skimming (Magecart-style) attacks affected more than 100,000 e-commerce stores globally in 2022, with the majority targeting small and mid-sized merchants using widely deployed platforms including Magento, WooCommerce, and OpenCart.
  • Level 4 merchants - those processing fewer than 20,000 e-commerce transactions or fewer than 1 million total card transactions annually - represent over 90 percent of all PCI-DSS-in-scope merchants worldwide but receive the least formal compliance oversight from acquiring banks.
  • Only 43.4 percent of organizations were fully PCI-DSS compliant at their interim validation in 2022, meaning more than half of assessed organizations had at least one failing control at the time of assessment.

Frequently Asked Questions

Does PCI-DSS v4.0 apply to my small e-commerce store if I use Shopify or WooCommerce with Stripe?

Yes. Any business that accepts credit or debit cards is subject to PCI-DSS requirements set by your acquiring bank and card brands, regardless of platform. Using Shopify Payments or a Stripe-hosted checkout significantly reduces your scope and typically qualifies you for SAQ A, but you are still required to complete the self-assessment annually and comply with the new v4.0 controls for payment page script integrity.

What is the difference between SAQ A and SAQ D for a small e-commerce merchant?

SAQ A applies to merchants who have fully outsourced all cardholder data processing to a PCI-DSS compliant third party and whose own website only redirects or uses an iframe to a hosted payment page. SAQ A has approximately 22 controls. SAQ D applies to merchants who directly collect or process card data on their own systems and carries over 200 controls. The correct SAQ type is determined by how card data flows through your systems, not by your transaction volume.

What are the new PCI-DSS v4.0 requirements that become mandatory on March 31, 2025?

The most significant new mandatory controls as of March 31, 2025 include: Requirements 6.4.3 and 11.6.1 (script inventory and change detection on payment pages, applicable to SAQ A merchants); Requirement 8.3.6 (minimum 12-character passwords); phishing-resistant MFA for CDE administrator accounts (Requirement 8.4.1); and the targeted risk analysis framework (Requirement 12.3.1). The PCI SSC published a full list of future-dated requirements in the v4.0 standard document.

How much does PCI-DSS compliance typically cost for a small e-commerce business?

For an SAQ A merchant using a fully hosted payment page, annual compliance costs typically range from $500 to $3,000. This covers quarterly ASV scans ($200-$500 per quarter), an optional SAQ advisory session, and a page integrity monitoring tool if required ($200-$800 per month). SAQ D merchants face higher costs, potentially $5,000 to $20,000 annually, due to the broader control scope, penetration testing requirements, and greater documentation burden.

What happens if a small e-commerce business fails a PCI-DSS assessment or has a data breach?

Non-compliance penalties are set by payment card brands and enforced through your acquiring bank, not directly by the PCI SSC. Fines for non-compliant merchants can range from $5,000 to $100,000 per month. In the event of a confirmed cardholder data breach, you may face forensic investigation costs, card replacement fees charged by issuers, increased transaction fees, and potential termination of your merchant account. Cyber liability insurance can offset some of these costs but generally requires demonstrated PCI-DSS compliance efforts.

Does my hosting provider or cloud provider count as part of my PCI-DSS scope?

If your hosting or cloud provider stores, processes, or transmits cardholder data on your behalf, or provides infrastructure that hosts your CDE, they are a third-party service provider (TPSP) in scope for Requirement 12.8. Under PCI-DSS v4.0, you must maintain a list of all TPSPs, confirm their PCI-DSS compliance status annually, and document what controls each provider manages on your behalf versus what remains your responsibility.

What is a targeted risk analysis under PCI-DSS v4.0 and do small businesses need to complete one?

A targeted risk analysis (TRA) is a documented process, introduced in v4.0 Requirements 12.3.1 and 12.3.2, in which a merchant justifies the frequency and approach of specific controls based on their particular environment and risk factors. Small businesses must complete a TRA for any requirement where v4.0 allows a flexible frequency rather than a fixed one. In practice, this means documenting decisions such as how often you review access logs or run anti-malware scans and why that frequency is appropriate. A one-time template document, reviewed annually, is typically sufficient for small merchants.

Related guides

Where Value Aligners fits