PCI-DSS for web teams: how to stay in SAQ-A scope
Falling out of SAQ-A scope multiplies your PCI compliance overhead 20-40×. Here are the four web-development decisions that move you from SAQ-A to SAQ-A-EP or SAQ-D — and how to avoid each one.
PCI-DSS is the Payment Card Industry Data Security Standard — a contractual requirement imposed by Visa, Mastercard, American Express, Discover, and JCB on anyone who accepts their cards. It is not a statute, but the penalties for failing it (card-brand fines, increased processor rates, loss of merchant privileges) make it more enforceable than many regulations.
For web teams the entire game is staying in SAQ-A scope — the smallest, simplest, cheapest validation tier. Falling out of SAQ-A forces you into SAQ-A-EP or SAQ-D, which add quarterly ASV scans, annual on-site assessments, and a stack of documentation overhead.
The SAQ tiers, simplified
- SAQ-A — your site never touches the card number. Payment fields are inside a third-party iframe (Stripe Elements, Adyen Hosted Fields, Braintree Drop-in). Your origin sees nothing. Quarterly external scans waived. Annual self-assessment is a short questionnaire.
- SAQ-A-EP — your page hosts the payment form but submits to a third-party processor. Your page is in scope because it could be tampered with to redirect the card number. Adds quarterly external scans by an ASV.
- SAQ-D — your servers see the card number. Adds annual on-site assessment, penetration testing, encryption-at-rest requirements, network segmentation, and 12 controls categories worth of evidence.
The cost delta between SAQ-A and SAQ-D for a small business is approximately 20-40× — primarily in QSA assessment hours, ASV scan contracts, and engineering time on segmentation.
How web teams accidentally fall out of SAQ-A
Mistake 1: hosting the payment form yourself
A developer thinks “I'll just POST the card number to Stripe directly from my form.” The card number now traverses your origin. SAQ-A-EP minimum, possibly SAQ-D.
Stay in SAQ-A: use the processor's iframe / hosted fields component. The card-number input lives in a Stripe / Adyen / Braintree iframe; your code never sees the value.
Mistake 2: capturing card data with client-side JS
Form-field analytics, session replay, and even error monitoring will capture card numbers from input events if you let them run on checkout. Even if your servers never see the number, the third party did.
Stay in SAQ-A: disable session replay and form analytics on checkout pages. Filter sensitive inputs in your error monitoring (Sentry has a privacyInputTypes option; DataDog has a sanitizer).
Mistake 3: posting to a non-HTTPS endpoint
A misconfigured checkout form action points to http:// somewhere. Even if the page is HTTPS, the form submission downgrades. Out of SAQ-A immediately.
Stay in SAQ-A: enforce HTTPS on every form action across the site, not only checkout. Plumb's commerce module flags any HTTP form action.
Mistake 4: not setting autocomplete on CVV
A user enters their CVV on checkout. Their browser caches it. The next user of the device autofills the prior CVV. PCI-DSS requirement 3.4 expressly prohibits storing the CVV after authorization — and a cached browser autofill counts.
Stay in SAQ-A: set autocomplete="off" on CVV inputs. The card number can take cc-number; the expiration cc-exp; the CVV must be off.
The technical controls Plumb checks
- HTTPS enforced on checkout and all payment-form pages.
- Payment-form action URLs use HTTPS (no http:// downgrades).
- Payment forms use POST, not GET (no card data in URLs).
- Tokenization iframe present (signal for SAQ-A architecture).
autocomplete="off"on CVV inputs.- No card-number-pattern values in any URL anywhere.
These are necessary but not sufficient for PCI-DSS compliance — they cover the web-verifiable subset. The non-web parts (key management, network segmentation, vulnerability scanning, access reviews, incident response) live outside any web scan and require their own evidence.
What the auditor actually wants
For SAQ-A, your annual self-assessment is a questionnaire signed by an officer of the company. The questionnaire asks attestation-level questions. The Plumb report is useful in two ways:
- Pre-attestation sanity check — confirm before signing that the technical controls you're attesting to are actually in place. Plumb runs in 15 minutes; a misattestation could cost you SAQ-A scope and add six figures of compliance overhead.
- Evidence for higher tiers — if you are in SAQ-A-EP or SAQ-D, the Plumb report contributes to the technical-controls evidence the QSA reviews. It does not replace the QSA. It does replace the manual portion of their web-layer review.
This article is not legal or audit advice. PCI-DSS scope is determined by your acquiring bank, your card-brand contracts, and your QSA. Confirm specifics with them.