Which SAQ applies to e-commerce merchants who outsource all payment processing to compliant service providers?

Discover which SAQ fits e-commerce merchants who outsource all card processing to compliant service providers. Explore how SAQ A-EP contrasts with SAQ A, why third-party processors matter, and how PCI DSS compliance becomes simpler when merchant systems never touch cardholder data. It also covers supplier safeguards.

Short on PCI jargon, long on clarity: how to pick the right SAQ when you outsource payments

If you run an e-commerce store, the PCI DSS questions can feel like a maze. Safe, straightforward steps can save you time, money, and a lot of back-and-forth with auditors. The everyday challenge isn’t about memorizing every acronym; it’s about understanding how card data actually flows through your business and then choosing the right Self-Assessment Questionnaire (SAQ) to prove you’re handling that flow securely.

Let me set the stage with a simple map of the SAQ landscape. PCI DSS uses these questionnaires to help merchants, service providers, and their assessors confirm the level of risk and the controls you must have in place. There are several variants, each tied to how you process, store, or transmit cardholder data. Some merchants touch data, others don’t touch it at all, and a few sit somewhere in between.

The core idea you’ll hear a lot is this: if you outsource all payment processing to PCI DSS-compliant service providers, you’re in a different lane than if you still touch data on your own site. That distinction is what drives the SAQ choice.

Which SAQ applies to e-commerce merchants who outsource all processing to compliant service providers?

The specific scenario we’re talking about is: your e-commerce site routes payment to external processors, and you don’t store, process, or transmit card data on your own systems. In this case, the Self-Assessment Questionnaire that covers your position is SAQ A-EP. The “EP” stands for e-commerce partial, but here’s the twist: it’s designed for merchants that still have some level of interaction with cardholder data on their site, even if the bulk of the processing is handled externally.

To contrast, SAQ A is the other common destination for the outsourced model. SAQ A is for merchants who truly do not electronically store, process, or transmit cardholder data on their own systems or premises. They’re relying entirely on third-party service providers to handle everything payment-related. In practice, that means your own e-commerce environment stays away from CHD (cardholder data) altogether.

So why the distinction? Because the devil is in the data flow. If your site redirects a shopper to a payment processor and never touches card data in your own environment, you can simplify compliance with SAQ A. If your site has a form or integration that touches card data in some way—even briefly—it triggers the more nuanced SAQ A-EP. The “EP” acknowledges that your site participates in the ecosystem, even though the main processing happens elsewhere.

A quick tour of the other SAQs helps keep the map useful

  • SAQ B: This one is for merchants who use standalone, dial-out terminals and do not store electronic CHD. It’s narrow in scope and focuses on devices that aren’t connected to an ongoing online data stream.

  • SAQ B-IP: This is for merchants who use internet-based, point-of-interaction devices. The data path might touch your network in a more direct way than B, so the controls are a notch up.

  • SAQ C-VT: Targeted at merchants with payment application systems connected to the internet but that don’t heavily touch card data on-premises.

  • SAQ D: The catch-all for merchants who don’t fit into the other categories. If your data flow is complex or you’re unsure, this is your fallback, though it comes with more requirements.

In other words, the choice isn’t about which one sounds easiest. It’s about where card data actually lives in your environment and how it moves.

What does SAQ A-EP demand, in practical terms?

If your e-commerce setup sits in the SAQ A-EP lane, you do need to prove you’ve minimized card data exposure on your own systems and established strong protections around those data flows that do exist. Here are the practical threads you’ll see in that assessment:

  • Data flow mapping: You’ll show a clear map of how data travels from the customer’s browser to the payment processor, and where your systems touch data at all. If your site redirects away from your server to a PSP, you’ll illustrate that redirect path and the protections around it.

  • Environment controls: Even if card data lands only with a third-party processor, you still need strong security controls around any parts of your site or network that could be involved in the data path. Think secure redirects, proper tokenization practices, and tight access controls on any components that could touch data or its tokens.

  • Tokenization and encryption: The way you handle data is almost as important as the data itself. Demonstrating that you rely on tokenization or encryption where data does appear on your side strengthens your position.

  • Vendor management: Your agreements with third-party processors matter. You’ll include evidence that those providers meet PCI DSS requirements and that your own vendor risk management practices are solid.

  • Policy and procedures: Documentation around incident response, change control, vulnerability management, and monitoring completes the picture. The aim is to show a well-run security program that doesn’t rely on magic or luck.

A familiar pitfall to watch for

A common misconception is that fully outsourcing automatically means SAQ A. That’s true in spirit, but the “EP” variant keeps a closer eye on what actually happens on your own site. If your site has any interface where card data could be exposed, even indirectly, you’re in the SAQ A-EP lane rather than a clean SAQ A. It’s not about fear-mongering—it's about making sure your security controls reflect reality.

A practical mindset for merchants

  • Start with mapping: Draw a simple, honest map of who touches CHD, where, and how it’s protected. This is not a one-off exercise. It anchors your entire compliance effort.

  • Communicate with your PSPs: Make sure your processing partners share their PCI DSS status and remediation timelines for any gaps that affect you.

  • Keep it lean, but complete: SAQ A-EP isn’t a tape-measure challenge. It’s about showing that you’ve minimized CHD exposure on your end, implemented robust controls, and set up clear governance around third-party processing.

  • Don’t over-rotate toward complexity: If you truly don’t handle CHD on your site, you don’t want to complicate your controls unnecessarily. The goal is clarity and confidence, not a forest of redundant checks.

A small digression that helps intuition

Think of your e-commerce setup like a restaurant: you’re the host, the customer sits down, and a trusted kitchen (the PSP) does the heavy cooking. If the host never handles the ingredients, you can keep the dining room simple, clean, and well-policed. But if the host occasionally handles a spice jar or plates a dish before it leaves the kitchen, you’ve got to show you’ve got the right hygiene and safety procedures in place for that extra touch. SAQ A-EP reflects that nuance: the host’s duties exist, but they’re tightly controlled and always in step with the kitchen’s standards.

Real-world takeaways you can use

  • If you outsource all processing and your site never stores or transmits CHD, SAQ A is your baseline reference. It’s the simplest, most direct route to demonstrating PCI alignment when your own systems stay out of CHD entirely.

  • If your site interacts with card data even in a limited way, review SAQ A-EP. It’s designed for the reality of e-commerce architectures where some data-related touchpoints live on the merchant side, even as the heavy lifting happens with external processors.

  • If you’re unsure, map first, then check the guidance. The PCI ecosystem provides clear distinctions, but misclassifying your data flow happens easily when you rely on memory rather than a current diagram.

A few helpful resources and reminders

  • Your best starting point is the PCI DSS guidance from the PCI Security Standards Council. It lays out the definitions, the flow diagrams, and the exact criteria for each SAQ.

  • Talk to a QSA or a security consultant if your data path is not crystal clear. A quick session can save you hours of back-and-forth and prevent misalignment later on.

  • Vendors aren’t the only source of truth. Your own internal processes—how you supervise vendors, how you monitor trust boundaries, and how you respond when a third party changes its infrastructure—are equally important.

A final thought

Compliance isn’t a box to check. It’s a narrative about how safely data moves through your business, who owns it at each step, and how you prove that you’re doing right by your customers. For many e-commerce merchants outsourcing all processing to compliant providers, SAQ A-EP captures the reality of a modern, outsourced ecosystem: your site plays a role in the data path, but the serious processing and data protection happen with trusted partners. When you map that reality clearly, the path to compliance becomes less of a guessing game and more of a well-lit routine.

If you’re navigating this space, keep the focus on data flow, concrete controls, and honest documentation. The rest follows—consistently, calmly, and with a bit of practical swagger.

Subscribe

Get the latest from Examzify

You can unsubscribe at any time. Read our privacy policy