Listen to get a break down for each available SAQ type, including the newly introduced SAQ SPoC for PCI DSS 4.0.
Confused about PCI DSS compliance standards? This video breaks down each available SAQ type, including: SAQ-A, SAQ P2PE-HW, SAQ D for Service Providers, and the newly introduced SAQ SPoC for PCI DSS 4.0.
Join Host and Principal Security Analyst Jen Stone (MCIS, CISSP, CISA, QSA) as she chats with SecurityMetrics Principal Security Analyst Michael Simpson (CISSP, CISA, QSA) to learn which one is right for your business based on your payment processing environment.
Learn about:
Resources:
[Disclaimer] Before implementing any policies or procedures you hear about on this or any other episodes, make sure to talk to your legal department, IT department, and any other department assisting with your data security and compliance efforts.
Hello, and welcome back to the SecurityMetrics podcast. My name is Jen Stone. I'm one of the principal security analysts here at SecurityMetrics, and our guest today is also a principal security analyst. Michael Simpson, will you please, reintroduce yourself to people? I know you've been on before, but maybe some people haven't met you yet.
Yeah. I've been a principal security analyst at SecurityMetrics now. I think going on thirteen, fourteen years.
I lead our enterprise audit team, which handles all of our large enterprise government, higher education assessments.
And I've been doing it for a long time and I love it.
Thank you for joining me. Our topic today and the reason I wanted to talk to you is a lot of people want to know about the different SAQ types, and I couldn't think of anybody that I knew that knew them better than you did. So, let's jump into it.
First of all, maybe define what is an SAQ?
Yeah. So the full PCI standard can be a heavy lift. And even just, you know, reading through the standard for someone who's new to PCI, new to these security requirements, it can feel a little overwhelming.
And for small merchants, they have very simple environments. They don't need the full standard. So what the council's done is they created the self assessment questionnaires or the SAQs that are designed for specific simple payment environments. So if you're, you know, if you're a simple ecommerce merchant and you've outsourced all payment collection and processing to a PCI compliant third party provider, you know, you've got a a partner, that is PCI compliant themselves and they're the ones that's collecting the collecting and processing that data for you, then instead of going through, you know, all of the two hundred some odd controls that mostly don't apply to you, you can look at the self assessment questionnaire, the SAQ A, that's designed for that specific environment.
And it has kind of taken out all of the ones that the council field doesn't apply in this situation. And then you can focus on those PCI controls that really do apply to your environment, which is mostly centered around making sure you're choosing and keeping an eye on those third party providers that do have access to that data. So that's what the self assessment questionnaires are for, is it to simplify your validation of PCI DSS compliance for a simple merchant?
I I'm glad that you started with SAQ A, and you mentioned that it's in the ecommerce for people who outsource, ecommerce.
Maybe, let's talk a little bit about how you choose an SAQ A versus an SAQ A-EP versus a SAQ B versus a SAQ B-IP.
That's a good question. There is a guide on the SecurityMetrics website. You know, if you Google which SAQ is right for me, right, one of the first links is gonna be that guide that helps walk you through that decision making process. I think the council also is a little older, but they had a white paper titled Understanding SAQs for PCI DSS version three. It's really the same for version four as well. There's a few minor changes.
But the first thing you need to do is understand your payment flows. What how do you receive credit card data? You know, is it in person? Is this ecommerce transactions, over the phone transactions?
How is credit card data getting to you? How are you processing it? And then within each of the self assessment questionnaires or the SAQs, there's a part that's titled eligibility to complete. And what that is is a short list of maybe, you know, six or seven statements that all have to be accurate for you to qualify to use that simplified self assessment questionnaire to validate your merchant compliance.
Right.
So when it comes to ecommerce, you know, if you have an ecommerce payment flow, you're either gonna be an SAQ A, an A-EP, or a D. Those are the only ones that support ecommerce.
If you're a card present, you know, we've got several others. The B, the P2PE, the, the C, the D, the SPoC. So there's several that do support that card present. So the first thing you need to do is really have a good understanding of what your payment flows look like.
Right. And so hopping back to the SAQ A, I think it's a great place to start because so many merchants have at least a small storefront somewhere, something they're taking payments online in some way. And a lot of them are doing it through things like Shopify, Squarespace, Etsy.
Right.
Right? There are a lot of third parties. So, basically, what you were saying was if you have third parties managing the code on your page and how that payment, acceptance drops in there, those details, then you could qualify to be an SAQ A.
Yeah. So between if you have e-commerce, like I mentioned before, there you're either gonna be an A, an A-EP, or a D.
If your website ever touches credit card data, you're a D. Yeah. You know, so if you're capturing it and then sending it on, to the payment provider, even if you don't store it, if you're just pulling it in memory and sending it forward, you're gonna be an SAQ D.
If your website is the one telling my browser or your customer's browser, hey. When you hit the submit button here, I want you to take these elements including the credit card and send it to my payment processor and not to me. So if it's your web browser doing that and usually, we see, like, JavaScript being used for that type of control.
If that's how your website is set up, then you're gonna be an SAQ A-EP, which is a little simpler than the SAQ D.
If, however, the whole website's fully hosted by a third party or you, you know, you have your own website where people are selecting the goods or services they wanna buy. And then when they come to payment, you're either redirecting them to another website. So, you know, the URL up at the top of the browser changes out to some third party payment gateway and then they make the payment get redirected back. If you use that to get payment data or if you're using a third party iframe, which is a small piece of code that's like a website within a website, then you qualify for that simplest form, the SAQ A.
So those are the three ecommerce ones and kind of how to figure out which one fits you.
I've sometimes seen organizations that want a little more control over what's happening on their web page. They want to take on the work of developing it. And instead of having it fully hosted by someone else, they take on that hosting themselves and then are kinda shocked because the jump from A to AEP is pretty hefty.
It is.
Just off the top of your head, what are some of the elements that you would have to put security controls on for an A-EP that you don't have to in A?
Yeah. So for the A-EP, I mean, you're looking at penetration testing, which we won't have in the SAQ A.
You're looking at file integrity monitoring, which again is not in the SAQ A, anti virus, yeah, anti malware protections, quite a few requirements that or even internal vulnerability scanning. Yeah. So good security requirements that the SAQ A merchants probably should be doing anyway, but they're not required for compliance to do it if they qualify for the SAQ A. If you're an SAQ A-EP and you have that additional control, there's additional requirements that get put in place to make sure that you really have that locked down.
Right. And it's a good thing to know exactly how much you're doing because if you don't realize how much you're actually responsible for, it's possible that maybe you're not securing things the way you need to.
Yeah. Well and even in the SAQ A space. So even if you do qualify for the SAQA, it there's almost two separate pathways within the SAQ A.
And that's if you do a full redirect out to a third party, then the two new requirements that came with PCI version four, requirement 6.4.3 and 11.6.1 that focus on, having a process for approving any scripts running on your site, and then also having a process and technology in place to make sure that those scripts aren't altered or changed without your knowledge.
Those can be kind of a hefty lift themselves, just those two requirements. So if you're an SAQ A and you're using an iframe because you like the look and feel of the iframe, you have a little more control than sending people out to, you know, redirecting to another party.
That control and that look and feel benefit does come with those two new additional security requirements. So it is kind of a give and take deciding how much control you want, but also, you know, the more control that you have over that shopping experience, the more requirements that come into play to make sure that you are securing that shopping experience.
Right. And it makes sense because the more control you have, the more potential you have to be able to affect the security of cardholder data.
So, moving on to the B's, the SAQ B and the B-IP. Can you just give a little bit of an overview of what the B is?
Yeah. So the SAQ B, I think this is going to be an SAQ that's used less and less often. The SAQ B, this is for an environment where all credit card data is processed on a payment terminal that's connected to an analog phone line. You know, so maybe you wanna start taking payments at your company. You talk to your bank and they give you this device that you bring back and plug into your phone line. And when you swipe the card or or tap the card, it actually dials up and connects with, you know, the payment processor and sends all that data over that phone line.
Right.
So the downside of that type of connection is just the speed. It takes a while to establish those connections and to send the data across the old analog phone line.
The benefit of that is all of those security controls in the standard that deal with network security and firewalls, they don't they don't apply because there's no network in place.
Right.
You know, so the SAQ B is a fairly simple assessment. It's mostly making sure you're training your staff, and making sure that you're inspecting your terminals and doing what you can to prevent skimming devices being put on your terminals.
Right.
You know, so fairly simple requirements for a fairly simple environment.
But as we have more and more companies getting rid of all of their analog lines, we're gonna see fewer companies that can meet that eligibility criteria Right.
Which brings us to the SAQ B-IP in a very similar environment where we have, you know, a terminal usually provided by your bank or your merchant acquirer.
But instead of being connected to, analog phone line, you're connecting it to an IP network.
But with that additional speed that comes with the IP network, there are some security requirements that also come along with that.
We need to have a PTS approved device, and that's usually you know, it's something that your bank will usually give you a PTS approved device. But that needs to be or should be, you know, on a segmented network where there's no other communication with other devices on that network.
Right.
So so a few additional requirements to kinda secure that network space.
Yeah. And so, again, the B-IP, you start bringing in networks, which, of course, you know, the word the IP infers all of that. Suddenly, networks are in scope. And, of course, when you bring a network in scope, there are a lot of security controls there that just didn't apply in the B world where you're going analog.
And so that can be a heavier lift going from the B to the B-IP, and it's something I think merchants need to consider if they're getting rid of their analog lines and they're saying, well, we'll just go and plug it into our network. It's maybe not as simple as that.
Yeah. Because if they simply do that, then not only will they not be able to check off the correct eligibility criteria in the B-IP, because one of the eligibility criteria is the fact that this is on a segmented network, not connected to any other device.
So we have some issues with scoping, but then it also, like you said, it brings that network segment that they plug it into into scope. So if there's any other devices on there, those devices are also in scope. So network segmentation is important, which if if you wanna get away from the SAQ B because you either don't have analog lines or you just need something that is a little faster, SAQ P2PE or using a point to point encrypted terminal would probably be a easier way to go because we don't have the network again. The network is eliminated from scope because of that end to end encryption instead of, you know, with the SAQ B, there was no network, so we didn't have to worry about it coming into scope.
Right. So moving along through the alphabet.
Yeah.
So we've we arrive at SAQ C.
And to be honest, c is not something I see very often. Occasionally, I will. I'll see a a c environment in, like, sometimes in a healthcare space, I'll see the C.
The SAQ C used to be something I saw more often. Like small restaurants, they would usually be SAQ Cs. And SAQ C, a typical SAQ C environment, we may have, you know, two or three registers that's on the same network and there might be, like, a back end point of sale server, you know, in the back office. So one location, a few systems on this PCI network, that is what an SAQ C is really designed to handle.
The SAQC, there's a really slippery edge. It's easy to fall off the SAQC, if you have multiple locations. So let's say this one restaurant becomes very popular and now you have three or four locations.
If those four locations are all interconnected, those networks are interconnected, then we now no longer qualify for the SAQ C because one of the eligibility criteria would not be met. It needs to be, you know, a single location environment.
So a lot of SAQ Cs either end up being SAQ Ds because they get a little more complicated.
Or if you have a point of sale environment, like I just explained, and you decide to store credit card data locally, either, you know, maybe you're doing a store and forward, for if the network goes down or maybe you wanna store it to be able to do recurring purchases.
Any type of electronic storage of credit card data would also slip you into that SAQ D from the SAQ C.
And then the other reason why I think we're seeing fewer SAQ Cs is a lot of merchants that were SAQ Cs have been implementing point to point encrypted payment terminals where they can qualify for the SAQ P2PE and bring their network out of scope for PCI compliance.
Right. We should probably talk about the P2PE because it's my favorite.
It is. It's a good one.
So people, if they're making payments in person, we love to see the P2PE, and maybe you can go over a little bit why.
Yeah. So the SAQ P2PE really relies on very strong data encryption that has been already assessed. So we have these listed P2PE solution providers and they're listed on the PCI Standards Council website.
But those providers go through their own assessment.
So they have assessors looking at, you know, what type of encryption they're using, the strength of that encryption algorithm, how they manage the key injections, how the, you know, encryption keys get injected on those terminals.
So because of the data, once you make a payment on one of these P2PE terminals, the terminal is going to strongly encrypt your data before it ever leaves the terminal. So even if that terminal is connected then to a point of sale workstation and that workstation was riddled with viruses, no one would be able to get the data or they would be able to get the encrypted data. But by time they could decrypt it, it would be long past when it was actually valid data.
Right.
So the end to end encryption that's provided or the point to point encryption provided by these P2PE solutions allow us to remove that network from scope. And it really simplifies what the merchants have to do. And it's really, again, back to training your staff, and making sure you have good physical security controls around the terminal so that people can't put skimmers or other devices on the terminal that could put that data at risk.
Right. Right. And so sometimes people are a little cautious about putting in P2PE when because of a cost. You know, they're used to maybe, hey. We've been SAQ B, and it's relatively inexpensive, and now you want me to pay this money for SAQ P2PE.
I still think it's a good idea. How about you?
Yeah. If you need something faster than what the SAQ B supports, you know, or the merchants very easily grow out of where SAQ B makes any sense.
If you look at the cost of maintaining, like, SAQ B-IP or SAQ C compliance, if you have networks that are in scope, having the right people there monitoring your network, securing your network infrastructure, you can easily outspend the additional cost that you would have to pay for one of these point to point encrypt solutions. So when it comes to, you know, the cost of the terminal and the processing fee, it may be slightly higher for P2PE.
But if you can reduce drastically your compliance cost. Yeah. Then for a lot of people, it makes it makes good sense to do that.
I agree.
And then we don't even sell the P2PE.
I'm just saying.
We don't. Yeah.
It actually we spend less time assessing environments through P2PE, but I still try to get people to implement it because it's better for them, not only from the compliance cost perspective Yeah. But from a risk perspective as well.
Exactly.
Yeah. I really like it for that. I kind of breezed right past the C-VT, because it's kind of its own creature even though it has c in the name.
It is. It's different from the SAQ C. Can you talk about the C-VT?
It's got some similarities. We're usually in SAQ C. We do have workstations in scope.
But unlike the SAQ C, the C-VT, we don't have any card readers.
You know, so we're not swiping any cards or taking payments over a dip or other transaction.
Usually, when I see a C-VT, it supports, like, you're receiving credit card data through the mail or over the phone, but you have a staff member that's on a workstation that's connected to someone's virtual terminal. That's where the VT comes in for C-VT. So there's a website they're going to and this website is all designed for them to enter the credit card number, expiration date, amount. They hit process, and you know, that third party is processing the payment.
Right. So in a C-VT environment, again, we have that workstation that they're using to enter the data, that's gonna be in scope as is the network it's connected to. So this is another environment where we have, you know, a segmented network environment. We want that CVT workstation on an isolated network segment, and it's only going to this website to process payments.
So this a C-VT environment, this is where I often see problems with C-VTs.
This shouldn't be, you know, Jan's office workstation that she does all of her emails and watches the little cat videos or Tom's workstation where he's watching his videos about whatever, you know, and doing emails and everything, you know, those are more risky environments. This should be a dedicated workstation. All you're doing is processing payments and it's just going to this virtual terminal workstation or station or website to enter the payment data.
Yep.
So sometimes I get asked, okay. I have ecommerce and a B-IP device. Can I just fill out the B-IP FAQ? Because doesn't a roll up into B and B roll up into C?
So for that roll up, it wouldn't. Because most like, if you look at the SAQ C or the B, the B-IP, the C-VT, it's specifically on those SAQs.
It'll say this is not intended for ecommerce use. So you cannot roll into one of these non SAQ, a non-ecommerce SAQ's. If you have so typically, when I see someone have both a card present environment and an ecommerce environment, if if they want to assess their ecommerce let's say their ecommerce qualifies for the SAQ A and their card present is maybe an SAQ B-IP, they will be rolling into an SAQ D because that that is the only one that will support both ecommerce and and another one. But they'll wanna talk to their acquiring bank because their acquiring bank sometimes will accept multiple SAQs. So maybe instead of rolling those into one SAQ, you can say, “Hey, can I give you an SAQ A for my ecommerce environment and SAQ P2PE or B-IP for my card present environment?”
And a lot of acquiring banks are okay with that, you know, assessing each payment channel separately. But if they do want those combined, you're gonna be combining to an SAQ D.
Alright, different SAQs we've already discussed, but then we come to this new one, which is the SPoC or the SPoC.
Can you speak to that just a little bit? What is that?
It's my favoritely named SAQ that I think most people will never use.
But there are some. I have seen it, and I think as we get more SPOC validated solutions, we'll see more. But what this is is, if there are some solutions very similar to the SAQ P2PE, there's this SPoC assessment, where SPoC providers usually use some type of mobile device to accept payment data.
If if you are using devices that have been validated under this s a under the SBOC assessment, so you go to the PCI Council's website, you see that your solution is a listed SPoC solution, then again, someone's already reviewed all of the security and the encryption that's involved in that type of an environment.
So that really takes a lot of that burden off of PCI compliance when you, as a merchant, are going through your own validation. You don't have to validate that, you know, mobile device that you're using is strongly encrypting the data because someone else already did that for you. You don't have to worry about the transmission between that device and another device cause that's included in that listed solutions assessment already. So the SoOC, I I haven't seen a lot because there's only fire members like four or five listed solutions right now on the council's website.
If we end up getting more SPoC validated solutions, it will be one that's more common.
It's something that we saw when the SAQ P2PE first came out. There were only a handful of, you know, P2PE solution providers out there. It's like FreedomPay and Bluefin, maybe a couple of others.
But now that list has grown. And as that list has grown and there's more options available that fit into more merchant environments, we see more SAQ P2PE merchants out there.
It may be the same with the SAQ SPoC. As the list of solutions grows, we may end up seeing more and more merchants that can use that when they're doing their own merchant compliance. But, really, whether you're using the P2PE and the SPoC are really down to your provider's validations themselves. So if your provider has either a P2PE validated solution or if they're you know, if you've signed up with someone that has an SPoC validated solution, that provider has done a lot of the footwork for you so that your merchant compliance is simpler.
Right.
So, that brings us to the SAQ D, which we've talked about a little bit, contains all of the requirements, and merchants can use them depending on their environment.
That is another great question.
And one that the council keeps getting all the time is can service providers use the SAQ A or can service you know, can they simplify their compliance? Because the SAQ D-SP, which is the service provider version of the D, it is all of the requirements, including the service provider only requirements.
And it is the only SAQ that a service provider can do.
Yeah.
And a lot of service providers feel that that's not fair. Why do merchants get all the fun and we just get one? But it's because you're held to a higher standard as a service provider. As a service provider, it's not just your customer data that's at risk.
It's all of your customer's customer's data. So if someone can compromise a service provider, they have access to potentially a lot more information, and they're affecting the security of, you know, other merchants' environments themselves. So because of that risk, there is more scrutiny put on service providers, and they only have the SAQ D-SP as their SAQ of choice. So if they're not having a QSA validated rock assessment, the SAQ D-SP is the only one that they qualify for as a service provider.
That being said, there may be things that don't apply to them. You know, if if they basically, are a service provider that acts like an SAQ A, you know, they don't store, process, or transmit credit card data, but they have third parties that do that for them, then there's gonna be a lot of requirements in section, you know, requirements three and requirements four that would be not applicable and they would just need to mark those as not applicable. If they don't, if they never touch credit card data, then all of requirement three, obviously, they're not storing it. You know, and if they never transmit credit card data, all of requirement four is all about how we secure data at tran when we're transmitting it.
Mhmm. So service providers can still have a fairly simplified assessment if they are a simple service provider, but the form that they need to use is the SAQ D-SP.
Right.
And then for any merchant environment that doesn't fit any of the other alphabets of SAQs, if you're reading through the eligibility criteria and you're like, oh, we got that one. We got that one. We don't need that. Yeah. If you don't fit into the a, the A-EP, all of these alphabet soups of FAQs, the D is the one that you end up in.
Right. So last question, really, and it's about it's called a self assessment questionnaire. Right?
Yes.
Yeah. So this deals a lot with the brands themselves. So like Visa and Mastercard, they get to make the rule Visa, Mastercard, Discover. I don't wanna keep anyone out, American Express. But they make the rules on how their merchants can validate their compliance and at what level they can self validate and at what level they need assistance in their validation.
For typically, where we see validated self assessment. So a merchant is doing an SAQ, but they're having a QSA sign off on that. That's usually our level two merchants. So if you make it to a level two merchant, usually, your acquiring bank is gonna ask at least for a validated SAQ.
So you can still fill out the SAQ. It's gonna probably cost less because your assessor doesn't have to write out for every control, this is who I talked to. This is what I looked at. You know, they're still doing that work assessing, verifying that when we click the in place checkbox, you know, we know that's in place because we did the correct testing for it, but we don't have to write it all out.
So it's a little more cost effective for merchants to do a validated self assessment questionnaire if that's allowed, like, for level two merchants.
Once you hit a level one merchant, usually, your acquiring bank is gonna wanna have a ROC, QSA performed rock assessment.
And then we get to do all the exciting writing.
We get to do a lot of writing, and you end up with this beautiful, very long report that you can read whenever you're having a hard time sleeping.
Well, thank you so much. That was a really clear explanation of the SAQs, and I appreciate you joining me today.
My pleasure. Thanks, Jen.
Alright. Bye bye.
Thanks for watching. To watch more episodes of SecurityMetrics podcast, click on the box on the left. If you prefer to listen to this podcast, it's available on all your favorite podcast platforms. See you on the slopes.
.svg)
