Announcer: Welcome to Cents Chat, the podcast where payments meet personality. From tech trends to legal twists, compliance quirks to marketplace moves, Kitty is here to keep ISVs, PayFacs, and marketplaces ahead of the curve. Get ready for insights, a few laughs, and the occasional compliance scare. Let's dive in and make payments make sense.

Kitty: Every ISV in payments asserts some version of the sentence: “We do not store card data, so we are 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 is just one problem. PCI does not 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 are talking about why ISVs need to take PCI seriously as service providers, why a compliant payment vendor does not magically make the ISV compliant, and why waiting until a major customer asks for a Level 1 AOC is usually a terrible time to discover how much work you have left.

Welcome to Cents Chat, the podcast for ISVs, fintech operators, marketplaces, PayFacs, and everyone else who has discovered that adding payments to software also adds several meetings nobody warned you about.

I am Kitty, and joining me today is Chris.

Chris, this is very much your kind of episode because we are 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.

Chris: Exactly. And this topic connects directly to the article I wrote last week, “PCI Compliance Is Your Insurance Policy, Not Your Checkbox.”

The argument was not that an AOC is literally an insurance policy. It is not going to write you a check after a breach. The point is that a real PCI program gives you evidence. It 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 and convenience drive decision-making. After an incident, accountability and documentation become the priority, and everyone wants it immediately.

Kitty: Preferably organized somewhere other than a folder called PCI_Final_Final_2024_Old.

Chris: 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 provides services that support a merchant’s PCI compliance, you should determine whether you qualify as a service provider.

Kitty: Now let’s deal with another confusing part early: Level 1 versus Level 2.

Under Visa’s Service Provider Validation Program, Level 1 generally includes VisaNet processors and service providers processing more than 300,000 Visa transactions annually. Level 1 requires an annual on-site assessment and an AOC signed by both the service provider and a Qualified Security Assessor.

Level 2 generally covers service providers below the transaction threshold. They may be permitted to complete SAQ D for service providers, although they can also undergo a QSA-led assessment.

But here is the important distinction: your validation level and the rigor of your assessment are not exactly the same thing.

Chris: Correct. A company does not just buy a Level 1 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 2 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.”

Kitty: Which is a sentence that always inspires confidence.

To help us unpack all of this, we are 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 is 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 Cents Chat.

Steve Levinson: Thank you very much. Happy to be here.

I have been in the PCI arena for approximately 150 years, because as you know, IT years and security years are like dog years. I have 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, iFrames, and 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. Therefore, the onus of protecting cardholder data falls to those service providers.

That makes sense. It makes the world a little easier, finding companies that specialize in this. However, there are a lot of service providers, and I have had this conversation dozens and dozens of times as we are getting ready to help them figure out their security posture or perform their PCI assessment, where they will say, “Well, we do not store, transmit, or process cardholder data. There is nothing to see here.”

Then we get to that part: “or impact the security of.”

A lot of times, at least on the surface, they will say, “Oh look, we cannot impact the security of it. We cannot even access cardholder data.” That is when we start turning the screws a little and say, “Well, let’s talk through some worst-case scenarios.”

For example, if an attacker were successful in obtaining credentials, could they redirect payments? Could they change an API? Could they change the pricing perhaps of a merchant’s product? Once you start talking through those worst-case scenarios, that really opens the eyes of service providers who thought, “There is nothing to see here, move along.”

Then it gets a little easier to start talking about what in their world could impact the security of cardholder data.

Kitty: I think that redirect example is especially important because a lot of software companies think a redirect automatically means they are completely outside the conversation. The cardholder leaves the ISV’s page, the payment happens somewhere else, and the ISV never sees the card number.

Why might the ISV still matter here, Steve?

Steve Levinson: It still matters for a number of reasons. Once it makes it to the payment provider, that is fine. But if an attacker gets in the middle and is able to redirect that payment somewhere else, or sometimes not even redirect it, but mirror it, it may still go where it is supposed to go while the attacker gets a mirror of that transaction and may be able to capture cardholder data.

All these things are fairly important even if there is no actual processing of cardholder data by the ISV itself. The merchant is not going to care that the ISV never stored or accessed cardholder data. That is not so important to the merchant. The merchant does care that if the customer is sent in the wrong direction, or there is a fraudulent transaction, or a transaction never takes place, that impacts the merchant.

Chris: Contractually, the merchant is not going to care very much that the ISV never stored the card number 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 becomes: who was supposed to keep that control secure?

That is where “we do not touch the data” starts sounding like an incomplete answer.

Kitty: Because the customer clicked the payment button inside your software. They did not conduct an architecture review before doing it.

Steve, let’s go deeper on Level 1 and Level 2, because these terms get thrown around in sales conversations without any explanation. What should an ISV understand about the difference?

Steve Levinson: First thing, usually the card brands are going to say the number of transactions is what dictates an entity’s level in PCI. In the world of service providers, where it gets a little convoluted is that there are some service providers where they are not actually in the transactional process. They might be involved on the periphery, where they can potentially access lots of cardholder transactions. Sometimes it becomes a gray area and is not quite as easy to measure.

Often, and we work with service providers in this space, there will be a financial institution, maybe the card brand, but it could be an acquiring bank, that says, “Based on what you are doing, we want you to be a Level 1 service provider.” That usually draws the line right there. Once it is a business enabler or you are forced to do it, you have to do it anyway.

Kitty: So, Steve, when a vendor sends you a one-page document and says, “Here is our PCI certification,” what should you actually look for?

Steve Levinson: Usually what I look for first is, let’s see what that one-page document is. If it is a self-assessment questionnaire, then it is akin to that entity patting themselves on the back and saying, “Yeah, we are PCI compliant.”

But even if a QSA has performed the assessment, you want to make sure that whatever was assessed is the service that you are purchasing.

Another thing that often goes along pretty well with that, and we make this recommendation all the time, is making sure there is some sort of responsibility matrix. Usually, that will have the control item, what the customer is responsible for, what the service provider is responsible for. Sometimes it is a shared responsibility, and often there might be notes that further delineate what that means.

The AOC itself is a great starting point. It gives you at least some degree of confidence that the service provider is PCI compliant, but it is never going to get granular enough to cover the responsibility matrix.

Chris: That is why some of the major customers are getting a little more skeptical of self-assessments. They want a little bit more detail.

A sophisticated customer is not just checking whether the AOC box is filled in. They are asking who performed the assessment, what was tested, what was excluded, whether the service they are buying was actually covered, and whether the company’s contracts match the responsibility model.

A QSA-led assessment creates independent evidence. It does not guarantee that a breach will never happen, but it makes the compliance statement much more defensible.

Kitty: And commercially, that is becoming a bigger problem. ISVs are increasingly finding out that a large enterprise customer, bank partner, processor, or payments vendor is not satisfied with, “We are under the transaction threshold, so we filled out the questionnaire ourselves.”

They want the QSA-signed AOC.

Sometimes they want the responsibility matrix, penetration testing results, policies, vendor lists, and evidence that the product named in the sales deck is actually the product included in the assessment.

Steve Levinson: Over time, procurement teams are ramping up their knowledge base, not just in the PCI space, where they are really looking for the right artifacts to give them confidence that their partners are doing the things they need to do to protect what is important. In this case, we are talking about cardholder data.

Sometimes it is going to be glaringly obvious if there are more than 300,000 transactions. Sometimes, from a business perspective, it will be glaringly obvious because that is what the customer is forcing you to do.

It is important to know that PCI compliance is the happy byproduct of a robust security program. Often, if an entity is going through PCI for the first time, it is not going to happen overnight. A lot of times there is 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 what you have built and make sure it is actually secure and doing all the things it needs to do.

Often, especially if it is 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.

Kitty: 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. It is not.

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 matter most for an ISV?

Steve Levinson: There are several of them, and within PCI DSS, it calls out some of those controls for service providers. With great power comes great responsibility.

For example, making sure you perform an additional network segmentation penetration test. You are having to do it twice a year rather than once a year, as an example. There are a few things where it says, “for service providers.” I think there are about a dozen controls or so that talk to that.

While nobody has the authority or budget or accountability, PCI becomes both a paperwork exercise, but more importantly, it becomes a way of being. You are trying to avoid incidents, because if there is some sort of incident, that becomes evident as far as how a company handles risk or its security posture.

Chris: 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 forwarding over to IT.

If nobody had authority, budget, or accountability, that is not just an operational weakness. It becomes evidence about how seriously the company took the risk.

Steve Levinson: I think this applies to all entities, including service providers. You really want to bake it into your culture and into your security. It should be important. It should not stop the business from doing what it should do, but it should be right-sized.

Key activities should be reviewed as periodically as they need to be. There are a lot of everyday controls that need to be reviewed. It could be log review, looking at your SIEM, or maybe you have a third party doing security event monitoring on your behalf, making sure they are actually doing their job.

A lot of this is making sure everything is kept current because it is easy for things to slip through the cracks.

Along with those, you want to create your audit trail demonstrating that you are doing this. It is one thing to say you are doing it, but it is another to create that audit log.

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

Steve Levinson: You want to create that audit trail showing that you are doing it. Having the records that show the logs are reviewed may not mean you actually did it, but it at least improves the likelihood that you did.

Obviously, when we are performing PCI assessments, we do more than just ask, “Did you review the logs?” We talk to those who are responsible and ask them, “Tell me, show me how you do it.” We dig in a bit deeper.

This ties into the difference between a self-assessment questionnaire and a full-blown Report on Compliance, where we as the QSA are going to say, “Show us this. Show us how you do it.”

In the world of change management, where things are changing all the time now, I find a lot of things maybe slip through cracks. A change gets made. People do not document it. They may not test all the changes that need to take place. Suddenly, there is a whole new part of the environment that was not vetted and may not even be PCI compliant.

It is important to build that into your everyday, because when we cross the fence, whether it is an SAQ or a Report on Compliance, that is fine. Everybody is PCI compliant. That is great.

That is only a snapshot in time.

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

Steve Levinson: Absolutely. The beauty is you only have to do a PCI assessment once a year.

We have a lot of clients come to us and say, “In three months, we are going to be making these big changes.” We tell them, “You do not have to do another assessment. You just want to make sure as the world is changing.” The way technology is now, it changes quite rapidly. What was here yesterday is something totally else tomorrow.

Kitty: 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 does not want an SAQ, does not want an old attestation from a different product, and does not want a paragraph explaining that the processor is compliant.

They want a current service-provider AOC signed by a QSA. Steve, what are you seeing in the market?

Steve Levinson: One of the funniest things I see in the world is service providers using the wrong templates.

A service provider really has only two artifacts that it can fill out as a service provider: SAQ D for service providers, and the Report on Compliance. However, we see a lot of service providers that, because not all 830-some-odd controls apply to them, just pick an SAQ that seems more their flavor, like SAQ A. Well, all the other SAQs are for merchants.

We see this time and time again. The PCI Council has FAQs that talk about this because they have seen this error so many times.

First and foremost, make sure service providers are using the right reporting templates. It is not to say that all the controls are going to apply to a service provider. Often, only a handful of controls will apply to them, especially if they could just impact the security of cardholder data and are not storing, processing, or transmitting it.

But they need to at least be filling out the right paperwork.

Chris: It is probably easier to do it earlier than later, too, instead of being under pressure when the deal is already negotiated and the customer says, “Send us the Level 1 AOC,” and the sales team wants the answer by Friday.

PCI readiness extends well beyond a technical assessment. It often requires meaningful operational changes, document controls, and continuous compliance efforts. If you get on that early, it is probably way easier to get ahead of the curve.

Kitty: You can create a document saying it was supposed to happen, and that is not the same thing.

Now let’s close this with something practical. An ISV is listening to this and thinking, “We use a third-party payment provider. We do not intentionally store card numbers, but we control the integration, and we have never been assessed as a service provider.”

What should they do next?

Steve Levinson: This is where it is important to define the service and map not just the data flow, if there is no cardholder data, but the data flow as it pertains to how it might impact any sort of security posture. That might be redirects, tokens, refunds, support access, or configurations.

When we are doing any PCI work, whether it is a front-end sales call or kicking off a PCI assessment with our clients, we call it the scoping dance. Let’s figure out what is important to you and your clients and what needs to be protected, because you cannot really start looking at various controls and tech stack until you know what you are trying to protect from a business perspective.

The scoping exercise is extremely important.

From that, we can determine which requirements may apply. It is not necessarily going to be all those requirements, but it will be a subset of them. To the extent it applies, you might also deal with segmentation or systems and evidence needs.

As we further define things, this is where the responsibility matrix is helpful.

Part of this is reviewing vendors, third-party service providers, and sometimes fourth- and fifth-party service providers, to understand their roles in the ecosystem. Those are all important things.

Sometimes, it is also important to understand what your customers are looking for.

Kitty: The big takeaway is that PCI scope does not 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.

Using a PCI-compliant payment provider does not erase those responsibilities. It just helps define which parts belong to them and which still belong to you.

Chris: Correct, Kitty. PCI is not 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, card brands, or even lawyers begin asking questions after an incident: evidence.

That was the point of the article, and it is the point of this conversation. Treat PCI as an ongoing operational discipline, not something you build after the fact.

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

Steve Levinson: 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. My team and I have literally performed hundreds of PCI assessments, and not just assessments. We take that advisory approach with our clients.

It could be PCI readiness, it could be, “Hey, just bounce something off of me.” I am always happy to talk to them at a time.

You can play the game, “You may be a service provider if...” if you are not sure. We do other things too. We work with other frameworks as well. We perform penetration testing, virtual CISO, security program management, and PCI program management. We can help with any of those things if there is ever that need.

Just know there is a friendly voice out there to help with any of those questions.

Kitty: Well, Steve, thank you so much for joining us. It has been a pleasure.

Chris, thank you for making sure everyone leaves today’s episode slightly more concerned about their contracts.

Chris: That is what I am here for.

Kitty: And if you have not read Chris’s article, “PCI Compliance Is Your Insurance Policy, Not Your Checkbox,” you can find it on CentsChat.com. It gets into the legal, financial, contractual, and reputational side of PCI for service providers, including why an AOC is valuable but is not the whole story.

Thank you for listening to Cents Chat. We will see you next time.

Announcer: Thanks for tuning in to Cents Chat. Got questions? Got ideas? Got payment problems keeping you up at night? We have got you covered. Head over to our website to take our quick survey. You might just land a guest spot on the pod.

Do not forget to subscribe, share this episode with your favorite ISV, and follow us on all social for the latest trends, tips, and debates. We promise no boring slideshows. At Cents Chat, we are here to make payments make sense and make it fun while we are at it. See you next time.