PCI-DSS Compliance for SaaS: A 2026 Founder's Checklist

PCI-DSS compliance is one of those topics where the lazy advice is "use Stripe" and the lazy advice is correct for 80% of SaaS — but the remaining 20% gets eaten alive when they accidentally take a payment outside the Stripe iframe and find themselves looking at SAQ-D. This checklist is what we hand clients during every Stripe build at QUANT LAB USA.

Background reading you might want first: What is PCI-DSS and our Next.js Stripe integration guide.

1. Network security controls. Firewall rules, WAF, deny-by-default ingress on production VPCs. For Stripe-iframe SaaS, this is largely about your hosting provider's defaults.
2. Secure configurations. No default passwords, hardened images, disabled unnecessary services. CIS benchmarks on AWS or GCP cover this.
3. Protect stored cardholder data. Do not store it. If you must, encrypt with strong keys and keep PAN truncated (last 4 only).
4. Strong cryptography in transit. TLS 1.2+ everywhere, no SSLv3, no weak ciphers, HSTS. This is one line of Cloudflare config in 2026.
5. Anti-malware. On any system that could process card data. Modern SaaS hosted on PaaS (Vercel, Render) inherits this from the platform.
6. Secure development. Code review, dependency scanning, SAST in CI, separate dev/staging/prod. The basics every reputable SaaS already does.
7. Need-to-know access. Role-based access at the data layer. Engineers do not have prod database creds by default.
8. User identification. SSO, MFA, unique accounts (no shared credentials). PCI 4.0 expanded MFA scope significantly.
9. Physical access. Mostly inherited from your cloud provider's SOC reports.
10. Log and monitor. Audit logs of access to cardholder data systems, 12-month retention, alerting on anomalies.
11. Regular testing. Quarterly external ASV scans, annual internal/external pentest (SAQ-D), file integrity monitoring, IDS.
12. Security policy. Written documents covering acceptable use, incident response, vendor management, security awareness.

SAQ-A is the holy grail for SaaS founders. To qualify, you must:

• Use a fully-outsourced payment page (Stripe Checkout redirect or hosted Payment Element).
• Never store, process, or transmit cardholder data on your servers — not even briefly.
• Have written agreements with your payment processor confirming their PCI compliance.
• Maintain controls over any system that could affect the integrity of the redirect page (your marketing site, your JS bundle, your CDN).

If you check those four boxes, you fill out SAQ-A annually, run quarterly ASV scans (about $300 to $1,500/year), and self-attest. Done.

We have audited dozens of Stripe integrations. The five most common SAQ-A-killing mistakes:

1. Logging request bodies that contain card data. Even a debug log that captured a single Stripe form post can blow your scope wide open. Sanitize at the proxy layer.
2. Custom payment forms instead of Stripe Elements. If your React form collects the PAN and posts it to your backend, you are SAQ-D. Use Stripe Elements or Checkout.
3. Storing the BIN (first 6 digits) for analytics. First-6 is still cardholder data under 4.0.
4. Saving the CVV anywhere, ever. Not in logs, not in support tools, not in CRM. CVV storage is a flat-out violation.
5. Letting third-party scripts inject on the checkout page. PCI 4.0 expanded scope for any script that runs in the cardholder data environment. Analytics tags on the checkout page need to be inventoried.

Version 4.0 added or strengthened several requirements that affect SaaS:

• MFA expansion (8.4): MFA on all access into the cardholder data environment, not just remote admin access. Most SaaS already have this.
• Targeted risk analysis (12.3.1): You can use a risk-based approach for certain controls instead of the prescriptive default. Requires written justification.
• Customized approach: Lets organizations meet objectives through alternative controls. Mostly useful for larger orgs.
• Script inventory (6.4.3): Must inventory and authorize all scripts running on payment pages. Big change for marketing-tag-heavy checkouts.
• Service provider expectations (12.8, 12.9): Tighter contractual obligations between service providers and merchants.
• Anti-phishing (5.4.1): Mechanisms to detect and protect against phishing attacks.

Scope reduction is the single highest-leverage PCI activity. Smaller scope means smaller audit, fewer controls, cheaper insurance. Techniques in priority order:

1. Iframe everything. Stripe Checkout redirect > Payment Element iframe > Stripe.js Elements > custom form. The further to the left, the smaller your scope.
2. Tokenize aggressively. Use Stripe Customer + Payment Method tokens. Your database stores token IDs, not PANs.
3. Sanitize at the edge. Strip card data from logs at the WAF / reverse proxy layer.
4. Segment networks. If you must touch card data, isolate the systems that do behind their own VPC.
5. Outsource refunds and chargebacks. Use Stripe's hosted dispute tooling rather than building your own.
6. Audit your CDN and analytics. Make sure no third-party scripts hit your checkout page.

If your SaaS lets other companies accept payments — Stripe Connect platforms, marketplace builds, embedded finance — you are likely a PCI Service Provider, not just a merchant. That changes the program meaningfully:

• You owe your sub-merchants written PCI responsibility allocations.
• Annual ASV scans are required regardless of transaction count.
• You must complete SAQ-D Service Provider (not SAQ-A) in most cases.
• Quarterly attestation and SOC-style reporting to acquirers may be required.

Building a marketplace? See our Stripe Connect Marketplace Architecture guide — we cover the compliance posture as part of the architecture.

For any path beyond SAQ-A, you will need an evidence package. The artifacts we collect at scoping:

• Network diagram showing cardholder data flow
• Asset inventory with CDE designation
• Annual pentest report (see our pentest cost guide)
• Quarterly ASV scan reports
• SAQ or RoC document
• Incident response plan
• Vendor management documentation (Stripe AOC, etc.)
• Information security policy
• Training records for security awareness
• Sample audit logs showing 12 months retention

Most SaaS founders end up needing both PCI and SOC 2. The good news: about 60% of the evidence overlaps. The bad news: the frameworks are not designed to be combined, so you still produce two reports.

Build the SOC 2 program first if you have the choice — it is broader. Then layer PCI scope artifacts on top. See our SOC 2 pentest prep guide for the SOC 2 path.