If you’ve been contacted by your bank or financial institution lately only to discover that your credit card information has been compromised, then you’ve felt the growing frustration many consumers face today. The situation with respect to credit card fraud is only getting worse.

Dealing with a compromise is a time-consuming hassle from a consumer’s perspective; particularly because many of us maintain large numbers of (supposedly secure) personal online profiles that afford us a convenient way to deal with recurring monthly or annual payments.

How can we be sure that these online service providers, who so readily accept and retain our credit card information, are taking the appropriate measures to secure it?

This is the purpose of PCI DSS –– and every retailer is required to comply. Depending on the ecommerce technology and backend a retailer uses, and how their payment systems are architected, PCI compliance can be an easy check on a long list of things retailers need to do to ensure their customers are transacting securely, or it can be a big pain –– costing ample time, resources and money.

In this guide, you’ll learn what PCI DSS is, how to achieve it for your business and how your ecommerce backend plays a large role in your required effort.

What is the PCI DSS?

The PCI Security Standards Council (PCI SSC) defines a series of specific Data Security Standards (DSS) that are relevant to all merchants who accept credit card, regardless of their revenue and annual credit card transaction volumes.

Achieving and maintaining PCI compliance is the ongoing process an organization undertakes to ensure that they are adhering to the security standards defined by the PCI SSC.

The SSC defines and manages the standards, while compliance to them is enforced by the credit card companies themselves. Again, these standards apply to all organizations that deal with cardholder data.

The PCI DSS breaks account data into two separate categories.

Cardholder data includes: the Primary Account Number (PAN), Cardholder Name, Expiration Date and Service Code.

Sensitive Authentication Data includes: Full track data (magnetic-stripe data or equivalent on a chip), CAV2/CVC2/CVV2/CID, and PINs/PIN blocks.

Credit Card Security: A Neglected Subject in Many Organizations, Including Large Enterprise Establishments

Jasper Studios provides ecommerce development services to omnichannel retailers both large and small and, as such, we have seen every kind of credit card storage transgression imaginable.

We’ve witnessed cardholder data stored in plain text files without any encryption or basic obfuscation residing under the CFO’s desk in a dusty PC dating back to the late 1990’s –– all freshly captured from an insecure payment gateway in a homegrown ecommerce platform. Could my credit card number have been stored in that dusty old PC? Was yours?

This sort of practice is plain negligence. Fortunately, however, this isn’t a practice undertaken by most organizations, and when done so, it’s typically caused by unintentional ignorance on the subject. But, these sorts of horror stories still persist today. No wonder so many of our credit cards have been or eventually become compromised.

It’s not just smaller organizations that can have deplorable standards for data security. In 2005, Wal-Mart had a serious security breach targeting their point-of-sale systems. An earlier internal audit revealed thousands of customer card numbers and other personal data had been found on their servers in unencrypted form. This data may have been compromised during the breach, although that has not been officially confirmed.

More recently, in 2013, U.S. retail giant Target Corporation was hacked –– a staggering 40 million credit and debit card numbers were stolen from their network. If this can happen to some of the world’s largest retailers, it can certainly happen to smaller ones, too.

Do I need to ensure PCI Compliance for my organization?

If you operate your own on-premise or self-hosted cloud commerce solution, then the short answer is, yes.

BigCommerce takes care of the vast majority of the steps toward PCI compliance for any customer on our platform. With an ecommerce software like Magento, a business will have to pay someone to set up servers and networking and take the steps to secure that infrastructure to get them PCI compliant. Magento is not PCI compliant out of the box. Learn about switching platforms here.

Whether you run a single brick-and-mortar retail location or you are a large organization selling goods across multiple stores and ecommerce sites, anywhere that your credit card merchant account has been connected and integrated requires attention.

All credit card transaction volumes your organization processes are aggregated across multiple channels (i.e. in store retail point-of-sale terminals and online payment gateways) and summed up to determine an appropriate PCI compliance level.

This means a large international retail chain handling six million transactions per year will still be considered a Level 1 merchant (the strictest level) and will be held to the highest of PCI compliance standards, even if their related ecommerce store processes less than 500 sales orders per month.

Fortunately, if you operate a SaaS-based ecommerce store and do not have any access to any credit cardholder data (which is the case for most modern SaaS commerce platforms), your need for PCI compliance is greatly mitigated. The heavy lifting has vested expertly and wonderfully in the hands of the technology experts working for the PCI-compliant SaaS companies, which in our professional opinion is exactly where it belongs.

PCI Compliance Requirements: How to Quickly Determine Compliance Level

If you host and manage your own ecommerce platform, you will need to ensure PCI compliance for your organization, and the first step is to determine the required compliance level.

All merchants fall into one of four levels based upon credit or debit card transaction volume over a 12-month period. Level 1 is the strictest in terms of DSS requirements, where Level 4 is the least strict:

Almost all small and medium sized businesses (SMBs) classify as the lower Level 3 or Level 4 merchant, however, this does not preclude the necessity to maintain compliance with the same diligence as larger organizations.

In fact, it’s a costly misconception encountered amongst SMBs who believe they do not need to worry about compliance at all because they don’t do a significant enough volume of online or in-store sales. Non-compliance is equally as costly as a breach, in which you are required to assess to the Level 1 standard for the next year, including an on-site audit.

BigCommerce’s Cardholder Data Environment is PCI DSS 3.1 Level 1 certified as both a Merchant and a Service Provider. This protects against credit card data breaches and eliminates the significant cost and hassle of compliance.

Penalties for Non-Compliance

PCI is not, in itself, a law. It’s a standard that was created by the major card brands including Visa, MasterCard, Discover, American Express and JCB. The credit card companies typically do not directly handle payment processing functions themselves, but rely on third party processors (such as Chase Paymentech or Moneris Solutions) to handle the transactional services.

Merchants that do not comply with PCI DSS and are involved in a credit card breach may be subject to fines, card replacement costs or incur costly forensic audits. They could also find themselves in the position where they can’t process credit cards, which can be a death knell. The credit card companies, at their discretion, are the ones who administer fines to the merchant’s bank (or similar financial institution, known as the acquirer) and can range between $5,000 – $100,000 per month for PCI compliance violations or breaches.

“Most states have breach reporting requirements and small businesses in particular can take a huge reputation hit and loss of business when they are breached,” says Tim Thomas, Senior Director of Product Management at ControlScan.

The bank/acquirer in turn passes the fines downstream until it eventually hits the merchant. On top of fines that originate from the credit card companies, merchants may be subject to additional penalties from their bank as well.

Banks and payment processors may terminate their relationship with the merchant altogether, or simply increase per-transaction processing fees and require the merchant to pay for the replacement of the credit cards that have been compromised in the originating beach.

What’s arguably worse is that the bank or processor may require the merchant to move up a level in compliance if they are breached, making the adherence requirements all the more onerous on the merchant moving forward.

Penalties are not openly discussed nor widely publicized, but they can be catastrophic to a business. It is important to be familiar with your credit card merchant account agreement(s), which should fully outline your exposure.

What the PCI Data Security Standards Involve

The full PCI DSS (data security standard) is an extremely dry read, akin to watching paint peel agonizingly off your wall on a hot summer afternoon. It’s a pretty technical subject to cover as well, which is summarized in the next chapter.

Most of the topics found in the PCI DSS deal with maintaining a professional data storage solution –– i.e. ensuring the security of cardholder data. It includes requirements on securing an internal hosting network, adequately protecting cardholder data, implementing strong user access control measures, managing data security policies, executing a vulnerability management program and performing an external security audit. It also provides detailed instructions on how to complete your own PCI Self-Assessment Questionnaire.

In all, if you’re a pure play (i.e. online-only) merchant that does not have a physical retail store but you accept, retain or transmit credit card data through your own self-hosted ecommerce store (via open source platforms such as: OpenCart, ZenCart, Magento Community Edition, etc.) you should positively familiarize yourself with the PCI Security DSS and understand your required compliance level.

Consider hiring a qualified external party who is well versed in PCI subject matter and can provide an objective opinion on how to specifically achieve compliance for your organization.

PCI compliance is its own entire universe of complexity and many organizations don’t have the internal resources qualified enough to delve into its bowels.

We also recommend obtaining an independent adoption consultant along with a Qualified Security Assessor (QSA). PSC is one such QSA partner who can provide detailed guidance as to how to obtain compliance and also act as an independent auditor to test your internal security.

How to Achieve PCI Compliance for Self-Hosted Ecommerce Solutions

The topic of PCI compliance is immensely important to any online retailer that transmits or stores cardholder data (i.e. credit card or debit card information) in their own, physical on-site servers or remote data farms. Cardholder data that is processed through an online store and retail point-of-sale system combine to form a single transaction volume used to determine an organization’s merchant compliance level.

Keep in mind that if you are using a SaaS or cloud-based ecommerce technology solution like BigCommerce, your PCI compliance is greatly mitigated through your provider.

For those not utilizing a SaaS or cloud-based ecommerce technology, the following information outlines the steps you must take in order to ensure that your online business is PCI compliant.

Your compliance level determines the amount of work you need to do, and the levels are as such:

Levels 1 and 2 are for merchants processing 1,000,000 transactions or more per year

Level 3 applies to an organization that processes greater than 20,000 credit or debit card transactions per year

Level 4 applies to an organization that processes less than 20,000 ecommerce transactions per year or less than one million card present transactions

In the interest of brevity, as this subject is vastly complex, we’ll concentrate on a Level 3 or Level 4 organization.

Self Assessment for PCI Merchant Levels 3 and 4

If you are a Level 3 or Level 4 merchant, the PCI DSS provides you the option of doing an internal assessment, whereby a qualified staff member or corporate officer from your organization can perform his or her own audit and sign-off to produce a formal PCI DSS Attestation of Compliance package indicating such.

The first steps are to determine your required compliance level and then download and review the appropriate Self-Assessment Questionnaire (SAQ) found on the PCI SSC Website. There are different SAQs for each merchant level and also different related DSS Attestation of Compliance forms for each level as well.

Before you venture down this path and attempt to download your SAQ and get started, you’ll need to first digest a six page document just to figure out which SAQ form to use in the first place.

And, if you aren’t thoroughly bored and confused after doing that, you almost certainly will be after referring to the lengthy PCI glossary of acronyms and technical jargon related to the subject.

In my humble opinion (and also according to the PCI SSC themselves), the best and easiest thing to do here is to contact your merchant bank and have them help you identify which specific documents you need to use. This is an essential step, as they will often point out deviances in the standard PCI DSS they feel may apply in your case.

Level 3 merchants require quarterly external vulnerability scans by an ASV (Approved Scan Vendor). A list of ASV’s can be found here and include such companies as Cisco Systems, Alert Logic and Backbone Security to name a few.

Completing a self-assessment questionnaire for Level 3 and Level 4 merchants is based upon the honor system, much like completing your income tax return. It’s tempting for organizations to guesstimate their way through some answers or outright fabricate them to avoid the human and physical resource expenditures required to correct vulnerabilities. Many frankly don’t understand some of the items on the SAQ to be begin with.

That said, don’t be dishonest or misrepresent information on the SAQ. If you have a data security breach and your documents come under scrutiny, you can be fined heavily and, in the worst case, your merchant account(s) can be dropped by your bank/financial institution.

Achieving PCI Compliance: Getting Started

The PCI DSS contains what are actually common-sense general data security best practices for any system administration team that is used to hosting sensitive corporate information in a modern network environment.

The trouble in reaching compliance begins when an organization does not have experienced enough internal IT/IS departments and can unfortunately discover that their internal hosting environment is wildly insecure and susceptible to both internal snooping by their own staff or they are wide open to outside intrusion.

Every organization aiming to achieve PCI compliance begins in the same place, and there are three steps in the journey to adhering to the PCI DSS and becoming compliant:

First, Assess –– Perform your own audit to identify the cardholder data you are responsible for, take an inventory of your IT assets and business processes for payment card processing and analyze them for vulnerabilities that could expose sensitive cardholder data.

“The discovery aspect is crucial in determining your PCI scope,”says Ben Rothke, a QSA with Nettitude, Ltd. “A firm must look under every nook and cranny to uncover every point where credit card data enters a system.  This includes everything from mail order, phone order, drop box, order-entry systems, to applications that process credit card data, order entry systems, and much more.”

Next, Remediate –– Fix the vulnerabilities you discover in priority sequence. Ideally move away from storing cardholder data at all unless you absolutely need to. Many organizations store cardholder data within their own homegrown ecommerce platforms after taking a one-off guest checkout order with no intention of using the information again. In this case, why hold onto it at all? Only a merchant looking to set up recurring billing may actually need to retain cardholder data themselves and we’ve often found that B2C ecommerce merchants typically don’t need to support recurring billing profiles.

Wherever and whenever cardholder data can be stored by an external qualified body instead of your own organization is ideal, because nothing will help reach immediate PCI compliance more quickly than not storing or transmitting cardholder data at all.

“Web applications and the protection of them often does not get enough attention,” says Chris Bucolo, Director of Market Strategy for ControlScan. “If you have developed a web application in conjunction with ecommerce payment activities it is very important that a review of the code be done to determine what vulnerabilities may exist, which could lead to common attacks like SQL injection and cross-site scripting.”

Finally, Report –– Compile and submit required remediation validation records (if applicable), and submit compliance reports to the acquiring bank and card brands (i.e. Visa, MasterCard, American Express, etc.) with which you do business.

Completing the Self Assessment Questionnaire (SAQ)

The SAQ is a relatively short document (i.e. five or six pages long) and can itself be completed in a number of hours by someone qualified within your organization. The work getting to that point, though, comes into play when attempting to answer the SAQ questions truthfully and thoroughly, and in a manner that will actually result in achieving compliance.

There are multiple SAQ types depending on your business. The SAQ A is a relatively short document, but SAQ D is 80 pages. You can get more information here about which one you will need.

In so doing, an organization will doubtlessly encounter some significant technical challenges. Below is a quick outline of what you can expect based on my own experience is seeking compliance for clients.

Technical Challenges to Satisfying the SAQ

Even if credit card data passes through your self-hosted (i.e. non-SaaS) ecommerce platform, you are still on the hook for ensuring that any related servers you control (be it your database server, PoS system, credit card processing terminal, utility server or internet application server) are sufficiently secure and compliant.

Each server – or all IP addressable devices – that cardholder data is stored inside or transmitted through is termed a CDE (cardholder data environment) and requires:

Intrusion detection and prevention software – likeTripwire – with a notification escalation profile to alert administrators that someone may have gained unauthorized access to the server and/or tampered with the files/permissions on the server. Tripwire is software that detects the presence of a code change or file structure profile change on a server. A notification escalation profile is a series of automated email or SMS messages. dispatched to key systems personnel in the event that intrusion is detected or an unexpected change to the file structure profile has occurred.

Virus scanning software installed and running daily.

Its operating system to be kept up-to-date with the latest security patches.

The containing room or server rack (i.e. the physical environment containing the computer systems running commerce related servers) be kept under lock-and-key with limited authorized administrative access only.

Entrance to/from the room by administrative personnel (including date/time and purpose of access) needs to be logged. These logs need to be archived and migrated off of the primary servers and housed securely elsewhere so that auditors can readily access them if required by the bank or credit card company.

All cardholder data that is retained for local storage be done so using what the PCI DSS refers to as strong encryption (see the PCI SSC Glossary of Terms for more info). Encryption protects the data from easily being read and utilized by attackers if stolen during a breach event.

The underlying strong encryption architecture must be fully documented and kept up to date.

Personnel with remote access (or non-console administrative access) to the server environment must connect via multi-factor authentication only.

External penetration testing be performed every six months to ensure the environment is secure.

Ongoing Maintenance: Mitigating Common Data Security Exploits

Physical servers need to be continually patched against newly discovered security vulnerabilities. Consider various security exploits that have arisen recently such as HEARTBLEED, POODLE and Logjam.

Note: TLS (transport layer security) –– sometimes referred to as SSL –– is the underlying encryption protocol for secure data transmission over the Internet. It is the “S” in HTTPS.

Your web application or ecommerce platform that is processing credit or debit cards also needs to be secured against client side (i.e. web browser) code exploits such as XSS and SQL Injection Attacks, to name a few.

PCI Breakdown: Time and Costs are Typically Involved in Reaching Compliance

On average, our experienced systems administration team will spend three to four business days securing a single server and preparing the appropriate documentation for a Level 3 or Level 4 merchant. The costs for doing so when factoring our time and the merchant’s staffing resources averages out to about $14,650 USD.

Merchants attempting to reach PCI compliance themselves however, without support from an outside partner, and who are already themselves adept at dealing with data security subject matter, can expect to spend upward of 3-4 weeks of time performing the following tasks:

Researching the PCI Data Security Standards (DSS)

Determining which level of compliance and which PCI SAQ is required

Securing their physical servers (often the largest and most costly aspect of the project)

Examining any third party plugins or software components on the servers that cardholder data passes through and ensuring they, too, are PCI compliant and can produce external documentation that proves such

Completing the PCI SAQ and Attestation of Compliance (ROC)

For complex undertakings involving more than one onsite data center and where a merchant is both capturing and retaining cardholder data, budget at least six weeks in your project plan and estimate related costs to be between $48,625 – $64,900 USD to reach compliance.

The above estimate factors some time for multiple staff within your organization that usually involves a multidisciplinary group of business analysts, system administrators, ecommerce platform developers, project managers, legal teams and resource protection staff. It also takes into account some budget for outside consultant/auditor fees, and provision to hire a third party Qualified Security Assessor.

Note however that our estimate does not factor in any additional costs related to purchasing new server racks, upgrading computer systems, adding new software licenses and installing access control systems (such as staff ID card systems) or any other physical expenses that may be required to achieve compliance.

How Your Ecommerce Software Affects Your PCI

You can acquire ecommerce software in different ways:

Buying commercial software to run on your on-premise hardware

Using open source software on your on-premise hardware (the Do-It-Yourself approach)

Signing up for hosted software delivered as a service (SaaS)

Each approach strikes a different balance between your costs, benefits and PCI risks and workload. The table sums up the highlights, and the following sections discuss each option in more detail.

#1: Commercial Software: The Costly Option

This requires you to buy and maintain your own hardware, plus shell out for a commercial software license and annual support.

The software might be PCI-compliant out of the box, or you could have lots of work getting there. But any extra support you require from the vendor for PCI will likely cost extra.

This option could work for you, if your company chooses to:

Buy and maintain on-premise hardware

Pay for an on-premise software license and support

Maintain in-house expertise to install, customize and maintain an ecommerce platform

Keep someone on call 24/7 to troubleshoot any problem and get the platform back up fast if it ever goes down

Clearly, the drawbacks here are the high costs of hardware, software, and support –– plus the unknown burden of handling some of your own PCI compliance. If that doesn’t sound appealing, skip this approach and read on.

#2: On-Premise, Open Source Software: Lower Cost, Higher Risk

This option is a lot like writing your own code. You still pay for your hardware, but you avoid paying any software license fee. Sounds like a bargain, right? Not so fast.

You have to assemble, compile, install and tweak your own software. And, as for PCI, this can turn into a money-pit. Open source is a black box where no one really knows what’s going on.

“The problem with open source is that you’re not buying from any vendor,” says Beckett. “So there’s no one to fall back on for help. You might not get any support, or no phone number you can call. Or maybe the PCI auditor might not like something about the platform.”

In that case, you’re stuck. You may have to document every step of your process in painful detail. That means holding meetings, analyzing code, sketching flowcharts, writing reports… spending weeks of effort that can easily outweigh any savings you gained from open source.

The DIY option could work, if your company can afford to:

Buy and maintain on-premise hardware

Maintain in-house expertise to link, tweak and maintain ecommerce software

Take staff time to hold many meetings and create PCI-related documents

Using open source software means you are responsible for 100% of your PCI compliance ––  not to mention your store’s uptime. If you don’t want to take on those burdens, skip this approach and read on.

#3: Hosted Software-as-a-Service (SaaS): Low Cost, Low Risk

Software running as a service is accessed through the web, running on hardware maintained in a secure data center by your service provider. If you want to save money, and can’t spare a lot of staff to develop PCI policies and write reports, consider using a hosted ecommerce service such as BigCommerce.

This way, you can forget about fiddling with ecommerce hardware and software, pay one monthly fee to cover your ecommerce platform, and remain PCI-compliant with a minimum of time and expense.

An important consideration when electing this option, however, is that you will still be required to complete an SAQ (self-assessment questionnaire) as a Level 2-4 merchant and an ROC (i.e. report on compliance, also synonymous with Attestation of Compliance) if you are a Level 1 merchant.

Therefore, the work in documenting and reporting on a quality SaaS ecommerce platform regardless of your compliance level is much less involved in terms of cost and risk than the other two options presented.

The SaaS option will work for you if your company:

Wants to save money on hardware, software licenses and support

Doesn’t have people to fiddle with hardware and software

Prefers to pay one monthly fee to cover your ecommerce platform

Wants to remain PCI-compliant with a minimum of effort

With lower costs, less risk, and fewer PCI hassles, this option is the chosen path for many online stores.

Here’s a full chart of what is covered and what isn’t with PCI Compliance and your chosen ecommerce platform:

We’ve Successfully Achieved PCI Compliance: What’s Next?

As if achieving PCI compliance wasn’t complex enough on its own, maintaining compliance year-over-year and keeping up with ever-evolving nuances to PCS data security standards (DSS) has proven itself a perpetual expense and burden to any organization.

The latest PCI DSS standard (version 3.2) released in April of 2016, for example, defines a number of changes to previously accepted rules and regulations on a variety of PCI subjects, touching upon both documentation requirements and technical adjustments to the physical hosting environment (CDE) itself. This means as a self-hosted merchant you’ll need to concern yourself not only with getting all these requirements perfected the first time around, but you’ll also be expected to manage lists of future change requests and down-the-road migration plans that will keep your technical teams very busy ad infinitum (i.e. forever). Let’s face it, they often have more than enough to do as it is.

In short, maintaining compliance is an ongoing process, involving all of the above as well as quarterly vulnerability scans and completing a new SAQ and Attestation of Compliance each year.

If your organization is presently at PCI compliance Level 3 and your credit card transaction volume is trending upwards at a rate of 20% or more annually, consider hiring a QSA and having a formal external security audit done every year, even if your bank doesn’t require it.

In this manner, your team won’t be flanked by a last minute crunch to get it done which will result in overstatements, omissions and increased third party auditing costs. You’ll also proactively position your organization for an easy transition upward to a higher compliance level at a later time.

Also, remember, PCI compliance is common-sense security best practices. Security expert Jeremiah Grossman explains that it’s hard for any standard that uses prescriptive guidance to keep up with attackers.

“Regardless of what the standard says, or requires, this is what I tell everyone on how best to protect themselves — or at least their websites.

1) Assign an individual or group that is accountable for website security.

2) Find your IT assets – all of them – and prioritize their business value. You can’t secure what you don’t know you own.

3) Measure your current security posture from an attacker’s perspective. Remember, the bad guys aren’t concerned with what standards say, what laws say or anything. They’ll take the path of least resistance in and don’t play by the rules.

4) Trend and track the lifecycle of vulnerabilities, such as the average number of vulnerabilities (by time, business unit, or vulnerability class), the average time to fix and remediation rates. Everyone has vulnerabilities, but what separates the hacked from the not hacked is often the speed and comprehensiveness of their patch processes.

5) Fast detection and response. When being attacked by professionals, everyone gets compromised eventually. What separates significant damage versus an annoyance incident is how fast the attackers are detected and kicked off the system. It’s difficult for attackers to cause a lot of harm if they’re only on a compromised system for no more than a day or a few hours.”

Have any questions or concerns about your business’s PCI compliance? Leave a comment below and we’ll work to get your connected with our security experts ASAP. 

Show more