PCI DSS v4.0 in 2026: a practical guide

If your business accepts card payments, anywhere in the world, in any volume, the Payment Card Industry Data Security Standard (PCI DSS) applies to you. There is no revenue threshold, no startup exemption, no country exclusion. The card brands (Visa, Mastercard, American Express, Discover, JCB) require it. Your acquirer enforces it. The cost of getting it wrong is measured in tens of thousands of dollars per month in fines, terminated merchant accounts, and post-breach liability that can wipe out small businesses.

The good news: for most modern e-commerce and SaaS businesses, PCI compliance is far less burdensome than it sounds, if you structure your payment flow correctly. Most businesses qualify for a much simpler Self-Assessment Questionnaire than they realise.

This guide is the practical version: who needs PCI DSS, which Self-Assessment Questionnaire applies to you, scope reduction strategies that legitimately cut compliance burden by 80%, real costs, and a realistic timeline.

What PCI DSS actually is

PCI DSS (Payment Card Industry Data Security Standard) is a security framework maintained by the PCI Security Standards Council, a consortium founded by the five major card brands. The current version is v4.0, fully enforced from 31 March 2025.

It applies to any organisation that:

• Stores cardholder data (CHD, primary account number, cardholder name, expiry, service code).
• Processes cardholder data.
• Transmits cardholder data.
• Could impact the security of cardholder data, even if you never see a card number.

The last category is the surprise one: could impact the security. A SaaS that integrates a payment iframe but never touches card data can still be in scope if its scripts run on the same page as the iframe. This is why scope is everything, getting scope right is the single most important decision in PCI compliance.

Merchant Levels and Self-Assessment Questionnaires

Card brands classify merchants into four levels by transaction volume:

• Level 1: 6M+ transactions/year per card brand. Annual Report on Compliance (ROC) by a Qualified Security Assessor (QSA). Quarterly Approved Scanning Vendor (ASV) scans.
• Level 2: 1M–6M transactions/year. Annual SAQ or ROC (depends on acquirer). Quarterly ASV scans.
• Level 3: 20K–1M e-commerce transactions/year. Annual SAQ. Quarterly ASV scans.
• Level 4: Under 20K e-commerce transactions/year (most SMBs). Annual SAQ. ASV scans may be required by acquirer.

Most small-to-mid businesses are Levels 3 or 4, which means a Self-Assessment Questionnaire (SAQ), not a full QSA-led Report on Compliance. There are nine SAQ types; the one you complete depends on how cards flow through your business:

• SAQ-A: fully outsourced. Hosted payment page; card data never touches your servers (Stripe Checkout, Razorpay redirect, PayPal Standard). The lightest path. 22 controls.
• SAQ-A-EP: your site iframes or scripts in a payment provider. Card data still doesn't touch your servers, but your site code runs on the payment page. ~191 controls.
• SAQ-B: payment terminals only, no e-commerce, no internet-connected POS.
• SAQ-B-IP: IP-connected payment terminals.
• SAQ-C: point-of-sale (POS) systems connected to the internet.
• SAQ-C-VT: virtual terminal only (manual entry by your staff).
• SAQ-D Merchant: any merchant that stores, processes or transmits card data on their own systems. The heaviest path. 329 controls.
• SAQ-D Service Provider: for service providers handling card data on behalf of merchants.
• SAQ-P2PE: point-to-point encryption only.

The path you want is SAQ-A. Most modern e-commerce and SaaS can qualify for it with a small architecture change: move from an embedded payment form (Stripe Elements, Razorpay Custom) to a hosted payment page (Stripe Checkout, Razorpay redirect). That single change drops your control count from 329 to 22 and your ongoing compliance cost by ~80%.

Scope reduction, the most important decision

Most PCI compliance burden comes from over-broad scope. Every system that touches cardholder data or shares a network with systems that do is in scope. That includes:

• Application servers handling card data.
• Databases storing card data.
• Logs that might contain card data.
• Backups of any of the above.
• Workstations that access systems in scope.
• Network segments connecting any of these.
• Vendors and third parties that touch card data.

Three legitimate scope-reduction strategies:

1. Outsource the cardholder data environment

Stripe Checkout, Razorpay redirect, PayPal Standard, Adyen hosted pages, Braintree hosted fields, these move card collection entirely to the payment provider's domain. Your site never sees a card number. You qualify for SAQ-A.

2. Tokenisation

Replace card numbers in your systems with tokens issued by your payment provider. The token can be stored, logged, sent in webhooks, it has no value if leaked. Only the payment provider can detokenise. Significantly reduces scope.

3. Network segmentation

If you must handle card data on your own systems (SAQ-D), isolate the Cardholder Data Environment (CDE) on its own network with strict firewall rules. Everything outside the CDE is out of scope, dramatically reducing audit burden.

What PCI DSS v4.0 changed

PCI DSS v4.0 (effective 31 March 2024 for early adopters, mandatory from 31 March 2025) tightened several areas:

• Multi-factor authentication: now required for ALL access into the CDE, not just admin access.
• Targeted risk analyses: for any control where you're using the “customised approach” flexibility.
• Continuous monitoring: several controls now require continuous monitoring rather than periodic checks.
• Authenticated vulnerability scans: internal scans must now use authentication, not just unauthenticated probes.
• Customised approach: mature security programs can substitute alternative controls if they meet the same objective, with documented rationale.
• Public-facing web applications: automated tools must continuously monitor for and respond to payment page tampering (script-injection attacks like Magecart).

The last one is particularly important for e-commerce: Magecart-style attacks have compromised tens of thousands of e-commerce sites since 2018, and v4.0 explicitly requires continuous integrity monitoring of payment pages.

Real costs

For an SMB e-commerce site qualifying for SAQ-A:

• Architecture work to qualify for SAQ-A (if not already there): $1,500–$8,000 USD.
• SAQ-A documentation: $1,500–$5,000 USD.
• Quarterly ASV scans (if required by acquirer): $200–$1,000 USD/year.
• Annual re-attestation: $800–$2,500 USD/year ongoing.

For SAQ-D Merchant (handling card data on own systems):

• Readiness and remediation: $8,000–$30,000 USD one-time.
• Annual SAQ-D documentation: $4,000–$15,000 USD/year.
• Quarterly ASV scans: $400–$2,000 USD/year.

For Level 1 merchants requiring full QSA-led Report on Compliance:

• QSA audit: $20,000–$100,000 USD/year depending on environment.
• Quarterly ASV scans: $1,000–$5,000 USD/year.
• Internal team commitment: significant.

Penalties

PCI non-compliance penalties are imposed by card brands through your acquirer:

• Initial non-compliance: $5,000–$10,000 USD/month.
• Continued non-compliance: escalating to $50,000–$100,000 USD/month.
• Per-incident breach fines: up to $500,000 USD per occurrence.
• Forensic investigation costs: $20,000–$50,000 USD typical.
• Card replacement: $3–$5 USD per card compromised, for a 100,000-card breach, that's $300K–$500K.
• MATCH list placement: your business goes on the Member Alert to Control High-risk merchants list, making future card processing extremely difficult.
• Acquirer termination: immediate loss of card acceptance ability.

The penalty model is asymmetric: compliance costs are predictable and modest; non-compliance costs are unbounded and potentially terminal for the business.

Common myths

“Stripe handles all my PCI compliance.”

False. Stripe handles their portion of PCI scope. You still have obligations: SAQ-A attestation, vendor management, security awareness training, password policies, access controls on your admin panels, anti-malware on workstations that access Stripe Dashboard. The amount of work is small, but it isn't zero.

“We're a small business, PCI doesn't apply.”

False. PCI applies from your first transaction. Level 4 merchants (under 20K transactions/year) still need SAQ-A or similar. Acquirers can require attestation as a condition of card acceptance.

“We're B2B, our customers don't use cards.”

Often false. Many B2B SaaS now offer card payment alongside invoicing. The moment your product accepts a card, you're in scope.

“PCI compliance certificates from third-party scan services prove we're compliant.”

False. ASV scans are one component of PCI compliance, not the whole. A clean scan report does not equal a clean SAQ or ROC.

Where to start

• Determine your merchant level by transaction volume per card brand. For most SMBs, Level 4.
• Map your card data flow.Where does a card number enter your system? Where does it go? Where does it stop? Most modern e-commerce/SaaS, the answer is “straight to Stripe”, and that's the answer you want.
• Pick the right SAQ.If you're using embedded payment forms, look hard at moving to hosted checkout (SAQ-A path). The architecture change is small; the compliance savings are large.
• Talk to your acquirer.Ask what attestation they require, what quarterly scans they expect, and when. They usually have requirements your payment provider can't answer.
• Document your controls.Even for SAQ-A, you need written policies and evidence that you're actually doing what the SAQ claims.

How RoseLeap can help

We offer PCI DSS Compliance as a service, scope reduction, SAQ documentation, quarterly scan coordination, and QSA / assessor liaison for businesses worldwide. We're not a QSA ourselves; we get you ready for one (or for a clean self-assessment) at a fraction of QSA pricing.

Tell us about your payment integration, merchant level, and growth plans at the contact page. We come back with a fixed-fee scope and a date you can be PCI DSS compliant by, within one business day.