Introduction
Many e-commerce merchants underestimate the scope of their PCI compliance responsibilities, misclassifying themselves under the wrong Self-Assessment Questionnaire (SAQ). The most common confusion is between SAQ A and SAQ A-EP.
Misclassification can lead to security blind spots and failed audits. Here’s how to identify your true category and what each requires.
SAQ A: Fully Outsourced Payments
SAQ A applies when:
- You use a third-party payment processor.
- Cardholder data is never handled or processed by your systems.
- Your checkout redirects entirely off your domain (e.g., Stripe-hosted page).
No scripts. No forms. No responsibility for client-side security logic.
SAQ A-EP: Embedded or Script-Based Payments
SAQ A-EP applies when:
- You embed payment forms using iframes or scripts.
- Your site loads JavaScript from the payment provider.
- Your website hosts any part of the payment experience.
You are now responsible for client-side security, even if you don’t directly handle cardholder data.
Key Differences
- SAQ A: Minimal PCI scope. Hosted redirect. No embedded code.
- SAQ A-EP: Expanded PCI scope. Embedded scripts or forms. Requires security controls.
Why This Distinction Matters
With PCI DSS 4.0, even SAQ A-EP merchants must comply with:
- 11.6.1: Monitoring for unauthorized JavaScript changes.
- 6.4.3: Logging and validating code changes on payment pages.
If you embed scripts, load third-party libraries, or host checkout components—even indirectly—you’re SAQ A-EP.
How Breachfin Supports Both
- Detects script tampering for SAQ A-EP.
- Logs script changes and DOM manipulation events.
- Provides audit-ready reports to demonstrate compliance.
Don’t guess your SAQ type. Audit teams won’t be lenient if you’re unprepared.
