Compliance Unfiltered is TCT’s tell-it-like-it is podcast, dedicated to making compliance suck less. It’s a fresh, raw, uncut alternative for anyone who needs honest, reliable, compliance expertise with a sprinkling of personality.
Show Notes: PCI FAQs When You’re Starting Your Compliance Program
Quick Take
Think PCI compliance is something you can outsource? Think again. Todd Coshow and Adam Goslin break down the biggest misconceptions about PCI DSS, from third-party payment processors and SAQs to merchant versus service provider responsibilities.
Learn why outsourcing payment processing doesn’t eliminate your compliance obligations, how scope really works, and why treating PCI as a one-time paperwork exercise creates unnecessary risk.
This episode is essential listening for merchants, service providers, and anyone navigating PCI compliance for the first time.
Read The Transcript:
So let’s face it, managing compliance sucks. It’s complicated, it’s hard to keep organized, and it requires a ton of expertise in order to survive the entire process.
Welcome to Compliance Unfiltered, a podcast dedicated to making compliance suck less. Now, here’s your host, Todd Coshow with Adam Goslin.
Todd Coshow:
Well, welcome in to another edition of Compliance Unfiltered. I’m Todd Coshow, alongside the Canadian maple syrup to your compliance pancakes, Mr. Adam Goslin. How the heck are you, sir?
Adam Goslin:
I am doing good today, Todd. How about you?
Todd Coshow:
Not bad. Not bad indeed. Some maple syrup on pancakes sounds delicious, if we’re being honest.
Today we’re gonna have a conversation about some frequently asked questions in the PCI arena when it comes to starting a compliance program.
But before we get there, Adam, as always, we’d like to take the opportunity to say thank you to those of you who’ve been kind enough to share some of your time with us by listening to this fine podcast, and we would invite you to reach out and give us your opinions, your thoughts, your perspectives on all the things, pancakes or otherwise.
Go ahead and reach out at [email protected].
Now, Adam, a long time ago in a land far, far away, there was a time where you asked the question, “What is PCI?” So bring the listeners up to speed on that.
Adam Goslin:
Everybody gets their start somewhere, and PCI was definitely mine.
I had kinda made my way up the IT management ranks. Boss comes by. Don’t ask me why, he decided to print the entirety of the PCI standards, but literally drops a four-inch deck of paper on my desk and says, “Hey, we need to get compliant with this.”
I’m looking at the cover page, and it says PCI on it, and I literally said, “What’s PCI?”
So that was my entree into the land of security and compliance.
I sat there staring at this volume of information and wondering, “What the hell do I do with this? Where do I go? How do I start?” etc.
It’s part of why I decided to step into the space to help people, because I clearly remember just how overwhelming it felt to be looking at that much stuff, not having any clue what the hell it was, what it meant, what it’s for, does it even apply to us, etc.
All the way around, it was very overwhelming to step into the compliance arena not already having been initiated.
TCT has, both I and TCT have kinda specialized in PCI since our inception, and the consulting work that I was doing for folks in the space, the history of the consulting practice goes back even further than PCI’s existence.
As we were sitting there and contemplating the types of things that organizations new to the space are facing, we decided to put together this almost like a frequently asked questions when you’re getting a compliance program off the ground.
Frequently asked PCI questions when you’re getting a compliance program off the ground.
Todd Coshow:
Does PCI apply to merchants who outsource all payment processing?
Adam Goslin:
It’s one of the common questions that I’ll get.
They’ll be like, “Oh, well, we don’t touch anything. We go ahead and outsource all of our payment stuff to blabbity-blah. That’s not my problem, and PCI doesn’t apply to us.”
The answer is you’re wrong.
Companies that are not storing, processing, transmitting, or receiving cardholder data, they still are subject to the PCI DSS.
One of the biggest misunderstandings is, sure, there’s some technical elements of how you’ve done what you’ve done in terms of the connectivity. The devil’s always in the details.
If you have a merchant account that is in any way, shape, or form receiving payments via credit cards, then you too get to fill out your PCI paperwork.
That’s one of the biggest misunderstandings that organizations have.
Honestly, a lot of the big names that have come out in the space over time, the Stripes, the Squares, the Intuits, if you will, back in the day, it was like the Wild West.
“Well, I’ll just go get a Stripe account, so I don’t have to worry about this.”
“Go process my stuff through Intuit, that way I don’t have to worry about it.”
The unfortunate part is that those organizations were on this mad race to get people to jump over to their platform and process their stuff via their platform, but they weren’t really doing a great job with enforcing, mandating that people were actually following the PCI DSS.
That kind of became a problem for a while because they were able to go in and easily turn it on, etc., and there wasn’t any enforcement arm that was coming at them.
Even recently, I know that Intuit put together a—I’m pretty sure that these organizations got their hands swatted by somebody.
I saw a number of organizations popping up with, “Oh, well, Intuit’s starting to mandate that we have to fill out or load our PCI paperwork,” that type of thing.
Those platforms have the capability to absorb a lot of the technical requirements, but there’s still a requirement for the organizations of maintaining specific internal controls for security awareness and having policies and procedures and, depending on the circumstance of the organization, having a game plan.
What happens if I’m on the phone with, I’m at a call center, I’m on the phone with somebody, and they just start rattling their card out?
Or sending card information in through the web, through the email web form submission, or directly in an email to one of the people at the company, or whatever.
Sometimes there’s things that you cannot absolutely control.
There are still elements, and even when it comes down to the technical implementation of how they go about implementing it, again, devil’s in the details when it comes to what exactly you need to do.
There’s some complication there, but I’ve heard often organizations pull the get-out-of-jail-free card.
“Oh, well, we don’t touch any of it, so not my problem.”
Oh, no. Sorry. Doesn’t quite work like that, but good try.
Todd Coshow:
In the PCI world, what is the difference between merchants and service providers, and can an organization be both?
Adam Goslin:
In the PCI arena, there’s a distinction that’s based on the relationship to the transaction.
For merchants, these are organizations that are accepting and receiving payments via credit cards.
In the case of service providers, those are organizations that are provisioning services to companies that are receiving money through credit cards.
That service provider bucket, it’s a pretty broad one.
This is everything from hosting companies and gateways and specialized solutions that help organizations meet specific compliance line items, so central logging vendors, file integrity monitoring vendors, etc.
There’s some very unique and specific security requirements that apply specifically to those service providers.
Otherwise, the list of the controls is identical.
Basically, service providers need to meet everything that merchants do and a little more. That’s probably the easiest way to say it.
In terms of could the organization be both merchant and service provider, the answer is absolutely.
If I’ve got a card processing gateway that is provisioning those services to merchants, thus making them a service provider, they may also take credit card payments for their own payments for their organization as well, which also makes them a merchant.
What I’ll see organizations do when they’re in this dual-category mode, they’ll either generate and maintain two separate sets of PCI documentation.
That way I can very easily, cleanly, clearly establish the scope for the service provider view of it.
That way I can scope it out, have the right context and boundary lines and all that fun stuff, and then I can have the second set of information that specifically addresses the handling of the merchant side of that equation.
Maintaining the two distinct sets makes it a little bit mentally easier.
But some organizations will say, “Nah, screw it. I don’t want two different pieces of paper. I just wanna maintain one thing.”
So they’ll combine everything into a single assessment.
But when you do that, that now means that I need to be going through, control by control, which of these are applying in my merchant instance, which of these are applying in my service provider instance, and being able to speak to those controls very deliberately if I’m gonna go ahead and collapse the engagement down into one single PCI assessment to rule them all.
Todd Coshow:
Yeah, that makes sense. What is some of the fallout from a company not maintaining their PCI compliance?
Adam Goslin:
Once you go through and sign off on the AOC, and honestly, I’ve seen this happen unfortunately a time or three, organizations will do all the hard work, get themselves to the point where they’re signing off on the piece of paper that says they’re compliant.
They’ll sign on the dotted line and then just be like, “You know what? I’m just not really gonna take this seriously now. We’re gonna go back to our day jobs, and we’ll look at the compliance stuff as we’re coming back toward our annual point.”
The difficulty is that once an organization goes in, signs off on their AOC, and starts distributing that to people and they’re depending on it, one of the check boxes on there is that you’re gonna manage and maintain your PCI compliance.
That’s one of the agreements of signing off on that paperwork.
Even though the piece of paper is valid for a year, if I sign the piece of paper and then just stuff my PCI program on the shelf, come back to it in 10 and a half months to do another annual scramble to sign another piece of paper, then it’s gonna bear a whole bunch of problems.
You literally are violating the nature of the agreement that you effectively signed off and the commitment that you made to those third parties.
It’s gonna place the organization, data, customers in pretty substantial jeopardy.
In the event that a data breach were to occur during that period while the company’s really not doing anything, you obviously would be in direct violation of PCI DSS and the signed attestation, and that’s gonna expose the business to substantial negative impacts.
Aggressive fines will be levied by the card brands, their merchant bank, payment processors, etc.
It’s certainly gonna expose the organization to some pretty substantial legal liability.
The other problem is, and this one I’ve looked at more pragmatically in terms of protecting the company, from an operational standpoint, if you let those controls lapse, you are willingly injecting massive blind spots into your visibility to what’s really going on.
If you just said, “Screw it,” turned off the central logging because the storage was getting too expensive, well, guess what? You now don’t have any visibility into the environment.
You have no way to be able to detect that you’ve got something going sideways, a problem within the environment, etc.
I’ve often implored organizations to take their active operational compliance responsibilities extremely seriously because that’s active protection for the company.
It’s, in many ways, better than your holy moly emergency parachute of the cyber liability insurance.
Actively taking this stuff seriously is far better of a shield, a true shield to the organization.
Todd Coshow:
That makes complete sense. Why do some companies use PCI DSS even though they’re not processing credit cards?
Adam Goslin:
The one thing that’s interesting about the PCI DSS is that it has for a long time, and quite frankly remains, one of the most prescriptive, granular protection guidelines that exists in the security industry.
There’s a lot of other frameworks that become—I like to use the phrase prescriptive, and that I would associate with PCI, and then directional, something like HIPAA.
HIPAA is an unbelievably directional standard.
HIPAA was intended to meet the requirements of everything from a single practitioner dental office all the way up to an entire health system, and these rules are supposed to apply to everybody in between.
When you’re writing up a framework with such a broad audience and scope, you have to be directional in nature.
Where we talk about in HIPAA, it’s like a one-liner talking about how organizations need to have secure authentication.
Where in PCI, that’s broken out into, I don’t know, make a number up, like 35 different specific line items of you’re gonna do this and this and this and this and this to assure secure authentication within the environment.
Organizations that are using that highly prescriptive PCI DSS are generally valuing robust data security.
It’s a problem when you have as much latitude as a directional cert gives you.
Are you interpreting it appropriately? Are you doing it accurately? Are you doing it in such a way that you actually are protecting the organization?
I would much rather say, “Give me the 35 things I need to go do for fill in the blank,” and that way I can go check all the way down the line and have a much higher level of assurance that I positioned myself, my organization properly for being able to go through it.
A lot of the organizations that I’ve spoken with about dipping their toe in the security and compliance pond, it’s one of the reasons why I’ll direct them.
“Go pick up the PCI DSS. Look at it differently. You don’t seclude this just to card processing and card data. Everywhere you see that, substitute sensitive data and then run down the rules, regs, etc., and go ahead and use that framework.”
It’s a really, really strong framework to use from that perspective.
It’s a heck of a lot easier to implement without the variability.
The best part is it’s astoundingly portable to other secondary standards.
It’s awesome to be able to have that prescriptive nature.
It makes it a hell of a lot easier.
If I’m now mapping my compliance program out against an ISO 27001 or a CIS or a SOC 2 engagement, etc., it’s so much easier to map when PCI is your baseline standard.
Todd Coshow:
Yeah, that makes complete sense.
The word that you said that really stuck out for me was assurance. I think that that’s such a critical piece when you’re having a conversation about compliance. I completely agree.
Now, what’s the purpose behind the multiple types of self-assessment questionnaires?
Adam Goslin:
There’s all sorts of different ones of them.
Some people are kind of surprised when they know that there’s a whole bunch of different levels of SAQs.
The PCI SSC has a diverse series of specialized self-assessment questionnaires that are tailored to specific transactional environments.
The mechanics of how the organization processes the transactions dictates which of the questionnaires they need to go in and complete.
At the front end of each of the self-assessment questionnaires is kind of like a how-to guide. You should be using this one if you blah, blah, blah.
Without getting into all the ad nauseam detail, there’s self-assessment questionnaire A.
I’m gonna start using the word SAQ, S-A-Q.
For an SAQ A, it’s really for organizations that have completely outsourced all their card processing activities to a validated third party.
There’s a number of intermediate SAQs.
This is SAQ B and C.
Those ones are tailored to specific hybrid processing methods, separating out various distinct methods of card exposure.
There’s a couple that sit in the middle based on the organization.
Then the SAQ D is the most exhaustive tier of the self-assessment questionnaires.
Effectively, an SAQ D and a Report on Compliance is literally the same line items between those two.
Just that in the case of the self-assessment questionnaire, it’s something that the organization could self-sign against.
But the self-assessment questionnaire is also a document that an assessor can also sign off on.
It’s got a good amount of portability.
The organization would have a choice to either fill out a self-assessment questionnaire D, have the assessor sign that, or just go with the Report on Compliance and have the assessor sign that as well.
Todd Coshow:
What from a PCI engagement should be shared with third parties?
Adam Goslin:
This is a question that I’ll get a fair amount, and one of the realms of education that I love to give to the folks that are dipping their toe into the PCI space.
Whenever you do either a self-assessment questionnaire of any form or a Report on Compliance, there’s an associated document which is called the Attestation of Compliance, which in the PCI world is short form to AOC.
That AOC is exactly the document that’s intended for public distribution.
Every time that you wrap up an SAQ or a ROC, then you’ll get the associated AOC.
That AOC is exactly what you should be sending out to third parties.
Your fully filled out SAQ or ROC document, those will typically contain highly sensitive information that you don’t want to be sharing out with third parties.
But the AOC, its exact intent is for you to be able to provide it, if you’re a service provider, provisioning that to your clients, being able to provide your AOC to interested customers, other third parties.
That AOC is exactly the document that one should leverage.
Todd Coshow:
For international firms, what impact is there on QSA choice?
Adam Goslin:
For international-style firms, let’s say we’ve got a US-based business with a scope, a footprint that crosses over into Europe or South America.
Then you need to make sure you’re using a QSA that’s registered and paid to operate in those geographic regions or countries.
The PCI Security Standards Council organizes the assessors by operational regions, so US, Canada, Europe, APAC, etc.
The organization just needs to ensure that whichever one they select is formally qualified and approved by the council to operate within any of the specific regions where your scope is located.
It’s natural for organizations to gravitate toward local assessors in close geographic proximity to their primary operations.
But this will definitely be a consideration for those that have more complicated circumstances.
Todd Coshow:
Here’s a hot button question. How has PCI addressed AI?
Adam Goslin:
They released some directional guidance regarding integration of AI.
It’s a framework that establishes rules for assessors leveraging automated tools, including mandatory client notifications and explicit consent protocols before using any AI for artifact and evidence reviews.
The guidance that was put up by the council mandates keeping the human in the loop, noting that, as we’ve been discovering through the AI zombie walk extravaganza, fully autonomous AI remains an elusive, unfulfilled promise.
Right now, all the PCI baseline requirements apply for internal AI integration.
All of those core principles that those who have been in the PCI space for a week or three know and love, least privilege and strict access control, need-to-know boundaries, etc., they don’t just suddenly not apply to your machine learning models.
If an organization is opening up AI tools to unencrypted data across underlying systems without verified business necessity, they’re already in direct violation of the standard, PCI DSS, across collection, storage, and transmission phases of the engagement.
To me, a lot of the “What do we do with AI?” is almost like organizations are just trying to bypass doing what’s right.
These are principles that, for those that have been in the space for a while, they already ought to know and love.
The organization ought to be taking those responsibilities seriously and applying them to their AI principles regardless.
Todd Coshow:
When does a self-assessment make sense for an organization to tackle, and where can companies find additional PCI resources?
Adam Goslin:
If your annual transactional card volume is below the formal thresholds as mandated by the card brands, then you’re allowed to go through and execute a self-assessment questionnaire rather than going through a full-blown Report on Compliance that has a mandated QSA involved.
Especially for the smaller, new, early-stage businesses, the self-assessment questionnaire process is a very cost-effective entry point to the compliance landscape.
But the self-assessment is a double-edged sword.
I cannot begin to tell you how many times I’ve seen either inventive or optimistic interpretation of what the controls really mean.
They’re going in, “Oh, yeah, yeah, yeah. No, we totally got that checked.”
Meanwhile, they didn’t even understand what the line item was in the first place.
The difficulty there is that you’re creating a very dangerous false sense of security.
You are obligating your organization by signing a legal document.
Just because you didn’t understand what it meant isn’t gonna eliminate risk from the organization.
If you’re going down that self-assessment route, and depending on the organization, some organizations are just too small to where it would not make sense.
But for the reasonably sized organization, I can’t underscore the importance enough.
Get somebody. Get a PCI consultant to give you a hand, be somebody that’s looking over your shoulder, giving you directional guidance, answering your questions.
Hearkening back to my early days, that would’ve been awesome.
As far as official documentation, all of the official documentation for the PCI from the PCI SSC is accessible through their public repository at www.pcisecuritystandards.org.
On there, there’s also a dedicated document library where you can go through and filter out different standard types.
For those that are going to look for self-assessment questionnaires, I believe when you hit that page, if you hit the dropdown, switch it from PCI to SAQ.
I believe that the PCI dropdown’s primarily relegated to the ROCs, but if you switch it to the self-assessment questionnaire dropdown, then you’ll be able to see all of the various self-assessment questionnaires and their associated AOCs there.
Todd Coshow:
Outstanding. Parting shots and thoughts for the folks this week, Adam?
Adam Goslin:
I kind of just tried to do a little bit of foreshadowing there.
The reality is that I remember when I was going through that first run at PCI, and I didn’t have any idea what the hell I was doing.
I was learning a lot at the time.
It was very enlightening and, honestly, I think it gave me all the perspective that I needed to be able to help organizations with their troubles in the PCI space.
When I stepped away from doing that first engagement for 18 months, I literally stepped into an arena where I said, “I like helping people, and I wanna help people not have to go through what I went through.”
That was part of the reason why we ended up building a system for tracking and managing PCI and multitudes of other security standard engagements, why we continued doing security and compliance consulting for organizations so that they don’t have to go through the same dimensions of hell that I did in the early days.
It’s counterintuitive.
“Well, we can just go Google it and look it up and do Google AI searches and yada, yada, yada.”
You can, but at the end of the day, you will end up having a far less risky path and a far more streamlined path for the organization if you just get some assistance.
Certainly, ask lots of questions.
Keep your eyeballs open.
Talk to your friends as you’re going through the process.
Find somebody that can give you some directional guidance if you’re really going through this for the first time.
You will thank me later.
Todd Coshow:
And that right there, that’s the good stuff.
Well, that’s all the time we have for this episode of Compliance Unfiltered. I’m Todd Coshow.
Adam Goslin:
And I’m Adam Goslin.
Todd Coshow:
Hope we helped to get you fired up to make your compliance suck less.
