PCI DSS compliance reduces the risk of intrusions and theft, building trust with cardholders and signaling to the marketplace that your organization takes data and privacy protection seriously. If your business requires you to hold or transfer credit card information or cardholder data, you’re subject to the Payment Card Industry Data Security Standard (PCI DSS).
But who must comply with PCI DSS, specifically, you may be asking? And who doesn’t need to worry about PCI DSS? Here’s a good cheat sheet:
Sam: 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 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 use 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.
Justin: Let me try one other use case on you — 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 these 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.
The other PCI DSS aspect to consider is which PCI DSS level applies to your company. PCI DSS requires organizations with more transactions to take greater efforts toward compliance than smaller organizations with fewer transactions.
The general expectations for all organizations are the same under PCI DSS, but specific PCI DSS compliance requirements vary based on the number of annual transactions an organization makes. Lower-volume organizations (presumably smaller businesses) can use self-reporting processes. Higher-volume organizations cannot.
There is not one consistent guideline, unfortunately, for assigning PCI DSS levels. Each payment card brand (such as Visa or MasterCard) has different levels of enforcement and validation. Depending on which level your organization is assessed at, you will use one of two methods to prove PCI DSS compliance: a Qualified Security Assessor (QSA) or the Self-Assessment Questionnaire.
What if you are a PCI-defined merchant and don’t comply with PCI DSS? Complying with the appropriate PCI rules is a requirement for participation in the credit card ecosystem. And, the consequences of noncompliance affect not just your company, but your bank as well.
Each acquiring bank (who processes the cards) is answerable to the payment brand and can be fined for noncompliance of its merchants. Fines and other consequences of non-compliance then trickle down to the merchants.
Fines historically have ranged from $5,000 to $100,000 per month while a merchant has been out of compliance. Merchants and banks can also lose the ability to process cards or face increased processing fees. Non-compliance can also expose an entity to lawsuits from consumers.
Once you discover your business is subject to PCI DSS, you’ll need to understand which PCI DSS level applies to your company and begin the three-step PCI DSS compliance process: assess, remediate, and report. These three steps must remain ongoing in order to maintain PCI DSS compliance.
There are a couple of paths you can take to reach PCI DSS compliance:
Strike Graph uses a risk-based approach to right-size your PCI DSS compliance process, eliminating unnecessary work. Our platform makes it easy to identify which exact PCI DSS regulations apply to your unique business context and then makes it easy to mitigate those risks using our extensive control and evidence libraries. Our approach is far faster than trying to answer every question on a one-size-fits-none checklist.