SecurityMetrics Podcast

The SecurityMetrics Podcast, hosted by Jen Stone (Principal Security Analyst, QSA, CISSP, CISA), will help you understand current data security and compliance trends. Each episode will feature a different security professional offering tips and security best practices.

All Episodes

SecurityMetrics Podcast

Which SAQ type is right for my business? | SecurityMetrics Podcast Ep 102

August 28, 2024 • Season 5 • Episode 14

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.

Learn which one is right for your business based on your payment processing environment.

Learn about:

Different SAQ types for merchants
Eligibility criteria for each SAQ type
Factors to consider when choosing a SAQ type
Simplifying your PCI compliance

Listen now to learn what your business can do to protect itself from data breaches and be compliant.

#PCIcompliance #paymentsecurity #merchant #smallbusiness #cybersecurity

https://www.youtube.com/watch?v=XoR0Tt8uHl4

Request a Quote for a PCI Audit ► https://www.securitymetrics.com/pci-audit

Request a Quote for a Penetration Test ► https://www.securitymetrics.com/penetration-testing

Get the Guide to PCI DSS compliance ► https://www.securitymetrics.com/lp/pci/pci-guide

Get FREE security and compliance training ► https://academy.securitymetrics.com/

Get in touch with SecurityMetrics' Sales Team ► https://www.securitymetrics.com/contact/lets-get-you-to-the-right-place

Hello and welcome back to the SecurityMetrics Podcast my name is Jen Stone I'm one of the Principal Security Analyst 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 13, 14, years. I lead our enterprise audit team which handles all of our our large enterprise, government, higher ED assessments. Been doing it for a long time and 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. So the the full PCI standard can be a heavy lift and 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 that have very simple environments they don't need the full standard. So what the council's done they created the self-assessment questionnaire or the SAQs that are designed for specific, simple payment environments. So if you're a simple e-commerce merchant and you've outsourced all payment collection and processing to a PCI Compliant third-party provider, you've got a a partner that is PCI Compliant themselves and they're the ones that's collecting and processing that data for you then instead of going through you know all of the 200 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 feel don't apply in this situation and then you can focus in 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. It simplifies 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 e-commerce--for people who outsource um e-commerce--Let's talk a little bit about how you choose an A versus an A-EP versus a B versus a B-IP. How would a a an a merchant go about just even deciding what SAQ do I need to choose?
That's a good question. On the SecurityMetrics website, there is a guide--you know if you Google "which SAQ is right for me?" One of the first links is going to be that guide that helps walk you through that decision-making process. I think the council also--it's a little older--but they had a white paper titled understanding SAQs for PCI DSS version 3. It's really the same for version 4.0 as well. There's a few minor changes. But the first thing you need to do is understand your payment flows. How do you receive credit card data? Is it in person? Is this e-commerce 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 a short list of 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 e-commerce, if you have an e-commerce payment flow you're either going to be an SAQ A an A, and A-EP, or a D those are the only ones that support e-commerce. If you're a card present, we've got several others: B, P2PE, C, 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.
These are a lot of third-parties. So basically what you were saying was if you have third-parties managing basically 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, between if you have e-commerce like I mentioned before that you're either going to be an A, and A-EP or a D. If your website ever touches credit card data you're a D. 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 going to 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", if it's your web browser doing that and usually we see JavaScript being used for that type of control. If that's how your website is set up then you're going to 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 have your own website where people are selecting the goods or services they want to buy and then when they come to payment you're either redirecting them to another website; 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 e-commerce ones and kind of how to figure out which one fits you.
I've seen sometimes organizations that they 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 kind of shocked because the jump from A to A-EP 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 an A?
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. Antivirus, antimalware protections, quite a few requirements--even internal vulnerability scanning. 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 SAQ A, 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 the two new requirements that came with PCI version 4.0--requirement 6.4.3 and requirement 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 them out 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 card holder data. Moving on to the Bs. the B and the B-IP can you just give a little bit of an overview of what 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. So maybe you want to 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 the payment processor and sends all that data over that phone line. So the downside of that type of a connection is just the speed. It takes a while to establish those connections and to send the data across the 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, 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 and doing what you can to prevent skimming devices being put on your terminals. 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 going to see fewer companies that can meet that eligibility criteria. Which brings us to the SAQ B-IP in a very similar environment where we have you know a terminal us usually provided by your bank or your merchant acquirer, but instead of being connected to an 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 on a segmented network where there's no other communication with other devices on that network. So a few additional requirements to kind of secure that network space.
Yeah and and so again that the B-IP you start bringing in networks which of course you know the word IP infers all of that suddenly networks are in scope and um of course when you bring a network scope there are a lot of security controls there that just didn't apply in 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 and plug it into our network" it's maybe not as simple as that.
Yeah because if 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 it brings that network segment that they plug it into scope so if there's any other devices on there those devices are also in scope. So network segmentation is important, which, if you want to get away from the SAQ B because you either don't have analog lines, or you just need something that is a little faster um 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, we arrive at SAQ C. And to be honest C is not something I see very often. Occasionally I will. I'll see a C environment in, sometimes in a healthcare space. I'll see the C, but can you describe the SAQ C to us a little bit
The SAQ C used to be something I saw more often, like small restaurants they would usually be SAQ Cs, and a typical SAQ C environment, we may have you know two or three registers that on the same network and there might be like a backend point-of-sales server 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 SAQ C there's a really slippery edge is easy to to fall off the SAQ C 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 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 network goes down, or maybe you want to 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'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 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 encryption keys get injected on those terminals. So because the data like once if 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 was actually valid data. So that 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, and so sometimes people are a little cautious about putting in P2PE when because of costs you know they 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 I if if you need something faster than what the SAQ B supports you know or very easily merchants grow out of where SAQ B makes any sense um 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 encrypted 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, then for a lot of people it makes good sense to do that. And from a--
I agree. And 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, but from a risk perspective as well.
Yes, 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 C can you talk about the C-VT?
It's got some similarities where 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, so we're not swiping any card 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 for in in 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 it process you know that third party is processing the payment. So in a C-VT environment again we that workstation that they're using to enter the data that's going to 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 C-VT workstation on a an isolated network segment and it's only going to this website to process payments so this--a C-VT environment--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 and doing emails and everything. 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 website to enter the payment data.
So sometimes I get asked, "okay I have e-commerce and a B-IP device can I just fill out the B-IP SAQ 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. Specifically on those SAQs it'll say this is not intended for e-commerce use. So you cannot roll into one of these non-eCommerce SAQs. If you have, so typically, when I see someone have both a card-present environment and an e-commerce environment, if they want to assess their e-commerce let's say their e-commerce 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 e-commerce and another one. But they'll want to 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 I can I give you an SAQ A for my e-commerce environment an SAQ P2PE or B-IP for my card-present environment?" and a lot of acquiring banks are okay with that. Assessing each payment channel separately but if they do want those combined you're going to be combining to an SAQ D.
All right, so there a lot of people are familiar with these different SAQs we've already discussed, but then we come to this new one which is the SPoC or the S-P-O-C 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 I have seen it and I think as we get more SPoC validated solutions we'll see more but, but what this is, is if there are some solutions very similar to the SAQ P2PE there's this SPoC assessment, where SPoC providers, this is usually using some type of mobile device to accept payment data. If you are using devices that have been validated under the SPoC assessment, so you go to the PCI council's website and 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 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 because that's included in that listed solutions assessment already. So the SPoC, I haven't seen a lot because if I remember, there's only 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 when the SAQ P2PE first came out, there was only a handful of you know P2PE solution providers out there 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 the SAQ SPoC as the 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... The P2PE and the SPoC are really down to your provider's validations themselves so if your provider has either a a P2PE validated solution or if they're, you know if 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. What about service providers?
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... can they simplify their compliance?" because the SAQ D-SP which is the 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. 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 customers' customers' data so if someone can compromise a service provider they have access to a 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 ROC 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. 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 going to be a lot of requirements in section you know requirements 3 and requirements 4 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 3, obviously they're not storing it. And if they never transmit credit card data, all of requirement 4 is all about how we secure data when we're transmitting it, 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 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, ah, we don't meet that one". If you if you don't fit into the A, the A-EP--all of these alphabet soups of SAQs, 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.
But sometimes, you get a third-party helping you like a QSA will help an organization. Why? What happens? What's going on there?
Yeah so, this deals a lot with the the brands themselves. So, like, Visa and MasterCard they get to make the rule... Visa, Mastercard, Discover--I don't want to keep anyone out --American Express. But they 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 doing an SAQ but they're having a QSA sign off on that, that's usually our level 2 merchants. So if you make it to a level two merchant, usually your acquiring bank is going to ask at least for a validated SAQ so you can still fill out the SAQ it's going to 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. They're still doing that work assessing, verifying that when we click the in in place check box, 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 2 merchants. Once you hit a level one merchant, usually your acquiring bank is going to want to have a QSA performed ROC 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!
All right. 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!