The Definitive Guide to PCI Compliance

The Payment Card Industry Data Security Standard (PCI DSS) is an information security standard that encompasses a detailed set of regulations for companies to manage and secure payment card data. It was established by the Payment Card Industry Security Standards Council (PCI SSC), which is an alliance of the five major credit card companies – VISA, American Express, JCB, Discover, and MasterCard. These card providers created the guidelines to ensure that a baseline of security requirements was established to protect cardholder data and to accommodate emerging payment methods.

If your business accepts, stores, processes, or transmits cardholder data – regardless of the size and transaction volume – then you’re expected to comply with PCI DSS.

Cardholder data as defined by the PCI DSS is the primary account number (PAN) at the minimum, or any combination of the PAN and the cardholder name, card expiration data, and the service code. Additionally, sensitive authentication data falls under PCI compliance and must not be stored unless it’s absolutely necessary. Only card issuers or companies that support card issuing services may store sensitive authentication data. This can include card validation codes, track data from a magnetic stripe or card chip, PINS, or other information used to validate cardholders or transactions.

As companies continue to find new ways to accept and process card data, then these guidelines will evolve. While staying on top of this can seem tedious, it’s more beneficial in the long run to not only protect your reputation but your customers’ data as well.

If a business stores, accepts, transmits, or processes payment card information, then they’re subject to following the guidelines and standards set by PCI SCC. Since the framework was mandated by the 5 leading international payment card providers, it’s considered to be a global industry standard to help ensure that cardholder information is being handled securely.

Europe does have their own set of data security standards called the General Data Protection Regulation (GDPR). Chances are you’ve probably heard about it since it went into effect in May 2018. GDPR and PCI DSS share some overlap, so businesses that are following both are better protecting their data.

While PCI compliance can seem daunting, think of it as a checklist of best practices that a business can use as a framework when dealing with cardholder data.

PCI compliance is an ongoing process that needs to be evaluated every year. It can be broken into three parts:

• Assess: This is the step where you take an inventory of all your IT assets and identify where cardholder data is located. This step is critical in determining where you’re exposing yourself to vulnerabilities.
• Repair: This is where you would fix those “holes.” In this stage, you’d also remove any cardholder data storage and implement secure processes to better manage cardholder information.
• Report: In this stage, you document your assessment and submit your reports to the card brands and acquiring bank that you do business with.

PCI compliance isn’t the same for all companies. It consists of 4 levels and a company is required to maintain compliance within that specific level. As a company’s number of transactions fluctuate, then they can either move up or down levels.

There are 4 PCI compliance levels for merchants, which are listed below, including the steps required to achieve compliance with each level.

Depending on their compliance level, some companies may need to contract an independent, PCI SSC-approved Qualified Security Assessor (QSA) to carry out an on-site assessment of compliance with the PCI DSS requirements and complete a Report on Compliance (ROC) afterwards. Other merchants may fill out a Self-Assessment Questionnaire (SAQ) and an Attestation of Compliance (AOC) instead of a ROC. An Approved Scanning Vendor (ASV) may also be needed for quarterly network scans.

• Level 1: Merchants processing over 6,000,000 transactions annually. Level 1 merchants must contract a QSA, file a ROC and pass quarterly network scans using an ASV.
• Level 2: Merchants processing between 1,000,000 and 6,000,000 transactions annually. Level 2 merchants may complete a SAQ and AOC and pass quarterly network scans using an ASV.
• Level 3: Merchants processing between 20,000 and 1,000,000 transactions annually. Level 3 merchants may complete a SAQ and AOC and pass quarterly network scans using an ASV.
• Level 4: Merchants processing less than 20,000 transactions annually. Level 4 merchants may complete a SAQ and AOC and pass quarterly network scans using an ASV if it is applicable to their cardholder environment.

Additionally, there are 2 PCI compliance levels for service providers.

Level 1: Service providers processing 300,000 or more transactions annually. Level 1 service providers must contract a QSA, file a ROC and pass quarterly network scans using an ASV. 

Level 2: Service providers processing less than 300,000 transactions annually. Level 2 service providers may complete a SAQ and AOC and pass quarterly network scans using an ASV. 

These compliance levels are aimed at simplifying the process of achieving and maintaining PCI compliance for smaller businesses processing fewer transactions compared to larger companies with more resources to dedicate towards compliance, and as such are ranked by the volume of transactions processed by a business in a year.

The Definitive Guide to PCI Compliance

Download the Guide

PCI DSS applies to every company that’s involved in processing cardholder data, and there are 12 high-level requirements that each company must adhere to in order to achieve and maintain PCI compliance.

Additionally, there are 200 sub-requirements, but not all of them may apply to your business. There are some requirements that can be more challenging to achieve than others.

Build and Maintain a Secure Network and Systems

Requirement 1: Install and maintain a firewall configuration to protect cardholder data

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

Protect Stored Cardholder Data

Requirement 3: Protect stored cardholder data

Requirement 4: Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program

Requirement 5: Use and regularly update anti-virus software or programs

Requirement 6: Develop and maintain secure systems and applications

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business need to know

Requirement 8: Assign a unique ID to each person with computer access

Requirement 9: Restrict physical access to cardholder data

Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data

Requirement 11: Regularly test security systems and processes

Maintain an Information Security Policy

Requirement 12: Maintain a policy that addresses information security for all personnel

The main consequence for not complying with the PCI DSS standards is a monetary fine. Fines vary depending on the circumstances. The types of fines can range from legal fees if this is a massive credit card data breach to credit monitoring fees to audit fees.

If a data breach were to occur at your business, you’ll be investigated to see if you were in compliance at the time of the breach. Fines can range from $5,000 – $100,000 per month and additional fines can be added if other noncompliance items have occurred. One of the biggest consequences that can occur from noncompliance is a stain on the company’s reputation and brand. While the financial loss can hit a business hard, it can be harder to regain your customers’ trust in your business.

Another consequence could be losing your merchant account, so you won’t be able to accept credit card payments anymore. It’s hard to imagine running a business where you don’t accept credit cards.

The best way to avoid being fined is to be make compliance an ongoing process. Keep in mind that being PCI compliant doesn’t prevent data breaches though. It significantly reduces your chances of a breach because you have regulations in place, but there’s no guarantee it can’t happen.

Virtual cards are becoming a commonly used payment method, so it’s no surprise that questions are coming up as to whether this falls under PCI DSS or not. Here’s what the PCI SSC notes on their website:

Articles 1285 and 1286:
“PCI DSS applies to all primary account numbers (PANs) that represent a PCI founding payment card brand (American Express, Discover, JCB, MasterCard, or Visa). This includes PANs that are only provided electronically (virtual PANs) as well as PANs that correspond to a physical payment card. Whether a one-time PAN is in scope for PCI DSS will depend on the particular restrictions around their usage as defined by the payment brands. Entities should contact the applicable payment brand to determine how PCI DSS applies.”

There are two main types of virtual cards: single use and multi-use. Single use cards are disabled after a one-time use, so they can’t be reused for fraudulent purposes. PCI DSS wouldn’t necessarily apply to them. However, that doesn’t mean the business that’s storing, transmitting, or processing the card is also out of scope.

It’s different with the multi-use cards though. Multi-use cards are subject to PCI DSS guidelines if they are being stored, transmitted, or processed by businesses.

Virtual card providers are expected to adhere to PCI DSS requirements. If you’re working with a virtual card provider, and it’s unclear if they’re following PCI guidelines for this specific payment method, then don’t hesitate to ask how PCI DSS applies. It’s worth noting that each payment card company may have a different opinion on whether they’re in PCI scope or not. When in doubt, just ask!

A common misconception is that PCI DSS is a law that we’re expected to abide by. It’s worth noting that it’s a set of rules created by the five major credit card brands to help promote an industry standard when handling cardholder data and better protect companies from a breach. Just like there are rules in other areas of our life that we’re expected to follow, think of PCI DSS as another set of practices worth incorporating into your business life.

Improved security: By ensuring that your business’s networks, systems, processes, and personnel are secure and customer cardholder data is protected from potential attacks, there is the knock-on effect of ensuring that other assets owned by your business are also protected from leakage, tampering or destruction. This can include assets such as intellectual property and other types of sensitive and classified data aside from cardholder data.

Legal protection: Some U.S. states (directly or indirectly) require merchants to be PCI compliant by state law. For instance, PCI compliant entities in Nevada are protected from liability for damages in the event of a security breach, as long as the security breach wasn’t caused by gross negligence or intentional misconduct by the company or any connected individual or entity. The legal protections provided by attaining PCI compliance are beneficial to the long-term stability and success of businesses involved in payment card processing.

Customer confidence: Achieving PCI compliance is a great way to boost customer confidence in your products and/or services, especially if you attain Level 1 compliance. This is attained by getting audited by an independent, trusted Qualified Security Assessor (QSA). Additionally, attaining Level 1 compliance allows a business to be listed on the Visa and MasterCard registry of service providers which makes it easy for prospective customers to look up your organization’s PCI compliance status.

Impact of data breaches: According to Ponemon Institute’s 2019 Cost of a Data Breach Report, the average total cost of a data breach is $3.92 million. Breaches also continue to impact companies negatively over a long period of time. This includes fines, lawsuits (and subsequent legal costs), penalties, reduced sales and loss of customers to competing businesses, job losses and other numerous repercussions. Achieving and validating Level 1 PCI compliance goes a long way in ensuring that multiple security controls and processes are put in place to protect sensitive data from compromise.

PCI compliance is not much of a choice to any company that values the long-term security of its customers and bottom line as well as its continuity. Every business that accepts payment information from its customers should consider achieving PCI compliance as soon as its able to dedicate resources towards that objective.

This PCI sub-requirement requires every business to document and maintain a detailed list of all their assets involved in the process of payment card processing to ensure that each asset receives all the protection required for it to meet configuration standards. 

Maintaining this inventory is important because the PCI DSS requirements apply to all systems within the company’s PCI DSS scope (which is defined according to the PCI DSS scoping guidance document as all people, processes, and technologies that interact with or could otherwise impact the security of cardholder data) and there is a risk of having systems which are within the PCI scope that are unaccounted for, and therefore unprotected. 

To ensure that your asset inventory document is complete and accurate, it’s important to maintain asset management policies and procedures and distribute them to the personnel responsible for maintaining the inventory. Also, automated processes such as network discovery scans will help ensure that all assets are discovered, accounted for, and secured using the business’s configuration standards. Supporting documentation such as network diagrams may also be used to verify the accuracy of the asset inventory. 

This PCI requirement requires every business that stores cardholder data to put in place a number of controls to ensure that this data is stored securely and not disclosed to unauthorized parties. This doesn’t only include methods for protecting stored cardholder data such as hashing, encryption, truncation, masking and tokenization, but also data retention policies, cardholder data flows (to ensure that all systems that interact with cardholder data are accounted for), and key management policies and procedures to ensure that the keys used to encrypt cardholder data are handled and stored as securely as possible and accessed by as few key custodians as possible. 

This requirement also defines which parts of cardholder data can be stored after authorization (such as cardholder name, Primary Account Number/Credit card number, card brand, expiration date, etc) and which parts cannot (full track data, PIN data and the 3-digit card verification code/value on the back of the card) be stored, unless the business performs, facilitates or supports card issuing services or has a legitimate business need to store that data. Also, masking must be implemented to ensure that no more than the first six and last four digits of a PAN is visible unless there’s a legitimate business need to view the full PAN. 

To achieve compliance with this requirement, a company must identify all systems that interact with cardholder data, ensure that cardholder data is only stored in authorized and secured storage locations, and that it doesn’t exist in locations such as system logs and end user messaging tools. This can be verified using a PAN discovery scanner or detected manually. Cardholder data must also be deleted periodically and securely when it’s no longer needed in line with the documented data retention policy. A good rule of thumb is to never store cardholder data unless it is required. Lastly, key management policies and procedures must be documented, maintained, and disseminated to key custodians to ensure that that the cardholder data as well as the encryption keys are protected from disclosure and misuse. All individuals who have access to cardholder data and the encryption keys used to protect them must be documented. 

This PCI sub-requirement requires every system within the PCI scope to be protected from known vulnerabilities by installing critical or urgent patches within a month of release. All other security patches may be installed within a reasonable time frame of up to three months from release. This requirement also requires policies and procedures for the patch management process to be created, documented, and approved by management. 

Depending on the size of your business, it may be difficult to detect the missing patches for the operating systems and installed software on your critical infrastructure. However, patch management solutions can be used to automatically detect and install selected patches. 

A good practice would be to patch applicable systems in phases after they have been verified in a testing or staging environment. It’s also recommended to carry out reboots in phases (if required by your operating system after patching) to ensure as little downtime disruption as possible. 

This PCI sub-requirement requires every company that develops custom software to ensure that all software released is developed in a secure manner (i.e. with security incorporated in each phase of the software development lifecycle) and free from the most common coding vulnerabilities.

This can be challenging for your company since it requires every software developer to receive and complete training on up-to-date secure coding techniques at least annually to ensure that application developers have the necessary skills to avoid common coding vulnerabilities. 

This secure coding training can be developed in-house or provided by a third party. It is also important to note that the list of common coding vulnerabilities identified in the PCI requirements are a minimum baseline. It’s the responsibility of the company to remain up to date with vulnerability trends and include measures against the threats in its secure coding training and practices. 

A good practice to ensure compliance with this requirement would be to have static and dynamic application security testing take place early and often during the software development lifecycle. This complements the secure coding training and prevent common coding vulnerabilities from being introduced into production builds of your company’s software. 

This PCI requirement requires every business to ensure that all user activity that leads to cardholder data being accessed is logged and monitored. This includes not only ensuring the completeness and accuracy of the security and/or event logs, but it’s ensuring that they’re protected from tampering and only viewed by authorized users. 

To achieve this, all logs must be automatically generated and detailed enough (including details such as username, event, time and date of event, affected resource, etc) to link all access to individual accounts, including and especially privileged accounts. This also includes activities like invalid login access, changes to privileged accounts (including privilege escalation), changes to logging (including pausing, stopping, deletion etc) and changes to system-level objects. Logs must also be backed up centrally and reviewed periodically, with documented policies and procedures defining the periodic (at least daily) review of security events and the subsequent follow-ups and investigations as a result of the reviews if exceptions and anomalies are detected. 

The procurement of a Security Information and Events Management (SIEM) solution will be extremely beneficial to any business that seeks to pass this requirement. When configured properly, the SIEM can be used to automatically collect and analyze logs from various systems and then store these logs centrally where they can be accessed and analyzed frequently by the responsible personnel. It can also be used to notify users of events and alerts and play a role in preventing or responding to incidents. 

A SIEM is a very useful tool to ensure that critical systems interacting with cardholder data (as long as they send over complete and accurate logs) are properly monitored for threats and aids the investigation and incident response processes greatly. 

This PCI requirement requires every business to test all systems and processes for vulnerabilities, as well as remediate all found vulnerabilities and exploits as soon as possible. It also outlines the need to have solutions in place such as intrusion detection systems (IDS) or intrusion prevention systems (IPS) and file integrity monitoring (FIM) tools to prevent breaches as well as documented policies and procedures guiding all of the above. Lastly, a process to detect and identify unauthorized wireless access points has to be created to ensure network security and other infrastructure. 

Passing this requirement can be a bit challenging depending on the resources available to your company. It is important to use a rogue access point detection solution at least quarterly to ensure that there are no unauthorized wireless access points in your network which can lead to a breach. Internal and external vulnerability scanning schedules must be implemented and documented (preferably monthly), and an ASV must be used to carry out the external scanning. In both cases, all vulnerabilities must be remediated, with rescans carried out until a passing scan is achieved quarterly. 

Internal and external penetration testing must be carried out with an industry-accepted methodology and by qualified personnel. A qualified internal resource can carry out internal testing, or a qualified external third party can carry out both the internal and external penetration testing, at least annually. All exploits found during penetration testing must be resolved as soon as possible, and the penetration test is not considered successful until a rescan is carried out to ensure remediation. Service providers will also have to carry out penetration testing on segmentation controls every six months. Lastly, the IDS/IPS and FIM solutions must be implemented and configured properly and monitored in accordance to PCI requirement 10. 

The last of the 12 PCI requirements is the least technical, and is centered around the creation, implementation, maintenance, and dissemination of security policies and procedures to employees to ensure that they’re aware of their security responsibilities. This includes third parties such as contractors, vendors and business partners, if applicable. It outlines the security policies and procedures that every company seeking PCI compliance must establish and review at least annually. 

To pass this requirement, each company must create policies and procedures including but not limited to the following: 

• A risk assessment process to identify all critical assets, threats and vulnerabilities, as well as risk mitigation strategies. The process must also include annual risk assessments.
• Technology usage policies defining the appropriate and secure ways to use technology owned by the business, including approval procedures, inventories, remote-access technology policies, acceptable locations, etc. to ensure that risk to these technologies is minimized.
• Security policies and procedures that ensure that the security roles and responsibilities of all employees are clearly defined and documented.
• Information security management policies aimed at the teams and/or individuals responsible for information security defining the monitoring and analysis of security alerts, log reviews, incident response, account administration and access control.
• A formal security awareness program educating personnel about their security responsibilities upon hire that happens annually.
• Annual reoccurring process requiring all personnel to acknowledge that they’ve read the applicable security policies and procedures.
• HR/Recruitment policies requiring thorough screening (including background checks) for all personnel before hire to reduce the risk of unauthorized access and use of cardholder data by employees.
• A third party/vendor management policy defining security requirements for all third parties that cardholder data is shared with, including an acknowledgment that they are responsible for ensuring the security of data that is shared with them, as well as requiring thorough vetting for all third parties prior to their engagement.
• An incident response plan outlining the procedures and personnel required to ensure that all incidents are responded to as quickly and efficiently as possible to minimize the impact on the security of cardholder data.