PCI DSS Compliance for SaaS: How to Reduce Your Scope (And Cut Costs by 70%)

Before you implement a single PCI DSS control, before you call a QSA, before you write a single security policy — do this one thing: reduce your scope.

Scope is the universe of systems, people, and processes that touch cardholder data. Every system in scope must be patched, monitored, logged, assessed, and audited. Every person in scope must be trained and access-managed. Every process in scope must be documented and reviewed.

The size of your scope is the single most important variable in your PCI DSS compliance cost, timeline, and complexity. A company with 200 systems in scope and a company with 8 systems in scope are doing fundamentally different compliance programs — in terms of time, cost, and ongoing maintenance burden.

The good news: for most modern SaaS companies built on Stripe, Braintree, or Adyen, radical scope reduction is achievable. Many companies that believe they need SAQ D — the most comprehensive questionnaire, with 329 questions — actually qualify for SAQ A with 22 questions, once their payment architecture is correctly implemented.

This guide explains exactly how to achieve that.

Understanding PCI DSS Scope

The PCI SSC defines scope as: all system components included in or connected to the cardholder data environment (CDE). The CDE is all systems that store, process, or transmit cardholder data (CHD) or sensitive authentication data (SAD), plus all systems that provide security services to the CDE, or that can impact the security of the CDE.

That last clause is where scope expands explosively in poorly architected environments. A developer workstation that can SSH into a production database server is technically in scope. A monitoring system that reads from an in-scope system may be in scope. A build pipeline that deploys to in-scope servers may be in scope.

Scope reduction is the process of eliminating cardholder data from your environment entirely, or isolating it behind controls that are so strong that the rest of your infrastructure is provably out of scope.

Strategy 1: Tokenization — The Gold Standard

Tokenization replaces a sensitive cardholder number (PAN) with a non-sensitive token that references the original value stored securely at your payment processor. Your system stores and processes the token. It never sees the PAN.

How It Works with Stripe

When a customer enters their card number on your checkout page using Stripe.js or Stripe Elements, the card data goes directly to Stripe's servers over an encrypted connection. Stripe returns a token (a PaymentMethod ID like pm_1234... or a legacy Token like tok_1234...). Your server receives only this token.

Your database stores pm_1234.... To charge the card, your server sends this token and the charge amount to Stripe's API. Stripe looks up the actual card number, processes the transaction, and returns a charge result. The PAN never exists on your servers, in your logs, in your database, or in your application memory.

Scope impact: Your servers are out of scope for PCI DSS. If you use Stripe.js (or Stripe Elements) and never handle PANs server-side, you qualify for SAQ A — the lightest assessment — with 22 requirements.

How It Works with Braintree

Braintree's Drop-in UI and Hosted Fields work on the same principle. The Braintree.js library collects card data, sends it to Braintree's servers, and returns a nonce (a single-use payment method token). Your server sends the nonce to Braintree's API to complete the transaction. No PAN ever reaches your application.

How It Works with Adyen

Adyen's Web Components (previously Checkout SDK) collect and tokenize card data client-side. Adyen returns a paymentMethodToken which your application uses for subsequent transactions. Adyen's tokenization is network tokenization-capable, meaning in some implementations the token is further protected by the card network itself.

Common Tokenization Mistakes That Invalidate Scope Reduction

Mistake 1: Logging card data. Your application logs request payloads for debugging. Someone adds a full-body request log. If that log ever captured a PAN (before tokenization), your logging infrastructure is in scope. Use structured logging and explicitly exclude payment method fields from log output.

Mistake 2: Storing CVV2 in any form. CVV2 (the three-digit security code) cannot be stored after authorization under any circumstances. Even in an encrypted form. Even in a temporary cache. Storing CVV2 is a direct PCI DSS violation under Requirement 3.2.1.

Mistake 3: Passing card data through your server for "validation." Some engineering teams route card numbers through their backend for validation before sending to the payment processor. This eliminates your scope reduction benefit entirely. Validation must happen client-side or at the processor.

Mistake 4: Mobile apps that capture card data before sending to the processor. Mobile apps that read card numbers directly (e.g., manual card entry captured by a React Native form component) and then send them to your backend are handling PANs. Use the payment processor's mobile SDK instead.

Strategy 2: Hosted Payment Pages

A hosted payment page is a payment form served entirely by your payment processor — not by your web servers. When a customer clicks "Pay," they are redirected to (or presented with) a page hosted on Stripe's, Braintree's, or Adyen's domain. Your web server serves the product page; the processor serves the payment page.

Stripe Checkout

Stripe Checkout is a pre-built, Stripe-hosted payment page. The customer is redirected to a URL at checkout.stripe.com. Stripe handles the payment form, card collection, 3D Secure, and redirect back to your success/cancel URL. Your server initiates the session and handles the result — it never touches card data.

Scope impact: SAQ A eligibility if Stripe Checkout is your only card collection mechanism.

PayPal Checkout / Braintree PayPal

Fully hosted by PayPal/Braintree's infrastructure. SAQ A eligible.

Adyen Pay by Link / Hosted Payment Pages

Adyen's hosted payment page option provides a payment URL that your server generates and sends to the customer. Card collection happens on Adyen's hosted page.

iFrame-Based Payment Forms

Many processors offer iFrame-based payment forms (Stripe Elements, Braintree Hosted Fields) that embed a payment form served from the processor's domain inside an iFrame on your page. The card data is handled entirely within the iFrame by the processor's servers.

Scope impact: iFrame implementations typically qualify for SAQ A-EP rather than SAQ A, because your web server serves the page that contains the iFrame. SAQ A-EP has 191 requirements versus 22 for SAQ A — a meaningful difference. The PCI SSC considers the page origin and script execution environment in its SAQ eligibility determination.

Critical distinction: If your web server serves the payment page (even if the card input field is an iFrame from Stripe), you are SAQ A-EP. If the customer is fully redirected to the processor's page, you are SAQ A.

Strategy 3: Network Segmentation

If your business model requires processing cardholder data server-side — for example, a payment facilitator (PayFac), a card-present merchant, or a company integrating with card networks directly — you cannot eliminate your CDE through tokenization alone. But you can minimize its size through network segmentation.

Network segmentation isolates CDE systems behind strict firewall controls so that no system outside the CDE can communicate with systems inside the CDE without passing through controlled, monitored access points.

Before Segmentation: The Flat Network Problem

In a flat network architecture, all your services live in a single VPC (or equivalent) without strict internal firewalling. Your API servers, databases, analytics infrastructure, developer tools, and internal dashboards can all reach each other. If one of your analytics services or developer laptops is compromised, an attacker can potentially reach your card data.

Scope in a flat network: potentially hundreds of systems.

After Segmentation: The Minimal CDE

A properly segmented CDE in AWS might look like:

CDE VPC: Contains only the specific services that touch cardholder data (a dedicated payment processing microservice + a dedicated PCI-compliant database)
App VPC: Contains all other application services (API servers, worker queues, analytics)
VPC Peering with explicit allow rules: The CDE VPC allows inbound connections only from specific API server instances in the App VPC, on specific ports
No outbound internet access from CDE: CDE instances route through a NAT Gateway only for approved destinations
Security groups: Allow only required traffic; deny everything else by default

Scope in a segmented environment: 2–8 systems.

AWS Services for CDE Segmentation

Service	PCI Use
VPC with private subnets	CDE network isolation
Security Groups	Instance-level firewall rules
Network ACLs	Subnet-level traffic control
AWS Network Firewall	Deep packet inspection and traffic filtering
VPC Flow Logs	Traffic logging for Requirement 10
AWS PrivateLink	Private connectivity to AWS services without internet exposure
AWS Systems Manager Session Manager	Admin access to CDE instances without SSH exposure

GCP Services for CDE Segmentation

Service	PCI Use
VPC networks with firewall rules	CDE network isolation
VPC Service Controls	Perimeter-based access control
Cloud Armor	WAF and DDoS protection
Cloud Logging	Traffic and access logging
Private Google Access	Access to Google APIs without public internet routing

Mid-Article CTA

Your payment architecture may qualify for a far smaller PCI scope than you think. QuickTrust's engineers assess your payment integration and deliver a scope reduction plan — with implementation — in 6–10 weeks. Get your scope reduction assessment.

Before and After: A Real-World Scope Reduction Example

Company: B2B invoicing SaaS. 150-person company. Stripe integration built two years ago by a developer who embedded card forms in the app's own pages and forwarded payment data through the backend.

Before Scope Reduction

Payment data passed through API servers for "validation" before being sent to Stripe
Card numbers appearing in application debug logs
API servers, logging infrastructure, CI/CD pipeline, and developer VPN all technically in scope
Estimated PCI scope: 47 systems
Required assessment: SAQ D (329 questions) + QSA involvement
Estimated first-year compliance cost: $140,000

Scope Reduction Actions (4 weeks of engineering work)

Replaced custom card form with Stripe Elements (iFrame-based) — server-side card data handling eliminated
Removed card data from application logs using structured logging filters
Migrated from SAQ D to SAQ A-EP scope by moving card form to Stripe-hosted Checkout for web flows
Network segmented the Stripe webhook handler (the only remaining CDE component) into a dedicated service with minimal inbound access

After Scope Reduction

Zero cardholder data passes through application servers
One webhook receiver microservice in a dedicated VPC segment is the only in-scope system
Required assessment: SAQ A-EP (191 questions, primarily covering the webhook service)
Revised first-year compliance cost: $42,000

Cost reduction: 70%. Ongoing annual maintenance: 80% lower.

SAQ Eligibility After Scope Reduction

Your Architecture	Applicable SAQ	Questions
Stripe Checkout (full redirect) or equivalent	SAQ A	22
Stripe Elements / Braintree Hosted Fields (iFrame on your page)	SAQ A-EP	191
Payment processor API called from your server (no card data stored)	SAQ C	159
All card data fully within your environment	SAQ D	329

The Cost Impact of Scope Reduction

Scope Size	Systems in Scope	Estimated Annual QSA Cost	Estimated Annual Tooling + Engineering Cost	Total Annual Compliance Cost
SAQ A (minimal)	0–2	$3,000–$8,000	$8,000–$15,000	$11,000–$23,000
SAQ A-EP (moderate)	1–5	$8,000–$20,000	$20,000–$40,000	$28,000–$60,000
SAQ D (complex)	20–100+	$20,000–$50,000	$60,000–$150,000	$80,000–$200,000

Common Questions About PCI DSS Scope Reduction

Does using a payment processor's hosted payment page eliminate all PCI obligations? No. Even with SAQ A eligibility, you must complete the SAQ annually, undergo quarterly ASV scans, maintain a basic information security policy, and report compliance to your acquiring bank. What SAQ A eliminates is the need to control, monitor, and assess your own application servers for PCI purposes — a significant reduction in work.

Can I reduce scope after already being assessed at a higher level? Yes. If a previous assessment placed you at SAQ D due to your payment architecture, and you have since migrated to tokenized payments with Stripe Elements, you can re-scope and reassess at the lower level in your next assessment cycle. Your QSA will need to validate the scope reduction before accepting the lower-level SAQ.

Does network segmentation require physical network separation? No. Logical network segmentation using cloud-native controls (VPCs, security groups, firewall rules) is accepted by PCI DSS assessors as long as the controls are properly documented, tested, and provide equivalent isolation to physical separation.

Get Your Scope Reduction Assessment

QuickTrust's engineers analyze your payment architecture, identify every applicable scope reduction opportunity, and implement the changes — whether that means migrating to Stripe Elements, restructuring your API layer, or building network segmentation in your AWS environment. Most scope reduction projects complete in 4–6 weeks.

100% audit pass rate. Audit-ready in 6–10 weeks. Your engineering team contributes fewer than 20 hours.

Request your free scope reduction assessment at trust.quickintell.com

PCI DSS Compliance for SaaS: How to Reduce Your Scope (And Cut Costs by 70%)