post-img
PCI DSS PCI DSS

Who must comply with PCI DSS?

  • copy-link-icon

    Copy URL

  • linkedin-icon

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:

  • If you work with data from MasterCard, Visa, Discover, JCB International, or American Express (this largely means vendors who accept credit card payment either online or in person) you must comply with PCI DSS.
  • If you’re a manufacturer of PIN pads and other devices for accepting credit cards or a software developer or organization that integrates applications that interact with cardholder data, you are probably not required to comply with PCI DSS. (Although, you may be subject to other regulations like PCI PTS and PCI PA-DSS.)

Summary

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.

 

Which PCI DSS compliance level applies to my company?

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.

  • Qualified Security Assessors (QSA) are organizations approved by the PCI Council to be a third-party assessor of compliance.
  • Self-Assessment Questionnaires (SAQ) are for smaller-volume organizations. These questionnaires allow an organization to go through their own internal process to validate compliance. There are several SAQs. Guidance for which SAQ is appropriate is available in the PCI Self-Assessment Questionnaire Instructions and Guidelines.

What are the penalties for PCI DSS non-compliance?

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.

Looks like my company must comply with PCI DSS. Now what?!

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: 

  • Build your own expertise. The PCI Standards Council maintains an extensive document library of PCI DSS resources you can study and use to fill out the many required SAQs or navigate the QSA audit process’s twists and turns.
  • Hire a traditional security consulting firm that will handle PCI DSS compliance for a premium price.
  • Choose a user-friendly security platform — like Strike Graph — that makes the PCI DSS compliance process quick, easy, and less expensive.  

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.

Keep up to date with Strike Graph.

The security landscape is ever changing. Sign up for our newsletter to make sure you stay abreast of the latest regulations and requirements.