Keeping transaction and credit card data secure is critical for any business collecting or storing this information. Listen to compliance experts Justin Beals and Sam Oberholtzer as they share insights about what PCI DSS is, who needs to comply, why it's important, and how to stay compliant.

Justin:
Hey there Sam, glad to have you back on the Strike Graph video cast production studio thing that we're doing eventually.

Sam:
Compliance party.

Justin:
I know compliance party. That's awesome. 

Sam:
It Cinco de Mayo. So it truly is a compliance party today.

Justin:
All right. We'll make sure. And my favorite is Tecate with a lime. That's that's definitely my drink.

Sam:
Yeah. I like Tecate.

Justin:
Yeah, with tacos. I'm ready. Yeah, absolutely.

Sam:
And Pacificos too. I mean, I just got back from Mexico, so that's basically all I was drinking.

Justin:
Oh, I am jealous. Yeah. That's awesome. Well, excellent. Well, today we have a new piece of content that we're dealing with a little bit, because we're really happy that Strike Graph is rolling out support for PCI DSS in our platform. This is something we've been working on for a little bit to get all of our controls and our control database mapped onto another standard, and effective practices, and playbooks rolled out to our customers, and also start to now market PCI DSS as a standard. And you and I love tackling these new standards and aspects of this. And I know you've been doing some homework for us on what is, all that could be helpful to know about PCI DSS. So I think we're ready to dive in.

Sam:
Absolutely. And it's crazy. I mean, when I was on the audit side, I would always work together with the PCI manager when I was running the SOC 2, or HIPAA Privacy audit. So this is just interesting to actually get into a little bit more of the weaves, and then the comparison to SOC 2.

Justin:
Yeah. Yeah. All right. Great. So our first question, this is going to be a lot of fun. I'm the questioner. You are the expert today. What is PCI DSS? We could just start there with a big overview. Yeah.

Sam:
Of course. Of course. Don't want to bore everyone too much, but at least it's exciting for the folks that may not know that they actually need to be compliant to this. So just starting off, PCI DSS stands for Payment Card Industry Data Security Standard, and this is a type of audit that an independent body, or a qualified assessor will actually come in and assess against the standard. And so really there's a council called Security Standards Council, that is actually the ones that enforcing the standard, but really the big payment credit card companies, Visa, MasterCard, American Express, Discover, and JCB are actually the ones that have to enforce it.

Justin:
Oh, I see. So if essentially let's say that I have a tech startup or, I have an online platform. We want to process credit cards. I think that's the... You're not going to be able to store, submit, get Visa to pay you back, run a transaction without compliance against this standard. Is that right?

Sam:
So actually you technically are still going to be allowed to process card holders data. However, it's up to those five big crack card companies to actually perform audits and investigations. So we'll definitely dive into the fines later, but I thought that was super interesting, that the council is not actually required to do so, but the banks themselves are allowed to and should do that.

Justin:
Yeah. I definitely know that as we, as I've built technologies that have taken up credit card processing, like if we were to collect credit card information online, some of the B2C businesses that we built in the past, there was some form of PCI DSS compliance that we had to talk about to get that to happen. And it usually did come down to the bank, like when we were trying to get the bank to approve us, to be able to do that work. So for me then it's kind of like, you're not going to be able to roll out your business bank relationship, and you need that partnership to do this processing, without meeting the type of compliance check that they're going to do on you.

Sam:
Absolutely. Yeah. And it's kind of crazy and we'll definitely get this in the process, but all merchants and that goes into the next, who is actually compliant. And to your point, like you were just stating, it's any company, any organization, regardless of size, regardless of transactions, because we'll get to those levels later, but it's any organization that accepts transmits or stores cardholder data. And this goes for telephone, email, which email probably shouldn't, encrypted services, in house developed software, even if you outsource to other payment processing companies such as Stripe, because that's a big organization that's up and coming, or PayPal, something of that nature. If you actually are utilizing it as an organization and performing, or touching any of that offered services, then to some extent you need to go through PCI compliance.

Justin:
I think there's been a lot of desire to skirt this compliance issue by trying to use some third party vendor. And so let me try out a couple used cases here and you say, "Yeah, they're going to have to be compliant or not." So let's say that I am collecting a credit card information over the phone, plugging it into Stripe and hitting submit for a one time transaction, but I don't long term store it let's say, like Stripe obfuscates the credit card information after I do it that once, am I still needing to be PCI DSS compliant?

Sam:
Absolutely. Because you are still collecting that information regardless if you're using a third party. And so actually that third party does minimize the risk that is in your responsibility. So as we know in the SOC 2 world for organizations that have been through that, they know that sometimes different criteria areas are not applicable because it's either their customer's responsibility, or their vendors are just really just not applicable. It doesn't exist in their process. And that's how PCI works. You basically scope. You scope your services, you scope your payment systems, you scope what systems collect that. And then that's how you tackle it. And you also look at the number of transactions, because that will dictate what level the organization has to achieve.

Justin:
Let me try one other used case on you before we get to what levels there are in PCI DSS. A really common tactic that I've heard from chief technology officers is they use a tool called VGS, Very Good Security, and it's called a tokenizer. And what it will do is like, let's say I have a form on my website to get credit card information, but I never store it in a database. What I do is when I ingest that data, I send it to this third party. It tokenizes the data under encryption, and then I only store the token. But then when let's say, I want to go process again, instead of storing in a database that credit card, I use the token to retrieve the information just long enough to send it via API over to Stripe, to do the processing. In that instance, do I still need to be PCI DSS compliant?

Sam:
Absolutely. But again, there's going to be a handful of controls that just would not be in the bucket, or that's lower minimized risk, but the risk is still there. Because there's a vendor that's taking care of that, but that's still technically under your responsibility of managing that vendor that's doing so, and making sure those controls are still in place.

Justin:
I think I'm starting to get the gist of this a little better now. It's almost like it used to be with AWS. There was a time where people would say, "Are you SOC 2 compliant?" They'd say, "Oh, I don't think I need to be because I'm using a really great vendor like AWS." And actually that flew for a little while, but it doesn't seem to anymore. And I think you're telling me it's a very similar situation, right?

Sam:
Yes. Absolutely right.

Justin:
Just because you are using this third party tools doesn't mean you need to go through compliance, but just like with SOC 2, if I'm using AWS, maybe they're handling data encryption, but it still have to go through the audit, it doesn't keep me from having to do that.

Sam:
Absolutely. That's exactly right. And so we're just out here trying to break down all these myths, Justin.

Justin:
So you mentioned the concept of tier, and so this probably gets into like, how is an audit or an assessment conducted for PCI DSS. This is one of my top three questions for any standard we come across. How do they specify the testing? Tell us a little bit about what you've learned about that.

Sam:
Sure, absolutely. So for organizations, or merchants is what they call it in PCI, similar as if you were to call a service provider, it's still a merchant, even if they're not the one storing the credit card information. So there's four different levels. And so level one is the highest risk. So those are your large global, those are your PayPals, your WhatsApp, any of the ones that are actually storing and processing themselves. So level one is the riskiest. And so this is any merchant that has over 6 million Visa transactions.

Justin:
So I'm going to describe companies that I think fall into this bucket. If you're a FinTech organization, and you are trying to connect, let's say you're billing a FinTech platform, a processing platform, and you want to connect a bunch of merchants to a bank, i.e Let's say you are Stripe. This is the highest level of compliance. You need to do this level one level of compliance. Is that right?

Sam:
Absolutely.

Justin:
Okay. Great. All right. Who's our level twos.

Sam:
Yeah. So the level twos are from 1 million to 6 million transactions. And so then your level three is your 20,000 transactions to 1 million. And then you have your level four finally, which is the least riskiest, and it's under 20,000 transactions.

Justin:
Okay. So let's see if I can pick out some examples of these. A level two would be, to me might be, either an early FinTech platform, that wants to do a lot of processing, but hasn't quite gotten big enough, or a mature B2C organization that is processing a lot of credit card information.

Sam:
Correct. For the one that's processing a lot of credit card information. And so has over 6 million transactions, would be the level one.

Justin:
At the level. So then even you can go too far and wind up in level one, if you're a B2C organization and you're really big.

Sam:
Correct. Yep. And so it's kind of crazy because I actually was a little bit shocked that it really does come down to the transactions. It doesn't even matter who's storing it, versus maybe who's processing it, or who's transmitting it, which is probably the least riskiest, but they're all part of the same bucket that they have to, they're all held to a similar standard.

Justin:
I see.

Sam:
Of course, I will admit that the organizations storing it, are holding even more elevated, or elevated risk, or high risk. It's just, they have more controls in what they have to assess.

Justin:
Well, and this is like the experience breach. Where it's like millions and millions and millions of people's private information gets exposed because they're storing a ton of data on them, especially probably the credit card information, what credit cards they have, and things like that. So they're not even necessarily processing a ton of transactions, they just have so many people in their database.

Sam:
Exactly.

Justin:
So break it down for me a little bit. Level one, level two, level three, level four, four being probably the easiest assessment level one being the toughest assessment or the hardest set of requirements. Do all of them require an independent assessor?

Sam:
No. So only level one is required to have a Qualified Security Assessor or a QSA, or an Internal Security Assessor ISA, which is not as common. You typically get a QSA. And so that's your third party, typically CPA firm, but it could be other organizations as long as they're QSA, but they're the ones that have to validate your scope, perform the assessment. They're the ones that have to send the assessment, and send not only the report on compliance, but actually send that, basically the opinion on that compliance report to the bank. So they're the ones that are in charge of sending it on your behalf, on the organizations behalf.

Justin:
You don't even get... You're just like, "Hey, I've worked with this third party. They're the QSA. They have done the assessment to us to level one, Hey, third party, will you send this new customer, this bank, this partner, that report." You can't even originate from your email?

Sam:
No. And on top of that, a third party, so the QSA firm, should get a confirmation of compliance, acceptance. So that's one thing that the organization should confirm with a third party. I've seen it before where in my previous life at audit firms, I just remember this, sometimes they wouldn't submit it even when they completed it. And so you can see that it was delayed, and what if they just never confirm? So I would just make sure that, that is your responsibility as an organization to at least confirm with that third party that you hired.

Justin:
So two, three and four don't require an independent assessor. Does that mean a self-assessment, or an internal audit, or outsourced internal audit would suffice?

Sam:
Yes. So you're exactly right. So levels two through four. So the least riskiest or least under the umbrella. So really depending on what type of services, what type of company they are, there is what's called a self assessment questionnaire. And so all they have to do is confirm that they are compliant for, in case if the bank does come and investigate. And then the level two is different than all the other levels, because it operates similarly to level one. However, it's not required to have a third party perform that report on compliance, so your audit report. They can actually perform that, but they have to send that to bank.

Justin:
Okay. I see. Is there any benefit, let's say that you are a FinTech company, you want to help, we call them trust assets of course. Is there any benefit in that way us being like, not only are we stating we're compliant, we did this self assessment, but we actually got assessed and got a report from a reputable auditor on this. It seems to me that might be an effective marketing tool.

Sam:
Absolutely. Because as we know, just like SOC 2, in a SOC 2 world, similarly in financial institutions or insurance, a lot of them are getting questionnaires as is. So if they really want to one, no longer answer those questionnaires and then two, accelerate their sales process, then if they have this report, they can just send that directly to their prospects. And you'll cover it.

Justin:
Absolutely. Yeah. So tell me a little bit, a lot of our customers are looking for SOC 2 reports. That's the general security compliance standard that I think a lot of people in North America have gravitated towards. What's the difference between PCI DSS and SOC 2, if I did SOC 2, how far away might I be from PCI DSS?

Sam:
Yeah, absolutely. So PCI pretty much includes all of SOC 2. Of course, I will say I do have to do a disclaimer, even though when I was in the audit side, the systems overlapped. So PCI would take all of SOC 2, and then additional systems that collected the payment and credit card information. So that's why I say typically PCI will include SOC 2, because SOC 2, as we may know, really derives around the systems and the services that the company provides.

Justin:
Got you.

Sam:
While PCI is really highlighting the payment systems. Payment processing systems, card holder data systems. However you may call it. And a lot of the times it is including the so two systems. And so-

Justin:
Go ahead, Sam.

Sam:
And I was going to say, and so typically there's about a 60% overlap. And so PCI just has an additional 40% depending on the services of the company.

Justin:
Okay. That's super helpful. What we love about this, and something we of course have built into the intelligence in our platform is that activities that you might be doing for SOC 2 that are applicable to the standard like PCI DSS, are essentially mapped to both standards. And so you're able to take advantage of work on one for work on the other. That's super helpful. Well, any pitfalls to realize about PCI DSS? Customers might be thinking about going after this particular compliance issue?

Sam:
Absolutely. So there was a, I think we hit a couple of them. So one of them that I keep hearing is that organizations don't think that phone systems are considered to be part of PCI audits, third party processors, or third party storage in any way, you're still supposed to be PCI. Even if you have a third party that you outsource, you should still, depending on the transaction, go through PCI compliance. If you do not store the credit card data, and sorry, card hold information does include debit as well as credit, just as a note, because some people might think just credit cards, they still have to be PCI. So that's a myth or pitfall. And then lastly, I would say, honestly, I think those are the biggest ones.

Justin:
I think the one that I always worry about is if you are going to be running these types of financial transactions, there's just so little room for error. And I think that while it's great to minimize, look, we all want to minimize the amount of compliance we have to go through. That is a given, at the same time it always makes me nervous when you're working in situations where every transaction has to be perfect. And so I do think if I were doing this, I might look through the SOC 2 portion of the standard for processing integrity.

Justin:
And also probably wrap that into what I'm thinking and broadly to say like, "Do I have some controls around processing integrity, and error checking around processing integrity, so that I'm sure that these transactions are processed in the correct way." And then you get into financial controls too.

Sam:
Exactly.

Justin:
Something your CFO exactly might need to own, and fraud issues that may happen. And then I think about the type of legal requirements that may have you adding in some controls. So there is a real co-mingling if you're not thinking about it from a high level. Well, I know that I'm going to be at the Finovate Conference in just a couple weeks, then we're doing our grand launch for this PCI DSS feature inside of Strike Graph, there I'll be speaking at the conference as well. I'm excited to, now that I've learned so much Sam, you're always a great teacher. I think I'm feel empowered to answer any questions that might crop up.

Sam:
Yeah. I think, from your standpoint, so out of what kind of... And you can cut this out if you want, but I just want to know.

Justin:
It's all in Sam, we're going for it.

Sam:
So, after we just discussed the levels, and what merchants would fall in each level. So from your perspective, what organizations do you think that we're going to go after, or really having our product out of what levels I should say?

Justin:
Well, I think that one of the things that I would think of right off the bat is that even if you're a level four or level three, and you have to answer those self assessments, knowing, using Strike Graph to say, I have the right controls in place, we are operating them, and I am collecting evidence. Even if you're doing a self assessment, it's just a better way to organize it. Because otherwise, and I have done this here. I've sat with the CFO before, as we're trying to set up the payment gateway. And I'm just looking at this security questionnaire from the bank, as we're setting up the payment gateway and being like, "Yes, yes, yes. I think we're doing all that." And then I just forget completely that those were the things we were supposed to do.

Justin:
So look, you don't want to set up your business, start processing transactions, turn around and have a breach, and then have the bank come and asking hard questions about, "Hey, you told us that you were living by these rules and now it looks like you're not." Because it seems to me that the real issue here is what if they pull their card and they're like, "Fine, you can't process transactions anymore." And then your whole revenue pipeline shuts down.

Justin:
So I do think that the risks are quite high for not having at least some active practice of, these are our controls, this is how they line up to PCI DSS, and this is how we're actively monitoring them. I certainly think that any FinTech product, and there are a lot of them these days that are built to help processing issues should probably try and get up to the level two right off the bat, and be prepared to go after level one with a QSA.

Sam:
Absolutely.

Justin:
Yeah. And in a very Strike Graphish fashion, we've been looking into what it takes to be a QSA so that we can provide these types of services for our customers ourselves, and always super excited about closing the loop for customers on getting all the way through. Certainly scoping your security practice through good risk assessment, using the platform to identify and distribute control activity that matches the standard, collecting evidence, so you can validate the activity from across your organization, and then having a vendor like Strike Graph that can say, "Hey, yeah, we can ensure through assessment, or audit that you're meeting these particular requirements."

Justin:
And so I have to say that even if all I'm dealing with is the level four, I would sure love to have a tool like Strike Graph so that I can ensure the control operation that we're saying we're doing is happening. So in the event of a breach, or enough fraud activity happens, that I don't get my revenue stream pulled by the bank. Yeah.

Sam:
Yeah. And more importantly, for smaller organizations that might be getting into transactions and setting up their company, or assisting in the processing or storage. This is something to look at because the banks can find them and it's up to the discretion. So typically it could be five to 10 grand. It could be reoccurring. It could be... It's really up to them because again, the council's is not the one determining the consequences. The banks are.

Justin:
Yeah. The banks are. Well, and my impression is that if you have a fraudulent activity or breaches, the banks don't care about the fine, they just don't even want to do business with you anymore.

Sam:
Exactly. Yeah.

Justin:
And that's a death now. That'll kill the whole business. Yeah.

Sam:
Yeah. And, oh, I forgot to say one last thing for a part of the levels two, three, four, I totally forgot about this is the actual vulnerability scan. Where the PCI ASV or... Oh God, what is the...

Justin:
Yeah, it's an Accredited Scanning Vendor, I think.

Sam:
That's it.

Justin:
Is that right?

Sam:
Approved, approved.

Justin:
Approved Scanning Vendor. Oh, I love the acronyms. Yeah. There's two different types of assessors. According to my understanding from PCI DSS is an Accredited Scanning Vendor and a QSV, a Qualified Scanning Vendor, I guess. And so is that a little penetration test essentially?

Sam:
Yep.

Justin:
The ASV? Yeah.

Sam:
Absolutely. Your vulnerability assessment essentially. And it really depends on the services. Some might not be required depending on the self-assessment, the type of company, but majority will. And so that's just important to know that again, depending on the services, that's going to be out in the lookout.

Justin:
So does the ASV produce a report similar to SOC 2?

Sam:
Correct. Yes.

Justin:
But then differently than a level one, you get to keep that report and distributed as much as you want. Right?

Sam:
Correct. Well it's up to them if it's everything's remediated, hopefully.

Justin:
Yeah and of course if you want to share it. Well, I always love saying that we're so proud of the fact that none of our SOC 2 customers for example, have had a single deficiency on any of their report. And now having done 100s of these things with customers. And it's that high level of quality and attention to detail that I think that makes our customer so loyal to the solution we provide. We really care, you're trying to get this trust asset, it doesn't help if you've failed one of the grades on it.

Sam:
Yep. And I'm excited for PCI because especially for the lower levels, we're going to be able to really help them with their self-assessment.

Justin:
Yeah. Yeah. All right, Sam, it's always a joy to do these video casts with you. I really appreciate your expertise. And thanks for doing the research around this. Congrats to the entire StarCraft team for rolling out this new feature in our product for PCI DSS. And we'll talk to you again next week. Have a great day.

Sam:
Thank you. You as well. It's always a pleasure.