PCI DSS Scope for SaaS: The SAQ Ladder, Merchant Levels, and the Math That Shrinks Your Audit

The question that decides your compliance bill

A SaaS founder adding card payments asks one question first: how much of my company becomes a PCI DSS audit? The answer is not a price list. It is a boundary. The standard applies to every entity that stores, processes, or transmits cardholder data or sensitive authentication data, or that could affect its security. The standard follows the data: every system the data touches — or that can touch the systems the data touches — is in scope until you prove otherwise.

Most SaaS companies get this backwards: they start by asking which questionnaire to file, when the questionnaire is the last step. The first step is drawing the cardholder data environment, the CDE, then shrinking it until the questionnaire left is the smallest your architecture honestly earns. This guide does that work in order: the twelve requirements, the merchant levels, the SAQ ladder, the scope math, and the filing sequence.

Who this guide is for, and who should stop here

This guide is for a SaaS operator that accepts cards — through its own checkout, a hosted payment page, or a payment provider — and must attest compliance annually to its acquirer or brand. It assumes a reader who can name their payment flow: where the card number enters, what system first sees it, and where it goes next. It is written for founders, CTOs, and compliance leads, from first revenue to Level 1 volume.

It is not for a company that only receives bank transfers, invoices, or crypto and never touches card data: the standard does not apply to payment methods carrying no cardholder data. Nor is it a substitute for a Qualified Security Assessor — the assessor, not the article, signs the attestation.

The twelve requirements, in the order they bite

PCI DSS v4.0 organises its controls into twelve requirements: the first six build the walls, the next four control who walks through them, the last two prove the walls held.

The Council's FAQ confirms the reach: all entities involved in payment processing, regardless of size or volume. Small merchants often have simpler environments, which reduces effort — but nothing exempts one. Validation, by contrast, is set by the brands and acquirers, which is why two merchants of the same size file different paperwork.

Merchant levels: the table that decides your validation

Stripe's compliance guide publishes the level table its merchants live under, the clearest public statement of how the brands slice volume. Levels are counted per brand, per year, and the counting method differs by level — online transactions for the middle levels, total transactions for the outer ones — so compute each brand separately.

Three traps hide in that table. First, Level 1 is per brand: 5 million Visa plus 5 million Mastercard is not Level 1 on either brand. Second, Level 3 counts online transactions while Level 4 offers an either-or test — a merchant with 900,000 total transactions but only 15,000 online is Level 4 under the online test, so confirm the classification with the acquirer in writing. Third, the quarterly ASV scan is not optional: a failed scan never remediated is an unfiled quarter.

Worked boundary: 1,050,000 Visa transactions a year, all online, is Level 2 — above the 1 million floor. Add 5 million and it crosses Level 1, where the SAQ stops being an option. The compliance budget jumps at thresholds.

The questionnaire ladder: SAQ A to SAQ D

Self-Assessment Questionnaires are, in the Council's words, validation tools for SAQ-eligible merchants and service providers, developed for specific environment types. Eligibility is the whole test: you do not choose the shortest questionnaire; your architecture qualifies for it or not.

The distance between the ends of this ladder is the article's central number. Stripe's security guide states that a business handling sensitive card data directly might be required to meet more than 300 security controls, with dedicated security software and hardware and external auditors. SAQ A answers only the controls surviving full outsourcing. Moving from SAQ D to SAQ A removes whole requirement families from your filing, not a percentage of the work.

Scope math: what tokenization and segmentation actually buy

Scope is where founders save or lose a year of audit. Encryption with strong cryptography is an acceptable method of rendering data unreadable under Requirement 3.5.1, but encryption alone is generally insufficient to render cardholder data out of scope, and does not remove the need for PCI DSS.

The Council then lists what is each in scope: systems performing encryption or decryption and key management; encrypted data not isolated from those processes; encrypted data on a system that also contains the key; encrypted data in the same environment as the key; and encrypted data accessible to an entity that also has access to the key. Design test: if your server can decrypt, it is in scope; if your logging pipeline carries ciphertext and your team holds the key, so is the pipeline.

Worked scope reduction, with illustrative system counts:

Before redesign: 6 systems store, process, or transmit card data; 9 connect to them; 4 affect their security (identity, logging, deployment, monitoring) — 19 in scope. After redesign — hosted payment page, tokenization, segmentation, shared services split so only payment-facing components touch the CDE — 2 + 1 + 1 = 4. The reduction is:

That percentage is the compliance budget: every system removed from scope drops its evidence and review burden. A validated point-to-point encryption solution can reduce requirements further, but the Council is explicit that it does not remove PCI DSS applicability — reduction, not disappearance, is the honest claim.

The storage rule is the most common accidental violation. Stripe's guide confirms what a SaaS may safely store from a charge response: card type, last four digits, and expiration date are not subject to PCI compliance, and anything returned by the API may be stored. The verification code must never be stored after authorization, and the full number must never land in logs, tickets, analytics, or error reports. One ticket pasting a card number moves that ticket system into scope; the cleanup is forensic, not a delete key.

The filing sequence, with its traps

• [x] Phase 1: Map the flow — Draw every hop of the card number from browser to provider, including webhooks, retries, and error paths. Anything unnamed is unscoped.
• [x] Phase 2: Draw the CDE boundary — Apply the scope formula. Segment the CDE from the corporate network; split shared services so only payment-facing components stay inside.
• [x] Phase 3: Pick the SAQ by eligibility, not preference — If the website builds the payment form, that is A-EP, not A, however the provider markets it.
• [x] Phase 4: Remediate before attesting — Patch, rotate defaults, enforce MFA on CDE access, confirm TLS 1.2 or above on every payment page.
• [x] Phase 5: Scan quarterly, attest annually — Run the ASV scan every quarter; file the SAQ or Report on Compliance annually with the acquirer.
• [x] Phase 6: Re-scope on every architecture change — A new analytics script on the payment page, a new logging pipeline, a new support tool: each re-opens the scope question.

Two traps: a third-party script on the payment page — analytics tag, chat widget, A/B test — pulls its host into scope under SAQ A-EP logic, so it is a scope decision, not a marketing decision. And the acquirer: the Council states that whether a small merchant must validate, and how, is determined by the brands and the acquirer, whose portal and deadlines govern your calendar.

Operator boundaries

This playbook fits a SaaS that outsources card handling to a provider and keeps its surface minimal. It does not fit a company building its own gateway, storing cards for a wallet, or processing cards for other merchants: those are service-provider validations, and a merchant SAQ will not cover them. Nor does it fit a product needing card data for its own logic — fraud models trained on full numbers, support flows displaying them. If the product needs the number, budget for SAQ D and a QSA from the first review: retrofitting a CDE around a product that already spreads card data is the most expensive project here.

Cross-border note: validation is brand- and acquirer-driven, and local laws add duties — breach notification, data residency, privacy — alongside the standard. A European base adds GDPR: PCI DSS asks whether card data is protected, GDPR whether you had a lawful basis to hold it. Answer both.

Decision matrix: which model for which SaaS

Related reading on this site: the Visa VAMP dispute-ratio defense playbook, the high-risk merchant processing guide, and the chargeback defense evidence guide. Price fee exposure with the break-even calculator.