PCI DSS Compliance for SaaS Companies: What You Actually Need to Do

If your SaaS product accepts credit card payments — and it almost certainly does — PCI DSS applies to you. The good news: for most SaaS companies, achieving compliance is far simpler than you think, if you architect your payment flow correctly.

The bad news: if you're handling card data directly, you're in for a painful and expensive compliance journey.

This guide helps you understand what PCI DSS requires, how to minimize your scope, and what you actually need to implement.

Does PCI DSS Apply to You?

PCI DSS applies to any organization that processes, stores, or transmits cardholder data. That includes:

• Merchants: You charge customers' credit cards (most SaaS companies)
• Service providers: You handle card data on behalf of other businesses (payment platforms)

The critical question: Does cardholder data (card numbers, CVV, expiration dates) ever touch your servers?

• If no (you use Stripe Checkout, Stripe Elements, PayPal hosted): You have minimal PCI scope → SAQ A or SAQ A-EP
• If yes (you collect card numbers server-side): You have significant PCI scope → SAQ D or full ROC

PCI DSS v4.0: What Changed

PCI DSS v4.0 became mandatory on March 31, 2025. Key changes:

1. Customized approach: Organizations can now implement alternative controls if they achieve the same security objective
2. Enhanced authentication: MFA required for all access to the cardholder data environment (not just admin)
3. Continuous monitoring: Quarterly scans aren't enough — ongoing security monitoring is now expected
4. Targeted risk analysis: Each requirement now expects a documented risk analysis
5. Client-side security: New requirements for managing JavaScript and preventing e-skimming attacks

Minimize Your Scope First

The single most important PCI strategy: keep cardholder data off your infrastructure entirely.

The Ideal Architecture (SAQ A)

Customer Browser
    ↓
Stripe.js / Stripe Elements (card number never touches your server)
    ↓
Stripe API (tokenization)
    ↓
Your Server (receives a token, never the card number)
    ↓
Stripe API (charge the token)

With this architecture, your PCI scope is minimal. Card numbers never touch your servers, and your SAQ A is approximately 20 requirements.

The Common Mistake (SAQ D)

Customer Browser
    ↓
Your Server (receives the card number! 🚨)
    ↓
Stripe API (charge the card)

Even if you immediately forward the card number to Stripe, you're in scope because the data passed through your server. This puts you in SAQ D territory — 300+ requirements and potentially a full on-site audit.

Payment Provider Integration Comparison

Our recommendation: Use Stripe Checkout or Stripe Elements. Period. The scope reduction is worth any UX trade-offs.

SAQ A: The SaaS Sweet Spot

If you've minimized scope correctly, here's what SAQ A requires:

1. No Storage of Cardholder Data

Confirm that your systems never store, process, or transmit cardholder data.

2. Payment Page Security (New in v4.0)

• Ensure your payment page is served over HTTPS
• Implement Content Security Policy (CSP) headers to prevent script injection
• Monitor scripts loaded on payment pages for unauthorized changes
• Maintain an inventory of all scripts on payment pages

<!-- Content Security Policy for payment pages -->
<meta http-equiv="Content-Security-Policy"
  content="script-src 'self' https://js.stripe.com;
           frame-src https://js.stripe.com https://hooks.stripe.com;
           connect-src https://api.stripe.com;">

3. Vulnerability Management

• Use a web application firewall (WAF) or have regular vulnerability scans
• Ensure all software is patched and up to date

4. Access Control

• Unique user IDs for all users
• Restrict access to payment-related systems

5. Service Provider Management

• Maintain a list of all service providers that handle cardholder data
• Ensure each has a current PCI DSS compliance attestation
• Monitor their compliance status annually

SAQ A-EP: For Client-Side Integration

If you use Stripe Elements or Stripe.js (where JavaScript runs on your page but card data goes directly to Stripe), you'll need SAQ A-EP. Additional requirements include:

Network Security

• Restrict inbound and outbound traffic to payment-related systems
• Install and maintain a firewall configuration

Secure Configuration

• Change default passwords on all systems
• Harden server configurations
• Remove unnecessary services

Encryption

• Use TLS 1.2+ for all connections
• Only use strong cryptographic protocols
• Test SSL/TLS configuration regularly

# Test your TLS configuration
# Using testssl.sh (open source)
testssl.sh --severity HIGH https://yourdomain.com

# Or check with Proveably's external scan
# which maps findings directly to PCI DSS requirements

Logging and Monitoring

• Log all access to payment-related systems
• Review logs regularly
• Implement automated alerting for suspicious activity

Vulnerability Management

• Run quarterly vulnerability scans by an Approved Scanning Vendor (ASV)
• Conduct annual penetration tests
• Patch critical vulnerabilities within 30 days

PCI DSS and Other Frameworks

If you're already working on SOC 2 or ISO 27001, there's significant overlap with PCI DSS:

With Proveably, a single scan maps findings across SOC 2, ISO 27001, HIPAA, and PCI DSS simultaneously. Fix one finding and make progress on all applicable frameworks.

Quarterly ASV Scans

PCI DSS requires quarterly external vulnerability scans by an Approved Scanning Vendor (ASV). These scans check your external-facing systems for:

• Known vulnerabilities (CVEs)
• SSL/TLS configuration issues
• Open ports and services
• Web application vulnerabilities
• DNS security issues

ASV scan requirements:

• Must pass with no high-severity vulnerabilities (CVSS ≥ 4.0)
• If you fail, you must remediate and rescan
• Four passing quarterly scans required annually
• Scans must be performed by a PCI SSC-approved ASV

Pro tip: Run your own vulnerability scans between ASV quarters using Proveably. Catch and fix issues before your quarterly scan, so you pass on the first attempt.

Common PCI Mistakes We See

1. Processing card data server-side "just for a moment": Even transient handling puts you in SAQ D scope
2. Storing card data in logs: Application logs that capture POST bodies or API responses containing card numbers
3. Missing CSP headers on payment pages: PCI DSS v4.0 requires Content Security Policy on pages with payment forms
4. Sharing database between payment and non-payment systems: Segment your cardholder data environment
5. Not monitoring payment page scripts: Third-party scripts on your payment page can skim card data (Magecart-style attacks)
6. Ignoring test/sandbox card numbers: Test data with real card formats still counts as cardholder data

PCI DSS Compliance Timeline

For SAQ A (Minimal Scope)

• Week 1: Verify payment architecture — confirm card data never touches your servers
• Week 2: Implement CSP headers, review payment page scripts
• Week 3: Complete your SAQ A questionnaire
• Week 4: Submit to your acquiring bank

For SAQ A-EP (Client-Side Integration)

• Week 1-2: Architecture review and network security hardening
• Week 3-4: Implement logging, monitoring, and access controls
• Week 5-6: First ASV scan and remediation
• Week 7-8: Complete SAQ A-EP questionnaire, pass rescan if needed

Not sure where your PCI DSS scope starts and ends? Run a free Proveably scan to assess your external attack surface and get findings mapped directly to PCI DSS requirements. We'll help you understand your actual scope and prioritize remediation so you can achieve compliance faster.