Your PCI Scope Is Too Big. Here's How To Fix That
Struggling with PCI scope creep? Learn how segmentation, P2PE, and tokenization can shrink your cardholder data environment.
Updated:
August 7, 2026
Struggling with PCI scope creep? Learn how segmentation, P2PE, and tokenization can shrink your cardholder data environment.
How much of your business actually needs to be PCI compliant? Almost always less than you think. Every system inside your PCI scope is something you have to secure, document, and prove — year after year.
So the fastest way to cut the cost and effort of compliance isn't working harder on controls. It's making your scope smaller. Principal Security Analysts Jen Stone and Michael Simpson break down how PCI scope actually works: the three buckets every system falls into, the connected systems most people forget, and four practical ways to shrink your Cardholder Data Environment (and the bill that comes with proving it).
WHAT YOU'LL LEARN
CHAPTERS
Free PCI Resources
2017 Guide: scoping resources: https://listings.pcisecuritystandards...
2025 Guide: https://blog.pcisecuritystandards.org...
Jen Stone: Hello and welcome back to the Practical Cybersecurity Podcast. I'm Jen Stone. I'm one of the principal security analysts here at SecurityMetrics. With me today is another one of the principal security analysts, Michael Simpson. Michael, thank you for joining me.
Michael Simpson: Good to be back.
Jen Stone: We just did a how to scope for an SAQ podcast, which is great, but it doesn't cover all of the questions about scoping, because if you don't get scoping right, you're not going to be looking at the right security controls.You're not going to be filling out the right SAQs. So this is, I think, critical.
Michael Simpson: So the PCI standard, the data security standard — set of security controls designed to protect credit card data — scoping helps us define what systems, networks, people, and processes those controls apply to, because it can be expensive to apply these security controls.
So defining where we apply these controls, that's really what scoping is. A scoping exercise is just an exercise to determine what systems do I have that are either storing, processing, or transmitting cardholder data — or systems that can affect systems that store, process, or transmit cardholder data.
Jen Stone: And it's not just expensive to apply the controls — there's a lot of organizations I work with that have the controls in place everywhere, but then it's expensive to demonstrate that the controls are because it takes more time. And time, of course, translates into money.
So when you meet with a small business for the very first time and they're struggling with scoping, what is your first step?
Michael Simpson: It's just to have a discussion to understand what they do — how are they making money and what are the ways that they're taking payments. And sometimes, when I first start working with someone at an organization, they put me in charge, or they put me in contact with either someone from maybe their IT team or a security team, or it might even be someone from their business office or treasury office that I'm working with. Sometimes they don't even know all the different ways that credit card data is taken.
Jen Stone: Don't just tell me what you believe your scope is — if you tell me all of the things, I can help you maybe identify things that should be on the list that aren't, or that are on the list that we actually don't need to worry about, because it happens in both directions.
Micheal Simpson: So it might take multiple conversations with multiple people to find out what are all the different ways that credit card data is coming into this business. Maybe you have a restaurant that a couple of times a year sends a food truck out to an event, and maybe the way that they process there is different than the way they're processing in the store.
This barbecue restaurant sells their spices online, and people can send in order forms, and maybe they're mailing these forms and it has credit card data coming in on paper. So you just have to see what are all of the different ways credit card data comes in. How are you processing it once you have it?
And what happens once you've taken the payment? Is there any credit card data you're still hanging on to? If so, how is that destroyed once it's no longer needed? And it's not just looking at what systems are involved. We also need to understand the processes and the people that support those payment flows, because some of these security controls in the PCI standard are staff training.
So we need to know what staff that applies to and what type of training. If you have point of sale devices where you're taking in-person payments, then there's different training requirements as opposed to a fully e-commerce environment where you just have staff that are supporting these web servers that are taking payments.
Jen Stone: It seems like if the training isn't focused on what the person's job is — in what way it could be relevant to them — the training doesn't take.
Michael Simpson: And then on the system side, when I'm working with them to help define scope, the way that I try to help visualize that is I'm looking at three different distinct buckets. My first — I call it primary scope — my first bucket that I'm looking at is any system that touches credit card data. So anything that's storing, processing, transmitting credit card data — that's primary scope. All PCI DSS controls apply or need to be applied to it. Some may not apply, but you need to at least look at all PCI DSS controls.
Jen Stone: Right. And that's the easy scope, right? You have a network diagram, you can circle it, you can point to the systems — these have credit card data.
Michael Simpson: Any system that's in that first bucket, the network segment it sits on is also in scope, as is any other device on that same network segment.
Jen Stone: Right. Exactly.
Michael Simpson And this is where some companies have flat networks. Segmentation is not a PCI requirement, but it definitely helps, because if you have a flat network — which means everything is basically plugged into the same network segment, we're all talking on the same line —if one device is storing, processing, transmitting cardholder data, all of those devices are now in your primary scope and all PCI DSS controls need to be applied on all of those devices.
Jen Stone: My favorite analogy — probably because I've lost close to this — is if you put a Sharpie in the dryer, it's not going to stay in that one pair of pants it was in. Right? You're going to have Sharpie all over everything. And that's what happens when you have something happen in a subnet. One system gets compromised, and it's very easy for all of the systems to get compromised just because of the way they communicate with each other.
What's your second bucket?
Michael Simpson: So the second bucket, which I would call my secondary scope — these are systems that don't store, process, or transmit data themselves, but they're connected to and affect that primary scope bucket. Even though they don't store, process, or transmit data, they either have elevated access to communicate with our primary scope, or they're controlling our access into those. So if we have, like, Active Directory that's used to authenticate someone to gain access to the system — if someone can gain control of your Active Directory instance, it's easier for them to then gain unauthorized access into that primary scope.
And if we go back to your laundry scenario, the secondary scope bucket — this is like, okay, I might have a Sharpie in my pocket, but now it's in a Ziploc bag, so it's not going to affect everything else.
So if our Active Directory server is in secondary scope, all the devices connected to that same network segment don't necessarily become part of scope themselves.
Jen Stone: Not necessarily.
Michael Simpson: It's an individual look at each of these systems to see what type of access or effect they can have on our primary scope.
Jen Stone: So what's your third bucket?
Michael Simpson: The third bucket is the out-of-scope bucket. So these are systems that don't store, process, or transmit credit card data, and they don't connect to the card data environment or to that primary scope, and they can't affect the security of that primary scope area.
Jen Stone: We would also like to have as much of an organization's network in that bucket as possible. Favorite bucket. Don't have to look at it. But how do they know that they don't have to look at it?
Michael Simpson: So if we have devices connected to segments of our network where there's a firewall in place, there's something in place to prevent any type of communication between that primary scope and these other systems, then it's easier to say, hey, yep, these systems are completely out of scope.
They're not at all affecting our primary scope environment. Segmentation, I think, is one of the best ways that organizations can limit the scope that has to be part of a PCI engagement. And there's different ways to do segmentation. I mentioned firewall, which is probably the one we see most often. Or the other type of network segmentation, where it just prevents communication over the network between two different ones.
The other way that we see scope reduction based on a different type of isolation is end-to-end encryption or point-to-point encryption. And this is where — like the SAQ P2PE — it's one of the simplest card-present type solutions to assess. It's because that encryption provides that encapsulation to protect cardholder data and the systems that are processing cardholder data.
Jen Stone Exactly. Then we see some interesting new ones. We don't see them a lot in small medium businesses, but we do occasionally see a zero trust environment, and that's basically nothing can talk to anything else unless it's told that it can talk to it. But then another one that we didn't used to see a lot in SMEs, but we're starting to more, is cloud environment, because they'll often have a web server in the cloud that is separate from their corporate environment.
One of the challenges there that I see is they'll say, yes, we have our web server in the cloud, but we don't have segmentation, so your corporate environment is in scope, and they're like, no — okay, well, that's not true. And it seems like a no-brainer that of course a cloud environment that has your web server in it would be automatically segmented, because it's in a completely different environment.
But sometimes your IT folks can put something in place, like a site-to-site VPN — something that then permanently connects them. So again, I think it's really important when we talk to organizations that we get the full picture, so that we can know exactly what's going on and help with that scope.
But I've actually helped people get their segmentation in, and I don't think a lot of organizations realize this — as assessors, we would love to see you less. I mean, I love you, but we want to see less of your environment. We want it to be controlled.
We want to have that security around the cardholder data, and segmentation is a fantastic way to do it.
So I think this would be a great time to talk about a few ways that we know how to reduce scope. We've already talked about segmentation — get as many of your systems out of the PCI scope as possible.
Jen Stone What are some other ways – I think you mentioned P2PE?
Michael Simpson P2PE is the one that we see the most often right now for scope reduction, especially for point-of-sale environments. P2PE is the best way to minimize or reduce your scope. One little thing I wanted to mention, though: just because something is out of scope doesn't mean that you don't want to protect it as an organization.
Jen Stone That is a great point.
Michael Simpson: If they get compromised there, it could still cost them a lot of money, even if they don't lose credit card data. The PCI standard is designed to protect credit card data, but that's not the only important thing for a business. Besides encryption and segmentation, I think the next thing that's just as important to scope minimization would be to determine if there's any storage of credit card data that is unnecessary.If you don't need to store it, get rid of it.
Jen Stone: Even if you have recurring payments, you don't have to use the full card data — you can do a tokenized approach. I think it's a great way to reduce scope. What about organizations that are taking payments over the phone? Because that can really blow up your scope, right?
Michael Simpson: Whenever you have credit card data being transmitted over an IP network, that transmission is in scope — whether that's a phone call or whether that's sending it from your computer out to a processor, that's going to be in scope. So understanding your phone system is really important. If you have a voice over IP system, find out if you're doing call recordings, because that's going to increase your scope — now we have electronic storage of credit card data.
So all PCI DSS controls come into play to try to protect that data. So minimize any kind of electronic storage if you can. There are a lot of companies out there that will use DTMF tone masking, which basically — the call center agents on the phone, when they get to the point where they need to take credit card data, the system will take the credit card data, so they'll have the customer type it in instead of speak it in. And then it tone-masks it. So it takes your call center people and their computers out of scope, if you can .Do you know one of these third-party solutions that will do that DTMF tone masking and take the payment for you? Or I've seen ones where they get to the point where they're ready to take a payment and it transfers into an IVR system, right? Where basically they’re working with a computer to take the payment. And then once they’re done making the payment, they get transferred back to the call center agent. So there’s ways to remove those agents from your scope.
Jen Stone: Another one I’ve seen – I had a customer that did this – they're working with a computer to take the payment, and then once they're done making the payment, they get transferred back to the call center agent. So there's ways to remove those agents. I had a customer that did this — they stay on the phone with the customer the entire time, so they never dropped that customer, but they send them a pay-by-link either to their phone or to their computer, so the person can pay by link while they're on the phone with them and help them through it.
And this company was worried about a sales drop-off, which, of course, is something we have to be concerned about — if you interrupt the payment flow, somebody might go, I really don't need this. But if you stay on the phone with them and then send them that pay-by-link — they did the testing, and they did an A/B test to see how it affects that sales rate, and it didn't for them. I was really happy, because then they were able to get that out of scope by using a pay-by-link.
So we can use DTMF masking. We can use handoff to an IVR. We can use pay-by-link. There's a lot of options to get that call center, or your accounting department, or whoever is doing that, out of scope.
Michael Simpson: One thing to keep in mind, though: you are, as the merchant, still ultimately responsible. So you need to make sure if you're using a third party to help you reduce that, they are PCI compliant.
And I've seen too many instances where we have a third party that they themselves don't understand how to scope — this whole discussion, they should be watching this. But sometimes, I see this a lot with e-commerce, where a company focuses on helping small merchants do e-commerce, but they don't want to touch credit card data, which is great.
Michael Simpson: So they then use another third party to capture the data on their behalf. They're hosting what I would call a shopping cart server, where people can go online, pick what they want to buy, and get to the checkout page. But then, when customers are actually making a payment, the customer is interacting with their third party to make the payment.
Michael Simpson: So sometimes it's the middleman third party — they'll tell the merchant, oh yeah, I'm out of scope, I don't need to be PCI compliant, it's really this company over here that needs to be PCI compliant, and trust me, I'm making sure that they are.
Jen Stone: This is absolutely untrue.
Michael Simpson: Yes, because their system is in what I would call that secondary scope. They don't store, process, or transmit credit card data, but they sure as heck affect the security of that data.
Jen Stone: As long as everybody in the chain can supply you with a valid attestation of compliance, because that's the best way for you to actually stay out of the mix. If they can't provide the attestation of compliance, then the assessor says, well, I have to assess them under you for you to be compliant. And wow does that ever get messy and possibly expensive.
Michael Simpson: Yes. And I can't tell you how many calls I've been on where customers bring in that middleman third party to the call so I can explain to them, yes, you are in scope, and this is why. And one thing it could be too — PCI evolves as the threat landscape evolves. If we were having the same discussion back in the PCI 2.0 days, I would agree that middleman is out of scope — they don't store, process, or transmit data. But that's changed.
Jen Stone: What are some other myths — we just talked about the myth of the middleman, right, that it is not in scope, but absolutely is. Are there some other myths or gotchas that you run into a lot?
Michael Simpson: Yeah, I was just out a couple of months ago with a university, and they're like, oh yeah, all of these systems are point-to-point encrypted.
And then I start asking them, what point-to-point solution are you using? And as they dig into it, they find out, oh, it's not point-to-point — it's a non-listed end-to-end encryption solution. As an assessor, we can say, oh yes, this is validated, I know it's using a good encryption algorithm.
I know the keys are managed appropriately, so I know that this data is secure enough that I can ignore the network. But end-to-end encryption hasn't gone through that level of scrutiny. So either I need to go through that scrutiny for the company, which can be costly, or we need to reach out to their merchant bank and say, hey, we've got this non-listed solution.
Are you guys okay trusting that this is providing enough security that we don't need to bring the network into scope?
Jen Stone: That's something that takes months to validate. For going down the right paths — trying to get an assessor to do it, and it's a heavy, heavy lift.
Michael Simpson: But P2PE is very different than E2EE. P2PE is a trademark, the council kind of owns that. You know what P2PE means, and it has to be a validated solution for it to be a true P2PE solution.
Jen Stone: So let's say somebody right now is in the middle of choosing what kind of payment solution to get, and they want to see if it's a P2PE solution. What's the best way for them to know whether it really is P2PE or not?
Michael Simpson: The best way is to ask for a copy of the PIM, the P2PE Implementation Manual, because if it's not P2PE, they won't have a PIM to give you. So if you don't get a PIM, it's probably not P2PE.
One thing to know, especially when we're thinking about modern architecture —some people, when they move to the cloud, they host a solution in AWS or Microsoft Azure, and they think, well, because they're PCI compliant, I automatically am PCI compliant if I'm in their environment. But that's not the case. You need to understand what you're responsible for. If part of your solution — as you go through your scoping, if you say, oh yeah, I've got some scope in the cloud — you need to determine what my cloud provider has acknowledged responsibility for, and what they say I'm still responsible for.
Jen Stone: Whoever's doing this project needs to actually read those responsibility matrices first, and determine what is the biggest bang for my buck to reduce scope.
Michael Simpson: And it can be a great asset. It can really help minimize scope and help you become compliant — you just have to be sure you're understanding it.
Jen Stone I think if people want more on that, they can go back to our most recent conversation, where we talked about the SAQ, because choosing an SAQ is just a scoping exercise — you figure out what your scope is, and you figure out what your data flows are, and it'll tell you which SAQ.
Michael Simpson So there's more information there that people can use. And there's also, on the council's website, two different scoping guides. One came out in 2017, one came out just last year. The one from last year is Understanding Scoping and Segmentation Practices for Modern Network Architecture. Both of them are good reads, and the new one doesn't replace the old one. It just adds more information.
Jen Stone: Exactly. Well, thank you for coming on and talking to me. I sure appreciate it.
Michael Simpson: Always a pleasure.
.svg)