Watch to learn how to help you prepare your team, streamline your process, and set the foundation for a successful and smooth assessment process.
In this webinar, Gary Glover (VP of Assessments) and Matt Halbleib (Director of Security Assessments) discuss how to:
This webinar was given on August 27, 2025.
We're grateful that you're here with us, and we're excited just to kinda talk about a few things that Matt and I have been thinking about for a long time now.
And with that said, let me do a little bit of introduction. I'm Gary Glover, the VP of our audit department
here at Security Metrics, the assessment department. I've been working with specifically the PCI standard for twenty years about and, from the beginning. And we also have with us today, Matt Halbla, who is the director of our audit team here at secure Securitymetrics. Matt, how long have you been doing this?
Seventeen and a half years and a little change.
Seventeen and a half. So just a little bit of experience between us two here. So, hopefully, we can give you something that we've learned in that time. We're gonna be talking today just a little bit about some of the common mistakes that organizations can make, during their very first PCI audit.
And, you know, I think we chose seven. I'm not sure that there's only seven, and maybe you will have some different difficulties that if you've been through a PCI audit before, maybe you'll have something else that we won't say. We're not gonna say that these are in any order of importance necessarily. We're just gonna be kinda talking and having a discussion today between the two of us.
And then, we're hoping that you can, go ahead and, submit any questions you may have, and we'll do our best to answer those, when we're done pontificating about this topic. So, with that, I guess we'll kinda just jump in. I think there's a lot of time that people will begin a PCI audit. Maybe they've heard about it or you've been in an SCQ situation before, and now you're finally, you know, your level is high enough that you need to have an assessment conducted by somebody like Matt or myself.
And what does that really entail, and what kind of things are gonna be difficult that you need to be thinking about as you prepare for that experience? So, hopefully, those are some of the things you'll come away with after our visit today.
And I think, you know, we I said before, Matt, that if we, we didn't really put any of these at importance. However, the first one we're gonna talk about probably if I was gonna pick the most important thing, it would be this. And that's really kind of underestimating and really not understanding scope. And as we define scope for a PCI audit, it's really helping you define the card data environment or anything that may affect the security of the card data environment. And those are the systems that have to be thought about.
And the card data environment is defined as, you know, people, systems, process, technology.
That are gonna affect the storage processing and transmission of credit card data, during any of the processes that you may be conducting there at your businesses. So now let's just have a quick discussion about that. What are some of the things I think that come up in our minds about scoping and the difficulties there?
Yeah.
You know, like I said, we it's not that we've ranked these or anything, but it helps to every time we talk to any new customers or anything, we have to have a discussion about scope.
Like you mentioned, it's something that's often misunderstood.
Sometimes you can have some difference of opinion on things.
But, like you said, it's people, process, technology.
If you read the PDF version of the PCI DSS, they have a good scoping discussion at the start there, and there's actually some supplementary materials that the council's put out trying to help people understand this concept.
But, you know, kind of in a nutshell, if I had to put it all into one sentence, it would be if it stores, processes, transmits cardholder data, it's connected to systems that do, or it could impact the security of systems that do those things, then it's in scope for, as the PCI Council says, all applicable PCI DSS controls.
Sometimes that means that some controls might not be as applicable to an area as another, but, then that at least helps us understand where we need to take this PCI standard and to which systems people process technology we need to apply these controls.
So kinda like you, I'm sure in your experience, you've also interviewed a lot of people.
And, I know for me, we start with that. I call it peeling the onion, but, you know, start with this kind of this big scope and go, okay. Name everything that comes in and out of this environment here as you think of it. Where do you have cardholder data?
And then start asking about where it leaves that same environment.
Mhmm.
Are you just sending it to a processor?
Sometimes people overlook. It's like they don't think about the call center and the fact that sometimes they get, card data coming in through the phones. Right. Because they have people either accepting transactions or asking questions about them, and people will be actually stating the card number on the phone. That means then there's the ancillary systems of your phone system potentially, especially if you're using voice over IP.
But also then if you're doing call recordings. And people don't always think about those things as being part of their cardholder scope, but they are. Right.
I know when I talk to people initially when they're getting ready for an audit, I draw a little bit on some of my mechanical engineering days and use this thing that I call a control volume. So I'll just draw a square on a piece of paper as I'm talking to people and say, now that square represents your border per se. Now what and you mentioned earlier, what are all the things that cross that border in and out? And it's interesting how you go through all of those obvious ones, you know. Well, yes. We're getting card numbers from our POS system. We're getting card numbers through ecommerce.
And then, you know, after a while, you go through all these things and then you say, well, is there anything any other way? Well, yeah. Well, I mean, we do get this transmission of card data from the banks, but that's really not part of our thing. And it's like, okay.
Well, let's talk about that. How do you get that? Well, it's an FTP server and oh, okay. So it's funny how people have presupposed in their minds, here's what our scope is.
Don't tell me what it is. Right? I know what my scope is, and I want it to be my POS systems and nothing else. Or I want it to be my ecommerce system, and nothing else.
But maybe you only have that. But after just discussing and talking about all the processes, what departments you have, do you have anybody in accounting that's doing something weird?
Are they getting data?
At one point, I was interviewing some people that were in accounting, and they said, oh, yeah. No. No. We keep all of those files that are sent to us from the bank because we wanna make sure we have those.
And so let's look at those. So, yeah, they're just Excel files, and they're in our shared directory, you know, our shared drive. We go, oh, okay. So people are often just doing their jobs, what they need their jobs to be, and and, making sure that they can back up everything that they've done.
So it's really important, as you mentioned, to talk to people.
Yeah. And as you said, you know, asking about the inflows and outflows and and specifically, like, say, okay. Well, you know, it enters here, but then what other systems do you send it on to? I mean, I mentioned phone systems and things too.
But sometimes you're like, oh, well, yeah, we keep backups over here. And then you ask specific I mean, there's specific questions and requirements around securing the backups, but they don't, they just think of that as a utility, and it's just there. It just does backups and everything. But from PCI's perspective, that's storing cardholder data.
Mhmm.
You mentioned finance. You know, oftentimes, they get a feed from the bank so they can reconcile the books and go, okay. Our our, you know, our website or our stores or whatever said we sold these items. The bank says we got these monies in and out.
Sometimes there's also disputed transactions or chargebacks and things that have a slightly different process.
Sometimes it's logging into a portal at the bank, which is probably the best way to have that, and the bank often won't show the full card number. They've kinda gotten better about that.
But sometimes too, they'll send, maybe a PDF and an email or something with details about, chargebacks and things. And finance is the one who gets those.
I think, you know, I think people often just think they know where all the card data is. They kind of decide that this is our normal process.
But it's really important for somebody to go through kind of a formal, and that's one of the things we ask them to do at the very beginning is, well, let's chart out. Let's describe if anything or or draw all the different flows of data. Once you figure out what comes through the control volume, now you have to figure out, you know, through your borders in and out of your borders, now what happens when it's inside.
And it's this process of talking to people, understanding all of the different people that might be involved in it, and it takes time. And you have to do investigative work often, and people will find stuff that they do not necessarily understand or even think that people are doing.
Yeah.
You know, that's a great point. And it's not that you can't do those things. It's not that you can't store the cardholder data and stuff. But if you don't know what's happening, then you don't know how to secure it improperly.
It's hard to figure out if there's a way to stop that process.
Right?
Sometimes Right.
Or modify your business processes to go, why are we sending it over there? We don't, we don't need to do that. You know, maybe it was an old process that just never got deprecated.
Right.
So yeah. That's and that's the advantage of having somebody like us come and ask questions, is that we'll start poking on processes. And, you know, we'll get your database administrator in there, and we'll talk to them and say, oh, well, what else does it do? And we start asking about, you know, proceed stored procedures and whatever they have.
Right? And what the database interacts with. And I know you and I have been doing this long enough that oftentimes, you know, when I start poking on I'll I'll think we have the scope defined. I go start interviewing people to ask about all the different requirements and tell me how you're doing your encryption and whatever.
And you start asking about these specific systems. And then as you do, you'll every now and then, you'll hear somebody mention a name. You're like, I haven't heard that system mentioned before. What is that?
And, and then you'll find a process that Mhmm.
Many people didn't know that was still going on or whatever.
And we didn't think our call center was in scope, you know?
Yeah. Right. Yeah.
And like I say, it's not a negative that, like, like, you're gonna fail your assessment or something just because we found, you know, a spot where you had cardholder data and you didn't know it.
You know, the advantages yeah. For, you know, from a security perspective, like I say, if you don't know that it exists, you don't know how to secure it either.
So it's actually a good thing to find those processes that were kind of hidden, if you will.
So how does network segmentation relate to scoping in your experience?
Yeah.
Good question. And so requirement one is all about firewalls and things. And one of the things we have to do, right, is go in there and actually look at firewall rules. And there's a requirement that says that you need to limit all inbound and outbound traffic to only that which is necessary for the cardholder environment.
And so this goes back to your scope and what's, you know, things that are connected to what you kinda consider your CDE, your cardholder data environment, or your cardholder environment.
And so that with that firewall, we're gonna look at your rules, and we're gonna go through. And this is one of those, you know, backing up slightly in our discovery process. We like to get diagrams of the network and your cardholder flows. Right?
And we'll talk to you about them. We'll go, okay. Is this all of it? Yeah. Yep. That's it. And then in that process, we'll go in and look at your firewall rules and say, oh, you have this rule that says these ports and protocols between this system and this system are permitted or whatever.
And going back to what you told me about your diagrams, I'm gonna go, well, on the diagram, you showed those two systems weren't communicating.
But in your firewall rules, it shows you are. Mhmm. So from PCI's perspective, that means that those two are connected, and therefore, they're in scope.
Right. So at that point then, you have a business decision. It's like, well, okay. Do those two need to talk? Or is that rule there for something older and it's no longer necessary?
But you get to make a a business decision at that point and decide how you wanna handle that. Right.
What is your experience?
So I'm sure you've seen some interesting things.
So even in between, you know, lots of times I see people will say, well, no.
It's on a different network segment.
We have a different zone in our network defined from the firewall or whatever. Okay. Well, let's look at the rules between these two zones or look at the, you know, the router, the rules on the router.
And they're just open on ports that are very promiscuous. You know, often there's some Microsoft, ports. Early on in history, there was a lot more of this action going on. But, really just understanding it's not just, yes, I have it segmented.
This is on this zone, this is on this zone, and this is on this zone. You have to actually segment those by rules and by logic, not just by, hey. I created a different spot for that. So it's definitely segmented.
So it's understanding kinda when your auditor or someone says, is it segmented? Is it separate? Is it limited in its traffic? So, you know, this is one of those topics I think Matt and I could probably talk about for a long time.
In fact, I've given whole presentations just about scoping before. So in other words, you know, to summarize up then, scoping and understanding your environment, super important. If you don't, it may give you this false sense of, look, I I really know what's going on here.
And, you know, there's a risk then that your breaches can occur through an unmonitored system or through some other area that you're not protecting an HVAC system or whatever. And we've seen that happen, through our forensics team a lot of times. So Yeah. We've talked about different ways to avoid it. It's really just doing your due diligence, thinking through the process, drawing it all out, taking the time, and not just assuming that you know everything.
I think another important thing might be that you can actually even use tools that are out there that can discover unencrypted card data if you as you set it to look at different file locations.
Think about a river and where the eddies and eddies just collect, you know, flotsam in a river. And are you gonna try to find those eddies where this card data maybe you don't even know where it is. So look through people's systems, use these search tools. Security metrics has one called PanScan. There are many other tools, on the Internet or on the, available from vendors out there that look for card data. So that's part of a good scoping system. Right.
And it helps you tell your story of why this is my environment.
And Right.
I mean, if you've gone and searched and gone, yeah. I've actively gone and looked for card data, and I didn't find it in other spots.
Whereas, you know, in some of the new requirements since in four dot o says, have you confirmed your scope, and what is the documentation you've done that? How do you know that's and that kind of implies, you know, show me proof show your auditor proof that you've you've done those, those events or those actions. So that's down in section twelve of the PCI standard.
So the next big topic, I think, that is often misunderstood and hard to do is just kinda skipping any kind of documentation until the very end or not worrying about security policies and documented procedures. And if you're encrypting card data, have you written out how you're doing it? And why is documentation so important? And for small companies, especially, they're thinking like, no.
You know, there's four people here. Come on. We all know what we're doing. We don't need to document this.
And where, you know, I used to work for a company that had a hundred and thirty thousand people. Of course, you need to have documentation of of of that. But why is documentation important for even well, for everybody? And why is it a requirement, you know, kind of in PCI?
Yeah.
And it is true. We have often have a lot of new clients who don't have any policies or procedures, because frankly I get it to an extent. They're just trying to get their business done. Mhmm.
And like I say, it's you know, it started with four people, and writing it all down wasn't a problem because you and I talk to each other every day, and, you know, he's just right down the hall or across the office or whatever. It's you know, it seems like that's easy. But without the formal policies and procedures in place, then it's also easy to deviate from what you should be doing. And PCI has a very specific, as we talked about, the scoping thing.
There's implications when you change a process.
If you say, oh, well, you know, before we chose to not store cardholder data, but now the marketing department really wants it because it's this great unique identifier, right, for people, and we can we wanna, see what they've been browsing on our, on our web page. We wanna make the checkout process easier or whatever. So as you make changes to those, policies or even procedures in your organization, then you need to understand the implications of that. And so you need to have the policies that back it up and say, oh, well, we're going to encrypt all our cardholder data, and we're only going to store it for so long. And then you need to build the processes or procedures that back up that policy. So when you say we're going to you know, your policy may say I'm going to encrypt, but then you have a procedure that says, oh, we're choosing to use AES.
And, you know, now with things like quantum cryptography coming in, threatening certain kinds of crypto, you know, it's important to have the ability to understand what an an four o ask you to do this, track what kinds of cryptography you're using in your organization, and have the ability to easily modify it in case there's a you know, an algorithm is broken or whatever and becomes, you know, necessary to change it. You don't want it hard coded everywhere to make it hard to do that. So, anyways, that's kind of an example of policy procedure thing. But those policies dictate what you should be doing. The procedures tell you how you should do it, and then are easy to communicate when somebody new comes along.
Right. I'm sure you've probably seen lots of people who don't have it, and therefore, things vary across the organization.
And if I would say, that's probably you know, we're all kinda techie nerds that get into this stuff for the most part, and none of us really like to write anything much. Right? Yet we're asked to do a lot of writing. So that is sort of a pain point.
The first time you've been through this assessment is, like, you mean you're telling me I gotta write or I have to document this stuff? Some people love it. Some people just really don't like it. And having adequate documentation, and this policy and everything is super important, and it's not something to leave to the end.
So a lot of times, we really force people upfront to say, okay. Well, let's work on making sure you have these, and let me review them, and let me help you. Well, can we give you a a checklist of all the things that need to be in there if you already have some policies written?
A lot of times, you know, some large organizations have tons of policies, but they may not specifically address the things that need to be there for PCI.
Or maybe their policies are, like, a hundred different documents, and maybe they need to consolidate for PCI. There's lots of different things that people may need to do, but, you know, you don't wanna have to scramble to do that. It can lead to delays at the end.
And from a more mundane perspective, like, say, it's not that everybody likes to write policies and things. But, ultimately, for us to complete the report on compliance, I have to say you have policies that say all these things.
And very specific. We even have to kinda know where they're at and confirm that they're all there as QSA. So a lot of times people will provide a template maybe to start with. As you know, QSAs can't write your policy and then audit them. So there may be you know, if you are really having troubles with that, you maybe look for an external consultant or somebody. Get us a set of templates from somebody, and then they're easier to modify. There's lots of ways to approach this problem, you know, that we've tried to make it easier for people over the years.
But it's still the thing that is procrastinated quite a bit. Right?
Yeah.
And like I say, it's nice to have even an example to start from so it's not just created from whole cloth, but exactly.
You can go out and find those, you know, example policies and things. Yeah.
A lot of places. And, you know, companies like SecurityMetrics, obviously, we have some of those templates that are made available to people.
So, that kinda wraps up. So documentation, again, is one of the harder things for people to do, kind of a longer poll item that really needs to be worked on at the beginning rather than, oh, we'll leave that to the end because people just hate doing it. So, and I think, let's go on another topic here, and that is kind of understanding the effort required to really beat this assessment.
And really, you know, do I treat this as well, let's get this over, and then I don't have to think about it anymore for a whole year. Right? Is that really the mindset that you should be in when starting this PCI process? Have to admit there are times when we do meet customers that have this, you know, just get this over.
Give me my check marks, and let me get back to selling things, or give me back to my work. And they don't understand that it really is something that will help them in the long run, and it keeps them taking credit cards. If they don't, you know, if you don't wanna do this, then you don't take credit cards. So, thinking about PCI as a continuous process and and, you know, actually doing things and making yourself say, well, it's not just once a year.
There's once a year to validate, but there are many toss tasks and things that I need to be doing continuously. What are some of your thoughts kind of about the hardships people have in those areas?
Yeah. Good question. And I think that is a, you know, there's kinda two parts to what you said. One is misunderstanding the effort that's required.
Some people think they're secure and they've got everything buttoned up. And on very rare occasions, we find that's true. But in many cases, when you get somebody from outside, an assessor, who's coming to look and poke at your systems and and go, why are you doing this? And is this in place?
And tell me describe this process for me and everything. You start to understand that the effort required to be PCI compliant is greater than you thought. And some of that, I think, is because people honestly just don't take the time to go read the standard.
It's not exactly scintillating reading. It can be rather dry. But, you know, it is important to go read it and understand the requirements because you're gonna be asked to comply with them and show me evidence that you're doing it. So you mentioned this continuous process idea.
Version four of the PCI DSS actually has a section requirement twelve dot three where it talks about a a TRA, and you have to do this risk assessment.
Targeted assessment or targeted risk analysis.
Yes. Targeted risk assessment. Thank you. TRA.
Yeah. So for certain things that have a certain periodicity to their requirements, doing your seg checks every six months, if you're a service provider, at least annually if you're a merchant or whatever, doing your pen testing, doing your quarterly scans. All those things have to go on a regular basis.
And some of them, the periodicity is left up to you as an organization. You can do this TRA, go through a little risk assessment, and go, oh, okay. Based on how we do business, we think this needs to be checked every x frequency.
And then the assessor is going to ask you to demonstrate that you're doing that.
So change control is one that's required both for software development as well as applying patches, as well as updating your firewalls and things.
So if you tell me that, you know, oh, yeah. We changed the firewall rules and added this and add that. I'm going to ask to see the evidence that you did that and you followed the process in your change control process. So that means you have to have the documentation that you did it.
So the effort isn't a one time, we're gonna, you know, rally the troops and get it all done in six months and be done with things and then ignore it. It's putting in place new controls, new processes and things, and then all of a sudden, you know, okay. We got our rock. Some people have a tendency to kinda step off the gas at that point.
Mhmm. And go, okay. Whew. We're done for another year.
When in reality, you have to maintain those processes throughout the year.
Right.
And you have to be able to demonstrate to you or to me that you've done them.
And that means some sort of documentation. You can't just say, oh, yeah. I pinky promise. We did those things all year long. The assessor has to have something they can cite in their report that shows that you actually did it.
Right. And, you know, one of the examples I think that's kind of new to people in four o is just that if there's a change in your cross if there's gonna be a change, you need to rescope. You know? So in other words, if you decide, hey. We're gonna add ecommerce. Okay. Well, then do rescoping documentation.
And if you lose an employee who is at the head of a department or something like that, then you need to make sure that you're make rescoping and make sure there hasn't been something that's changed. If you're going to be modifying your network, you need to so these are all things you have to be thinking about.
When you do those activities, you think how does that affect our security, And and, therefore, how does that affect my PCI compliance potentially or compliance to many other standards, the same kind of a thing.
Yeah. You bring up a good point there. If somebody has experience in the privacy world, you know, you're a DPO, data protection officer. Right?
That's one of the requirements. If you make a change to your processes and things, you're supposed to evaluate what that means to the privacy data. Mhmm. Well, it's a similar thing in PCI.
Right? They're both security standards in that sense. They're trying to protect information from people.
And, like you say, okay. You're gonna make a change. Alright. Let's evaluate what that means to our cardholder data environment and to our PCI compliance.
So yeah. Great point.
So that kind of wraps up that topic.
Don't underestimate how long this takes. Don't think if it's gonna be just a quick thing, get my auditor in here and have them check the boxes and get out.
I would like to really change. I wanna make sure that I'm doing this. First timers really get, you know there's often we see somebody, we go and do the initial gap analysis and then they kinda go quiet because it's kinda like, oh my gosh. I'm curled up in the corner.
I can't figure out all this stuff. You just have to move through it, keep going, and it does take a little longer the first time. But people who have been through this over and over and over, I remember guys saying, hey. You know, it was really hard the first time, but, boy, I feel better after that.
And next year, I feel better. And next year, I feel better. Always be looking for little ways to improve instead of thinking of it as a box that I have to tick. Right?
These standards are here to actually help you enforce security. Right? So that's all this. So, anyway, that's that topic.
So the next topic would be the topic of third party service providers.
Often, merchants or even a service provider will have other things that they farm out. Typically in ecommerce, you know, you're you're you're maybe contracting with a company that's providing you either a hosted payment page or some sort of content for an iframe, or maybe you contract with a company to manage your network or your firewalls, or maybe you contracted with somebody for your data center services, security, all that kind of thing. So whenever you're engaging other third parties, your responsibility as the person who is doing that is to, one, make sure that they are meeting the compliance that is necessary for them at whatever level.
Sometimes that requires them to be actually PCI compliant, which would then you would say, well, show me your attestation of compliance then. And make sure I think one thing that's really funny is a lot of guys will give us or a lot of people will give us, their AOC and, and we read it and we go, it doesn't even cover the service that you're using. Right?
So it becomes a sales kind of problem where sometimes service providers will say, well, no. This is what we're doing. We're doing this for you. Here's our AOC. It covers this. But when you look really carefully, it doesn't cover the thing that they're thinking it covers. So being able to look at the responsibility matrix provided by the service provider, ask for that, demand that, make sure that you know that they have their AOC, that it covers, that it's current.
And if not, you've gotta basically include them somehow in your assessment. And that may be what you don't really wanna do, and they don't want you to do it either. But there have been times when we have had to then go in and say, well Mhmm. If you don't have any proof here, we're gonna have to include them somewhat in the audit.
Right? Yeah. Absolutely. So go ahead.
Well, like I say, service providers, if people want to understand what's required when it comes to service providers, go look at requirement twelve dot eight and its five sub requirements. But you've mentioned in your discussion there, you've mentioned several of the items, having the agreement, the legal agreements in place and doing due diligence before you engage a service provider. Because it's easy for people to think, oh, I need somebody to do x, and so they just go find somebody to do it. But as you said, you know, if they can't demonstrate their own PCI compliance in some way, then they either have to be included in yours or in some way provide evidence that they are compliant.
So, like, it's common more common now for data centers. It used to be, you know, people to have a colo somewhere, a data center, and we'd have to go there and review the security and look at the cameras and look at the badging system and see the security on the cage and do several things like that. Now, a lot of data centers are getting their own PCI assessment of the physical security that they manage on behalf of somebody else.
And then they can produce an AOC that says, yes. Like, as you said, you know, here's the services we provide, and here's what we're doing for this client. So does the AOC cover the service I'm purchasing? Or not me personally. You know, the merchant is purchasing from the service provider.
That's one thing. And then does the responsibility matrix clearly delineate which requirements are the responsibility of which party? And that becomes even more and more important as we get more cloud based stuff, and you're taking more and more advantage of certain services that the cloud providers are adding.
Now the good news is all the big cloud providers are very aware of it, and you can go out and typically download a responsibility matrix from them. It'll say what's their responsibility, what's a shared responsibility, what's your responsibility.
You then have to go through and sometimes kinda look and go, well, why did they call this a shared responsibility? Let's say it's wireless or whatever. You have to scan for rogue wireless devices, right, on a quarterly basis. So some people wonder, well, I'm all hosted in Amazon. Why is that part of my responsibility? Because they call it a shared responsibility.
And, you know, if you step back and kinda go, well, Amazon doesn't know how your environment's architected. Probably know. Yeah. Yeah. You may have a VPN that connects your office to your VPC out in Amazon or GCP or Azure or whatever. You may have a a permanent, site to site VPN.
Well, then while your cloud provider is scanning for rogue wireless in their environment, you have to scan for it in yours. So it becomes a shared responsibility. Or for that might or you might have CDE in both locations. And so, anyway, so sometimes you have to think about why they're calling it a shared responsibility and examine it a little more closely than just go, we're all hosted in Amazon. That's not our problem.
So I think if we were to summarize this topic, it would be, I'm sorry, the person being audited. You are responsible for what your third party providers are doing, and you need to make sure that you understand that and don't just necessarily trust but verify. You have to make sure that you know really what it is that they're providing to you and confirm it and check up on them and make sure that things are going forward. It's not just that you need a little management process on your third party service providers.
You can't just say, no. No. No. They're handling it for me. They told me they're handling it for me.
I'm gonna be okay. And many times that's true, but many times it's not. It's like, oh, wait. No.
You mean you're not doing this?
Yeah.
So and, actually, you kinda reminded me of one thing that I think is important for people to understand.
Like you say, the responsibility matrix and and those things are super important, not minimizing that at all. But sometimes we get clients in here who think, oh, I've outsourced everything to somebody else, and they feel like they don't have any responsibility for PCI compliance.
But, ultimately, it's their name, their merchant ID, their responsibility to be PCI compliant and to manage all those. Yeah. You've given somebody else a a certain portion of the work and responsibility, but you still have to to make sure that they're doing it correctly and everything. And as the assessor, I'm gonna ask you, are they doing those things? You can't just say it's somebody else's problem when you're the actual merchant, and it's your name that's on the line.
If you get compromised, there's a lot of potential reputational damage there. And you can say all you want. It was a third party service provider who screwed up, but everybody sees your name in the headlines, not not the other guy.
That's right.
So the next one, it's really so the next topic kind of relates to scoping as well, and that's making sure that you have good access controls and enforcing proper access controls.
Whether that's, you know, internal access on networks and whether you think this group of people doesn't have access to the CDE, but your access controls don't define that, and they actually do have access to the card folder data environment. So making sure that you understand and enforce those, you know, making sure people are using multifactor authentication in the correct places, for the correct reasons and with the correct strength. All those kinds of things are often difficulties.
Making sure you define who really has the need to know and get access to stuff.
So I don't know if this is a massive problem that we have. Everybody has access controls, typically. It's just making sure that they're set up and enforced the right way. So it has to be something you pay attention to.
You can't just say, yeah. Yeah. Yeah. No. No. We log in.
No. It's okay. We log in. Everybody knows what their login is. Now you have to find out, well, do three, service people on a call center log in with the same ID? You know, there's all those kind of things that we go through as assessors that sometimes catch people that are thinking that they, you know, they got that one handled. Right?
Yeah. It kinda goes back to your previous thing about the spreadsheet where they, you know, the finance department was just saving the spreadsheet out on a share. And it's like, well, everybody had access to it. Well, did everybody really need access? And, you know, PCI does require role based access control, only grant the privileges that are necessary for somebody to do their job. Going back to the comment about providing documentation showing you're doing those things, we expect, you know, if you hire somebody new, show me the roles they've got, show me the permissions in the system that match the role that they're granted as an employee.
And, like I say, it's not you know, many modern operating systems kind of have a role based access control kind of framework idea, but making sure that you've done it and don't just kinda have everyone with access to everything is important.
Right?
So our next topic, you know, I don't think is, again, as big, but it's also something that we find people failing a lot. And that is, oh, no. You know, our people are well trained. I trained them five years ago on this PCI stuff, and they know that they can't take credit card data.
The requirements kinda state that we have to find evidence and procedures of processes that will cover annual training, reminder training. I mean, anybody who's been through any kind of a government security clearance type of thing knows that you don't just get that clearance and then you're done. You have to go through every six months for some kind of training. So in PCI, there's that same concept.
You have to make sure they understand their role in protecting the cardholder data. You have to remind them about things and update them if anything new has happened.
So, you know, there's social engineering, there's handling of data, there's reporting of incidents, all those kinds of things you have to know. And you have to create a culture where it's okay to let them have time to be trained.
Yeah. And for, you know, there's small organizations, training's easier because we can go, let's all get together this Friday and go through the training or whatever.
Mhmm.
And the training, you know, whatever training is required, whether it's a general, security awareness kind of stuff or whether also because there's a requirement for twelve ten about training the people who have incident response processes, who are responsible for incident response.
But you also need to do a policy acknowledgment.
So along with the training, typically, then we have people sign something that they're aware of. This goes back to one of our earlier points, right, about having policies and things in place. People have to acknowledge that they know and understand the security policies, and they have to do that at least annually.
Big companies often have the mechanisms to track everything. That's nice because then they can provide nice reports showing that everybody took the training, and they can, you know, in the training systems, they can have them sign and acknowledge their policy responsibilities and that sort of thing.
Smaller organizations have to kinda do it manually, typically, but not always done.
Right.
So that kinda gives us to get us to number seven.
And we're not saying that there isn't any more either that that may be difficult for somebody. These are kind of some of the most common ones we see. And over the last two years, this last topic really has been probably the hot topic, and that is, are you following what the new PCI requirements added in 4.0 are? They were future-dated for a while. Now they're not. Everything's all in place and must be complied with.
And adequately preparing for those new requirements.
Some of the topics, you know, are in multifactor authentication a little few changes, enhanced ecommerce controls for e skimming prevention.
Password lengths have kind of gone up. All these different things that now have to be in place, you have to be aware of, and, you know, don't get caught by them. You know, sometimes we've seen people say, well, I wanna get this done just before the deadline so I don't have to worry about it. That's really not the get this audit done so that's not so I don't have to do these future data requirements. It's not the right way to think about it because you do have to do them. And, you know, in some cases, you've kinda gotta show you've known how to do them for a while for your next assessment. So it it's a it's a problem that will be going away over the next year or so, but as you start if you're going through the first time audit, this time, some of those requirements, you know, have are new, and maybe you weren't thinking about them before when you were trying to research it or or something.
You know? And speaking of that and these new requirements that are probably, One which is still causing well, two of them. Still causing people a lot of problems. Right? Six four three eleven six one. Mhmm. They're challenging to be able to meet them in the way that PCI requires.
And they may mean that you have to go out and purchase some services from somebody to help you meet them. You know, we have tools to help meet those requirements.
Other people, as a QSA, I have to tell you, other people have them too. Mhmm.
But they're nontrivial when it comes to I have to say, oh, I can handle this on myself.
I'll just write something to do that. Yeah. We know for a fact you know, I've been talking to these guys doing this in this industry for many years now. And, you know, we've been working on this for three or four years researching this because we knew it was coming because we see the forensics happening.
We see these compromises in ecommerce skimming happening more and more frequently. They are almost the prevalent method now. So is it real? Yes.
And do you have to deal with it? Yes. And is it simple to do on your own? No.
So, you know, mentally prepare for figuring out your solution in that area is gonna be helpful. So we're getting kinda close. It's ten forty five now. We wanna leave a few minutes for questions.
We've talked about some of our, you know, the seven common mistakes that are made or seven common hardships.
Like, so there might be more that you experience.
The real kind of root of it is do your homework. Read the standard. Think about it. Get people to talk to.
Don't you know, take this seriously. It really is useful and helpful.
Don't think of it as a checkbox thing that I've gotta get done, but as a process that I can use to make, our company more secure. Focus on the security aspects of it rather than the compliance. That's really what kinda helps you through some of these long and arduous processes.
It's senior management buy off. That's super critical. Exactly.
So, it looks like we've had, a few questions come in. So we'll try to handle some of those. I'll read them.
First one is, how do you know you've reached the level that I how do I know that I've reached the level I need to perform a PCI assessment versus an SAQA?
How do I know if I have to do an assessment? So what are the ways that they're communicated to people, man?
Knowing that you have to have so Yeah.
Another taking credit card data, you have to do something to demonstrate that you're PCI compliant.
But what makes what pushes you over the edge into a report rather than an FAQ?
Right. Typically, two things. One is that you've become a level one merchant or service provider.
Those have vol transaction volumes, associated with them. Six million or more of one card type for merchants.
So if you're getting close to that threshold, typically, your acquirer is going to come to you and well, they may come to you and tell you that you have to do a report on compliance.
Sometimes that actually occurs as a, as a level two merchant. So that's between one and six million transactions.
Sometimes your acquirer will come to you and go, okay. Look. We want you to have what we call an assisted SAQ or self assessment questionnaire. You're still allowed to do a self assessment questionnaire, but we want an assessor, AKA me, Gary, to come and validate as well and then sign that report.
So it's really based on volume.
Now if you're a service provider, the volume is significantly less as a level one service. Right? Is it three hundred fifty k?
I can't remember off the top of my head right now. Think it's around three hundred fifty thousand transactions.
So, you know, that's, that's significantly less, obviously, than a level one merchant.
But they view service providers as having their fingers in more pie than just their one, and therefore, they kinda look at them in a different light.
And you get two options as a service provider. You do the full SAQ D or you do a rock. And so you don't get choices to do anything else. That's those two things.
Yeah. Okay. So we have another question here.
How do you handle sampling for systems and devices? What are the criteria for selecting which ones you will review during the assessment?
Oh, So we have to sample across, systems and system types and facilities.
So I'll kinda give examples to try and illustrate what I'm saying there. If you've got a hundred servers, I don't just look at ten of them, which, you know, maybe a decent sample or whatever. But I have to know, okay. Well, how many web servers do you have? How many databases do you have? How many application servers do you have?
I look at the roles of the servers, and then we sample in those different roles because we're we're PCI tells us we have to. So I look at the roles and then the quantity as well. And like I say, we can also sample facilities.
If you're a merchant with lots of locations all around the country or the world, we'll look at a certain percentage of those. The number will vary based on how consistent your implementation of your PCI solution is across those different locations.
So if you can demonstrate to me that you have the exact same software and operating system and point of sale system and everything across every store, then your sample size doesn't have to be quite as big. But if you have, you know, one point of sale system in this geography over in Europe and another in the US and another in Asia. I'm gonna have to see some of all of them because they're different. And the report is trying to indicate that I've seen the compliance status of all your environment. And so I'll sample across all of those things.
I think kinda what goes along with that is a question on, so why can't you do all my stuff remotely?
Right. Let me take that one. I'm on the global executive system roundtable part of the council. And clearly, we've been, you know, we've been through some stuff over the past few years, COVID, whatever, that did limit travel. And so remote assessments became kind of the norm.
And now kind of the overall rule, kinda quick ruling is if there are actual systems that we can see that are being used, we need to be there in person to see them. If it's all virtual in a cloud, everything in your company is virtual in a cloud, then, yes, there's a case for doing remote assessments.
But if you have an office with computers, if you have a data center with servers, if you have stores with POS systems, if you have a firewall that you manage to protect the network segment, that's actual hardware that we have to see. So there's kind of a quick rule that you can use and help your auditors say, well, look. I can't do everything remotely. I need to be able to meet what's expected of me by the PCI council. So that's just a quick answer on that one. Matt, what would, have the last maybe the last question we're gonna handle, maybe it'll be one more after this.
What's a realistic timeline from start to finish, including an on-site visit and final report delivery?
What should people expect as far as the first time that they've done this if they're an average service provider or maybe a smaller, you know, a merchant that needs to do this situation?
Yeah. I hate to hedge on my answers or whatever.
But to a large extent, it depends on your environment, how many resources you can apply to these things.
If you've just got a super small environment, you know, you got one web server and, you know, some database, and I don't know, you got three, four servers or whatever and, low transaction volumes, whatever.
Six months to a year maybe.
If you're a large merchant and you have to apply changes across your entire environment, maybe you have to update your point of sale system because it's running end of life software and stuff. Sometimes those changes can take much longer even on the order of two or three years because you're trying to roll out to, you know, thousands of systems.
And so, you know, maybe on the low end, I'd say six months ish. We sometimes have people come to us and think, I'm ready. Come tomorrow. And we kinda discourage that process because our experience shows that you aren't really ready.
We get asked all the questions and, like, oh, yeah. We don't have that. Oh, we don't have that. Yeah. The pen test isn't finished either. And then the pen test comes in and shows you have vulnerabilities. And now you have to write some new code.
You're asking all the questions, then come on. Yeah.
So, I mean, I understand it can be overwhelming for people. I really do, even in small environments. But, you know, yeah, that's and this goes to the difference between merchants and service providers. Right?
The Council has tried to take the PCI standard and go, well, how do you do business? And if you meet these requirements, then you're allowed to do this type of SAQ.
You know, a simple example would be, a p SAQ P2PE. If you're taking all your credit cards on and you've been able to or implemented a P2PE solution, then there's things that just you can't even do. You can't electronically store the cardholder data because you never get it. You don't have any key management kind of stuff because you never get it. So it's pointless to ask you questions about those things because you just don't do them.
And and so, you know, they've gone through and tried to go, okay. Well, it's another simple SAQ B-IP. Right? Or B. B is for the old dial out only terminals. If all you've got is a phone line connected to your point of sale terminal, you just don't have much to do.
And so we're not even gonna ask you the questions around it. So that would make the environment simpler. And that's one thing I'd say is, well, look at how you're taking credit cards, and can I simplify my environment to where I really don't store it? I don't process it through my systems? Well, I mean, I may process Take take a look at ways to simplify your life and your environment, and that'll speed up your time to to be compliant.
So this answer is, it depends. And, we're gonna help you do it as quick as possible, but don't assume that it's a two week process.
Yeah. Yeah. Sorry.
Well, the I'm gonna take one last one here, which is a pretty simple one. What's the process for addressing and remediating findings or noncompliant items that are uncovered during the audit?
And that's really you know, hey. We do find things during the assessment. We do our best to prepare people beforehand to cover all the topics so we don't get surprised online on-site. Sometimes during the validation process, we do get surprised and and find something.
But it's not like it's over. Sorry. You failed.
You know?
So we will work with you afterwards during a kind of remediation process. Sixty days, typically, you can have time to fix things. And, then we may think of ways to validate that that's in place, whether that's remotely, whether we need some files, whatever it may be.
Often, it doesn't require a revisit, but if it's really complex, maybe it does. So, you know, yes, we will work with you on figuring out, how to get things that are uncovered in the audit. It's not the end of the world. It's gonna be okay. Just be calm. Right?
So, basically, I think the last question that we have here was, are there any other resources you'd recommend to help us prepare for the assessment? And, you know, there are so much stuff out there, online. We have a learning resource center that you can go to at SecurityMetrics from our website. We have blogs. We have lots of webinars.
Look for ways to educate yourself before you engage potentially an assessor, find an assessor that kinda matches your style, and, you know, interview people, talk to them. And and, take this take this seriously and don't just, you know, try to get through it as quick as possible. There will be some study required. Homework probably will be required, on your part. Think about it.
Try to be as prepared as possible. Again, many sources out there from all kinds of QSAs, all kinds of different companies.
There's our PCI guide that we published that's a pretty well it's basically tips from real live auditors and real life situations covering every single requirement. There's lots of things like that. So go through those. Read the standard.
Amazingly is a good one as well, and know what's in there. So, Matt, thank you very much for your time today. Appreciate it. And thank all of you who have attended and been with us today.
We didn't think we'd have this much to talk about, but you get two of us have been doing it for a long time together. We could talk your ear off over and over and over. So we really appreciate the time you've given to us to educate you a little bit. Good luck if you're first time, assess or first time in an assessment, and it's gonna be okay.
You're gonna make it through, and, let us know if we can help you out. Thank you very much for attending, and, Qapla’.
.svg)
