SPEAKER_00 0:00

Welcome to SenseCat, the podcast where payments meet personality. From tech trends to legal twists. Compliance quirks to marketplace moves. Kitty's here to keep ISVs, PayPal's, and marketplaces ahead of the curve. Get ready for insights, a few laps, and the occasional compliance gear. Let's dive in and make payments make sense.

SPEAKER_03 0:24

Every ISV in payments asserts some version of the sentence. We don't store card data, so we're good. Sometimes they add another sentence for emphasis. Our payment provider is PCI compliant. And everyone nods, closes the compliance spreadsheet, and goes back to building features. There's just one problem. PCI doesn't only apply to companies that store, process, or transmit cardholder data. It can also apply to companies that could impact the security of cardholder data. That last part changes the conversation completely because an ISV might never save a card number, but it may control the checkout experience, configure the payment connection, manage the integration, deploy software into a merchant environment, select downstream vendors, administer user access, or push an update that changes where payment data goes. You might not touch the card data, but you may still have your hands all over the security. Today we're talking about why ISVs need to take PCI seriously as service providers, why a compliant payment vendor doesn't magically make the ISV compliant, and why waiting until a major customer asks for a level one AOC is usually a terrible time to discover how much work you have left. Welcome to SenseChat, the podcast for ISVs, FinTech operators, marketplaces, PayPal's, and everyone else who has discovered that adding payments to software also adds several meetings nobody warned you about. I'm Kitty, and joining me today is Chris. Chris, this is very much your kind of episode because we're talking about cybersecurity, compliance, contracts, financial exposure, and what happens when a company says, oh, our vendor handles that, right before everyone discovers that the vendor did not, in fact, handle all of that.

SPEAKER_01 2:02

Exactly. And this topic connects directly to the article I wrote last week. PCI compliance is your insurance policy, not your checkbox. The argument wasn't that an AOC is literally an insurance policy, is not going to write you a check after a breach. The point is that a real PCI program gives you evidence, creates a record of the system's scope, the controls that were validated, the roles and responsibilities of each party, and whether the company's practices aligned with its policies. Before an incident, speed of and convenience drive decision making. After an incident, accountability and documentation become priority, and everyone wants it immediately.

SPEAKER_03 2:39

Preferably organized somewhere other than a folder called PCI Final Final 2024 Old.

SPEAKER_01 2:44

Right. And the service provider issue is where a lot of ISVs get uncomfortable. PCI DSS applies not only to entities that store, process, or transmit cardholder data, but also to entities that could impact its security. That can include an ISV even when the actual processing is performed by another company. If your platform plays a role in how payment data is processed, transmitted, or secured, or provide services that support a merchant's PCI compliance, you should determine whether you qualify as a service provider.

SPEAKER_03 3:13

Now let's deal with another confusing part early: level one versus level two. Under Visa Service Provider Validation Program, Level One generally includes VisaNet processors and service providers processing more than 300,000 Visa transactions annually. Level one requires an annual on-site assessment and an AOC signed by both the service provider and a quality security assessor. Level two generally covers service providers below the transaction threshold. They may be permitted to complete SACD for service providers, although they can also undergo a QSA-led assessment. But here's the important distinction: your validation level and the rigor of your assessment aren't exactly the same thing.

SPEAKER_01 3:52

Correct. A company doesn't just buy a level one designation because it wants a nicer logo. The validation level is generally determined by the applicable card brand or compliance program criteria. But a level two service provider can still choose to have a QSA assess the environment rather than relying solely on a self-assessment. From a risk, customer diligence, and commercial perspective, independent validation is stronger evidence than saying we reviewed ourselves and found ourselves to be doing a great job.

SPEAKER_03 4:19

Which is a sentence that always inspires confidence. To help us unpack all of this, we're joined by Steve Levinson, co-founder and CEO of LHC Advisors. Steve has spent decades in cybersecurity consulting and has extensive experience performing PCI assessments, risk assessments, and virtual CISO work. He's also a QSA, which means he knows exactly how uncomfortable these conversations can get when someone starts asking where the evidence is. Steve, welcome to Sense Shot.

SPEAKER_02 4:45

I've been in the PCI arena for approximately 150 years, because as you guys know, IT years and security year years are like dog years. So I've been here long enough to have permanent brain damage and have seen all sorts of things. A trend that I have seen over the past many years is more and more merchants have been successfully de-scoping their environments through tokenization, through iframes, through various service providers involved in the payment stream, such that the merchants no longer really have to worry about it as much, or sometimes not at all. But therefore, the onus of protecting cardholder data falls to those service providers. Okay, that makes sense. Makes the world a little easier, you know, find companies that specialize in this, right? However, there's a lot of service providers, and again, I've had this conversation dozens and dozens of times as we're getting ready to either help them with uh figuring out their security posture or performing their PCI assessment, where they'll say, Well, we don't store, transmit, or or or process cardholder data. There's nothing to see here. Then we get to that part or impact the security of. And a lot of times, at least on the surface, they'll say, Oh, look, we can't impact the security of it. We can't even access cardholder data. And that's when we start kind of turning the screws a little and say, well, let's let's talk through some worst case scenarios. For example, if an attacker was successful in obtaining credentials, could they redirect payments, for example? Could they, you know, can they change an API? Could they, can they change the pricing perhaps of a merchant's product? So once you start kind of talking through those worst case scenarios, that's what really kind of opens the eyes to a lot of these service providers who thought, oh, wait, there's nothing to say here, move along, move along. Uh then you know it gets a little easier to at least start talking about, you know, what in their world could impact the security of cardholder data.

SPEAKER_03 6:37

And I think that redirect example is especially important because a lot of software companies think a redirect automatically means they're completely outside the conversation. But the cardholder leaves the ISV's page, the payment happens somewhere else, the ISV never sees the card number. Why might the ISV still matter here, Steve?

SPEAKER_02 6:55

So it still matter for a number of reasons, right? Uh again, if uh yes, once it makes it to the ISV, that's fine. But if an attacker gets in the middle and is able to redirect that payment to somewhere else, or sometimes not even redirect it. We've also seen where they they also just kind of mirror it. So it might, you know, it may still go to where it's supposed to go, but at the same point in time they're getting a mirror of that transaction where it's able to potentially capture cardholder data. Um all these things are are fairly important to it even if there's no actual processing of cardholder data itself. You know, the merchant's not gonna care that the ISB never stores or access cardholder data. It that to them is not so important as to the merchant. The merchant does care though that the you know if the if the customer sent in the wrong direction, uh, or it's a fraudulent transaction or a transaction never takes place, that's gonna impact the merchant.

SPEAKER_01 7:48

And contractually, the merchant isn't going to care very much that the ISV never stored the card number, or if the ISV's compromised software sent the customer to the wrong place, as you said. The first question will be who controlled the experience? The next question ends up becoming who was supposed to keep that control secure? And that's where we don't touch the data starts sounding like an incomplete answer.

SPEAKER_03 8:10

Because the customer clicked the payment button inside your software, they didn't conduct an architecture review before doing it. Now, Steve, let's go deeper on level one and level two, because these terms get thrown around in sales conversations without any explanation. What should an ISV understand about the difference?

SPEAKER_02 8:26

First thing. So usually the card brands are going to say the number of transactions are what dictates an entity's uh you know level in PCI. In the world of service providers, um, where it gets a little bit convoluted though, is there are some service providers where they're not actually in the transactional process, right? They might be involved on the peripheral where they can potentially access lots of cardholder transactions. So sometimes it becomes a gray area and it's not quite as easy to measure. Oftentimes as well, and again, we work with service providers in this space, um, there will be a financial institution, maybe it's the card brand, but it could be an acquiring bank that says, you know what, based on what you are doing, we want you to be a level one service provider. And that usually kind of draws the line right there. Once it's a business enabler or you're forced to do it, you have to do it anyway.

SPEAKER_03 9:15

So, Steve, when a vendor sends you a one-page document and says, here's our PCI certification, what should you actually look for?

SPEAKER_02 9:22

So, usually what I look for first, well, let's see what that one-page document is. If it's a self-assessment questionnaire, then it's the it's akin to that entity patting themselves on the back saying, Yeah, we're PCI compliant. But even if a QSA is actually performed the assessment, you want to make sure that whatever it was that was assessed are the services that you are purchasing. Another thing that often goes along pretty well with that, um, and we make this recommendation all the time, is to make sure that there's some sort of responsibility matrix. And usually that'll have it'll have here, here's the control item, here's what the here's what the customer is responsible for, here's what the service provider is responsible for. Sometimes it's a shared responsibility, and then oftentimes there might be some notes that further delineate what that means. So again, you know, the the AOC itself, it's a great starting point. It gives you, it gives you at least some degree of confidence that that service provider is PCI compliant, but it's never going to get granular enough to cover the responsibility matrix.

SPEAKER_01 10:22

That's kind of why some of the major customers you're seeing they're getting a little more skeptical of those self-assessments. They want a little bit more detail on that. Uh, you'll see a sophisticated customer isn't just checking whether the AOC box is filled in. They're asking who performed the assessment, what was tested, what was excluded, whether the service they're buying was actually covered, and whether the company's contracts match the responsibility model. A QSA-led assessment creates independent evidence. It doesn't guarantee that a breach will never happen, but it makes the compliance statement much more defensible.

SPEAKER_03 10:55

And commercially, that's becoming a bigger problem. ISVs are increasingly finding out that a large enterprise customer, bank partner, processor, or payments vendor isn't satisfied with we're under the transaction threshold. So we filled out the questionnaire ourselves. They want the QSA signed AOC. Sometimes they want the responsibility matrix, sometimes they want penetration testing results, policies, vendor lists, and evidence that the product named in the sales deck is actually the product included in the assessment.

SPEAKER_02 11:26

And I'd say that, you know, over time, procurement teams are they're ramping up their knowledge base, right? Across the board, not just in the PCI space, where they're really looking for the right artifacts to give them a warm fuzzy that their partners are doing the things they need to do to protect what's important. In this case, we're talking about cardholder data. Sometimes it's going to be glaringly obvious if there's the over 300,000 transactions. Sometimes, from a business perspective, it'll be glaringly obvious because that's what the customer is forcing you to have to do. It's important to know too that we don't a lot of times you'll say, well, PCI compliance is the happy byproduct of a robust security program. Oftentimes, if it's an entity that's going through PCI for the first time, it's it's not going to happen overnight. So a lot of times there's a runway into it. Do you have all the right policies? Do you have the procedures? Are you following them? Now let's take a look at you what you've built out and make sure it's actually secure and doing all the things it needs to do. And so oftentimes, especially if it's a first go-around with a PCI assessment, it can take weeks, if not even a few months, to cross that goal line for the first go-around.

SPEAKER_03 12:30

Let's talk about the service provider only requirements because this is another area where companies assume PCI is basically the same checklist for everybody. And it isn't. There are requirements specifically identified for service providers because one provider can create exposure across hundreds or thousands of customers. Steve, which of those controls matters most for an ISV?

SPEAKER_02 12:50

Well, there's several of them, and you'll see within the PCI DSS, it actually calls out some of those controls for the ISVs. And you said, right? With great power comes great responsibility. So it's anything from making sure you're able to, you know, you perform an additional network segmentation pen test. You're having to do it twice a year rather than once a year, as an example. So there'll be a few things where it says for service providers. Um I think there's about a dozen controls or so that uh that talk to that. So, you know, while nobody has the authority or budget or accountability, PCI becomes that both a paperwork exercise, but more importantly, it becomes a way of being, right? And so trying to avoid any sorts of incidents, because obviously if there's some sort of incident, that that becomes kind of evident as far as how a company handles risk or how they handle their security, you know, security posture.

SPEAKER_01 13:39

That executive ownership is legally important too. After an incident, it becomes obvious very quickly whether PCI was treated as a company program or as an annual document request someone kept porting over to IT. If nobody had authority, budget, or accountability, that isn't just an operational weakness. It becomes evidence about how seriously the company took the risk.

SPEAKER_02 14:02

I think you know this applies to all entities, and you know, including service providers, is you really want to kind of bake it into your culture and into your security, it should be important. It shouldn't stop the business from doing what it should do, but there should be we always say it should be right-sized, right? So key activities should be reviewed as periodically as they need to. And there's a lot of the everyday controls that need to be reviewed, right? It could be log review, it could be just looking at your at your SIM, or maybe you have a third party that's you know doing your uh security event monitoring on your behalf, is making sure that they're actually doing their job. So a lot of this is just to make sure that everything is being kept current because it's easy for things to slip through the crack. And along with those two, you know, you want to create your your audit trail demonstrating that you're doing this. It's one thing to say you're doing it, but it's another to create that audit log.

SPEAKER_03 14:53

So our policy says we review logs, and here are the actual records showing the logs that have been reviewed are two very different sentences.

SPEAKER_02 15:03

You want to create that audit trail showing that you're doing it. And and you know, and yes, having the records that show the logs are reviewed. It may not mean you actually did it, but at least improve the likelihood that you did. And obviously, you know, part of this when we're performing PCI assessments, we're doing more than just asking, hey, did you review the logs? We'll talk to those who are responsible for and ask them, well, tell me, show me how you do it. So we'll dig in a bit deeper. And again, this kind of ties into the difference between a self-assessment questionnaire and a full-blown report on compliance that we as the QSA are gonna say, Yeah, show us this, you know, show us how you do it. And let's face it, you know, in the world of change management where things are changing all the time now, I find as well, a lot of things maybe slip through cracks through change management, right? A change gets made. And back to the thing that I said, people don't document it, they may not test all the changes that need to take place. So all of a sudden there's a whole new part of the environment that wasn't vetted that may not even be PCI compliant. And so it's important again to build that into your everyday because we're trying to make sure as we perform, I don't care if it's an SAQ or a report on compliance, but when we cross the fence, it's fine, right? Everybody's PCI compliant. That's great. That's only a snapshot in time.

SPEAKER_03 16:12

And that feels especially relevant for software companies because the product probably changes more than once a year.

SPEAKER_02 16:18

Absolutely. And the beauty of it is you only have to do a PCI assessment once a year. You know, we have a lot of clients come to us and say, Well, you know, in three months we're gonna be making these big changes. And we'll tell them, look, you don't have to do another assessment. You just want to make sure as the world is changing. And let's face it, the the way technology is now, it changes quite rapidly. You know, thank you to our friends like Claude. That what was here yesterday is something totally else tomorrow.

SPEAKER_03 16:41

Now, boys, let's bring this back to the practical reason a lot of ISVs suddenly care about PCI. A prospect asks for the AOC, then the ISV discovers that the prospect doesn't want a SAC, doesn't want an old attestation from a different product, and doesn't want a paragraph explaining what the processor is compliant. They want a current service provider AOC signed by a QSA. Steve, what are you seeing in the market?

SPEAKER_02 17:05

One of the funniest things I see in the world is service providers. So a service writer can only, there's only two artifacts that they can fill out as a service writer, as we mentioned before, the SAC B for service providers, and then of course the report on compliance. However, we'll see a lot of service providers that just because of the fact that not all 830 some odd controls apply to them, they'll just pick a sack that seems more their flavor, like a SAC A. Well, all the other SACs are for merchants. So we see this time and time again. In fact, the PCI council has some uh some FAQ for frequently asked questions, reports that kind of talk to the fact that because they've seen this error so many times. So, first and foremost, is to make sure service providers are using the right reporting templates. Now, again, it's not to say that all the controls are going to apply to a service provider. Oftentimes the only a handful of controls will apply to them, especially if they're just they could just impact security of cardholder data and not storing or processing or transmitting it. But that's the first thing is that they just you know they need to at least be filling out the right paperwork, right?

SPEAKER_01 18:06

It's probably easier to do it earlier than later, too. It takes the uh instead of being under pressure. And when the deal is already negotiated, the customer says, send us the level one AOC, the sales team wants the answer by Friday. Uh, then PCI readiness extends well beyond a technical assessment. It often requires meaningful operational changes, document controls, and continuous compliance efforts. And if you get on that early, it's probably way easier to get ahead of the curve on that.

SPEAKER_03 18:34

You can create a document saying it was supposed to happen, and that isn't the same thing. Now let's close this with something practical. And ISV is listening to this and thinking we use a third-party payment provider. We don't intentionally store card numbers, but we control the integration, and we've never been assessed as a service provider. What should they do next?

SPEAKER_02 18:53

So this is where we again important to define the service and map, you know, not just the data flow if there's no cardinal or data, but the data flow as it pertains to how it might impact any sort of security posture. So that might be redirect, it might be tokens or refunds or support access configurations. So anything that could potentially, and that becomes for us, when we're doing any sort of uh you know, PCI, I don't care if it's a front-end sales call or when we're working with our clients to kick off PCI assessment, we call it the scoping dance, right? Let's figure out what's important to you and to your clients and what needs to be protected, right? Because you can't really start looking at various controls and tech stack until you know what it is you're trying to protect from a business perspective, right? So the scoping exercise is extremely important. From that, then we can kind of you know determine hey, here's the requirements that may apply. Because it's not necessarily going to be all those requirements, but it'll be a subset of them. To the extent it applies, you might also deal with segmentation or systems and evidence needs, right? Um, as we further define things, this is where the responsibility matrix is helpful. Again, part of this is reviewing the vendors, you know, third start third-party service providers, sometimes for the fifth party service providers, to understand their roles into the ecosystem. Those all be important things. Sometimes as well, it's important to understand what are your customers looking for.

SPEAKER_03 20:21

The big takeaway is that PCI scope doesn't stop at the place where the card number is stored. If your software can alter the payment flow, control an integration, administer access, deploy code, manage vendors, or otherwise affect the security of the environment, you may have service provider responsibilities. And using a PCI compliant payment provider doesn't erase those responsibilities. It just helps define which parts belong to them and which still belongs to you.

SPEAKER_01 20:47

Trick, kid, a PCI isn't a magic shield, but a QSA-led assessment supported by a well-defined scope and documented compliance program provides something incredibly valuable when customers, banks, and card brands, or even lawyers begin asking questions after an incident. Evidence. That was the point of the article, and it's the point of this conversation. Treat PCI as an ongoing operational discipline, not something you build after the fact.

SPEAKER_03 21:14

Steve, before we let you go, where can people learn more about you and LHC Advisors?

SPEAKER_02 21:19

One thing you can do is go to our website, which is lhc-advisors.com. We really collect brain damage from having done PCI for so many years. And you know, I and my team have literally performed hundreds of PCI assessments and not just assessments. You know, we take that advisory approach with our clients and with our clients. So it could be PCI readiness, it could be, hey, just bounce something off of me. I'm always happy to talk to them at a time. You can play the game, you may be a service provider if dot dot dot if you're not sure, right? Yeah, we do other things too. We work with other frameworks as well. We perform pen testing, we perform virtual CISO and/or security program management or even PCI program management. So we can help with any of those things if if ever there's that need. So just know there's a friendly voice out there to help with any of those questions.

SPEAKER_03 22:10

Well, Steve, thank you so much for joining us. It's been a pleasure. Chris, thank you for making sure everyone leaves today's episode slightly more concerned about their contracts.

SPEAKER_01 22:19

That's what I'm here for.

SPEAKER_03 22:20

And if you haven't read Chris's article, PCI compliance is your insurance policy, not your checkbox. You can find it on SenseChat.com. It gets into the legal, financial, contractual, and reputational side of PCI for service providers, including why an AOC is valuable but isn't the whole story. Thank you for listening to SenseChat. We'll see you next time.

SPEAKER_00 22:40

Thanks for tuning in to SenseChat. Got questions? Got ideas? Got payment problems keeping you up at night? We've got you covered. Head over to our website to take our quick survey. You might just land a guest spot on the pod. Don't forget to subscribe, share this episode with your favorite ISP, and follow us on all social for the latest trends, tips, and debates. We promise no boring slideshows. At FenceChat, we're here to make payments make sense and make it fun while we're at it. See you next time.