Which PCI SAQ Do You Actually Need? (ep. 10)

First time filling out a PCI SAQ? In this episode, two QSAs who've scoped hundreds of payment environments walk you through how to pick the right one—so you don't end up with the wrong form, the wrong security controls, and the wrong amount of risk.

Choosing the right PCI DSS Self-Assessment Questionnaire (SAQ) isn't just a paperwork decision. Pick the wrong form and you can leave blind spots in your network security or lock yourself into compliance requirements you never needed.

In this episode of the Practical Cybersecurity Podcast, SecurityMetrics experts Jen Stone (QSA) and Michael Simpson break down the complex, often misunderstood rules of PCI scoping. They translate confusing auditor-speak into a practical roadmap so you can identify your payment channels, reduce your data footprint, and satisfy your acquiring bank.

In this episode:

• The e-commerce breakdown: the technical triggers that separate SAQ A, SAQ A-EP, and SAQ D—and the "iframe vs. direct post" buzzwords that decide which one is yours
• How to spot bad PCI advice, including the common Toast POS / SAQ A myth that sends merchants to the wrong form
• Why validated Point-to-Point Encryption (P2PE) is the gold standard for in-person payments and how it eliminates local network scope
• E2EE vs. P2PE: the critical difference between proprietary end-to-end encryption and a formally validated solution—and why you can't use the P2PE form for E2EE
• The cellular terminal question: how to document network-connected mobile payment devices
• Virtual terminals (SAQ C-VT): how to stress-test your network segmentation so a call center actually qualifies
• The SAQ roll-up: how to combine multiple payment environments into one master document without losing your mind
• Service providers: the one unyielding rule for B2B vendors who handle downstream cardholder data

Resources:
Official PCI SSC PTS device search: https://listings.pcisecuritystandards.org/assessors_and_solutions/pin_transaction_devices?agree=true

Talk to a SecurityMetrics QSA about scoping: https://www.securitymetrics.com/security-consulting

A note from Jen: We built Practical Cybersecurity because we were tired of the fear-mongering in this industry. Security shouldn't be a secret club.

If you're trying to figure out PCI compliance or need a pen test, my team at SecurityMetrics can help you out: https://www.securitymetrics.com/contact/lets-get-you-to-the-right-place 

But if you just want to learn how to protect yourself for free, start here:  https://academy.securitymetrics.com/ 

Transcript

Michael Simpson: There's a lot of misleading information out there, too. For example, if you're a merchant that uses Toast for your point of sale, some places online will incorrectly tell you that you should use SAQ A, which is completely wrong…

Jen Stone: That's not right at all!

Jen Stone: Hello and welcome back to the Practical Cybersecurity Podcast. My name is Jen Stone. I think this is a really important conversation because it's the beginning of what a lot of merchants are faced with, which is: which SAQ? There are so many SAQs, and what SAQ do I start with? With all the universities and municipalities in the states that you work with, you see a lot of small merchants that are trying to figure this out. So what is your approach to helping people know which SAQ to do?

Michael Simpson: The Self-Assessment Questionnaire, or the SAQ, is designed for simple merchant environments to help them become PCI compliant. Instead of having to go through the full PCI DSS standard, if they have a very simple environment in the way they are accepting and processing credit cards, they can use specific SAQs. There are six core SAQs that the Council created to help merchants narrow in on the specific PCI requirements that secure their particular type of payment channel.

The first thing I try to go through with a merchant is to have them explain the different ways they receive credit card data. How does it come into your environment? What are you doing with that credit card data? How is it being processed? How is it being stored? And then, where do you send it?

Almost all merchants are going to collect it in some way, and then they send it to a third party that's going to process that payment on their behalf. Once we understand the data flow, that helps us understand which SAQ applies.

There's a lot of misleading information out there, too. For example, if you're a merchant that uses Toast for your point of sale, some places online will incorrectly tell you that you should use SAQ A, which is completely—

Jen Stone: That's not right at all! Whoever wrote that particular website didn't understand what that means.

Michael Simpson: Right, yeah. We can kind of bundle the SAQs into two main groups. When I'm looking at which SAQ to choose, it's an easy flow tree that you could follow. The first question is: Do I support e-commerce transactions or card-present transactions?

We have several SAQs like SAQ A, SAQ A-EP, and SAQ D. Those are the only ones that can be used for an e-commerce environment. So if you have a card-present environment—like a Toast point-of-sale system, for example—the SAQ A is not right for you. SAQ A is for e-commerce or outsourced third parties where you don't have any card-present elements in your environment. For card-present, we're looking at SAQ B, SAQ B-IP, and SAQ P2PE. There's a host of other ones meant for when you're dealing with credit card data physically in your location, so you know you can ignore the A and A-EP because those don't apply in that situation.

Jen Stone: Right. Conversely, if you don't have any kind of device that swipes, taps, dips, or interacts with a card or card data in any way, then you know you don't have to worry about the card-present ones. You really are focusing only on e-commerce. But if they don't qualify for the SAQ A, we also frequently see the SAQ A-EP, and it's not uncommon. Do you want to talk about how people know if they fall into SAQ A-EP rather than SAQ A?

Michael Simpson: Yeah. There are three choices for e-commerce: A, A-EP, and D. As we discussed, with SAQ A, you fully outsource all collection and processing to a third-party provider, and your server is not the one directing the client's browser on where to send that credit card data.

The SAQ A-EP is very similar in that, as a merchant, you don't store, process, or transmit credit card data, so your e-commerce environment never touches the raw data. But the main difference here is that your web server is the one telling the customer's browser, "Hey, when you enter your credit card data and hit the submit button, I want you to take these fields and send them to my payment gateway."

If it's your server orchestrating that flow of credit card data, it puts a little more security scrutiny on your systems, which is why the A-EP has a lot more security requirements built around it. We now have a server with the power and authority to tell the customer's browser where to send data. If that server gets compromised, it's easier for an attacker to say, "Okay, instead of sending credit card data here, send a copy over here to me." The process still goes through, and people don't notice that something is wrong.

Jen Stone: Right. I sit in on a lot of initial calls with customers who have never worked with a QSA before, who have some sort of e-commerce, and they will be completely adamant: "I don't receive, I don't capture, I don't process, I don't transmit." They think because their systems never touch the cardholder data, they are completely out of it. Explaining to them that regardless of whether they touch it or not, if they have responsibility regarding it, then they have scope—that's a big hurdle.

So, knowing whether it's the A or the A-EP is key. But then there's the bigger, deeper dive, and that's SAQ D. Some e-commerce merchants have to fill out SAQ D. Can you explain in what cases that might happen?

Michael Simpson: Yeah, and there are some buzzwords to keep an eye on, too. For SAQ A, the tech buzzwords are "full redirect" or "iframe." For SAQ A-EP, if you're doing a "direct post" method or using certain types of JavaScript, that's usually an indication of an A-EP.

If your e-commerce server ever touches the credit card data directly—say you are capturing the data on your server and then using an API function call to pass it along—that is the trigger. If you're using some type of function call where you collect it and then pass it right to your payment gateway, even if you don't store it, your server touched it. That automatically pushes you right to SAQ D, where all of those PCI security controls apply. If your server ever touches it, or if you store any credit card data electronically, it is an automatic SAQ D.

Jen Stone: And I'll be quite honest, for small merchants, if they fall into the SAQ D category, they probably don't need to be. There are usually much better ways for them to take credit card payments, and they should look into alternative options because it's going to drastically reduce their scope. It’s not just about how much time it takes to answer an assessment and fill out paperwork—that's not the big deal. The big deal is the massive risk they are taking on by having that credit card data pass through their environment.

Michael Simpson: I agree, and I would even say that most small merchants don't really have a need to be an SAQ A-EP either. Sometimes it's a merchant's choice because they want a little more control over the look and feel of the entire checkout experience. They may say, "Hey, it's worth it to me to manage a few more controls and accept the added security risk in order to have full control over the payment experience from start to finish." So, some small merchants will choose to go through the A-EP instead of an iframe or a full redirect method.

But for SAQ D, very few small merchants should be looking at that. If all they're doing is e-commerce, SAQ D is not a great fit. You're not gaining much by capturing and sending the data yourself; your customers aren't going to see any difference whether you do the capture or whether the customer's browser sends it directly to your gateway.

Jen Stone: Yeah, and we're not being critical of choices merchants have made in the past. A lot of times, until they work with a QSA, they might not have ever asked these questions internally. It just might have been set up that way originally, and that's what they've been doing. Now they're faced with, "Is that the way I want to continue?" It's generally a good point in time to consider other options.

Jen Stone: All right, so that's e-commerce in a nutshell. Let's take a look at taking credit card payments in person. What is the most common way we're seeing people do that right now?

Michael Simpson: The most common method right now—and I think it's a great thing—is SAQ P2PE. It’s the gold standard of the point-of-sale environment because it is the easiest self-assessment questionnaire for a merchant to validate their PCI compliance. It's also one of the least risky environments for the merchant. Once that card reader reads the credit card data, it is strongly encrypted immediately. Even if the point-of-sale system had a virus on it, or someone on the network captured that packet of data containing the credit card number, it is encrypted so strongly that the Council feels by the time someone could decrypt it, the data would no longer be useful.

Jen Stone: I really like SAQ P2PE because it simplifies complex situations for a lot of merchants. There are merchants who share networks with a facility they are renting in, and they don't have a lot of control over that network. P2PE doesn't care; it's not going to look at that network. It's just looking at the P2PE device itself, how it's handled, and how you check it for physical skimmers. We don't have to look at other traditional network security controls because there isn't considered to be a significant risk to the card data in those situations.

Michael Simpson: Yeah, the risks we see in a point-to-point encrypted environment really come down to: Do we have card skimmers? or Do we have staff who are potentially allowing credit card data to be stolen? Most of what you'll see from a requirement standpoint in SAQ P2PE is focused on physical security and training staff. Those are the big things.

Jen Stone: Exactly. But we don't see P2PE everywhere. We still see two traditional workhorses, which are SAQ B and SAQ B-IP. Can you talk a little bit about what those are?

Michael Simpson: The big difference between B and B-IP comes down to connectivity. The "IP" stands for Internet Protocol, meaning it's a network-connected Point of Interaction (POI) device or payment terminal.

Usually, if you talk to your bank and say, "Hey, I want to start taking credit card payments," if they send you a standalone terminal—like a Verifone or an Ingenico device—it's usually going to be a PTS (PIN Transaction Security) approved device. PTS approval is an assessment these hardware vendors go through to verify that the terminal has built-in security to help prevent physical tampering and ensure strong encryption to protect processed credit card data.

If that terminal is connected to an analog phone line—though we're seeing less and less of this as the years go on because it just takes too long, so for most merchants it's not worth it—that falls under SAQ B. It's very simple because there is no computer network in scope. In a way, it's even simpler than P2PE because you aren't managing a P2PE Implementation Manual (PIM). It’s basically just physical security of the terminal and training staff. But it's less applicable today.

Most bank terminals today are going to be plugged into an IP connection, making it part of your network. If it is not point-to-point encrypted, then your network suddenly gets pulled into scope. We now have a device sending credit card data across your network. We need to make sure that device is on a secure network that is segmented from other devices that shouldn't have access to it. That is what SAQ B-IP covers. It is more expanded than SAQ P2PE or SAQ B because it brings in questions about how you manage firewalls and what access controls are in place to limit traffic entering and exiting that secure network environment.

Jen Stone: Right. Now, a lot of times I'll ask a new merchant, "What kind of devices do you have? Are they P2PE? Are they not? Do you know if they are PTS approved?" A lot of times I just get a blank stare because they don't know.

Michael Simpson: It's a whole bunch of acronyms.

Jen Stone: Yeah, I just threw a bunch of letters at them and now we're not friends anymore! It's a lot, and merchants shouldn't be expected to know all these technical details off the top of their heads. But they should be given the right information. Let's say you're working with someone who has hardware devices; how do they figure out whether they are P2PE devices or standard B/B-IP devices?

Michael Simpson: PTS approval is pretty easy to find out. Usually, I don't even ask my merchants because I can look it up myself. You go to the Council's website (pcisecuritystandards.org), and under "Devices," there is a PTS device listing. You enter the make and model of your device, and it will show you if it is PTS-approved and what version of the approval it went through. If it's an Ingenico or a Verifone device, those vendors will also have links to their PTS approvals right on their sites. Most common terminal types from major vendors have gone through this.

Determining if it is a validated P2PE solution is harder. I could look at an Ingenico Lane 3000 terminal that is part of a validated P2PE solution, and see another identical one that is not. Just by knowing what type of terminal I'm looking at, I don't know what encryption key was injected into it.

The only way to find out for sure is to talk to your payment vendor or whoever provided the solution to you. Ask them: "Is this a validated P2PE approved solution that I'm using? If so, can you give me a copy of the P2PE Implementation Manual (PIM)?" That PIM will have all the details needed to verify that you are indeed part of a validated P2PE solution.

Jen Stone: And I love that question because if nobody can come up with a P2PE Implementation Manual—or a PIM—not just the merchant, but their vendor or their bank, that tells you something. I've had merchants who were told they were on a P2PE solution, but none of the documentation was provided. The more we dug, the more we found out it wasn't a validated solution at all, and they got sold a bill of goods.

Michael Simpson: Luckily, it's happening less than it used to. But you still run into situations where there is end-to-end encryption (E2EE) happening, but it's not a validated solution. There has been no independent verification that the encryption methods are strong, or that the key injection facilities used to program those devices have undergone third-party validation. End-to-end encryption and point-to-point encryption are two entirely different things.

Jen Stone: Exactly, because it's all about that formal verification step. That can be a tricky nuance to navigate when you've been sold an "end-to-end encrypted" solution and assume that means automated P2PE scope reduction. It doesn't always. But to make it even more confusing, sometimes it does! In what cases can an E2EE solution use the P2PE SAQ?

Michael Simpson: Good question, and technically, the answer is never. One of the strict eligibility criteria in the P2PE SAQ is that all credit card data being processed must go through a formally PCI-validated P2PE terminal that's part of a validated P2PE solution.

However, what some non-validated E2EE providers or merchant banks will do is tell the merchant: "Fill out SAQ B-IP because this is a PTS-approved, IP-connected terminal, but because of our encryption, you only have to answer the questions that match what would be in a P2PE SAQ. Everything else you can mark as Not Applicable."

Jen Stone: And that is such a tricky nuance. Can you follow P2PE requirements for it? Yes, if the bank approves it. But can you actually use the official SAQ P2PE form? No. You use the P2PE SAQ to inform you as you fill out the SAQ B-IP form, which is a piece of just ridiculous nuance. It's hard to explain why, but when you're following the rules—which we like to do—if the Council says that's how to do it, that's how you do it.

Michael Simpson: I've even seen banks give their merchants a partially pre-filled SAQ B-IP to make it easier. They will pre-fill all the network security questions as "Not Applicable" because of their proprietary end-to-end encryption. Then, in the appendix where you have to explain your N/A answers, they provide a statement explaining that because of the E2EE solution in place, the network is considered out of scope. That is a totally fine way to go. But remember, if you have an E2EE solution that isn't formally PCI-validated, you are usually filling out the SAQ B-IP form, and your bank must guide you on what to do. You can't just make this up on your own.

Jen Stone: You really have to make sure that the people who are approving your SAQ and AOC reports are fully on board with how you're handling it. Even if your setup is simple, you want to confirm exactly how they expect you to document it.

 Jen Stone: Here's another nuanced scenario that I find interesting. We see payment devices that are connected via cellular networks. The merchant will say, "Well, there's no local network in scope, so I'm going to fill out the standard analog SAQ B." Tell me about that.

Michael Simpson: That is an excellent question, and it's one I wish we would get more concrete guidance on from the Council. Technically, if you look through the eligibility criteria for SAQ B, it states it only applies if you have an analog connection. Cellular connections are not analog; the device gets assigned an IP address.

So, technically, you are in SAQ B-IP territory in my opinion. However, a lot of those traditional B-IP network requirements—like performing external vulnerability scanning—are impossible because you can't scan a cellular carrier's network. Even though you are technically filling out the SAQ B-IP form, you are often following the SAQ B requirements for guidance because the local network really is out of scope, even though a network technically exists.

Jen Stone: Right. At this point, a lot of merchants might just think, "This sounds really confusing because there are so many options when I'm just trying to accept a credit card." Fortunately, there are places we can go to read the definitions. Can you expand a little bit on eligibility criteria? Let's say an organization believes they are SAQ B-IP—what should they read to find out for sure if they're correct?

Michael Simpson: Every SAQ has an eligibility criteria list. It's located in Part 2 of every form. The list is going to be different for each one, but there are usually five to seven bullet points you need to be able to check off. If you read through them and cannot answer affirmatively to all of them, then you're probably looking at the wrong SAQ.

Jen Stone: Yeah. I've been doing this for over a decade, and I still go back and double-check myself to make sure an SAQ really describes the environment I'm looking at. Merchants shouldn't feel like they need to know this off the top of their heads. It can be a lot of words, but if you take the time to read through those bullet points a couple of times, it’s not actually complicated—it’s just unfamiliar. That's how you'll know for sure if you're filling out the right form.

Michael Simpson: Exactly. There's a lot of information on the internet that can help out. But if someone still feels like they just don't know which one to go with, get a couple of hours of consulting with a QSA. They should be able to tell you pretty quickly, "Hey, this is the SAQ you need."

Getting a little guidance at the very beginning ensures you are filling out the right form and implementing the right controls to protect your environment. It’s a one-time thing to get you on the right track, and then from then on, you can just keep going forward.

Jen Stone: Exactly. We've talked about e-commerce and we've talked about physical face-to-face card swiping. But there are other ways credit card information can be taken, either in person or over the phone, where an employee is typing the credit card number into a machine. Tell me a little bit about that.

Michael Simpson: We call those Virtual Terminals, which fall under SAQ C-VT. This applies if you have a workstation or laptop where you pull up a web browser to access a payment portal interface provided by your payment gateway or a third-party, PCI-compliant processor. You manually type in the customer's credit card number, expiration date, CVV, and the amount, and hit process. You don't have a physical payment terminal device, and you're not taking card-present transactions; you're just manually typing it in. This is common in call centers, or environments receiving order forms through the mail or fax.

Under SAQ C-VT, that workstation or laptop is heavily in scope, and the network it sits on is in scope. Similar to SAQ B-IP, you're going to see questions about firewalls and network segmentation. We want to make sure those virtual terminal laptops are on a secure network, are locked down for this specific purpose, and are protected against malware and other intrusions.

Jen Stone: Yeah. When I'm working with an organization that claims they fall under SAQ C-VT, one of the things I do to stress-test that assumption is ask: "The employees who are typing in those payments on their computers, can they also go to Amazon? Can they check their email? Can they go to Facebook?" If they can access all these random corners of the internet that have nothing to do with the payment data flow, then the answer is: no, you either don't qualify for SAQ C-VT, or you haven't properly defined your network. I can't accept that you are a clean SAQ C-VT environment because it's not a clearly defined, restricted subnet.

Now, what about SAQ C? I still see this occasionally, especially in the healthcare industry. What exactly is SAQ C?

Michael Simpson: We used to see SAQ C everywhere long ago; almost all merchants used to use it. A typical SAQ C deployment involves multiple point-of-sale workstations or registers sitting at a counter area, communicating back to a local payment server in the back room, which then connects to the payment processor. It's for multiple POS registers in a single location, rather than a massive distributed network across different cities.

Sometimes the card readers connected to these systems are basic USB magstripe swipe readers that are not PTS-approved. In this case, the point-of-sale software running on the workstation is the powerhouse of the environment—it intercepts the card data, processes it, and sends it out. Under SAQ C, you are not allowed to electronically store credit card data; you can only capture and transmit it. Because the software handles raw data, these devices must have strict local network protections in place. That's the biggest difference between SAQ C and the other forms we've discussed.

Jen Stone: I almost never see a standard SAQ C anymore. It’s just not common.

Michael Simpson: Yeah, it's really not.

Jen Stone: And that's a good thing because it really does reduce the risk footprint. A traditional SAQ C environment leaves you much more wide open than an SAQ P2PE or even an SAQ B-IP setup.

Michael Simpson: Yeah. And some of the traditional SAQ C environments I see now have made small technical tweaks to transition to SAQ B-IP. They might still have three registers upfront and a server in the back, but the actual payment terminal sitting on the counter—like an Ingenico or a Pax terminal—has its own direct IP connection. It might connect to the cash register via a serial cable to get the dollar amount, but when it transmits the credit card data, it sends it out over its own isolated IP connection directly to the processor, allowing it to fall into that B-IP bucket.

Jen Stone: Right. You can't just look at the physical setup and assume what's going on; you have to look under the hood to see where the network traffic is actually going.

We've covered a lot of different options. But what happens if a merchant has several of these environments simultaneously—say they have two or three different types in their environment?

Michael Simpson: In that case, it depends entirely on your merchant bank. I've seen some merchant acquirers who are perfectly happy to let you fill out separate questionnaires—like submitting an SAQ A for your website and an SAQ P2PE for your retail store.

Other banks will absolutely refuse multiple forms; they demand a single SAQ that describes you as a merchant and covers your entire footprint. When that happens, you have to do what we call an SAQ Roll-Up. If you mix e-commerce (A or A-EP) with card-present environments (B-IP, C-VT, C), the only single SAQ form that can encompass everything is SAQ D.

If your bank forces a single form, my recommendation is to still use the individual, simpler SAQs (like SAQ A and SAQ P2PE) to perform your internal assessments for those specific areas. Then, take all those answers and transpose them into the master SAQ D.

Naturally, there are going to be a lot of questions in SAQ D that weren't in your individual assessments. For those, you go through and mark them as "Not Applicable." In the appendix where you have to justify your N/A responses, you simply write a row stating: "These requirements were marked N/A because our payment footprint consists strictly of an isolated SAQ A e-commerce flow and an SAQ P2PE retail flow; these specific PCI requirements do not apply to either architecture." That is how you handle an SAQ roll-up, and it almost always rolls up into an SAQ D.

Jen Stone: Right, because an SAQ A can't roll into an SAQ B; they have completely distinct requirements. SAQ D is the only bucket large enough to hold all of them.

We've been focusing heavily on merchants, but it's worth reiterating one more time: if you are a Service Provider, you don't get to choose from a list of flavors. Your only option is SAQ D for Service Providers.

Michael Simpson: Yes, the choice is incredibly easy for service providers! The validation itself might be complex, but the selection is simple. If credit card payments are not being processed under your own merchant ID, and you are instead helping other merchants process their payments, you are a Service Provider. SAQ D for Service Providers is your only option.

Jen Stone: I'm glad you mentioned that, because sometimes we encounter service providers who act as merchants for their own sales, but provide a downstream service to others. They get confused about which hat to wear, and sometimes you can be both. Like you said, if it becomes a major challenge to parse out your scope, spending a few hours with a QSA to clear things up is a great investment.

Well, this has been incredibly useful. Any final SAQ-related thoughts before we wrap up?

Michael Simpson: No, I think that pretty well covers it.

Jen Stone: Perfect. Knowing which SAQ applies to you is a massive part of establishing your compliance footprint, but it isn't the entire scoping story. There is a whole separate methodology regarding what assets are included in your scope, and I think that topic deserves its own dedicated episode. We'll get together next time to map that out.

Michael Simpson: I look forward to it.