SAQ A Unpacked: What Merchants Actually Need to Know
In this episode, QSAs Jen Stone and Michael Simpson break down the requirements that often catch even seasoned security teams off guard, specifically the new scrutiny on third-party scripts.
In this episode, QSAs Jen Stone and Michael Simpson break down the requirements that often catch even seasoned security teams off guard, specifically the new scrutiny on third-party scripts.
Stop guessing about your PCI status. Get a direct walkthrough from the auditors.
If you are an IT Director or CISO managing an e-commerce environment, you likely aim for SAQ A because it represents the smallest compliance footprint. However, most organizations fail before they even start because they skip the Eligibility Criteria.
In this episode, QSAs Jen Stone and Michael Simpson break down the "stealth" requirements that often catch even seasoned security teams off guard—specifically the new scrutiny on third-party scripts and the "Iframe Paradox."
What we actually cover in this deep dive:
Resources for you:
Official SAQ A v4.0.1 doc: https://docs-prv.pcisecuritystandards.org/SAQ%20(Assessment)/SAQ/PCI-DSS-v4_0_1-SAQ-A-r1.pdf
List of Approved Scanning Vendors (ASVs): https://www.pcisecuritystandards.org/assessors_and_solutions/approved_scanning_vendors/
AWS Responsibility Matrix:
https://aws.amazon.com/compliance/shared-responsibility-model/
Azure Responsibility Matrix:
https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility
0:00 - Introduction
0:39 - SAQ A Eligibility Criteria
1:41 - Criterion 1: Card Not Present Transactions
2:01 - Criterion 2: Totally Outsourced Payment Flows
2:31 - Criterion 3: No Electronic Storing or Processing
3:06 - Criterion 4: Analog Records
3:25 - Criterion 5: e-Commerce Page Origins (Redirects vs. iFrames)
5:19 - Criterion 6: Protecting against Scripting Attacks
6:24 - How to "confirm your site is not susceptible"
7:37 - Technical Requirement Overview
7:58 - 2.2.2: Server Hardening and Default Passwords
8:43 - 6.3.1: Managing Vulnerabilities with Policies and Procedures
9:08 - 6.3.3: Patch Management (30-Day Rule)
9:24 - Access Management: Backend vs. Customers
10:05 - 8.2.1: Unique IDs
10:21 - 8.2.2: Securing Break-Glass Accounts
11:51 - 8.2.5: Managing User Departures
12:03 - 8.3.1: Identity Verification
12:21 - 8.3.5, 6, 7 & 9: Password Standards & MFA Recommendations
14:18 - Requirement 9: When it applies to SAQ A
15:03 - 11.3.2 & 11.3.2.1: Approved Scanning Vendors
15:39 - Tips for Passing your Vulnerability Scans
16:22 - Requirement 12: Vetting TSPS
17:58 - Common Misconceptions: AWS/Azure Responsibility Matrix
18:47 - 12.10.1: Plan for the Worst, Hope for the Best
19:23 - Conclusion: Avoiding Scope Creep, and Keeping Compliance
Jen Stone
My name is Jen Stone. I'm one of the principal security analysts here at Security Metrics. Today I have with me Michael Simpson. Oh, let people know a little bit about you.
Michael Simpson
I'm a QSA here at SecurityMetrics. Been doing this for about 15 years.
Jen Stone
Awesome. So we are going to be talking about the SAQ A, which a lot of times people go, oh, I'm an e-commerce, I'm just going to do an SAQ A. And then they jump right into answering the questions, but they skip by the most important thing, which is eligibility criteria.
Michael Simpson
The SAQ A is one of the three SAQs that can be used for e-commerce. The SAQ A is definitely the easiest one. The, you know, the most simple e-commerce environment. This is an e-commerce environment where as a merchant, we don't store, process, or transmit data. We never touch it. We don't. We've outsourced that to PCI complaint third party providers. They're doing that for us in order to know that this is the right SAQ for me.
Michael Simpson
We need to be able to answer or check each of those eligibility criteria. So they're just statements to say, you know, statements that talk about the merchant payment environment. And if all of them apply to you, then that's probably the correct SAQ.
Jen Stone
So I mean, let's just walk through the first bullet point of eligibility criteria. What does “card not present" mean?
Michael Simpson
We don't have customers coming on site and making payments. Customers at home, they're either calling or they're going to our website. If it's a third party call center that's answering the phone, taking the payment on your behalf. You could still be an SAQ A.
Jen Stone
Well, let's look at the next bullet point. All account data processing entirely outsourced to a PCI, DSS compliant TPSP or third party service provider.
Michael Simpson
The biggest point here is where entirely outsourcing. So we're not part of that payment collection or processing at all. And not only are we outsourcing, but the companies were outsourcing that to they are PCI compliant themselves.
Jen Stone
Yeah. And that third bullet point it does it says exactly what you've been saying all along. Merchant is not electronically store, process or transmit any account data on their systems or premises.
Michael Simpson
I've seen so many e-commerce merchants that are trying to fill out the SAQ A, where I go to do their assessment, and they have a third party that's hosting that website is capturing payment data, but they're receiving over the phone, and their staff is typing it in to that third party website. Yeah. You know, so this makes it very clear that you can't do that.
Michael Simpson
You know, if everything from the customer entering the data to the data being process, you are out of it. It's only your third party.
Jen Stone
The fourth one is I think we're looking at any retained account. Data is on paper only.
Michael Simpson
I've been doing this, like I said, for 15 years. I've never seen an SAQ A merchant that has credit card data on paper. It could happen. I haven't seen that.
Jen Stone
I've never seen it.
Michael Simpson
It could.
Jen Stone
Happen then that last, the fifth bullet point in the first section. I shouldn't say last because there's two more that are really important coming up. But for e-commerce specifically, all payment page elements delivered to the customer's browser originate only and directly from a PCI DSS compliant TSB.
Michael Simpson
There's three different types of e-commerce setups that would qualify to be eligible for the SAQ A. The easiest and the most clear example of an SAQ A is if from the very beginning, like if someone goes to the website to select what they're going to purchase all the way to the checkout page. If everything is done on a third party website, that's for sure in SAQ A.
Michael Simpson
So people will be on, you know, the merchant managed website, they're selecting what they're going to be purchasing and then it then at some point you know they're ready to check out during checkout, one of two things will happen for them to be an SAQ A. They will either be fully redirected out to a third party to make, you know, a payment capture.
Michael Simpson
So instead of having, you know, the URL up at the top will all of a sudden switch to like authorized on it or PayPal or, you know, some third party website is going to capture that payment information. That's one of those three ways. The second, maybe they stay on that merchant's website. So if they look at the URL, they get to the checkout page, and the URL still looks like we're on the same page.
Michael Simpson
Sometimes what can happen is they're pulling in a third party iframe, which is a small piece of code. So it's kind of like we've got this little payment website within the big website that we've been dealing with that whole time.
Jen Stone
So we've covered the the ones that if people do read the eligibility criteria, which, which more people need to read that they'll they'll stop there and not look at the last two, which are the really important ones.
Michael Simpson
Yes, the very last one. The merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchants e-commerce systems.
Jen Stone
This is so big.
Michael Simpson
It is. It is big. It's confusing in my opinion. Poorly written. Every site can be susceptible to attack from scripts.
Jen Stone
Yeah.
Michael Simpson
But we know the the the the reason or the what the council is trying to get at from this question. If you are using an iframe, iframes on the merchant website are by definition susceptible to scripting attacks. Yeah, this, you know, malicious code could potentially get all of the information or scrape all the information that's being typed into that iframe.
Jen Stone
Right. And people might have heard of mage card attacks. That's one type of this, this attack. That's where we're seeing breaches happen. And and I think we shouldn't downplay the criticality of making sure that you're not susceptible to skimming attacks. Merchants that believe they're Saka if they haven't considered this this point of make sure that you're not susceptible to skimming attacks, how can they do that?
Michael Simpson
The council's told us there's two ways to do that. The easiest is if whatever third party is providing the iframe that's used to capture payment data, if they provide documentation, the merchant that says, hey, your site, because of the way you're interacting with with us, is not susceptible to scripting attacks. Technically, Council says you can check that box and move on.
Michael Simpson
So the third party, the payment gateway, they're not managing your website, so they can't really say, oh yeah, your website's not susceptible to attacks in my opinion. It's just we're okay assuming that risk. So that's one way the other way that the council has said that we can check this box if we're using iframes to capture payment data is to be compliant with requirements 643 and 1161.
Michael Simpson
Those two requirements that they took out of the SAQ A between version four and 4.0.
Jen Stone
And one people said, oh, well, it's not necessary anymore. Not not realizing that. Yes it is. Yes, yes. Now that we've done a pretty exhaustive overview of the eligibility criteria, actually, that's the hard part. Yeah, you get through that and then there's requirements. And and the nice thing about SAQ A is that there's very few requirements. But so let's talk through them.
Michael Simpson
They apply to the shopping cart website or your website. Yes. That is interfacing with the third party that that is then going to capture payment data right. Requirement 2.2.2 is part of the the server hardening requirements. Right. So as part of standing up a new server, you know, this e-commerce server, we need to make sure that as part of that hardening process that you went through, that you've removed any default user accounts or passwords.
Michael Simpson
Usually the only time I see default passwords nowadays is if you're using like SNMP for management, they'll have default community strings. You'll want to make sure that those were changed. If if you enable SNMP on your servers we want to make sure that people can't just Google, hey what's the default password for X. And then just go and log into your system as the administrator.
Jen Stone
Yeah exactly. So requirement six as you mentioned there's only two there. 631633.
Michael Simpson
631 says we have a vulnerability management process in place. So we've got policies and procedures that define how we find out about vulnerabilities that could affect that server or any applications running on the server. We have a way to identify the criticality or the risk that each of these vulnerabilities post six, three three is specifically patching vulnerability. So we also need to have a patch management process that would include, you know, installing these critical and high security patches within a 30, you know, least 30 days from the time there.
Jen Stone
So yeah. Right. Okay. So requirement eight also some technical ones. And this is the the biggest set of requirements you know per requirement. This is all about user authentication.
Michael Simpson
And again it's authenticating to the server. One thing that some people mistake. This is not like if if you have an environment where your customers have to authenticate into your your system when they're making purchases, this doesn't have to do with your customers. This is your administrator. Your developers are liking into the server to to make changes to your website.
Michael Simpson
You know, how how are they authenticating to that server.
Jen Stone
So unique IDs group or shared credentials tightly controlled. If there's a business justification, I have a hard time accepting the that they're any type of group or shared credentials is necessary. I you know I've, I've looked at this requirement in a lot of different environments and I'm I'm. Suspicious of group insurance.
Michael Simpson
In version four, I think the council came to the realization that, you know, a lot of people, while they they may not actively use group accounts, they have break glass accounts that are not tied to an individual.
Jen Stone
Okay. Yeah.
Michael Simpson
You know, so they might still have an administrator account or a root level user that just in case everything goes wrong, you know, maybe we just have one admin, Lisa, as our admin. And she just won the lottery and is gone. And we just hired Bob and we have to get him in. But Lisa is not there to log him in and create an account.
Michael Simpson
So we take that break glass account. You know the old crap, something's gone wrong. We need to get in here. And then we use that to create Bob's account. So I think that, in my opinion, is where, you know, there are some instances where there would be a need for a group account or an account that's not assigned to one specific individual.
Michael Simpson
But we need to make sure that we have policies and procedures in place that say this account is only used in exceptional circumstances, it's only used after management approval and the use of it is documented. We know when it was used, who used it and why it was used, you know. So I think that really applies to those great classic.
Jen Stone
Yeah. Honestly I'm going to want to see some monitoring and alerting as well. So if somebody does use it, a whole group of people get to find out. About 8 to 5 terminated users. Access is immediately immediately revoked.
Michael Simpson
If someone like we just talked about Lisa won the lottery, she doesn't need access anymore. Well, Lisa's account shouldn't be on there. And there's 831. This just basically says that we have some type of authentication happening. So we're not just using the user ID, so we either need to have a password a token or a biometric event. So 831 is pretty simple.
Michael Simpson
It just says we are authenticating our people. Right. 835 talks about the process when we're creating new accounts. Like we just hired Bob. We we shouldn't always when we set up his account, his temporary password, if we're creating one shouldn't always be temp one, two, three, you know. And then we know. Everyone knows. Oh, they just hired a new administrator.
Michael Simpson
I'll bet I know his password.
Jen Stone
So 836 password.
Michael Simpson
Minimum the the password. As long as the system supports it. And most of them do. And I've seen some that won't need, well, characters long with complexity enabled, which basically means we have at least, you know, alpha and numeric digits within our password.
Jen Stone
And then eight three, seven.
Michael Simpson
When we're setting new passwords we can't reuse the last four. So it's a password history requirement. We need to at least keep four passwords in that history so that, you know, if if Bob is going to reset his password and he already used the yellow dog, ran around the tree one, two, three as his last one. When he tries to do that, it'll say, oh, sorry, this passwords already been used.
Michael Simpson
Try something else. There's one more eight, three, nine. And if if passwords are how you authenticate and you're not using multi-factor authentication, the passwords need to rotate every 90 days. If if you're using username, password and a multi-factor authentication, which is what I would recommend. So so people put in their username and password, and then maybe they get a one time token from their phone or some other, some other way to, to authenticate who they are.
Michael Simpson
That's not something they know. It's either something they have or something they are like a biometric. Then eight, three, nine wouldn't apply to them because 839 only applies for single factor authentication setups.
Jen Stone
But everybody should be using multi-factor authentication. They should for really for everything.
Michael Simpson
If you look at the rights and breach report bad passwords, in my opinion, at this point in time, there's very few instances where it makes sense not to have MFA.
Jen Stone
I agree, I agree. All right. So that brings us to requirement nine. And there's a handful of of sub requirements there. And it's special in the same way that requirement three is special.
Michael Simpson
I don't know why these are in the Sakha. Maybe I've been assessing the wrong merchant. So I. Just every merchant that I've assessed nine four doesn't apply. If you do store credit card data on file, you know, you need to you need to have policies and procedures that define how it's secured. It needs to be in a secure location, ways to securely destroy that once it goes beyond that retention period.
Michael Simpson
Be using a secure courier service or someone internal that management needs to track. You know, when that data is being sent from one location to another. For most SAQ A, it's just not going to apply.
Jen Stone
So three 211 321. We're talking about external vulnerability scan done by an ASP. So walk us through some of those.
Michael Simpson
There's third parties out there that have been qualified by the PCI Security Standards Council. To perform these PCI required external vulnerability scans. ASV stands for Approved Scanning Vendor. So find one of those companies and you'll need to have scans done on your site at least every quarter. And then if you're failing one of those scans, you need to go fix it and reskin.
Jen Stone
What if it's your first year?
Michael Simpson
You don't necessarily have to have four quarters worth of scans, but you do need to have a policy that says you're going to do a quarterly, and then you need to get that first scan in. We see people fail this a lot when they have staff turnover. If there's only one person that's responsible to make sure you're passing your scans and that person leaves and the, you know, the person they hire doesn't realize that the scans are even happening.
Michael Simpson
It makes sure in your process that there's some kind of redundancy built into it. You know, maybe, maybe there's an administrator that's responsible for this. But management is also getting those scan results so they can make sure that that they do pass those scans.
Jen Stone
So that brings us to requirement 12. Walk us through what that looks like a little bit.
Michael Simpson
1281 says that we keep a list of who those third parties are. Requirement 1282 says that we have some type of written agreement with them, where that provider's acknowledging their responsibility to protect that data for us. So this is usually in the contract that you have signed with the third party. It doesn't necessarily have to be and it doesn't say exactly what the wording needs to be, but something that you are comfortable with as a merchant.
Michael Simpson
You know, if there was to be some type of a data breach and you had to litigate this, you want to make sure that you have a good acknowledgment that you can use in an event like that. 1283 really talks about the process for selecting these third party providers. Vet them in some way before you select them. Some companies will check their the third parties financials, because it can be a pain to switch these third parties out.
Michael Simpson
And then 1284 basically says once you've selected a third party, you can't just ignore it. You should have a programed least every year. You're kind of rebuilding or reevaluating, making sure that that third party is still PCI compliant and they're still handling your data in the way that you want it to be handled. Right. And then the last 12 eight requirement talks about our knowing what each of your third parties is responsible for and what you might still be responsible for.
Michael Simpson
This is something that I see happen a lot when companies are hosting their their e-commerce site, like in Amazon Cloud. So if they're in AWS or maybe Microsoft Azure, a lot of them feel like, oh, well, AWS is compliant. So I'm obviously PCI compliant as well. Not always. It's not necessarily true. So so you should look at, you know, those those cloud providers, they have a security responsibility matrix that goes through every requirement.
Michael Simpson
And it helps you understand whether it's a requirement is fully managed by the third party or if it's shared between the merchant and the third party, or if it's a merchant only responsibility. Make sure that you understand exactly what you've outsourced, a third party and what you are still responsible for.
Jen Stone
Right? Excellent. So then the last one is 12 .1.1.
Michael Simpson
Everyone should have an incident response plan. Sometimes bad things will happen and you need to know how to respond in an incident. You don't want to get to a point where you find out that there's been a security breach. Figure out, oh crap, what do I do now? You should know what to do now because it should be in your plan, right?
Jen Stone
So that covers, you know, all the requirements. It covers the eligibility criteria. What is maybe some of the gotchas that people need to look out for or, or a piece of advice that you might give people who are, who are trying to fill out the SAQ A.
Michael Simpson
Know what your people are doing. People are just helpful and which is great. But if if your environment is set up to be an SAQ A which states that you are not part of storing, processing or transmitting data, if someone comes into your place of business and says, hey, I really want to make this purchase or sign up for this event, but I'm having a hard time.
Michael Simpson
Can you help me out? If your staff goes, hey, no worries, let me bring up the website and do that for you. You all of a sudden have broken your scope. You're not an SAQ A anymore because we've got workstations that are processing credit card data. Yeah, and it wasn't designed to do that. The other one is PCI compliance is not a once a year event.
Michael Simpson
You know, it's an everyday event. So just because we were able to go through all these questions and mark everything is in place doesn't necessarily mean we're going to stay that way. Right. So plan for the worst. Hope for the best.
Jen Stone
Thank you so much for joining me. Can’t wait to talk to you again soon.
.svg)