PCI DSS Compliance for SaaS Founders: What You Actually Need to Do
If your SaaS product takes payments — even through Stripe or Braintree — you are in scope for the Payment Card Industry Data Security Standard (PCI DSS). The question isn't whether PCI DSS applies to you. It's how much applies, and how you prove it.
This guide explains PCI DSS v4.0 in plain terms, walks through the Self-Assessment Questionnaire (SAQ) types, and tells you exactly what a typical SaaS founder needs to do (and what they don't).
What Is PCI DSS?
PCI DSS is a security standard created by the major card brands (Visa, Mastercard, American Express, Discover, UnionPay) through the PCI Security Standards Council (PCI SSC). It applies to any organisation that stores, processes, or transmits cardholder data (CHD) — meaning credit and debit card numbers, names, expiry dates, and CVV codes.
PCI DSS v4.0 replaced v3.2.1 in March 2024. Some new requirements become mandatory by 31 March 2025.
Non-compliance can result in:
- Fines from your acquiring bank ($5,000–$100,000/month)
- Termination of your merchant account (can't take cards)
- Card brand assessments and forensic investigation costs after a breach
- Per-card replacement fees if fraud occurs
The Most Important Thing: Your SAQ Type
Not every merchant needs to implement all 12 PCI DSS requirements. The SAQ (Self-Assessment Questionnaire) you need depends on how you process payments.
| SAQ Type | Who It Applies To | Controls |
|---|---|---|
| SAQ A | Card-not-present merchants where ALL payment functions are outsourced to PCI DSS-compliant providers (Stripe Checkout, Braintree Hosted Fields, PayPal redirect). Your servers never touch card data. | ~22 requirements |
| SAQ A-EP | E-commerce merchants with a third-party payment page, but your website could affect payment page security (e.g. JavaScript on the page that loads the payment form). | ~191 requirements |
| SAQ B | Imprint machines / standalone dial-out terminals, not internet-connected. | ~41 requirements |
| SAQ C | Payment application systems connected to internet, no electronic CHD storage. | ~160 requirements |
| SAQ D (Merchant) | All merchants not eligible for other SAQ types. Stores/processes/transmits CHD directly. | All 12 requirements |
| SAQ D (Service Provider) | Service providers that handle CHD on behalf of other merchants. | All 12 requirements + SP-specific |
Most SaaS founders using Stripe, Braintree, or Adyen hosted checkout qualify for SAQ A. This is intentional — it dramatically reduces your compliance burden by delegating card data handling to a certified provider.
SAQ A vs SAQ A-EP: The Critical Distinction
The line between SAQ A and SAQ A-EP matters enormously for scope.
SAQ A applies when:
- All cardholder data functions are fully outsourced
- Your website redirects customers to a fully hosted payment page (Stripe Checkout, PayPal redirect)
- OR you use an iframe where the iframe is fully hosted and controlled by your payment processor
- Your servers never receive card data
SAQ A-EP applies when:
- You use a JavaScript-based hosted payment field (Stripe Elements, Braintree JavaScript SDK)
- The cardholder's browser loads your page AND your JavaScript, which then calls the payment processor
- You don't receive card data but your servers could affect the integrity of the payment page
The difference matters because SAQ A-EP includes Requirement 6 (secure software development), Requirement 11 (penetration testing), and significantly more controls around your web application security.
The 12 PCI DSS Requirements
| Requirement | What It Covers | SAQ A Required? |
|---|---|---|
| 1. Network Security Controls | Firewalls, network segmentation | No |
| 2. Secure Configurations | Default passwords changed, hardening standards | No |
| 3. Protect Stored CHD | No SAD storage, PAN encryption/tokenisation | No (you don't store) |
| 4. Encryption in Transit | TLS 1.2+ for all card data transmission | Yes — verify TLS on payment links |
| 5. Anti-malware | AV on all systems, anti-phishing (v4.0 new) | No |
| 6. Secure Development | OWASP, code review, WAF, script integrity (v4.0 new) | Req 6.4.3 / 11.6.1 — Yes |
| 7. Access Control | Least privilege, RBAC, access reviews | No |
| 8. Authentication | Unique IDs, MFA (expanded in v4.0), 12-char passwords | Yes — MFA for admin access |
| 9. Physical Security | Physical access controls, visitor logs | No |
| 10. Logging & Monitoring | Audit logs, 12-month retention | No |
| 11. Security Testing | Vulnerability scans, pen tests, script monitoring | Req 11.6.1 — Yes (v4.0) |
| 12. Security Policies & Programmes | InfoSec policy, awareness training, TPSP management, IRP | Yes — policy, training, IRP, TPSP list |
PCI DSS v4.0 New Requirements to Know
PCI DSS v4.0 introduced several important changes from v3.2.1. Two are critical for SaaS merchants:
Req 6.4.3 and 11.6.1 — Payment Page Script Integrity (Effective March 2025)
This is the most impactful new requirement for SAQ A and SAQ A-EP merchants. It's designed to combat Magecart-style attacks where attackers inject skimming code into payment pages.
- 6.4.3: All payment page scripts must be managed: authorised, reviewed for integrity, and justified. Use Subresource Integrity (SRI) for third-party scripts.
- 11.6.1: A change and tamper-detection mechanism must be in place. HTTP headers and payment page content must be reviewed (automatically) at least weekly for unauthorised changes. Solutions include Content Security Policy (CSP), SRI, and specialised tools like Featurespace or SourceDefense.
Practical implementation: Add CSP headers to your payment page. Use SRI attributes on all script tags. Configure a tool to alert on unexpected script changes.
Req 8.4.2 — MFA Expansion
v4.0 expands MFA requirements. MFA is now required for all administrator access to the CDE (not just remote access). For SAQ A merchants, this means MFA for your payment processor admin panels and any system that could affect the payment flow.
Req 8.6.3 — 12-Character Passwords
Minimum password length is now 12 characters (up from 7 in v3.2.1). This applies to all accounts with access to CHD or systems in scope.
Merchant Levels: Who Gets Audited by a QSA?
| Level | Transaction Volume | Validation Requirement |
|---|---|---|
| Level 1 | >6M Visa/MC transactions/year, or any merchant after a breach | Annual on-site audit by QSA + quarterly ASV scans |
| Level 2 | 1M–6M transactions/year | Annual SAQ + quarterly ASV scans |
| Level 3 | 20K–1M e-commerce transactions/year | Annual SAQ + quarterly ASV scans |
| Level 4 | <20K e-commerce, or up to 1M all other | Annual SAQ recommended + quarterly scans (acquirer discretion) |
Most SaaS founders start as Level 4 or Level 3 — self-assessment only, no QSA required. You move to Level 1 only at very high volume or after a breach.
The Minimal Viable Compliance Stack for SAQ A SaaS
If you're using Stripe Checkout or a fully hosted payment page, your SAQ A requirements are manageable:
- Use TLS 1.2+ everywhere — especially on any page or API that has anything to do with the payment flow
- Enable MFA on your Stripe/payment processor admin account and all other admin access
- Use 12+ character passwords for all accounts in scope
- Implement script integrity monitoring on your payment page (CSP + SRI + weekly check) — required from March 2025
- Maintain an information security policy that references your payment processing environment
- Run security awareness training annually, including phishing awareness
- Maintain a TPSP list — document that Stripe/your processor is PCI DSS certified and get their latest AOC (Attestation of Compliance)
- Have an incident response plan that covers payment data breaches (24-hour notification to card brands and acquirer)
- Complete and sign your SAQ annually — submit to your acquiring bank
The Biggest Mistakes SaaS Companies Make with PCI DSS
- Assuming hosted payments = zero compliance burden. SAQ A still has ~22 requirements. The new script integrity rules (Req 6.4.3 / 11.6.1) apply to you.
- Not scoping correctly. Any system connected to your CHD environment is in scope — including dev/staging if they can reach production card systems.
- Forgetting third-party service provider management. You need a list of all TPSPs and their PCI DSS compliance status. Stripe, Braintree, etc. publish their AOCs — download and keep them.
- Not completing the SAQ annually. PCI DSS compliance is an annual exercise. Missing your annual submission is a compliance gap your acquiring bank can act on.
- Assuming v3.2.1 knowledge is sufficient. v4.0 is live. The new script integrity requirements (Req 6.4.3, 11.6.1) are critical for anyone with a payment page — even SAQ A merchants.
Generate Your PCI DSS SAQ Now
ComplyKit's free PCI DSS SAQ Generator walks you through the relevant controls for your SAQ type and generates a structured self-assessment report you can use as a starting point. It covers all 12 requirements, highlights v4.0 new requirements, identifies your gaps, and produces a remediation priority list.
Related documents you'll likely need:
- Information Security Policy Generator — required for Req 12.1
- Incident Response Plan Generator — required for Req 12.10
- Vendor Risk Assessment Generator — for Req 12.8 TPSP management
- Data Retention Policy Generator — for Req 3.2 data minimisation
⚠️ This guide is for informational purposes and does not constitute legal advice. PCI DSS compliance should be validated with your acquiring bank and, for complex environments, a Qualified Security Assessor (QSA).