PCI DSS for SaaS startups: do you actually need it?

The most common question I get from early-stage founders about PCI DSS is some version of "we use Stripe, do we need to worry about this?" The answer is almost always "less than you think, but not zero."

Let me break down how PCI DSS actually applies to SaaS startups in 2026, because the answer varies significantly depending on how you've implemented payments, and getting this wrong in either direction costs you.

Getting it wrong by over-scoping costs you time and money on compliance work you didn't need to do. Getting it wrong by under-scoping puts you in violation of your payment processor's merchant agreement, which can result in fines, increased processing fees, or having your account terminated. Neither outcome is good.

What PCI DSS actually is

The Payment Card Industry Data Security Standard is a set of security requirements maintained by the PCI Security Standards Council (a body created by Visa, Mastercard, American Express, Discover, and JCB). Any entity that accepts, processes, stores, or transmits payment card data must comply.

The specific requirements that apply to you depend on your "merchant level" determined by your annual transaction volume, and your Self-Assessment Questionnaire (SAQ) type, which is determined by how card data flows through your systems.

For most early-stage SaaS startups, merchant level is not the gating factor. SAQ type is.

The three scenarios for SaaS startups

Scenario 1: You use Stripe or Braintree and card data never touches your servers

This is the most common situation for early-stage SaaS startups and it's the most favorable from a compliance standpoint.

If you're using Stripe Checkout, Stripe Elements, or Braintree's Drop-in UI, cardholders enter their payment information directly into a form hosted and secured by your payment processor. The card data never touches your application server. You never see it. Your server only ever receives a token.

In this case, you fall under SAQ A, which is the simplest self-assessment questionnaire in the PCI DSS framework. SAQ A has 22 requirements (as of PCI DSS v4.0), almost all of which are handled by your payment processor by virtue of them being PCI certified.

Your obligations under SAQ A are mostly about:

• Confirming you're using an approved payment processor
• Basic security practices for your own environment (don't store cardholder data, keep software patched, have an incident response process)
• Annual completion of the SAQ A form itself

If you're in this bucket, PCI DSS is not a major compliance burden. Complete the SAQ A annually, keep your Stripe integration current, and don't do anything to bring card data into your own environment.

Scenario 2: You use a payment processor but have a custom payment form on your own domain

This is where things get more complicated. If you've built a custom payment form using a JavaScript library like Stripe.js, where the form is on your domain but the data is transmitted directly to Stripe via their JavaScript, you're in SAQ A-EP territory.

SAQ A-EP is substantially more demanding than SAQ A. It has around 191 requirements and covers things like:

• Maintaining a secure development lifecycle
• Vulnerability scanning (quarterly external scans by an Approved Scanning Vendor)
• Regular penetration testing
• Detailed access control requirements
• Change detection mechanisms on your payment pages

The reason SAQ A-EP is more demanding is that because the payment form lives on your domain, an attacker who compromises your web server or injects malicious JavaScript could potentially intercept card data before it reaches Stripe. You're responsible for making sure that doesn't happen.

If you're in this scenario, it's worth having a conversation with your engineering team about whether moving to Stripe Checkout or Stripe's hosted payment links would simplify your compliance scope. For most SaaS products, there's no compelling reason to have a fully custom payment form and the compliance overhead of SAQ A-EP vs. SAQ A is substantial.

Scenario 3: You store, process, or transmit card data directly

If card numbers, CVVs, or magnetic stripe data pass through or are stored in your systems in any form, even temporarily, you're in full PCI DSS scope. This means all 12 PCI DSS requirement domains, merchant level assessment, and potentially a Qualified Security Assessor (QSA) conducting your audit rather than a self-assessment.

For early-stage SaaS startups, this scenario is almost always the result of a design decision that didn't have to be made this way. If you find yourself here, the first question to ask is: "Can we redesign our payment flow to use tokenization and eliminate direct card data handling?"

In most cases, the answer is yes, and the engineering work to get there is worth it to avoid the compliance overhead of full PCI DSS scope.

The practical checklist

Here's how to figure out where you stand in about 30 minutes:

Step 1: Ask your payment processor which integration method you're using. If you're using Stripe, log into your dashboard and look at how your Checkout integration is set up. Stripe's documentation clearly identifies which integration types are SAQ A eligible.

Step 2: Search your codebase for any storage of card numbers, CVVs, or expiration dates. Check your logs. Check your database. If you find any, that's an urgent remediation item regardless of which SAQ type applies.

Step 3: Look at your checkout flow from the customer's perspective. Is the payment form on your domain? Is it hosted entirely by Stripe/Braintree (e.g., you redirect to a Stripe-hosted page)?

Step 4: Contact your payment processor's merchant support and ask them directly: "What SAQ type do we fall under given our current integration?" They deal with this question constantly and can give you a definitive answer.

PCI DSS v4.0: what changed

PCI DSS v4.0 was released in 2022 and became the mandatory standard as of March 2024, with PCI DSS v3.2.1 officially retired. If you're looking at older compliance documentation, be aware that the SAQ forms and requirement counts have changed.

The headline changes in v4.0 that matter for early-stage startups:

• Stronger multi-factor authentication requirements (now required for all access into the cardholder data environment, not just remote access)
• New requirements around targeted risk analysis, you can customize some controls if you document your risk-based rationale
• Explicit requirements around web skimming prevention, which is particularly relevant if you have a custom payment form (SAQ A-EP)

The bottom line

If you're a typical early-stage SaaS startup using Stripe Checkout with no custom payment form, you need to complete SAQ A annually. That's genuinely not a big deal, budget a day of work the first time you go through it, and maybe a couple of hours for subsequent years.

If you have a custom payment form on your own domain, talk to your team about whether that's necessary. If it is, budget for SAQ A-EP and consider bringing in a QSA for at least an initial review.

If card data is touching your systems directly, that's the first engineering problem to solve, not the compliance question.

The goal of PCI DSS, stripped of all the bureaucracy, is simple: don't be the reason your customers' card numbers get stolen. The requirements exist because that outcome has happened, repeatedly, to companies that thought they were being careful. Most of what PCI DSS requires is just good security practice, the compliance program is the forcing function to actually do it.

---

Sprala includes automated PCI DSS monitoring alongside SOC 2, ISO 27001, and HIPAA, so you're not running four separate compliance programs. Request early access to see it in action.