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.
Indeed, the situation with respect to credit card fraud appears to be a reoccurring issue.
In 2013, U.S. retail giant Target Corporation was hacked — a staggering 40 million credit and debit card numbers were stolen from their network.
In 2014, Home Depot saw a similar breach with 56 million credit card numbers stolen.
In 2018, Saks and Lord & Taylor became the latest victim of a breach — this time coming from hackers in their POS solution in-store.
Recently, Neiman Marcus had its second breach in less than a decade. In the cyber hit, more than 4.6 million customers were affected.
Dealing with a compromise is a time-consuming hassle from both a consumer's and merchant's perspective. This is mainly 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 the Payment Card Industry Data Security Standard (PCI DSS) — and every retailer is required to comply.
Depending on the ecommerce technology and backend a retailer uses, PCI compliance can be an easy check on a long list of things retailers need to do to ensure their customers are transacting securely. It can also become a significant pain if not done correctly — costing ample time, resources and money.
Unfortunately, the difficulties in compliance primarily come from a lack of knowledge.
According to an April 2019 survey conducted among adults in the United States, only 58 percent of respondents stated they had never heard of the Payment Card Industry Data Security Standard (PCI-DSS). Furthermore, only 16 percent of respondents reported knowing the basics of the standard.
By understanding what the PCI DSS requirements are and what it can do for your business, organizations can get ahead of potential threats — as well as significant fines — all while protecting their customers’ best interests.
In this guide, you’ll learn:
What PCI DSS is.
How to achieve it for your business.
How your ecommerce backend plays a prominent role in your required effort.
Below are the 12 High-Level Requirements Mandated by the PCI DSS.
What is the PCI DSS?
PCI DSS are standards all businesses that transact via credit card must abide by.
Originally created by Visa, MasterCard, Discover and American Express in 2004, the Payment Card Industry Data Security Standard (PCI DSS) has evolved over the years to ensure that online sellers have the systems and processes in place to prevent a data breach.
The most recent version is PCI DSS 4.0. Version 4.0 was scheduled to be released in March 2022 and replace Version 3.2.1.
The PCI Security Standards Council (PCI SSC) defines a series of specific Data Security Standards (DSS) relevant to all merchants, regardless of revenue and credit card transaction volumes. Achieving and maintaining PCI compliance is the ongoing process an organization undertakes to ensure that they adhere to the security requirements as defined by the PCI SSC.
The SSC defines and manages the standards, while the credit card companies enforce compliance.
These standards apply to all organizations that deal with cardholder data. Cardholder data refers specifically to the credit card number, along with cardholder name, expiration date and security code (CSC).
In total, PCI DSS outlines 12 requirements for compliance. Twelve requirements may not sound like much. A quick scan for PCI compliance documentation online can lead you to believe that PCI compliance is easy.
In reality, maintaining PCI compliance is extremely complex — especially for large enterprises. It means you need to comply with a total of 251 sub-requirements across the 12 requirements outlined in PCI DSS 4.0 to address the growing threats to customer payment security.
Most notable retail data breaches.
Data breaches are becoming increasingly common for all businesses, including retailers.
In 2005, Walmart 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.
Other instances include:
A surge in data breaches in 2019, affecting stores from Macy’s to Hy-Vee.
The infamous Yahoo data breach in 2017, which impacted more than 3 billion accounts.
First American Financial Corporation, which reportedly leaked 885 million users' sensitive records in 2019.
In 2021, a Linkedin data breach exposed the information of more than 700 million users.
Why credit card security is often neglected.
Any company that works with ecommerce development will inevitably deal with credit card security issues, whether from cardholder data stored in plain text files without any encryption to basic obfuscation residing under a CFO’s desk in a dusty PC dating back to the late 1990s.
While these sorts of practices may come from negligence, most issues regarding credit cards arise from unintentional ignorance.
Organizations that work with credit cards must prioritize credit card cybersecurity. The difference between a secure payment system and an unsecured one is significant and can affect the very ways that you do business. Don’t neglect it until it becomes an issue.
Do I need to ensure PCI compliance for my organization?
If you operate your on-premise or self-hosted cloud commerce solution, the short answer is yes.
Ecommerce PCI compliance is essential 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 — e.g., in-store retail point-of-sale terminals and online payment gateways — and summed up to determine an appropriate PCI compliance level.
What this means is that a large international retail chain handling 6 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 are 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, your need for PCI compliance is significantly mitigated.
SaaS solutions like BigCommerce take care of the vast majority of the steps toward ecommerce PCI compliance for any customer on the platform.
While on-premise solutions may give organizations more flexibility and familiarity, SaaS platforms are highly customizable and significantly more cost-effective — all while providing businesses with the compliance experts you need.
Ecommerce PCI Compliance Requirements
If you host and manage your own ecommerce platform, you will need to ensure PCI compliance for your organization.
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, whereas Level 4 is the least severe:
Almost all small and medium-sized businesses (SMBs) classify as Level 3 or Level 4 merchants. However, this does not mean that they shouldn't maintain compliance with the same diligence as larger organizations.
In fact, it's a costly misconception encountered among SMBs who believe they do not need to worry about compliance because they don't have 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.
Penalties for non-compliance.
PCI is not, in itself, a law. It’s a standard created by the major card brands, including Visa, MasterCard, Discover, AMEX and JCB.
The credit card companies typically do not directly manage 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 costly forensic audits.
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 – $500,000 per month for PCI compliance violations or breaches.
The bank/acquirer, in turn, passes the fines downstream until it eventually hits the merchant.
On top of fines originating from credit card companies, merchants may be subject to additional penalties from their bank.
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 even 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 can be catastrophic to a business.
It is important to be familiar with your credit card merchant account agreement(s), which should thoroughly outline your exposure.
What is the PCI Data Security Standard?
As summarized in the next chapter, the full PCI DSS (data security standard) is a technical subject to cover. Most of the topics found deal with maintaining a professional data storage solution.
It includes information on securing an internal hosting network, adequately protecting the transmission of cardholder data, implementing strong access control measures, managing data protection 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 short, if you’re an online-only merchant that does not have a physical retail store, but you accept, retain or transmit credit card data through your self-hosted ecommerce store — via open-source platforms such as OpenCart, ZenCart, Magento, etc. — you should 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 achieving compliance for your organization specifically. 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 (or QSA). PSC is one such QSA partner who can provide detailed guidance on compliance and act as an independent auditor to test your internal security.
Ecommerce PCI Compliance
Any business that processes, stores or transmits information from a credit or debit card is required to be compliant with PCI DSS.
For ecommerce organizations that accept credit cards, noncompliance isn’t possible if only because credit card payments are critical for the success of an online business. The PCI DSS efforts to prevent credit card fraud are especially important for the online sphere, as a significant data breach could be crippling for any SMBs.
The following section highlights how PCI DSS compliance works with the three primary ecommerce platforms:
For Open Source Platforms.
As open source platforms continue to grow in popularity, it is no surprise that open source security has begun to question. The software industry has failed to protect the public from data theft and breaches, which is why the PCI DSS has become so critical for organizations.
Open source issues have become so prevalent that PCI addressed it directly. In section 3.2b of the PCI Secure SLC document, the guidelines state:
Where open-source software components are utilized as part of the software, the assessor shall examine vendor evidence, including process documentation and assessment results to confirm these components are managed as follows:
An inventory of open-source components used in the vendor’s software is maintained.
A mature process exists to analyze and mitigate the use of open-source components with known vulnerabilities.
The software vendor monitors vulnerabilities in open-source components throughout their use or inclusion in the vendor’s software.
An appropriate patching strategy for open-source components is defined.
For SaaS Platforms.
Many Software as a Service (SaaS) platforms and providers are now involved in transmitting and storing credit or debit card data.
While they may not be processing the actual data themselves, the fact that it passes through their system is more than enough to fall under the careful eye of PCI DSS compliance.
To ensure PCI compliance, Saas platforms should look to prioritize the following:
1. Information Security Policies
SaaS platforms must take care to have direct and explicit information security policies and procedures in place. Organization is key here — you want to be able to point to the processes in place in the event of a data breach or security issue.
2. Documentation
Similarly, documentation is critical for SaaS. PCI compliance demands in-depth policies and procedures. Organizations need to be able to log all of the information they have related to payment data, and it needs to be readily available for review.
The more documentation a business has, the fewer potential gray areas it will have to deal with.
3. Risk Assessment
Lastly, a significant part of PCI compliance for SaaS platforms is the assessment of risk for cloud computing providers. PCI DSS requires that SaaS providers perform an annual risk assessment to review for any potential threats.
Knowing what to watch out for is half of the battle. Every business faces a different set of challenges and threats, depending on industry, size or location. By setting yourself up for success, you can prevent broader security issues.
For Headless Platforms.
Headless platforms work primarily by separating the frontend storefront from the backend commerce services.
PCI compliance comes into play in the connection of the frontend with the backend, particularly in regards to card payment. If a customer enters the wrong credit card information at the frontend, then the backend should reject the transaction.
What the PCI regulations ask in an instance like this is, instead of triggering a specific message on why the transaction failed, the frontend should create a general message about invalid information.
Why is that? If the goal is to prevent fraud ultimately, businesses should do their best to lessen the chance of fraud whenever possible. Instead of giving fraudulent customers an area in which to make an educated guess, you're simply making sure they're aware of an issue.
Data breaches and credit card fraud can ruin a business' bottom line and reputation. Businesses can set themselves up for success and prevent potential risk by ensuring the front-end and backend are as harmonious as possible.
Achieving PCI Compliance
The PCI DSS contains common-sense general data security best practices for any system administration team used to hosting sensitive corporate information in a modern, secure network environment.
The trouble in reaching compliance begins when an organization does not have experienced enough internal IT/IS departments. Unfortunately, it can discover that their internal hosting environment is wildly insecure and susceptible to internal snooping by their staff or wide open to outside intrusion.
Every organization aiming to achieve PCI compliance begins in the same place.
There are three steps in the journey to adhering to the PCI DSS and becoming compliant:
1. Assess.
Perform an 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.
2. Remediate.
Fix the vulnerabilities you discover in priority sequences. Ideally, move away from storing cardholder data at all unless you need to. Many organizations store cardholder data within their 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 need to retain cardholder data themselves. 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 a qualified external body instead of your organization is ideal because nothing will help reach immediate PCI compliance more quickly than not storing or transmitting cardholder data at all.
3. 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, Amex, etc. — with which you do business.
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 their 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 additional related DSS Attestation of Compliance forms for each level.
Before you venture down this path and attempt to download your SAQ and get started, you’ll need first to digest a six-page document to figure out which SAQ form to use in the first place.
While reading, you can refer to the lengthy PCI glossary of acronyms and technical jargon related to the subject.
According to the PCI SSC themselves, the 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 ASVs can be found here and include such companies as Cisco Systems Inc, Alert Logic, Inc and Backbone Security, Inc.
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 guess 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 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.
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 comes into play when attempting to answer the SAQ questions truthfully and thoroughly and in a manner that will achieve compliance.
In so doing, an organization will doubtlessly encounter some significant technical challenges.
Below is a quick outline of what you can expect:.
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 software, credit card processing terminal, utility server or internet application server — are sufficiently secure and compliant.
Each server that cardholder data is stored inside or transmitted through is termed a cardholder data environment (CDE) and requires:
Tripwire software 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. A tripwire is a 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 if an intrusion is detected or an unexpected change to the file structure profile has occurred.
Virus scanning software installed and running daily.
Its operating system 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) kept under lock-and-key with limited authorized administrative access only.
The administrative personnel's entrance to/from the room (including date/time and purpose of access) needs to be logged. These logs need to be archived and migrated off 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 retained for local storage can be done 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 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 is 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.
PRO TIP
Transport layer security (TLS) — 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.
The time and costs to reach 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.
When factoring in time and the merchant’s staffing resources, the costs for doing so can be significant.
Merchants attempting to reach PCI compliance themselves without support from an outside partner and are already themselves adept at dealing with data security subject matter, can
expect to spend upward of 3-4 weeks 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 capturing and retaining cardholder data, budget at least six weeks in your project plan and estimate extensive costs 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.
Resource protection staff.
It also considers some budget for outside consultant/auditor fees and provision to hire a third-party Qualified Security Assessor.
Note 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.
5 Risks If You Aren’t PCI Compliant
PCI DSS compliance can be a hassle for companies, as it is difficult and time-consuming. However, PCI compliance is ensured with the customer in mind, giving you peace of mind and keeping your business free from data breaches and violations.
If PCI compliance benefits won’t convince some companies, then the potential risks will do the trick. Non-compliance can lead to many different consequences, including:
1. PCI compliance fees.
PCI non-compliance can result in significant monetary fines, ranging from $5,000 to $500,000 per month by various credit card companies. The penalties depend on the volume of clients and transactions, and which level of PCI compliance a company should be on.
These fines are referred to simply as “PCI non-compliance fees.”
2. Suspension of credit cards.
If a company decides to remain PCI non-compliant, there is a significant chance that they won’t be able to use credit cards for any payments within their system. For an online or ecommerce-based organization, that could be a death knell.
3. Notification and credit monitoring.
If a company is suspected of non-compliance, or if a company is dealing with alleged breaches in their security system, a Common Point of purchase (CPP) notice could be issued.
What this means is that a company will have a limited amount of time to resolve their credit issues and compliance, all while being reviewed by a PCI investigator.
4. Liability for fraud charges.
A weak or non-compliant security system is a prime target for online fraud, opening up your company and customers to potentially stolen payment data and personal information.
While PCI DSS compliance does not prevent data breaches, companies that are compliant and suffer a data breach face significantly lower fines than if they were non-compliant.
According to a study by the Ponemon Institute, the average cost of a breach is $150 per record. For larger companies, that can lead to brutal, debilitating fines.
5. GDPR and other privacy regulations.
The key difference between PCI DSS compliance and privacy regulations such as GDPR is that PCI’s primary focus is on security concerns, whereas GDPRO focuses on privacy concerns.
Where the two interact is with data breaches. Anytime a cardholder or customer’s data is exposed, it is considered a breach of both PCI DSS and GDPR.
In the case of a data breach, instead of simply receiving a fine from PCI or GDPR, companies under GDPR could be facing significant penalties from both organizations.
Ecommerce PCI Compliance Levels and Requirements
A company’s ecommerce PCI compliance level is determined by their number of transactions processed annually.
Organizations must know what their level is and what can happen due to a data breach. If a merchant suffers a data breach, that can cause them to be escalated to a higher level.
The PCI Compliance levels are organized into the following four tiers:
1. PCI Compliance Level 1.
Level 1 merchants include:
Merchants that process more than 6 million Visa or Mastercard transactions per year, including in-store and online.
Any merchant that Visa determines should be a Level 1 merchant to minimize risks to the Visa system.
All Payment Facilitators that process more than 300,000 transactions annually.
Merchants who are considered Level 1 must:
Complete an annual Report on Compliance (ROC) through a Qualified Security Assessor (QSA).
Complete quarterly network scans by an Approved Scanning Vendor (ASV).
Complete the Attestation of Compliance Form.
2. PCI Compliance Level 2.
Level 2 merchants include:
Merchants that process 1 million to 6 million Visa transactions per year regardless of the processing channel.
All Payment Facilitators that process less than 300,000 transactions annually.
Merchants who are considered Level 2 must:
Complete an annual Self-Assessment Questionnaire (SAQ).
Complete a quarterly network scan by an ASV.
Complete the Attestation of Compliance Form.
3. PCI Compliance Level 3.
Level 3 merchants include:
Merchants that process 20,000 to 1 million Visa e-commerce transactions per year.
Merchants who are considered Level 3 must:
Complete an annual SAQ.
Complete a quarterly network scan by an ASV.
Complete the Attestation of Compliance Form.
4. PCI Compliance Level 4.
Level 4 merchants include:
Merchants that process fewer than 20,000 Visa e-commerce transactions per year.
Any company that processes up to 1 million Visa transactions per year.
Merchants who are considered Level 4 must:
Complete an annual SAQ.
Complete a quarterly network scan by an ASV.
Complete the Attestation of Compliance Form.
How Your Ecommerce Platform Affects Your PCI Compliance
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 DIY approach).
Signing up for hosted software delivered as a service (SaaS).
Each approach strikes a different balance between your costs, benefits and ecommerce 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.
Commercial software requires you to buy and maintain your hardware, plus shell out for a commercial software license and annual support.
The ecommerce software might be PCI-compliant out of the box, or you could have lots of work getting there. 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.
The drawbacks here are the high costs of hardware, software and support — plus the unknown burden of handling some of your own PCI compliance.
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.
You have to assemble, compile, install and tweak your software. Just as for PCI, this can quickly turn into a money pit. Open source is a black box where no one really knows what’s happening.
The problem with open source is that you’re not buying from any vendor, so there’s no one to fall back on for help — whether support or even a phone number to call. Even worse, the PCI auditor you work with may not like something about the platform itself.
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. Potentially weeks of effort that can 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.
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 selecting this option, however, is that you will still be required to complete a self-assessment questionnaire (SAQ) 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.
PCI Compliance Requirements Checklist
Again, this is only applicable to your IT team if you choose not to go with a SaaS solution. If you use an open-source or custom-built ecommerce platform, your IT team will need to go through the following checklist annually.
We’ve broken the checklist down below based on the PCI requirement.
1. Safeguard cardholder data by implementing and maintaining a firewall.
Maintaining requirement for 1:
Positioning firewalls to only allow necessary traffic to enter your CDE.
Having a “deny all” rule for all other inbound and outbound traffic.
Dynamic packet filtering.
Creating a secure zone for any card data storage.
Ensuring all outbound connections from your CDE are explicitly authorized.
Installing a firewall between wireless networks and your CDE.
Documenting all firewall policies and procedures, including business justifications for each port or protocol allowed through firewalls.
2. Create custom passwords and other unique security measures rather than using the default setting from your vendor-supplied systems.
Maintaining requirement for 2:
Maintaining an inventory of all hardware and software used in the CDE.
Assigning a system administrator to be responsible for configuring system components.
Implementing a system configuration and hardening guide that covers all components of the CDE.
Disabling or uninstalling any unnecessary services, programs, accounts, drivers, scripts, features, systems, and web servers, and documenting which ones are allowed.
Changing vendor-supplied default usernames and passwords.
Documenting security policies and operating procedures for managing vendor defaults and other security settings.
Using technologies such as VPN for web-based management and ensuring all traffic is encrypted following current standards. There are both paid and free VPNs available.
Enabling only one primary function per server.
3. Safeguard stored cardholder data.
Maintaining requirement for 3:
Documenting a data retention policy.
Having employees acknowledge their training and understanding of the policy.
Eliminating storage of sensitive authentication data after card authorization.
Masking the primary account number on customer receipts.
Understanding guidelines for handling and storing cardholder data.
Making sure primary account number storage is accessible by as few employees as possible, including limiting access to cryptographic keys, removable media, or hard copies of data.
4. Encrypt cardholder data that is transmitted across open, public networks.
Maintaining requirement for 4:
Reviewing all locations, systems, and devices where cardholder data is transmitted to ensure you’re using appropriate encryption to safeguard data over open, public networks.
Verifying that encryption keys/certificates are valid and trusted.
Continually checking the latest encryption vulnerabilities and updating as needed.
Having a policy to ensure you don’t send unprotected cardholder data via end-user messaging technologies.
Checking with vendors to ensure supplied POS devices are appropriately encrypting data.
Reviewing and implementing best practices, policies and procedures for sending and receiving payment card data.
Ensuring TLS is enabled whenever cardholder data is transmitted or received through web-based services.
Prohibiting the use of WEP, an unsecured wireless encryption standard.
5. Anti-virus software needs to be implemented and actively updated.
Maintaining requirement for 5:
Deploying anti-virus programs on commonly affected systems.
Setting anti-virus to scan automatically to detect and remove malicious software.
Maintaining audit logs for review.
Ensuring the anti-virus system is updated automatically.
Setting up administrative access to ensure anti-virus can’t be disabled or altered by users.
Documenting malware procedures and reviewing with necessary staff.
Examining system configurations and periodically evaluating malware threats to your system.
6. Create and sustain secure systems and applications.
Maintaining requirement for 6:
Having a change management process.
Having an update server.
Having a process in place to keep up-to-date with the latest identified security vulnerabilities and their threat level.
Installing vendor-supplied security patches on all system components.
Ensuring all security updates are installed within one month of release.
Setting up a manual or automatic schedule to install the latest security patches for all system Components.
7. Keep cardholder access limited by need-to-know.
Maintaining requirement for 7:
Implementing access controls on any systems where cardholder data is stored and handled.
Having a written policy that details access to cardholder data based on defined job roles and privilege levels.
Training employees on their specific access level.
Configuring access controls to only allow authorized parties and denying all others without prior approval or access.
8. Users with digital access to cardholder data need unique identifiers.
Maintaining requirement for 8:
Monitoring all remote access accounts used by vendors, business partners, IT support personnel, etc. when the account is in use.
Disabling all remote access accounts when not in use.
Enabling accounts used for remote access only when they are needed.
Implementing a multi-factor authentication solution for all remote access sessions.
9. Physical access to cardholder data needs to be restricted.
Maintaining requirement for 9:
Restricting access to any publicly accessible network jacks in the business.
Keeping physical media secure and maintaining strict control over any media being moved within the building and outside of it.
Keeping media in a secure area with limited access and requiring management approval before the media is moved from its secure location.
Using a secure courier when sending media through the mail so the location of the media can be tracked.
Destroying media in a way that it cannot be reconstructed.
Maintaining a list of all devices used for processing and training all employees to inspect devices for evidence of tampering.
Having training processes for verifying the identity of outside vendors wanting access to devices and processes for reporting suspicious behavior around devices.
10. Network resources and cardholder data access needs to be logged and reported.
Maintaining requirement for 10:
Having audit logs that track every action taken by someone with administrative privileges, failed login attempts and changes to accounts.
The ability to identify a user, the date and time of the event, the type of event, whether the event was a success or failure, where the event originated from and the name of the impacted data or system component.
Having processes and procedures to review logs and security events daily, as well as review system components defined by your risk management strategy.
Having a process to respond to anomalies or exceptions in logs.
Keeping all audit log records for at least one year and maintaining logs for the most recent three months readily available for analysis.
11. Run frequent security systems and processes tests.
Maintaining requirement for 11:
Running quarterly internal vulnerability scans using a qualified internal resource or external third party.
Running quarterly external vulnerability scans using a PCI-approved scanning vendor (ASV).
Using a qualified resource to run internal and external scans after any major change to your network .
Configuring the change-detection tools to alert you to unauthorized modification of critical content files, system files or configuration files, and to configure the tools to perform critical file comparisons at least once a week.
Having a process to respond to alerts generated by the change-detection tool.
Running a quarterly scan on wireless access points and developing a plan to respond to the detection of unauthorized wireless access points.
Performing penetration tests to confirm segmentation is operational and isolates systems in the CDE from all other systems.
12. Address information security throughout your business by creating a policy.
Maintaining requirement for 12:
Developing written compliance and security policies.
Ensuring every employee working in the CDE completes annual security awareness training.
Creating a company policy documenting all critical devices and services within the CDE, including laptops, tablets, remote access, wireless access and email/Internet usage
Developing a comprehensive description of each employee’s role in the CDE and documenting acceptable uses and storage of all technologies.
Creating an incident response plan in the event cardholder data is compromised.
Creating and updating a current list of third-party service providers.
Annually documenting a policy for engaging with third-party providers, obtaining a written agreement acknowledging responsibility for the cardholder data they possess and having a process for engaging new providers.
The Final Word
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 for any organization.
The latest PCI DSS standard 4.0 — released in Q1 2022 — defines a number of changes to previously accepted rules and regulations on various PCI subjects, touching upon both documentation requirements and technical adjustments to the physical hosting environment (CDE) itself.
This means that self-hosted merchants will 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..
In short, maintaining compliance is an ongoing process involving all of the above and 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, resulting 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.
PCI DSS compliance is not easy, nor is it simple. However, it is necessary, and companies that can understand what it is will have a better chance of preventing future data breaches, maintaining their bottom line, and most importantly, keeping their customer's information safe and secure.