It’s hard to argue the role PCI compliance plays in today’s digital economy.
Today, the framework introduced in the early 2000s outlines 12 PCI requirements that merchants must satisfy to process credit card transactions on the card networks. By outlining, defining, and enforcing standards for storing, processing, and transmitting cardholder data, the Payment Card Industry Security Standard (PCI DSS) gave organizations a security framework that brought trust and commerce to the internet.
Failure to meet these standards could result in fines or bans as a merchant or service, rendering you unable to process payments or send payment data with the major networks.
Nearly 20 years later, with more than 300 requirements and sub-requirements, PCI DSS continues evolving. Today, more merchants are becoming PCI DSS compliant despite not having the prerequisite volume to necessitate it. Why? Achieving PCI compliance, especially Level 1, tells a powerful story to the market: you take your data and its security seriously.
So, while you may not need PCI Level 1 compliance, understanding the different levels of PCI compliance and the 12 PCI requirements will certainly help.
What are PCI Compliance Levels, and why do they matter?
PCI Levels allow organizations to understand and determine their reporting requirements when processing credit card payments. PCI Levels vary by card brand but are generally determined by an organization’s current or projected annual card transaction volume. As the number of transactions rises, so do the requirements for establishing and maintaining compliance.
Here are Visa's merchant levels as a frame of reference:
- PCI Level 4 Compliant: Less than 20,000 transactions per year.
- PCI Level 3 Compliant: Between 20,000 and 1 million transactions per year.
- PCI Level 2 Compliant: Between 1 million and 6 million transactions per year.
- PCI Level 1 Compliant: Over 6 million transactions per year.
Those qualifying for Level 4 compliance have a smaller compliance scope, while PCI Level 1 has the largest. The larger the scope, the more obligations (and the more compliance will cost.)
For example, PCI Level 1 requires an annual Report on Compliance (ROC) from an independent Qualified Security Assessor (QSA). The report evaluates an organization’s program against the 12 requirements and 300+ sub-requirements.
On the other hand, organizations with Levels 2, 3, or 4 use Self-Assessment Questionnaires (SAQs) to audit their compliance program.
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 that is collecting credit card numbers to transmit with a payment gateway, placing details into a shared customer relationship management system, or storing card numbers in an encrypted database—all of this 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.
Generally, if you’re coming into contact with cardholder data, it’s your organization’s responsibility to protect it. However, the effort required to implement, maintain, and prove the necessary controls depends on your approach to managing the cardholder data and the number of transactions being processed 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 requirement efforts to a couple of forms once a year.
Cost of PCI Compliance
Your implementation approach will differentiate the cost of PCI compliance. Deciding between maintaining PCI compliance in-house vs. using a service provider.
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.
Traditionally, when we think about "the cost of PCI compliance," we think about Level 1 merchants.
Note: Level 1 merchants using a service provider inherits 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.)
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 set these systems up in a timely manner.
Costs to Maintain and Assess PCI Compliance
You'll need to draft, socialize, 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, checklists or companies like Secureframe can help.
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.
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.
Risk of Non-Compliance
Each PCI requirement acts as a proactive measure to protect cardholder data, and as a legal framework to isolate and financially penalize non-compliance.
Typically, these 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.
Other types of penalties include:
- 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.
- 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.
While the price tag around PCI compliance is difficult to calculate, decreasing the impact and cost to your organization can be done by reducing or eliminating PCI scope. 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 DSS 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?
Using a payment service provider reduces scope at the expense of your data’s utility. Thankfully, a new type of service provider, called a tokenization orchestration 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.
Overview of the 12 PCI DSS Requirements
With so many paths and considerations to securing your data, familiarizing yourself with the spirit of the 12 PCI DSS requirements serves as a primer to modern data security strategies.
1. Install and maintain a firewall configuration to protect cardholder data
Card data is inherently more valuable than most data; thus, organizations must segment it away from other pieces of information in a system. In doing so, organizations create a Cardholder Data Environment (CDE). The CDE provides organizations and assessors with clear blue lines and a solid foundation to build the other 11 requirements.
Identifying all the data and systems using card data is the first step. To create a CDE, PCI requires a combination of firewalls and network segmentation to control the transmission of cardholder data between an organization’s networks (internal) and untrusted ones (external). In addition, documenting configurations, settings, and policies ensures future compliance for the CDE.
Learn more about PCI DSS Requirement 1.
2. Do not use vendor-supplied defaults for system passwords and other security parameters
Bad actors, which could be individuals or software programs, love out-of-the-box system configurations, like default passwords, wireless environments, and unnecessary functionality. If left, organizations open themselves to fairly predictable and practiced attack vectors that hackers can exploit at a relatively low cost.
PCI helps by outlining some standard best practices to follow. These include, but are not limited to, changing passwords and disabling default accounts before implementation, using hardened industry configuration standards, and consistently enforcing preventative policies, like vendor reviews.
Learn more about PCI DSS Requirement 2.
3. Protect stored cardholder data
Both organizations and bad actors want to use the card numbers. While capturing this information can happen in transit (see: #4), most of all, data spends 99.9% of its life on your servers in an “at-rest” state.
PCI DSS outlines many requirements on how organizations must protect their data when not in use, but encryption is one of the most popular methods.
Data encryption uses math to convert plaintext values—like the 16-digit personal account number (PAN) on your card—into ciphertext, an unrecognizable jumble of characters.
Instead of storing the PAN in plaintext, organizations store it as ciphertext. So, even if an intruder were to gain access to the CDE and take all the encrypted data, they’d be unable to view it. To decrypt the ciphertext back into plaintext, an actor must use a unique cryptographic key. To ensure the keys themselves aren’t compromised, PCI provides guidance for key management (generation, storing, TTL, retirement, etc.) and also requires organizations to document, and adhere to their encryption key management policy.
Another popular approach, data tokenization, complements encryption and helps address some of its developer challenges. Unlike encryption, tokenization creates a net new value, called a token. With the right tokenization provider, organizations can use tokens to simultaneously leverage part or all of the underlying data without bringing a system into scope. This allows the sensitive data to stay encrypted and secured at rest.
Learn more about PCI DSS Requirement 3.
4. Encrypt transmission of cardholder data across open, public networks
Bad actors commonly target public networks to intercept card data. To prevent this, PCI mandates some security requirements to be in place when transmitting data, such as maintaining data encryption standards and up-to-date certificates.
Scaling encryption is extremely difficult and risky for developers. To automate this process, reduce risk, and maintain compliance, many tokenization providers, like Basis Theory, manage data encryption as part of their services.
Learn more about PCI DSS Requirement 4.
5. Maintain a Vulnerability Management Program
Bad actors have many tools to help them compromise systems, including malware and viruses. Therefore, PCI requires anti-malware and anti-virus software to be deployed on almost all systems and be updated, run, and evaluated frequently.
Learn more about PCI DSS Requirement 5.
6. Develop and maintain secure systems and applications
Bad actors prey on organizations unable to maintain their data security posture during its software development and data lifecycles. It only takes one weak link, like a missed system patch, for a bad actor to harm a system.
Taking a holistic approach to the Software Development Lifecycle (SDLC) security is key. To do this, PCI requires organizations to document their patching, software delivery, and data lifecycles.
This allows organizations to create internal policies, processes, and standards at different touchpoints, ensuring proper preventative measures are met and routinely updated. PCI additionally provides requirements and guidance around separating development and production environments, change management procedures, and common application vulnerabilities.
Pro-tip: Use external guidance, like OWASP’s top 10 to help identify and prioritize common threats during different stages of the software development lifecycle.
Learn more about PCI DSS Requirement 6.
7. Restrict access to cardholder data by business need to know
Like in the real world, only authorized personnel should access all or part of the card data. Of course, this is easier said than done with the proliferation of data in today’s organizations.
Without it, however, bad actors have many threat vectors to exploit.
Role-based access controls (RBAC) and other models satisfy PCI’s requirement by ensuring actors only have access and visibility to the sensitive data and systems they need to do their job. In addition, limiting access to those with legitimate business reasons helps an organization prevent mishandling of cardholder data through inexperience or malice.
Learn more about PCI DSS Requirement 7.
8. Identify and authenticate access to system components
Bad actors can appear as good actors in any system. Also, and not to complicate matters, good actors can turn bad or simply make mistakes. Understanding who did what and when helps prevent and remediate incidents.
To do that, PCI requires system administrators to assign unique identifiers (i.e. user accounts) for each actor with access to the CDE. When combined with logging (#10), this identifier creates the data trail needed to help remediate an issue, identify the threat vector, and much more. PCI additionally outlines requirements for user management procedures and rules.
Another precaution worth highlighting is the use of multi-factor authentication (MFA). Authentication confirms an actor’s identity to another system through trusted secret handshakes—the more unique steps in the handshakes, the stronger the security.
Learn more about PCI DSS Requirement 8.
9. Restrict physical access to cardholder data
Poor physical safeguards provide bad actors with another vector to capture data. The scope includes digital, like disks; analog, like scratch paper; or physical areas where card account data is stored, processed, or transmitted, like data centers.
PCI outlines a handful of sub-requirements for organizations to use when creating internal controls and policies, from system access controls (see #8) to visitor logs and device management to the destruction of materials.
Learn more about PCI DSS Requirement 9.
10. Track and monitor all access to network resources and cardholder data
As you might’ve guessed, most of these requirements build on top of or fold into each other. Number 10 is no exception.
By creating clear blue lines around your cardholder environment (#1) and identifying the who, what, when, where, and how data is being accessed (#7 and #8), we can track and monitor activities critical to preventing, detecting, or minimizing security risks to card data.
The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Without system activity logs, determining the cause of an incident is very difficult—if not impossible.
Learn more about PCI DSS Requirement 10.
11. Regularly test security systems and processes
Bad actors constantly probe high-value targets for weaknesses, frequently simulating normal-looking activities or actors on networks.
To prevent compromise, PCI DSS requires regular software testing of known weak points in your systems and training of employees that regularly interface with sensitive data. This includes but is not limited to network scans, intrusion detection systems, and external penetration testing. Together, these contain and identify threats that might otherwise slip through unknowingly.
12. Maintain a policy that addresses information security for employees and contractors
Most companies don’t see sensitive data, like card data, as a value-driving asset needing investment. To most, it’s a risk to be managed with the bare minimum done to protect it. Bad actors exploit bad security cultures.
While the final PCI requirement may seem rigid, it plays a vital role in creating an organization's security culture. What is sensitive data? What should we do? An appreciation for security is one of the best defensive measures an organization can take.
Achieving 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 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, your PCI compliance go-live checklist is handled by Basis Theory—providing the forms to collect PII, securely storing all PII in a secure vault, and providing tokens to initiate transactions, 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.
Reduce your PCI Level 1 scope by nearly 90%. Check out our developer docs or talk to an expert today.
