Understanding the different PCI merchant levels is the first step to reducing the challenges they...
While frustrating to many, it’s hard to argue the role PCI compliance has played in creating today’s digital economy. By outlining, defining, and enforcing standards for storing, processing, and transmitting cardholder data, the Payment Card Industry Standard Data Security Standard (PCI DSS) gave organizations a security framework that brought trust and commerce to the Internet.
Why was PCI Compliance created?
By the early 2000s, the Internet had cemented its potential as an information superhighway. E-commerce, however, was still a raw proposition to consumers. Giving payment information was scary, and weekly breaches did little to give consumers confidence that merchants could or would secure their payment information correctly.
Recognizing the potential role cards could play in unlocking e-commerce, the major card networks came forth and created the PCI DSS in 2004. This set of rules and requirements established a strict security framework all merchants storing, processing, and transmitting card data must comply with to process card transactions.
Nearly 20 years later and topping over 300 requirements and sub-requirements, the PCI DSS continues to evolve and frustrate many. This post aims to provide a primer for your PCI journey and, hopefully, make it less frustrating.
Before we get into the post, let’s outline a few concepts you’ll need to know.
What is PCI Compliance?
The PCI DSS outlines hundreds of requirements for storing, processing, and transmitting cardholder data. Any entity that accepts card payments from any of the major networks (i.e., Visa, Mastercard, Discover, etc.) must comply with the PCI DSS and assess their compliance annually.
The good news is that third-party service providers have stepped in to help. These platforms extend their PCI DSS-compliant environments, programs, and assessments to merchants as a service. Nowadays, for most online merchants, complying with PCI DSS looks like using Stripe and filling out a couple of forms each year.
For those building it in-house, however, meeting the PCI DSS represents months' worth of preparation, long engagements with auditors, dozens of documented policies and procedures, and a cost of doing business (with a lifetime price tag in the millions).
Still, PCI DSS is widely considered one of the world's most detailed and robust security frameworks.
Is PCI compliance legally required?
While PCI DSS is not required by law, it is a contractually-enforced security standard between multiple parties, like merchants, banks, and various card brands. It is important to note that PCI DSS does not guarantee safety in online transactions. It’s only a standard for security.
What is a PCI requirement or control?
Now on its third iteration, the PCI v3.2.1 outlines over 300 different requirements and sub-requirements that organizations must meet to store, process, or transmit cardholder data. Controls simply refer to the measures taken to address the requirements.
Note: PCI DSS v.4.0 was published earlier in June 2022. Entities may choose to report against v4 or v3.2.1 as of today. Starting March 2024, v.4.0 will be required.
What is a Cardholder Data Environment?
A Cardholder Data Environment (CDE) consists of a computer system or network that processes, stores, and/or transmits cardholder or sensitive authentication data, including any component that connects directly to and/or supports this network. In that sense, CDE encompasses all components, systems, and processes in facilitating card transactions.
Who needs to be PCI Compliant?
The short version is: anyone who has control, however fleeting, of consumer credit card or personally identifiable information. Whether collecting credit card numbers to transmit to a payment gateway, placing details into a shared customer relationship management system, or storing card numbers in an encrypted database, all that sensitive information must be protected according to the specifics of the PCI-DSS standard.
Such entities include:
- Merchants include "any entity that accepts payment cards bearing the logos of any of the five members of PCI Security Standards Council" (PCI SSC, the organization that governs and enforces PCI DSS). Don't, however, let the term "merchants" fool you. The term applies as much to retailers selling t-shirts as it does to marketplace platforms facilitating payments between buyers and sellers.
- Third-Party Service Provider (TPSP or "service provider") refers to an entity—other than the Merchant, Acquirer, or Issuer—involved in storing, processing, or transmitting card data. These could include processors, gateways, and tokenization platforms, like Basis Theory.
Note: Issuers and acquirers (i.e., the financial institutions providing and processing cards), respectively, play critical roles in protecting the larger transaction ecosystem; however, in this blog, we'll focus on merchants, and the role played by service providers to help merchants.
What’s my responsibility for PCI?
Generally, if you’re coming into contact with cardholder data, it’s your organization’s responsibility to protect it and comply with all +300 PCI DSS requirements. However, the effort required to implement, maintain, and prove the necessary controls depends on your approach to managing the cardholder data and, as you’ll see in the next section, how many transactions you’re processing each year.
Today, most companies offset this effort by inheriting the compliance posture of their service provider, like Basis Theory. This can reduce a merchant’s PCI efforts to a couple of forms once a year.
What are the objectives and requirements of PCI DSS?
The current PCI DSS version (v3.2.1) consists of 6 objectives. The 12 top-level PCI DSS requirements in those objectives contain over 300 sub-requirements.
While the objectives help normalize the safety of cardholder and sensitive authentication data at a high level, the meat lies within these sub-requirements. These convey PCI’s expectations around securely storing, processing, and transmitting cardholder data and, thus, define what is compliant. Check out our quick dive into 12 PCI DSS requirements to learn more about each.
Note: PCI DSS is constantly evolving to account for new threats and needs in the market. For example, PCI v4.0 will go into effect in 2024.
Objective 1: Build and maintain a secure network
Merchants must establish and maintain a secure network to ensure a safe cardholder data environment (CDE). This objective outlines the requisite posture needed to do so. While some language may be outdated depending on your implementation (e.g., firewalls), the intent remains to maintain your network: to maintain the integrity of your network and secure the systems processing your card data.
Requirement 1: Install and maintain network security controls. Learn more about Requirement 1.
Requirement 2: Apply secure configurations to all systems. Learn more about Requirement 2.
Objective 2: Protect account data
Stored account data should be protected using tokenization, encryption, masking, and hashing technologies.
Requirement 3: Protect stored account data. Learn more about Requirement 3.
Requirement 4: Protect cardholder data with strong cryptography during transmission over open public networks. Learn more about Requirement 4.
Objective 3: Maintain a vulnerability management program
Computer systems and networks must be protected and kept up-to-date to minimize threats from getting a foothold in your environment. This includes maintaining a program to promptly identify vulnerabilities, update your systems, and properly run anti-virus measures.
Requirement 5: Protect all systems and networks from malicious software. Learn more about Requirement 5.
Requirement 6: Develop and maintain secure systems and software. Learn more about Requirement 6.
Objective 4: Implement strong access control measures
Enabling the security and utility of cardholder data is a tough balancing act. The PCI DSS drew inspiration from principles of least privilege and need-to-know in its attempt to minimize access to cardholder data by unauthorized parties.
Requirement 7: Restrict access to system components and cardholder data by business need-to-know. Learn more about Requirement 7.
Requirement 8: Identify users and authenticate access to system components. Learn more about Requirement 8.
Requirement 9: Restrict physical access to cardholder data. Learn more about Requirement 9.
Objective 5: Regularly monitor and test networks
The entity must constantly monitor and regularly test networks to ensure that all security measures and processes are in place, kept up-to-date, and functioning properly.
Requirement 10: Log and monitor all access to system components and cardholder data. Learn more about Requirement 10.
Requirement 11: Test the security of systems and networks regularly. Learn more about Requirement 11.
Objective 6: Maintain an information security policy
Securing data isn’t just system work. It’s also documenting, training, and adhering to best practices.
Requirement 12: Support information security with organizational policies and programs. Learn more about Requirement 12.
What are PCI Levels, and why are they important?
PCI levels provide stakeholders tiers to align, bucket, and assess merchants by the risk they pose to the larger ecosystem. Today, the industry uses the number of transactions as the primary risk indicator.
It’s important to note that the depth and breadth an organization must assess its compliance posture increases with each level. Understanding these Levels and their obligations will help you better evaluate your implementation and partner strategy with service providers and acquiring banks.
- Level 1: Processing over 6 million transactions per year
- Level 2: Processing 1 million to 6 million transactions per year
- Level 3: Processing 20,000 to 1 million per year
- Level 4: Processing fewer than 20,000
Note: Other contributing factors may determine an organization’s compliance level. For example, an acquiring bank may bump you to Level 1 based on previous non-compliance findings.
How do I prove PCI compliance?
Each year, a merchant is required to assess its compliance. The number of requirements that must be assessed and who assesses them depends on your PCI level and approach to implementation (i.e., using a service provider vs. building your own CDE). As you might have guessed, the surface area of an assessment increases with the number of transactions.
Aside from assessments, other obligations apply to merchants. So let’s take a look.
Conduct and report on Quarterly Network Scans
Who: All levels
A strong scanning program enables an organization to address security vulnerabilities on time without suffering extended damage (or being found out-of-compliance). It can also provide insight into any data security changes that need to be made to address the vulnerabilities present in the system. As such, PCI requires quarterly external and internal vulnerability scans of the cardholder environment.
External scans must be completed by an Approved Scanning Vendor (ASVs) while internal scans can be conducted by any tool.
Conduct a Penetration Test
Who: PCI Level 1
Penetration testing is an active process whereby the testers look for any security issues with your CDE that the ASVs may not or could not have identified. These penetration tests assist organizations in addressing vulnerabilities before attackers can exploit them.
PCI DSS Level 1 merchants must perform a penetration test at least once a year on their infrastructure. The findings of the test will be detailed in the penetration testing results.
Conduct Annual Compliance Assessments
Who: All levels
Yearly compliance assessments may be performed by a:
- Qualified Security Assessors (QSA): An independent, external, and certified PCI expert hired by merchants to assess their PCI environment and program. PCI requires QSAs for Level 1 merchants, but their use is optional for other levels.
- Internal Security Assessors (ISA): An in-house expert certified by PCI to conduct assessments of internal systems. Some acquiring banks may require an ISA for Level 2 assessments.
- PCI program lead: An individual authorized by the merchant to represent their compliance posture in Levels 2-4. This is typically someone in a security, compliance, technical, or leadership position.
Once completed, organizations submit their assessment to their acquiring bank or service provider.
There are two types of assessments. Let’s look at each.
Report on Compliance (ROC)
Who: Levels 1 (and occasionally 2)
Processing six million transactions poses significantly more risk to the system than a couple thousand. As such, PCI requires Level 1 organizations to submit themselves to an independent assessment by a QSA.
Some acquiring banks may also require a ROC (pronounced “rock”) for some PCI Level 2 merchants, especially if you’ve had recent security incidents or non-compliance findings.
After thoroughly analyzing your systems, documentation, and policies, a QSA compiles its findings into a ROC. Here, you’ll find a line-by-line assessment of your organization’s “compensating controls” (or lack thereof) against PCI’s over 300 requirements and sub-requirements. You must remediate or have compensating control for all findings to achieve a compliant or "passing" ROC before submitting it to your acquirer.
As you can imagine, preparing and facilitating an assessment and receiving your ROC can take months; however, there are partnerships between risk, compliance, and auditor partners that can help you reduce your time to PCI Level 1 compliance.
Self-Assessment Questionnaire (SAQ)
Who: Levels 2-4
If you’re processing less than 6 million, then you’ll typically evaluate yourself using one of PCI’s eight Self-Assessment Questionnaires.
The number of questions (i.e., time and effort) requiring answers varies depending on which SAQ form you’re eligible to complete. The form you’re eligible to complete, however, depends on how and where you store, process, or transmit card data. The more of the system “you own,” the larger the SAQ and the more questions you’ll have to self-assess.
For example, say you accept less than 6 million card payments each year online and use a third party (e.g., Basis Theory or Stripe) to collect and store payment information. In this case, you’ll likely use an SAQ A or SAQ A-EP and be sipping Mai Tais by the afternoon. If you’re handling cardholder data in your systems, you’re looking at an SAQ D and a war room with different internal stakeholders gathering evidence for a couple of weeks.
Like the ROC, you’ll very likely need to address any compliance gaps before sending in your SAQ.
Attestation of Compliance (AOC)
Who: All levels
The Attestation of Compliance (AOC) summarizes your assessment and its findings, thus, “attesting” to your current state of compliance. An AOC is primarily used to summarize and convey your adherence without having to showcase the details of your assessment to partners, vendors, and investors.
Costs associated with PCI compliance
Generically speaking, your implementation approach (i.e., in-house vs. service provider) informs your costs to build, while your PCI level informs your costs to assess PCI compliance—the cost to maintain falls somewhere in between those two factors.
Let's take a look at a few scenarios:
Scenario 1: If you're processing less than 6 million transactions and using a service provider, you may be eligible to complete an SAQ A. This could take as little as a few hours each year. As such, you should reduce your scope to SAQ A or SAQ A-EP for as long as possible.
Scenario 2: If you're processing less than 6 million transactions and aren't using a service provider, someone in your organization will need to address over 300 questions in your annual SAQ D. Gathering the evidence to support your compliance claims takes a large cross-functional effort with many teams involved.
Scenario 3: Let's dive deeper into the costs of PCI Level 1.
Costs associated with PCI compliance Level 1
Traditionally, when we think about "the cost of PCI compliance", we're thinking about Level 1 merchants.
Note: Level 1 merchants using a service provider inherit their vendor's existing compliance posture (i.e., its cardholder environment, quarterly scans, pen tests, configurations, etc.) and assessments, significantly eliminating prep efforts and reducing audit timelines (to as little as 21 days). Some QSAs, like Prescient Assurance, even offer discounts for approved service providers, like Basis Theory.
Cost to implement a PCI-compliant system
A CDE doesn’t build itself. Instead, organizations must purchase, implement, and configure the necessary systems to meet various PCI requirements and policies. Depending on existing resources and expertise, additional hires may be needed to stand these systems up in a timely manner.
Costs to maintain and assess PCI compliance
You'll need to draft, social, and track adherence to policies and procedures required by the PCI DSS. This is a deceivingly high cost in terms of time and effort. Luckily, companies like Secureframe can help here.
As for the assessments needed to prove and maintain compliance, a PCI Level 1 merchant will be responsible for much more than Level 2 through 4 counterparts.
- Annual penetration tests by an independent third party typically can cost anywhere between $15,000 to $50,000
- Quarterly scans typically run around $175 per IP address.
- QSA assessment represents the second or third largest price tag for Level 1 merchants (outside any personnel costs to build and support your systems). While your annual audit can become a well-oiled machine—especially if your QSAs are familiar with your business and architecture—most engagements cost organizations between $20,000 to $500,000 and can take up to 8-10 weeks to complete. This doesn’t account for the internal cross-functional time and effort required to gather evidence and facilitate the assessment.
Read our in-depth post about the costs of maintaining PCI compliance.
Opportunity costs of PCI compliance
While hardest to calculate, "what you weren't able to do" is likely one of the most costly components of a PCI program. Building, maintaining, and assessing your system requires time and money that could’ve been allocated to differentiating your product, improving customer support, or unlocking that new partnership.
Risks of PCI DSS non-compliance
The PCI SSC created the PCI DSS as a proactive measure to protect cardholder data and a legal framework to isolate and financially penalize non-compliance.
By outlining and getting you to agree to these requirements contractually, PCI DSS has made non-compliance one of the most costly and inescapable forms of non-compliance.
Increased compliance burden: As discussed, networks and banks frequently add additional requirements to companies deemed out-of-compliance, meaning a Level 2 merchant could now have the burdens of a Level 1. This can significantly increase the cost of your compliance for years to come.
Increased processing costs: It’s important to remember that your payment partners have compliance requirements and responsibilities themselves. So reviewing your PCI assessment helps them better understand the risk you pose to them as a Merchant. Findings of non-compliance or a recent security incident may shift your risk profile. To offset this risk, acquiring banks may charge more to do what they were already doing or require you to purchase additional precautionary products or services.
Financial penalties: If your organization is non-compliant, the card networks can impose penalties on your acquiring bank. Naturally, your bank will turn around and impose those penalties on you.
Based on severity and duration of non-compliance, as well as your level. Typically, these monthly fines range from around $5,000 to $100,000. If an actual data breach does occur, companies can also expect fines for anyone whose data has been breached or has been affected in some way by a data breach. The fines range from $50 to $90 per cardholder.
Vulnerable systems: As onerous and slightly outdated as they are, PCI DSS’ objectives and requirements represent some of the most well-known and proven security practices. Failing to meet these requirements places you out of compliance and makes your organization more vulnerable to internal and external threats.
Lost revenue: While customers may not hear about the gaps in your most recent ROC, they will likely hear about any security incident involving their cardholder data. This loss of trust often leads to near-term and possibly long-term losses in revenue.
It’s also important to note that in the B2B space, it’s also common for prospective customers to request a copy of your AOC.
Legal action: Breached organizations subject themselves to expensive litigation from impacted customers, cardholders, and banks. To compound the problem, the PCI DSS and its yearly cadence provide litigators with a convenient artifact from which to identify incongruences and establish timelines, making it easier to prove negligence and increase payouts to those affected.
Roadmap risk: Organizations must remediate gaps quickly once found to be non-compliant. Depending on the size and state of your information systems, this could take anywhere from weeks to months or even years to correct.
How do I reduce the cost of my PCI compliance?
While the price tag around PCI compliance is hard to calculate, decreasing the impact and cost on your organization is fairly simple: reduce or eliminate scope.
What is PCI scope, and how do I reduce it?
PCI scope refers to the depth and breadth of cardholder data in a given system. When we “reduce or eliminate PCI scope,” we remove cardholder data from the systems, processes, and people. In doing so, we decrease the surface area of PCI compliance and, thus, the costs, risks, and distractions associated with assessing it.
The challenge comes in reducing scope while maintaining day-to-day operations.
Over the years, many payment service providers, like Stripe, have helped businesses accept payments online and significantly reduce PCI scope. By using its embeddable iframes, compliant cardholder environments, and built-in processes, customers isolate the PCI DDS data to their payment service providers’ cardholder environment for safekeeping.
Unfortunately, what you can do with that data is usually limited to processing card transactions with that payment service provider. What if you want to add a new processor or a partner (and their processor)? What if you need to share card insights with your fraud, risk, or support teams? What if you want to collect cardholder data from a third party?
When you use a payment service provider, you’re reducing scope at the expense of your data’s utility. Thankfully, a new type of service provider, called a tokenization platform, allows merchants to decouple the tokenization service from PSPs, providing merchants their own CDE and a host of developer tools to interact with payment information like it’s their own.
The Best Way To Achieve PCI Compliance
Thinking about the purpose of PCI-DSS more than the strictures of its requirements - the best, safest way to eliminate both resource drain and business risk is to take control of as little PII as is possible, while maintaining control of the transaction processing mechanism.
The simplest example is to use a full-service processor, which provides forms to collect PII (so it never hits the merchant’s systems in plain form), stores credit cards separately from the merchant, and executes all transactions without ever revealing protected sensitive data. While this certainly dulls the risk of data breaches - as the data is never in the hands of the merchant - it also limits the flexibility of the payment system: with all PII stored at the processor, there is no option to negotiate rates, spread transactions across multiple gateways, or apply comprehensive payment optimization strategies.
The most effective way to gain the risk-reduction benefits of being PCI Compliant, while maintaining the flexibility to automate payment processes, is to use a tokenization provider like Basis Theory. In this instance, Basis Theory provides the forms to collect PII, securely stores all PII in our secure vault, and provides tokens to the merchant to use to initiate transaction - much like the full-service payment processor. However, as Basis Theory does not provide any of the downstream services, the merchant is free to contract with as many, or as few, processors and gateways as make sense for their business - allowing for cost reductions through arbitrage, as well as improved transaction success rates by forwarding transactions to locally-located services.
