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.
> [!KEY TAKEAWAY]
> PCI DSS does not price your compliance; your architecture does. A SaaS that never touches a card number files the shortest questionnaire; one that stores card numbers answers more than 300 controls and hires an auditor. That difference is a design decision made the day the checkout is built, reversible only by rebuilding it.
!Stripe's compliance-level table: Level 1 and Level 2 thresholds and requirements
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.
| Requirement | What it demands | Authority |
| :--- | :--- | :--- |
| 1. Network security controls | Firewalls and segmentation around the CDE | PCI DSS v4.0, Requirement 1 |
| 2. Secure configurations | Hardened defaults on every component | PCI DSS v4.0, Requirement 2 |
| 3. Stored account data protection | Encryption, masking, truncation, key management | PCI DSS v4.0, Requirement 3 |
| 4. Data in transit protection | Strong cryptography over open networks | PCI DSS v4.0, Requirement 4 |
| 5. Malicious software protection | Anti-malware on all affected systems | PCI DSS v4.0, Requirement 5 |
| 6. Secure systems and software | Patching, secure development, change control | PCI DSS v4.0, Requirement 6 |
| 7. Access by business need | Least-privilege access | PCI DSS v4.0, Requirement 7 |
| 8. Identification and authentication | Unique IDs, strong passwords, MFA | PCI DSS v4.0, Requirement 8 |
| 9. Physical access restriction | Controls on physical access | PCI DSS v4.0, Requirement 9 |
| 10. Logging and monitoring | All CDE access logged, reviewed daily | PCI DSS v4.0, Requirement 10 |
| 11. Regular security testing | Vulnerability scans, penetration tests | PCI DSS v4.0, Requirement 11 |
| 12. Information security policy | Policies, training, incident response | PCI DSS v4.0, Requirement 12 |
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.
| Level | Volume test (per brand, per year) | What you file | Authority |
| :--- | :--- | :--- |
| Level 1 | More than 6 million Visa transactions, more than 6 million Mastercard transactions, or more than 2.5 million American Express transactions | Annual QSA-led Report on Compliance, plus quarterly ASV scans | Stripe PCI compliance guide |
| Level 2 | Between 1 million and 6 million transactions annually | SAQ, Attestation of Compliance, or Report on Compliance; SAQ A, A-EP, and D must be signed by a QSA or ISA; plus quarterly ASV scans | Stripe PCI compliance guide |
| Level 3 | Between 20,000 and 1 million online transactions annually | SAQ and quarterly ASV scans | Stripe PCI compliance guide |
| Level 4 | Fewer than 20,000 online transactions annually, or up to 1 million total transactions annually | SAQ and quarterly ASV scans | Stripe PCI compliance guide |
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.
| SAQ | Who qualifies | What it means in practice | Authority |
| :--- | :--- | :--- |
| SAQ A | Card-not-present merchants with all cardholder data functions fully outsourced; no electronic storage, processing, or transmission on merchant systems | Hosted page or iframe: the number goes to the provider, never to you | PCI SSC SAQ eligibility; Stripe guide |
| SAQ A-EP | E-commerce merchants whose website affects the security of the payment transaction, though card data itself is outsourced | Your page controls the form, so your web environment is in scope | PCI SSC SAQ eligibility; Stripe guide |
| SAQ C-VT | Web-based virtual terminals only, no electronic storage | Staff keying cards into a provider portal only | PCI SSC SAQ eligibility |
| SAQ B, B-IP, C | Terminal and payment-application variants | Countertop and POS models, largely irrelevant to SaaS | PCI SSC SAQ eligibility |
| SAQ D | Everyone else, including all merchants that store cardholder data electronically | The full standard, every applicable requirement | PCI SSC SAQ eligibility; Stripe guide |
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 PCI Council's scope rule: encryption alone does not remove cardholder data from scope
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:
$
\text{In-Scope Systems} = \text{CHD Systems} + \text{Connected-To Systems} + \text{Security-Impacting Systems}
$
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:
$
\text{Scope Reduction} = \frac{19 - 4}{19} \times 100 = 78.9\%
$
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
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.
> [!FOUNDER]
> "Founders treat PCI DSS as paperwork and discover it is architecture. The cheapest compliance program I have seen was not the one with the best auditor; it was the one where the checkout never let a card number into the building. Draw the boundary before the roadmap, because every system you let touch the data charges rent forever."
> — Enow A. Jovial, Founder & Chief Executive Officer
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.
> [!WARNING]
> Attesting SAQ A while your servers, logs, or scripts touch card data is not a shortcut; it is a false attestation to your acquirer and the brands. Discovery — through breach forensics, acquirer audits, or a scan failure — converts a scope correction into a compliance incident with fines, forensic costs, and a forced assessment on another timetable.
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.
> [!TIP]
> Run the scope formula on staging and analytics too: staging replaying production card data, and analytics ingesting checkout events, are where a clean production CDE quietly expands. Synthetic test cards in staging and a card-data filter on analytics ingestion close both gaps in under a day of engineering.
Decision matrix: which model for which SaaS
| Model | Your filing | Your audit surface | When it wins | Authority |
| :--- | :--- | :--- |
| Hosted payment page / iframe, no card data on your systems | SAQ A | Website outside the payment frame, plus policies | Default for most SaaS | PCI SSC SAQ eligibility; Stripe guide |
| Your page builds the payment form, provider holds the data | SAQ A-EP | Your web environment plus provider boundary | When checkout needs form control | PCI SSC SAQ eligibility; Stripe guide |
| Staff key cards into a provider portal | SAQ C-VT | The terminal workstations and their network | Manual order-taking only; never for self-serve checkout | PCI SSC SAQ eligibility |
| You store or process card numbers | SAQ D or QSA-led ROC | The full CDE, every requirement | Only when the product needs the number | Stripe guide: 300+ controls |
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.