The Master Guide to PCI Compliance

What is PCI Compliance?

PCI compliance is a set of security standards that must be met by any business that carries out payments or other transactions using credit card data.

The standards of PCI compliance are set and enforced by the Payment Card Industry Security Standards Council, or PCI SSC for short. These standards set forth by the PCI SSC evolve alongside the payments industry to reflect changes to digital payment systems and their security needs. As such, businesses must provide documentation and proof of PCI compliance every 12 months.

Why does PCI Compliance matter?

Although PCI compliance is not technically required by law, it is still considered a mandatory process since all major card brands (Visa, MasterCard, Discover, etc.) require this type of compliance for merchants who sign on with them for payment processing.

Do I Have to Get PCI Certified?

If you accept credit or debit cards from your customers then, yes. Any business that transmits, stores, handles, or accepts credit card data — regardless of size or processing volume — must comply with the PCI DSS Standards. The level of compliance required depends on your business specifics.

Many gateways and online payment processing solutions will claim their drop-in credit card widgets exclude you from PCI compliance or make you PCI compliant. What these type of solutions do, including Spreedly's, is reduce your compliance burden. You still have to certify, but can often do so with much less effort than if you were processing and storing the card data yourself.

Who's Who

There are a number of entities involved in the processes that make the credit card payment ecosystem function. In the pursuit of understanding the world of PCI DSS, here are the most relevant:

Merchants are people who sell stuff they make or services they provide. Most of them believe that they must take payment in forms other than cash. In the modern world, that means they must accept credit cards.
Card Associations are known by brand names like Visa and Mastercard. These are networks of banks that issue credit cards (issuing banks) to customers and banks that provide merchants with the ability to charge a customer's credit card (acquiring banks).
Cardholders are customers who want to buy things from merchants. It's super convenient to use a credit card. Cardholder data is the primary account number, cardholder name, expiration date and service code (CVV). Add in the sensitive authentication information there is a lot of data to ensure is safely handled. Ultimately that is the goal of PCI DSS - to ensure data is secure.
Service Providers are the companies that provide card storage or processing products and services, whether to merchants or cardholders. Spreedly is a service provider, as are other companies such as Stripe. Payment gateways are service providers. Any company that makes Point of Sale systems (NCR, IBM) is a service provider.
Payment Application Developers and Integrators build and deploy hardware and software systems that merchants purchase to facilitate transactions using credit cards. These fall under the Payment Application Data Security Standard (PA-DSS). Merchants are encouraged to adopt solutions by these approved vendors, thereby easing their compliance burden.
The Security Standards Council is made up of 5 major card associations. The council has produced the Data Security Standards as the representative requirements placed upon any other interested parties which process, store, or transmit credit card data, including companies that make hardware and software components for those purposes. In other words, they tell merchants, hardware manufacturers, application developers and integrators, and service providers what it means to secure the data owned by the card associations.
Approved Companies are the organizations and people certified by the Security Standards Council to be expert in some aspect of bringing about the plans and verifying the implementations of the Data Security Standards. These folks know how to audit and test systems that process, store, or transmit credit card data.

Spreedly is a service provider. Our platform interacts with payment gateways, which are service providers themselves, and must be PCI compliant. We are level one (L1) compliant, which means we have obtained the highest level of compliance based on the requirements set forth by the Security Standards Council, and we have engaged approved companies to assess our systems and provide regular scanning services. We are not considered a payment application developer or integrator because the solution we provide is not installed in an environment out of our control.

Scope

Scope refers to all of the components in your system that are subject to the requirements of the Data Security Standards. Including the collection of components - computers, routers, switches, physical or virtual - that process, store, or transmit cardholder data, known as the cardholder data environment, or CDE. Understanding scope when you begin to implement your solution is the same as buying an ounce of prevention. It is possible to build systems that cost substantially more under PCI DSS than others. More importantly, misunderstanding scope can lead to components which do not undergo proper care to protect your customer's data. If you have one computer serving a single HTML page, and that page contains a link to an offsite payment page, your scope is very small. You need only show that this single computer meets the requirements of PCI DSS.

Imagine three networks comprising 20 computers which are somehow involved in the storage, processing, or transmission of card data - databases, log aggregators, application servers, load balancers, and more. If your system requires these components in order to implement the necessary cardholder data flow of your business, there's not much you can do to reduce the scope. On the other hand, you can expand your PCI compliance scope unnecessarily by:

Granting access to the CDE to persons who do not need it. This would include anyone who is not responsible, in some way, for maintaining the components of the CDE.
Connecting components to the CDE that are not at all involved in the cardholder data flow, but grant access, in some form, to in-scope components. These systems must be as secure as any other in the CDE, and they will need to be maintained in a similar fashion.
Running unrelated software on in-scope components. These applications will undergo scrutiny, and they may expand the pool of people who have access to the CDE unnecessarily.

Every system can implement choices that dramatically increase or reduce its PCI compliance scope.

Both merchants and service providers can reduce their scope by outsourcing some aspects of their system to a PCI DSS compliant service provider. Merchants can use Spreedly to store and process the cards, limiting PCI scope to the HTML page that presented the credit card form.

Again, the application would still be subject to PCI compliance requirements, but the validation of its compliance would be a much easier task. As you become more acquainted with the DSS, you'll agree that limiting your scope by having as few components as possible handling card data is a good thing, both in terms of reducing the risk of breach as well as the costs of maintaining PCI compliance. Check out this helpful guide as you further evaluate your scope concerns.

How do I get PCI certified?

PCI certification takes two forms: Self-assessment (i.e. do-it-yourself) or hiring a third party QSA (Qualified Security Assessor). Though there are obvious advantages to self-assessing, including effort and cost, your ability to self-assess is dependent on your annual transaction volume and is reflected in the resulting level of PCI certification (1-4) you attain.

The table below describes the relationship between your transaction volume, required assessment approach, and level of certification:

Note: While PCI DSS outlines the requirements to become certified, there are subtle differences across payment networks (the table above was created from the Visa merchant guidelines). It is ultimately up to your merchant/acquiring bank to determine what is required for your compliance. Please be sure to check with them before beginning the compliance process.

Levels of PCI Compliance

The level of PCI compliance a business must meet depends on their transaction volume.

Level 1: 6M+ transactions per year

Level 2: 1M-6M transactions per year

Level 3: 20K-1M e-commerce transactions per year

Level 4: Up to 20K e-commerce transactions per year OR 1M transactions in a year

Your transaction volume should inform you of your level, which will in turn direct you down the path to assessing your compliance with PCI DSS. However, note that according to the documents from the Security Council, only the acquiring financial institution can assign a validation level to merchants.

If you're a merchant, before you invest a lot of time on a particular path, it is wise to ask your acquiring bank what level they assign to your business. Service providers may not have an acquiring bank and will simply work from transaction volume to choose the path to take. L1 merchants and service providers must engage a QSA. While this is an expensive proposition, as it involves a lot of time and communication, you may be able to see why the card associations believe it's a good idea to have someone validate your claim to be protecting all their gold!

L2 and L3 merchants may need to do the same, according to the requirements of their acquiring bank. For instance, there may be certain types of businesses which represent a greater perceived risk of breach, or a business has failed to protect data in the past and must now be subject to greater accountability. However, many L2 and L3 merchants may self-assess, using the appropriate SAQ. All L4 merchants can use a SAQ. There are a variety of Self Assessment Questionnaires because there are a variety of processing models.

We would encourage you to read the guide provided by the Security Council, designed to help merchants determine which SAQ to use.

SAQ A vs. SAQ A-EP: What is the Difference?

Version 3 of PCI DSS introduced a new SAQ, the SAQ A-EP. How your payment page is handled is a key factor in determining which SAQ is appropriate for your organization.

How does SAQ A-EP compare to SAQ-A? The following table provides a high-level overview of some of the key similarities and difference between SAQ-A and SAQ A-EP:

Source: https://www.pcisecuritystandards.org/documents/Understanding_SAQs_PCI_DSS_v3.pdf

The iFrame Middle Ground

A major impact of PCI DSS 3.0 was the somewhat quiet indication that the use of an iFrame approach allows a merchant to successfully qualify for a SAQ A (somewhat quiet because this information was released in a supplement published shortly after 3.0 came out).

Proper use of an iFrame became a middle ground between a URL Redirect and a Direct Post approach.

At the time, Spreedly responded quickly to launch an iFrame. Our goal was to give customers as much design freedom as they had before with our Direct Post while ensuring our approach was secure and allowed certification under PCI SAQ A. We did a pretty good job, too, both in terms of speed to market and quality of offering. We have a group of customers today whose primary driver for using Spreedly is to use our iFrame with their legacy gateway, which either doesn't have an iFrame offering or does but our customer prefers our approach.

The difference in amount of work between the PCI SAQ A and the SAQ A-EP is significant. For merchants that want to avoid the more arduous requirements of SAQ A-EP, there are benefits to using an iFrame over the Direct Post or Javascript methods. And based on feedback from Spreedly customers who use our iFrame, namely the ease and flexibility with which it allows them to customize their payment page, we don't see the benefit in using a Direct Post or Javascript method over the iFrame.

For more information on our iFrame solution check out the this blog post.

Cost of PCI Compliance

What most merchants and service providers really want to know when they get started is how much it's going to cost to achieve and validate PCI compliance. This is a function of both scope and the path of assessment as both of these factors impact nearly every other aspect of the cost, whether by increasing the number of components that need to be analyzed or the number of people involved. There's no easy answer to the question of cost because no two businesses are the same, whether you look at their business model, management team, technology team, or current systems. The best you can do at cost estimating, until you develop a record of compliance expenditures in your business, is ask Google.

Search results suggest that $225,000 for L1 compliance is not unrealistic. Don't forget, these are not one-time expenses. PCI DSS requires ongoing maintenance and annual re-scoping and re-assessment. Even small merchants, which must purchase and operate certified equipment in a compliant environment, can see costs far exceeding their expectations.

Providing Proof of PCI Compliance

Achieving PCI compliance is the work of building a secure system with the smallest scope necessary. Assessing compliance, or validating compliance, can be accomplished through one of two paths:

Complete a Self Assessment Questionnaire (SAQ). Someone in your business who understands the scope and implementation of your system will be a key player in doing this well.
Engage a Qualified Security Assessor (QSA). These approved companies will figure out what is in scope, review the configuration and authentication controls of components, and interview people. They produce a very detailed Report on Compliance (ROC), which is intended to demonstrate the extent of their audit, recording their findings.

In either case, you will sign an Attestation of Compliance (AOC). This is a sworn statement that, to the best of your knowledge, your business processes, stores, or transmits cardholder data in a way that is 100% compliant with PCI DSS. Which path should you take? PCI compliance levels are not a measure of degree of compliance, but a guide to the path you must take to assess your compliance with PCI DSS.

Key Objectives and Requirements for PCI Compliance

To be considered PCI compliant, businesses must meet 12 key requirements encompassing hundreds of sub requirements and test procedures to demonstrate compliance. The requirements and test procedures for PCI compliance are designed to achieve six main objectives to help protect cardholder data:

To build and maintain secure transaction networks and systems
To protect cardholder data
To maintain a vulnerability management program
To implement strong access control measures
To regularly monitor and test transaction networks
To maintain a consistent information security policy

There are 12 requirement categories:

Implementing and maintaining firewalls to prevent unauthorized access to private information
Employing appropriate password protections, such as a secure device inventory and regular password changes
Protecting cardholder data, primarily through encryption processes
Encrypting all transmitted cardholder data
Utilizing antivirus and anti-malware software on all devices that interact with primary account numbers
Embed security into all systems and software development practices
Restricting access to cardholder data on a “need to know” basis
Assigning unique IDs to anyone with access to cardholder and transactional data
Restricting physical access to cardholder data by storing it in a secure, locked physical location
Creating and monitoring access logs for all activity involving cardholder data
Scanning and testing security systems for vulnerabilities regularly
Maintain a strong security policy that is accessible to all personnel

What’s next in PCI / PCI 4.0

To meet the challenges posed by an ever-evolving threat landscape and increasingly sophisticated attacks targeting payment card data, the PCI SSC continuously evaluates, updates and improves the PCI DSS. These efforts result in periodic updates, both minor and major, to the PCI DSS, the latest of which being the release of PCI DSS version 4.0 (v4.0) on March 31, 2022. According to current timelines set forth by the PCI SSC, PCI DSS v3.2.1 will be officially retired as of March 31, 2024, after which all entities required to comply with PCI DSS will need to be compliant with and assessed under PCI DSS v4.0.

In recognition of the potential complexity and cost associated with implementing some of the new requirements, a subset of requirements in the v4.0 standard is future-dated. The future-dated requirements are identified within the standard as security best practices until they need to be in place by March 31, 2025.

Changes can be summarized into four high-level categories.

New or updated technical controls in recognition of technological advancements
Controls about the direct protection of cardholder data (CHD)
Process maturity
Continuous PCI DSS compliance and program management

For more information on these changes see our recent blog post and PCI DSS 4.0 Resource Hub

How can Spreedly Help?

All online merchants that accept credit card payments must be PCI compliant. By leveraging a secure PCI Level 1 card vault, merchants can significantly reduce their PCI scope and help avoid costly and time-intensive, on-site data security assessments.

Staying on top of constantly changing payments regulations like PCI DSS v4.0 is difficult. Payment orchestration solutions like those offered by Spreedly, help merchants to minimize the effort and risk that comes with regulatory burdens. We stay on top of the latest requirements, building support into our platform. That lets our customers focus on their core business functions as well as delivering a great customer experience and meeting their revenue goals.

It is important to note that each merchant has its own unique needs. This means that there may be additional steps you must take based on your specific situation to ensure PCI DSS compliance.

We’re here to help. Interested to learn more about how Payments Orchestration can help ensure your organization is compliant? Reach out to our team here.

When evaluating your compliance, keep the following in mind:

What level of compliance you need is determined by your merchant bank, informed by the number of annual transactions you are processing.
Self-assessing is less costly and time consuming, but is only an option for online merchants seeking less than a PCI Level 1 certification.
If self-assessing, using a PCI compliant service provider that provides an iFrame where all page content is from the PSP or hosted payment page results in the least compliance burden.
An AOC, together with a quarterly scan, is your proof of PCI compliance.

Good luck out there!

If you are a merchant that accepts payment cards, you are required to be compliant with the PCI Data Security Standards. Get more information here: https://www.pcisecuritystandards.org/merchants‍
See "What types of e-commerce implementations are eligible for SAQ A-EP vs. SAQ A?" from https://www.pcisecuritystandards.org/documents/Understanding_SAQs_PCI_DSS_v3.pdf

‍

Download the PDF Version of The Ultimate Guide to PCI Compliance below

‍