SaaS teams often inherit payment flows that leak cardholder data into places it never needed to go. That expands PCI scope, slows audits, and ties up engineers. The initial review should cover how to remove primary account numbers (PAN) from your platform, select the applicable Self‑Assessment Questionnaire (SAQ), and document the Cardholder Data Environment (CDE).
PCI DSS in 2025: what changed and what didn’t
Version 4.0 tightened multi‑factor authentication, clarified roles around e‑commerce scripts, and updated vulnerability management requirements. Scope remains a major factor in assessment effort. Tokenization still removes most of your app from the CDE. If PAN never reaches your storage, queues, logs, or support tools, the control surface stays narrow.
Keep sensitive components out of scope
In scope
- Anything that stores, processes, or transmits PAN
- Systems that can impact CDE security (authN/Z, CI/CD to CDE)
- Admin workstations used to manage CDE systems
- Network segments that route cardholder data
Keep out of scope
- Primary app backends: use tokens from your PSP, never PAN
- Event pipelines and logs: mask/purge PAN before ingest
- Support tooling: never ask for full card numbers
- Third parties: contractually require no PAN handling
Tokenization can reduce card-data handling in your application and data stores. Confirm which systems remain in assessment scope.
Which SAQ applies to a typical SaaS
Most subscription products can reach SAQ A or A‑EP by using a fully hosted checkout or redirect with a PCI‑validated provider. Confirm eligibility before committing to a questionnaire. Use the lowest‑scope option your architecture truthfully fits.
Which SAQ fits a typical SaaS?
PCI scope depends on how you accept and handle card data. Start with your payment flow, then pick the lowest‑scope form that truthfully applies.
- SAQ A: No card data touches your systems. You use a fully hosted payment page or redirect provided by a PCI‑validated service provider. JavaScript overlays like “drop‑in” forms that post directly to the provider can still qualify, but only if no PAN passes through your servers, logs, or front‑end code.
- SAQ A‑EP: E‑commerce where your site influences the page that collects card data (e.g., posts to provider, JS on your domain). No PAN on your servers, but your front end can affect the page presented to the cardholder. Requires more controls than SAQ A.
- SAQ D (Merchant): You store, process, or transmit any card data, or your architecture does not meet A/A‑EP conditions. This is the “everything applies” case and carries the full control set.
Review whether a redirect or fully hosted checkout qualifies your payment flow for SAQ A. Check logs and telemetry for PAN or track data.
Scoping: data flows, third parties, and tokenization
Map where PAN could appear: web forms, mobile SDKs, server endpoints, background jobs, support tools, logs, and analytics. Replace PAN with tokens end‑to‑end. Scrub collectors and pipelines that might sample payloads. Contractually require that processors never return PAN in webhooks or exports, and verify in staging.
Keep the CDE segmented: its identity, networks, CI/CD, and observability should be independent from the rest of your platform. The goal is to make a compromise outside the CDE incapable of affecting payment data.
Hosted checkout and card-data handling
Review whether a redirect or fully hosted checkout can remove PAN from your systems. Check custom forms that post PAN through your domain, logs and traces that capture request bodies, exports that leak masked data, support requests for full card numbers, and staging environments that mirror production data.
Review payment handling and assessment scope
- Adopt a fully hosted checkout with a PCI‑validated provider (redirect or iframe that posts directly to the PSP).
- Eliminate PAN from your app, logs, metrics, traces, and support flows. Add detectors and drop any accidental payloads.
- Segment the Cardholder Data Environment (CDE) from the rest of your platform. Separate accounts/VPCs and identity boundaries.
- Maintain the assessment records: network diagrams, data flow maps, hardening baselines, vulnerability management, and incident response.
- Pick the right SAQ and complete it honestly. Bring a QSA early if anything is ambiguous.
When to bring in a QSA, and what they ask for
A Qualified Security Assessor is worth bringing in early if you process high volumes, operate across multiple environments, or suspect SAQ D applies. Expect requests for data‑flow diagrams, network maps, hardening baselines, vulnerability and patch records, access reviews, incident procedures, and evidence that controls operate in practice: screenshots with timestamps, command output, and ticket trails.
What to do next
Confirm whether the proposed payment flow qualifies for SAQ A or A-EP before changing the checkout. Inventory every place PAN might leak, then remove or block it. Segment the CDE. Assign an owner for each evidence set and keep it current.