PCI DSS for EU SaaS and Fintech: The Practical Guide for 2026

If you take card payments in the EU — directly or through an embedded checkout — you are subject to PCI DSS. Most SaaS founders assume that using Stripe or Adyen fully outsources this obligation. In practice, it just changes which SAQ type applies to you. The obligation itself doesn't go away.

This guide cuts through the confusion. It explains what PCI DSS v4.0 actually requires, which SAQ type applies to your setup, how scope reduction works, and how PCI overlaps with frameworks you may already have in place.

What PCI DSS Actually Is

PCI DSS stands for Payment Card Industry Data Security Standard. It's a contractual standard maintained by the PCI Security Standards Council and enforced by the major card networks — Visa, Mastercard, Amex, Discover, JCB — through your acquiring bank.

It applies to any entity that stores, processes, or transmits cardholder data, or that could affect the security of such data. Cardholder data includes the Primary Account Number (PAN), cardholder name, expiration date, and service code. Sensitive Authentication Data — CVV2/CVC2/CID, magnetic stripe data, PIN blocks — must never be stored after authorization.

Unlike GDPR or DORA, PCI DSS is not a law. Non-compliance doesn't draw government fines. What it does draw: higher fees from your acquirer, elevated processing rates, increased transaction liability for fraud, and — in severe cases — loss of card-processing privileges entirely. Fees for non-compliance typically run €5,000 to €100,000 per month.

PCI DSS v4.0: What Changed

PCI DSS v4.0 replaced v3.2.1 on 31 March 2024. The v3.2.1 retirement is final — auditors will no longer accept submissions against the old standard. Some v4.0 requirements had a grace period until 31 March 2025, but by now all of them are fully in effect.

The headline changes in v4.0:

• Stronger passwords: 12-character minimum (up from 7), with multi-factor authentication required for all access to the Cardholder Data Environment (CDE), not just admin access
• Anti-phishing controls: mandatory technical controls to detect and prevent phishing against personnel
• Targeted risk analysis: for any requirement where you use the new "customized approach," you must document a risk analysis justifying it
• Automated log review: daily log review must use automated tools for high-volume environments
• Payment page script monitoring: a new Requirement 6.4.3 mandates monitoring of scripts loaded on your payment page (to catch Magecart-style attacks)
• Continuous compliance: the shift away from annual point-in-time assessments toward ongoing evidence

The most strategic change is the "customized approach" — you can meet a control differently than the stated requirement, as long as you document why and how it achieves the same objective. This is powerful for SaaS and cloud-native companies whose architecture doesn't match the implicit "traditional merchant" model of earlier PCI versions.

Which SAQ Type Applies to You

This is the single most important question for reducing effort and cost. SAQ stands for Self-Assessment Questionnaire — the form most companies fill out instead of a full ROC audit.

SAQ A — Fully Outsourced

Applies when your entire payment flow is outsourced to PCI-compliant third parties. Your website redirects to Stripe Checkout, Adyen's hosted payment page, or Mollie's full checkout. You never see card data. ~22 questions. Easiest path.

SAQ A-EP — E-commerce with Partial Outsourcing

Applies when your website loads the payment form (e.g., via Stripe Elements or Adyen Components), but the card data goes directly to the processor — not through your servers. You don't touch the data, but your page loads the form, so you have to protect that loading mechanism. ~191 questions. This is the most common category for modern SaaS.

SAQ D — Merchants with Stored/Processed Cardholder Data

Applies when card data passes through your systems, even briefly — or when you store it (tokenized PANs sometimes qualify, sometimes don't, depending on implementation). ~330+ questions. This is where scope reduction pays off enormously.

ROC — Report on Compliance

Required for Level 1 merchants (6M+ Visa/Mastercard transactions per year, or compromised in a past breach). A Qualified Security Assessor (QSA) performs the audit. Engagement costs €15,000–€60,000 depending on complexity.

The most common mistake: assuming you qualify for SAQ A when you actually need SAQ A-EP. If your checkout loads any payment form on your domain — even via an iframe or a tokenizing library — you are almost certainly in A-EP territory, not A.

Scope: The Single Biggest Lever

PCI DSS applies to your Cardholder Data Environment (CDE) — the systems that store, process, or transmit card data, plus any systems connected to them. The larger your CDE, the more expensive and time-consuming compliance becomes.

Two scope-reduction moves that genuinely work:

Network Segmentation

Isolate the CDE from the rest of your infrastructure using firewalls, VPCs, subnets, and access controls. A dedicated VPC for payment processing, with explicit deny rules from your main application VPC, can remove most of your infrastructure from scope. You document this in a segmentation test — typically an annual penetration test that specifically validates the boundary.

Tokenization

Don't store PANs. Store tokens issued by your processor (Stripe, Adyen, Mollie all offer this). Tokens are not cardholder data by PCI definition, so systems that only handle tokens are out of scope. The trade-off: you can't switch processors without re-tokenizing, which creates some lock-in.

A well-segmented SaaS with full tokenization can often shrink its CDE to a handful of servers or even a single serverless function — turning a SAQ D into an A-EP, or an A-EP into an A.

PCI DSS vs ISO 27001: The Overlap

If you already hold ISO 27001 certification, you've done roughly 60-70% of the work for PCI DSS. The frameworks overlap heavily on technical controls:

• Access control: both require role-based access, MFA, periodic reviews
• Change management: documented approval, testing, rollback
• Incident response: documented procedures, incident logs
• Risk assessment: formal, recurring
• Vendor management: due diligence on processors and sub-processors
• Employee security: background checks, security training, onboarding/offboarding
• Encryption: at rest and in transit, with strong key management
• Logging and monitoring: security-relevant events captured and reviewed

The differences: PCI DSS is narrower but more prescriptive (specific requirements for the CDE, specific technologies allowed), while ISO 27001 is broader but more flexible (scope is your ISMS as a whole, controls are risk-based).

An ISO 27001-certified company typically reaches PCI DSS readiness in 2-3 months of mapping work. Starting from zero takes 4-6 months.

PCI DSS and DORA: A Note for Financial Entities

If you're a financial entity in scope of DORA, you're likely also subject to PCI DSS (any payment-related activity triggers it). The good news: DORA's ICT risk management framework covers most PCI DSS technical and organizational requirements. The catch: DORA is EU regulation, PCI DSS is a contractual standard — you cannot substitute one for the other, even with strong overlap. You comply with both.

Most EU banks and payment institutions run a unified control framework that satisfies DORA, ISO 27001, and PCI DSS simultaneously, mapping each control to the requirements it covers across all three. Normado does this mapping automatically.

What a Realistic Timeline Looks Like

Month 1-2: Scope and Readiness

Determine which SAQ type applies. Document your CDE. Identify scope-reduction opportunities (segmentation, tokenization). Write or adopt the required policies — information security policy, access control, incident response, vendor management. Most SaaS teams discover their CDE is larger than they assumed and take 2-3 weeks just to map it properly.

Month 3: Remediation

Close the gaps. Typical remediation for a small SaaS: enable MFA everywhere, rotate long-standing service accounts, implement centralized logging, deploy a WAF on the payment page, complete staff security training, perform a network segmentation test.

Month 4: Quarterly ASV Scan

External vulnerability scan by an Approved Scanning Vendor. Required every 90 days for any SAQ except A. A failed scan means remediation plus a rescan — budget 2 weeks for the first one to pass.

Month 5-6: Annual Penetration Test and SAQ Submission

Annual penetration test (internal and external), segmentation test if applicable, then complete and submit the SAQ to your acquiring bank. Many acquirers provide a portal; some ask you to email it.

The Hidden Costs

Budget for the following when planning your first year:

• Quarterly ASV scans: €500–€2,000/year (e.g. Qualys, Trustwave, SecurityMetrics)
• Annual penetration test: €5,000–€15,000 depending on scope
• Segmentation test: €3,000–€8,000 if needed
• QSA engagement (ROC only): €15,000–€60,000
• Compliance tooling: €0–€15,000/year depending on platform
• Internal time: 150-400 hours across engineering, security, and leadership
• Remediation: highly variable — WAF, centralized logging, MFA rollout, tokenization migration can each run €5,000–€50,000

Total first-year cost for an EU SaaS going from zero to SAQ A-EP: typically €15,000–€40,000. For SAQ D: €30,000–€80,000. For ROC: €60,000–€200,000+.

Common Mistakes to Avoid

Misclassifying Your SAQ Type

Submitting SAQ A when you should have submitted SAQ A-EP is the most common PCI error. If your website loads any payment form on your domain, you likely need A-EP — even if you use a tokenization library that never puts card data on your servers. The loading mechanism itself is in scope.

Underestimating Scope Creep

Every system "connected to" the CDE is in scope. That includes monitoring tools, logging aggregators, jump hosts, CI/CD pipelines with production access, and anything on the same network. Network segmentation is non-negotiable if you want SAQ D to stay manageable.

Treating PCI as an Annual Project

v4.0 explicitly demands continuous compliance. Evidence collection must happen throughout the year — access reviews, log reviews, change tickets, vulnerability scans. Companies that treat PCI as "annual SAQ paperwork" fail v4.0 audits because the evidence isn't there.

Trusting Your Processor Blindly

Stripe, Adyen, and Mollie are all PCI-compliant — but their compliance does not transfer to you. You inherit a smaller scope, not zero scope. You're still responsible for your side of the integration: page loading, tokenization, access controls, logging, and your own staff training.

Missing the Script Monitoring Requirement

Requirement 6.4.3 (new in v4.0) requires monitoring of any scripts loaded on your payment page. Most e-commerce sites load Google Analytics, Facebook Pixel, customer support chat widgets, and 10 other scripts on their checkout. Each is a potential Magecart attack vector. You now need to inventory, authorize, and monitor every one of them.

How Normado Helps

PCI DSS readiness is mostly about generating the right policies, scoping your CDE correctly, and collecting evidence consistently. Normado handles the first two automatically — AI-generated policies mapped to all 12 PCI DSS requirement categories, a scope documentation workflow that maps to your infrastructure, and a gap analysis dashboard that shows what's missing before the SAQ is due.

Evidence collection is manual by nature (ASV scan reports, pen test reports, access review logs need to come from real systems and real processes). Normado's evidence management keeps everything organized by requirement, with expiry tracking so nothing falls through the cracks before your annual submission.

Because PCI overlaps heavily with ISO 27001 and DORA, one control implemented in Normado often satisfies all three — meaning the marginal cost of adding PCI to an existing compliance program is modest.