The Path to PCI Compliance

If you're starting a business that accepts credit cards online, my direct experience doing this very thing may provide helpful guidance as you navigate the requirements of PCI compliance.

A number of years ago I was working on a product that enabled groups of people to communicate with one another and collaborate as a community - let's call it "AwesomeGroups". We began to think there could be a revenue stream in features that allowed clubs and associations to collect membership dues or other monies. Here is what we thought we needed:

1. Money should flow into the association's bank account.
2. Members must be able to use credit cards.
3. We would host the payment flow ourselves.
4. Credit cards had to be stored to enable recurring payments.

We looked at PayPal, Amazon Payments, and the like. None of those solutions were capable of helping us fulfill our plans. So we dove deeper into the details of collecting and storing credit cards, connecting to various payment gateways, and keeping track of all the transactions. 

While there were many challenges we began to perceive, the one that concerned us the most was the collection and storage of credit cards. The costs of meeting the Data Security Standards of the Payment Card Industry were difficult to quantify. Everything we were reading led us to believe we would have to rethink every aspect of our system, including a move from our cloud host to a high security data center!

Missing the Forest for the Trees

The idiom "missing the forest for the trees' ' captures well the sense of what I experienced on that project. There were so many details surrounding PCI compliance that we had missed the point of it all! AwesomeGroups already had a custom payment form on it. Credit card information was sent to our servers, then forwarded to Authorize.net for storage and recurring billing of the monthly fees the associations paid to use the application. 

Somehow, we came away from our research with no idea that we had already placed ourselves in a position requiring us to be compliant with the PCI Data Security Standards! The fact that escaped me then may be perfectly clear to you: if any part of your systems ever sees a credit card number, you are responsible for ensuring those solutions are compliant with PCI DSS. Credit card numbers are like gold, and the systems that request them and move them are like armored trucks - high value targets for the criminally minded. 

There may be mechanisms in your system which represent the weakest link in a chain of transacting. All a hacker needs to do is compromise your system and send to himself a copy of every credit card your program forwards to Braintree. You may never know it's happening because you've done little to prevent it and nothing at all to detect it! Perhaps you're looking for the perspective I wish I'd had at the beginning of my research. The goal of this post is to help you step away from the trees and have a look at the forest.

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:

1. 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.
2. 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).
3. 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. 
4. 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. 
5. 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.
6. 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.
7. 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. Scope refers to 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. AwesomeGroups, if it had become a service provider to associations which wanted to accept dues from members, could have used Spreedly to store and process the cards, limiting its 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: http://itrevolution.com/pci-scoping-toolkit/

Levels 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:

1. 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.
2. 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. 

We have a table showing the compliance levels on our site where you can see that levels are determined by the scale of transaction activity in a business. Small online merchants processing 20,000 or fewer transactions per year are considered to be level four (L4) businesses. A large merchant clocks in at 6 million or more transactions per year, making them a level one (L1) business. 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 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 may be 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. 

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. 

I can tell you from our experience at Spreedly, when I last looked at the search results, $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.

Conclusion

I can see in retrospect that we were right to be very concerned about the cost of implementing credit card storage solutions in AwesomeGroups. I'd like to think this post would have helped us to quickly understand what our responsibilities were as well as expose us to terminology that would have helped us imagine creative solutions our business could afford. We could have integrated with a PAN tokenization service like Spreedly, dramatically reducing our scope, thereby affording the opportunity to really explore the viability of the features we wanted to build.

‍

Download the PCI Compliance eBook Below