PCI DSS Compliance

The Payment Card Industry Data Security Standard (PCI DSS) is a set of security controls  designed to ensure that all companies that accept, process, store, or transmit credit card information maintain a secure environment. PCI DSS was created by the PCI Security Standards Council, an independent body founded by major payment card brands including Visa, MasterCard, American Express, Discover, and JCB International. 

This guide covers all key aspects of PCI DSS compliance and answers common questions from organizations new to the PCI DSS compliance process. Much of the information in this guide is sourced from the PCI Security Standards Council, the creator of the PCI Data Security Standards and the definitive authority on this subject. Once you have read this guide, we recommend heading over to the PCI Security Standard Council Website to continue your learning process.

What is PCI DSS?

Whenever a business accepts, processes, or transmits payment data (e.g., credit or debit cards), it opens itself up to the risk that such data will be stolen. Hackers and cyber criminals want your customers’ credit card data. By obtaining the Primary Account Number (PAN) and sensitive authentication data, a thief can impersonate the cardholder, use the card, and steal the cardholder’s identity. 

Data breaches compromising sensitive cardholder data are incredibly common. In 2018 alone, $24.26 billion was lost due to payment card fraud worldwide, and the United States took the lead as the most credit fraud-prone country, with 38.6% of reported card fraud losses. Meanwhile, identity theft was the third largest cause of fraud in the US. in 2018. 

When businesses don’t take precautions to secure their systems and network, they’re likely to be targeted. Sensitive cardholder data can be stolen from many places, including compromised card readers, paper stored in a filing cabinet, data in a payment system database, hidden cameras recording entry of authentication data, or a secret tap into your store’s wireless or wired network.  

In 2006, major payment brands American Express, Discover, JCB International, MasterCard, and Visa Inc. came together to address the vital need to have a secure payment ecosystem. These companies formed the Payment Card Industry Security Standards Council with the mission of helping all merchants, service providers, and software developers and manufacturers of payment applications and devices understand and implement a set of security standards designed to ensure adequate protection of cardholder data. 

To fulfill this mission, The Council created the PCI Data Security Standards (PCI – DSS) — a set of technical and operational requirements for organizations accepting or processing payment transactions, and for software developers and manufacturers of applications and devices used in those transactions. By following these standards, organizations can keep their defenses up and minimize the chances of suffering from costly attacks aimed at stealing cardholder data.

Does your business need to be PCI DSS compliant?

Maintaining payment security is required for all entities that store, process, or transmit cardholder data. In fact, the security benefits of maintaining PCI DSS compliance are essential to the long-term success of organizations that accept, process or transmit cardholder data. Being PCI DSS compliant helps your organization maintain trust with customers who use their cards to purchase your products and services. 

Last but not least, the consequences of not protecting cardholder data are severe. The liabilities your organization may face when you experience a security breach that results in payment card data being compromised include: 

What are the common PCI DSS control failures?

The founding members of the PCI Security Standards Council continually monitor occurrences of account data compromise. Forensic analysis of compromises has shown that common security weaknesses, which are addressed by PCI DSS controls, are often exploited because PCI DSS controls either were not in place or were poorly implemented when the compromises occurred. 

Generally speaking, understanding the PCI requirements for the specific environment that addresses controls is the first step. There are 4 levels. At a minimum, you must select and complete the applicable self-assessment questionnaire (SAQ). You can summarize common control failures into several buckets: network configurations, network segmentation, data encryption, basic system configurations, physical security, and policies and procedures. Be sure to maintain PCI compliance at all times, not just before an assessment is scheduled.

Examples of common PCI DSS control failures include: 

When should you consider PCI DSS compliance?

Given the severe consequences of non-compliance, you shouldn’t take any risks by handling payments before receiving official validation of compliance. In other words, you need to become PCI-DSS compliant before accepting any card data from clients and customers.

What are the requirements specified in PCI DSS?

If you accept or process payment cards, the following standards apply to you.

Goals	PCI DSS requirements
Build and maintain a secure network	1. Install and maintain a firewall configuration to protect cardholder data2. Do not use vendor-supplied defaults for system passwords and other security parameters
Protect cardholder data	3. Protect stored cardholder data 4. Encrypt transmission of cardholder data across open, public networks
Maintain a vulnerability management system	5. Use and regularly update anti-virus software or programs 6. Develop and maintain security systems and applications
Implement strong access control measures	7. Restrict access to cardholder data to a need-to-know basis 8. Assign a unique ID to each person with computer access 9. Restrict physical access to cardholder data
Regularly monitor and test networks	10. Track and monitor all access to network resources and cardholder data11. Regularly test security systems and processes

What is the process for becoming PCI DSS compliant?

The PCI DSS compliance journey involves three steps: 

What is a qualified security assessor?

A qualified security assessor is a data security firm that is approved by the PCI Council to perform on-site PCI Data Security Standard Assessments. The Assessor will: 

You can visit the PCI Security Standards Council for a list of all Qualified Security Assessors.

What is an approved scanning vendor?

An approved scanning vendor is a data security firm that uses a scanning solution to determine whether or not the customer meets the external vulnerability scanning requirement. Approved Scanning Vendors are qualified by the PCI Security Standards Council to perform external network and system scans as required by the PCI Data Security Standard.

You can visit the PCI Security Standards Council for a list of all Approved Scanning Vendors.

What are the compliance validation levels for PCI DSS?

What you must do to become compliant will depend on your designated compliance level, which is determined by the individual payment brands.   

Speaking generally, merchants and service providers with low transaction volumes (e.g., under 50,000 card transactions per year) will be designated to a lower validation level. Such organizations will need to complete annual self-assessments, have those self-assessments certified by Senior Management, schedule quarterly network scans conducted by approved scanning vendors, and submit all reports to their acquiring bank. 

Merchants with high volumes of transactions (e.g., over 2.5 million card transactions per year) will be designated to a higher validation level. Such organizations will be required to go through annual on-site security examinations by a Qualified Security Assessor (QSA) and submit reports of quarterly network scans conducted by an approved scanning vendor. 

For an example of how payment brands designate validation levels and the requirements for each level, check out the reporting requirements for merchants and service providers from American Express below.

Source: American Express 

Levels	Level definition	Requirements
Level EMV	50,000 or more American Express Chip-enabled Card transactions per year with at least 75% made on an EMV-enabled (Chip-enabled) terminal capable of processing contact and contactless American Express transactions	Annual EMV attestation (required). This is a self examination of the PCI compliance status for equipment, systems, networks and their components where cardholder data or sensitive authorization data (or both) are stored, processed or transmitted.  You must complete the AEA and have it certified by your CEO, CFO, CIO or principal. Results must be submitted to Amex annually.
Level 3	<50,000 American Express card transactions per year (merchants only, not applicable to service providers)	Annual self assessment questionnaire recommended. This is a self-examination of the equipment, systems, networks and components where Card Member information is stored, processed, or transmitted using the PCI Security Standards Self-Assessment Questionnaire (“SAQ”). You may complete the questionnaire and have it certified by your CEO, CFO, CIO or principal. Results may be submitted to us annually. Quarterly network scan (recommended) This is a remote test of your Internet-connected computer networks and web servers for potential vulnerabilities.An Approved Scanning Vendor (ASV) must perform the exam. Then you must complete and submit the ASV’s Attestation of Scan Compliance (“AOSC”) or the executive summary of findings of the scan to us every 90 days.
Level 3 Designated	Less than 50,000 American Express Card Transactions per year and has been designated by American Express as being required to submit validation documents. (merchants only; does not apply to service providers).American Express will contact these designated merchants and provide them details for reporting their security status by submitting PCI validation documents.	Annual Self Assessment Questionnaire (required)This is a self-examination of the equipment, systems, networks and components where Card Member information is stored, processed, or transmitted using the PCI Data Security Standards Self-Assessment Questionnaire (“SAQ”).You must complete the questionnaire and have it certified by your chief executive officer, chief financial officer, chief information security officer or principal. Results must be submitted to us annually. Quarterly Network Scan (required)This is a remote test of your Internet-connected computer networks and web servers for potential vulnerabilities.An Approved Scanning Vendor (ASV) must perform the exam. Then you must complete and submit the ASV’s Attestation of Scan Compliance (“AOSC”) or the executive summary of findings of the scan to us every 90 days.
Level 2	50,000 to 2.5 million American Express Card transactions per year (Service providers: less than 2.5 million transactions)	Annual Self Assessment Questionnaire (required)This is a self-examination of the equipment, systems, networks and components where Card Member information is stored, processed, or transmitted using the PCI Data Security Standards Self-Assessment Questionnaire (“SAQ”).You must complete the questionnaire and have it certified by your chief executive officer, chief financial officer, chief information security officer or principal. Results must be submitted to us annually. Quarterly Network Scan (required)This is a remote test of your Internet-connected computer networks and web servers for potential vulnerabilities.An Approved Scanning Vendor (ASV) must perform the exam. Then you must complete and submit the ASV’s Attestation of Scan Compliance (“AOSC”) or the executive summary of findings of the scan to us every 90 days.
Level 1	2.5 million or more American Express Card transactions per year (or if you’ve been selected a Level 1 by American Express)	Annual On-site Security Assessment Report (required)This is a detailed on-site examination of the equipment, systems, networks and components where Card Member information is stored, processed, or transmitted.Either a Qualified Security Assessor (QSA) performs the exam, or you perform the exam and have the results certified by your chief executive officer, chief financial officer, chief information security officer or principal. Results must be submitted to us annually. Quarterly Network Scan (required)This is a remote test of your Internet-connected computer networks and web servers for potential vulnerabilities.An Approved Scanning Vendor (ASV) must perform the exam. Then you must complete and submit the ASV’s Attestation of Scan Compliance (“AOSC”) or the executive summary of findings of the scan to us every 90 days.

For specific questions about compliance validation levels and what you need to do to receive validation, you’ll need to contact your acquiring financial institution or payment card brand. 

Once you know what compliance level to aim for, you’ll need to submit the validation requirements to your acquiring bank, which will then report your compliance status to the payment card brand.

Where are PCI DSS controls required and which systems need to be protected?

Implementing PCI DSS starts with scoping, a process that involves identifying all system components that are located within or connected to the cardholder data environment (CDE). 

Your CDE is made of people, processes, and technology that interact with cardholder data or sensitive authentication data. To determine what’s in-scope, you’ll need to look at internal systems and networks as well as all connections from third-party vendors (e.g., business partners, firms providing remote support services).  All systems that interface with the PCI processing or computing environment should be protected.

The current PCI DSS standard is 4.0.1. The controls required will depend on the PCI environment (I.e. level, SAQ), including the SAQ to complete. Some environments require a third party QSA to complete an assessment. The PCI Data Security Council maintains documents here.

You must identify all locations and flows of cardholder data to ensure all applicable system components are included as in-scope for the PCI Data Security Standard assessment. Scoping should be done annually and must occur prior to the annual assessment. 

The controls that should be implemented for PCI DSS environments are outlined below:

To visualize your systems and how they interact with your cardholder data, developing a network diagram is a helpful step (and your PCI DSS assessor will need to see it at the time of the assessment). For details on how to develop a network diagram, check out this article. 

The general guidance provided by the PCI Security Standards Council is to start with the assumption that everything is in scope until verified otherwise. 

The PCI DSS points out that the CDE is really just the starting point when accurately determining your PCI scope. They strongly recommend organizations evaluate not only the CDE, but also the flow of cardholder data in and out of the CDE, reminding them that: 

Ways to reduce the scope of PCI DSS

There are a few ways for you to reduce the scope and subsequently reduce your compliance costs, operations costs, and the risk associated with interacting with payment card data. 

Don’t store cardholder data 

The best step you can take to protect cardholder data and reduce the PCI scope is to not store any cardholder data you do not need. For instance, if you do not store the primary account number (PAN), the PCI DSS does not apply to that area of your organization and the scope of the assessment can be reduced. 

Segmentation

One common way to reduce the number of in-scope systems within the CDE is to apply segmentation. According to PCI DSS, “To be considered out of scope for PCI DSS, a system component must be properly isolated (segmented) from the cardholder data environment (CDE), such that even if the out-of-scope system component was compromised it could not impact the security of the CDE.” 

Segmentation involves using additional controls to separate systems with different security needs. Segmentation can consist of logical controls, physical controls, or a combination of both. These controls would keep your payment card processing systems from interacting with your back office systems. 

Common segmentation methods for reducing PCI DSS scope include:

Depending on the complexity of your environment, segmenting your network can be challenging. Here’s a quick overview of a logical process for segmenting your network. You may need to reach out to a QSA to assist you in this work. 

Tokenization

Tokenization is the process of removing sensitive data such as payment card information from your business systems by replacing it with an indecipherable token (a string of numbers) and storing the original data in a secure cloud data vault. Tokenized data does not count as cardholder data. Once cardholder data is tokenized, it can flow through your environment without bringing any of those devices that store, process, or transmit the token into scope for PCI compliance requirements.

Essentially, the tokenization process allows you to outsource the handling and storage of sensitive data to a secure third party. You would need to use a tokenization platform to implement the technique. 

Outsourcing 

Using a qualified vendor that is PCI compliant can reduce your PCI exposure. For instance, you could only take payment card information through an eCommerce application hosted by a third-party PCI iFrame. You could also have a hosted contact center/customer support solution so payment card data flows through both the eCommerce and contact center environments without touching your own operational environment. 

To implement this tactic, you will need to find outsourcing vendors that have validated solutions and can demonstrate that their security posture is up to the standards specified by the PCI Security Standards Council.  

In addition to implementing these tactics, you can try to contact QSAs for additional ideas on how to reduce PCI scope.  

Caveats for reducing scope of PCI DSS 

The PCI Security Standards Council points out that reducing the number of in-scope systems for PCI DSS compliance does not reduce your need for security measures. A system that is not in scope for PCI DSS may still need certain protections, as it could still pose a risk to an organization’s network and business. 

Based on forensic analysis conducted by the Council, a common pattern in data breaches is for an attacker to target systems deemed by a business to be out-of-scope for PCI DSS, then use those systems to gain access to more systems, which eventually provide a path to systems where cardholder data (CHD) can be found. Thus, implementing scope-reduction tactics should not replace a holistic approach to securing your infrastructure. 

Determining the scope of PCI DSS compliance is a complicated topic. For further guidance, we recommend reading the Information Supplement Guidance for PCI DSS Scoping and Network Segmentation provided by the PCI Security Standards Council or consulting with a qualified professional services firm.

General tips and strategies for implementing PCI DSS

Below are some general tips for starting your PCI DSS compliance effort. These tips are designed to help you limit risks, limit the scope of your compliance effort, and keep costs contained. 

1. Limit the cardholder data you store

The best step you can take to protect cardholder data is to not store any cardholder data you do not need, and to isolate the data you do need to well-defined and controlled central locations. 

Payment brand rules allow for storage of primary account number (PAN), expiration date, cardholder name, and service data. However, if you don’t have a legitimate business purpose for storing the data, consider getting rid of it. 

Additionally, you should weigh the business benefits of storing such data against the risks and burdens associated with storage, including the risk of having the data compromised, the additional PCI DSS controls that must be applied to protect that data, and the ongoing maintenance efforts to remain PCI DSS compliant over time. 

2. Never store sensitive authentication data after authorization 

Sensitive authentication data includes the full track contents of the magnetic stripe or equivalent data on a chip, card verification codes and values, PINs, and PIN blocks. This data should NEVER be stored after authorization. 

3. Ask your POS vendor about the security of your system 

If your business uses POS in retail locations, you need to ensure that your POS vendor has sufficient security measures. In general, it’s useful to ask these vendors how they are mitigating the common control failures we outlined earlier. For instance, ask them whether default settings and passwords have been changed on systems and databases that are part of your POS system. Ask them whether your POS software is storing sensitive authentication data, such as track data or PIN blocks (this is prohibited), and if “yes,” how quickly they can delete this data. 

For a detailed list of questions to ask of your POS vendor, refer to page 5 of SAQ Guidelines and Instructions from the Council’s website. 

4. Isolate cardholder data you do need and consolidate it

You can limit the scope of a PCI DSS assessment by consolidating data storage in a defined environment and isolating the data through the use of proper network segmentation. For instance, by making sure that the cardholder data is stored on its own network segment, rather than the same network segment your employees use to receive emails and browse the internet, you can put PCI DSS controls on a portion of your network instead of the entire network.  

5. Compensating controls 

If your organization does not have the exact control specified by the PCI DSS but has other controls in place that meet the PCI DSS definition of compensating controls,  your organization can use such controls instead. However, they need to be documented appropriately.  

6. Contact a qualified security assessor for professional assistance and training 

If you’re new to the PCI DSS compliance process, we strongly encourage you to engage a security professional for help. Consider contacting a Qualified Security Assessor (QSA). QSAs have been trained by PCI SSC to conduct PCI DSS assessments and can be found here.

7. Maintain PCI DSS controls over time 

It’s not enough to set up the security controls just to pass a one-time assessment. To effectively secure these systems and payment data, your organization should continuously monitor and enforce the use of controls specified in the PCI Data Security Standard (more on this below). 

8. Additional tips for tackling common security concerns from the PCI Security Standards Council 

How does PCI-DSS fit into your overall compliance program?

Although PCI DSS covers a very specific type of information, the controls and safeguards required to protect payment are similar to those required in other cybersecurity frameworks. If you already have a robust information security program, you may already be meeting certain PCI DSS requirements and the additional work may be insignificant. 

Inversely, if you are already PCI DSS compliant and are looking to achieve compliance with other data protection standards, such as SOC 2, ISO27K, or CCPA, your PCI data security standards will likely give you a headstart. Access control, maintaining a vulnerability management system, and employee training are just a few examples of PCI DSS compliance requirements that overlap with requirements in other cybersecurity frameworks.

Using Hyperproof to become (and stay) PCI-DSS compliant

If you need to ensure compliance with PCI DSS requirements and stay on top of your security controls on a continuous basis, Hyperproof’s compliance operations software can make that work simpler and faster.  

Hyperproof allows you to easily see the requirements and controls for PCI DSS (as well as those for other common cybersecurity standards, such as SOC 2 and ISO 27001), tailor each control to your business, collect evidence of controls’ operating effectiveness, and automate repetitive administrative tasks associated with the compliance efforts. 

Hyperproof’s control crosswalking feature allows you to easily leverage your existing security controls to meet PCI DSS requirements.  Hyperproof has done the hard work of mapping out the relationships between various cybersecurity frameworks, so we know which requirements and controls are common across frameworks and/or standards.  

If you already have a robust security program that’s managed in Hyperproof (e.g., you’ve implemented SOC 2®controls), Hyperproof can tell you which of your existing controls can be applied to satisfy PCI DSS requirements to help you avoid creating duplicate controls. 

Conversely, if you’ve implemented all PCI DSS controls in Hyperproof and you’re considering becoming compliant with another infosec framework, for example, ISO 27001, Hyperproof can tell you which PCI DSS controls are similar to those required by ISO 27001 so you can become ISO 27001 compliant in a shorter amount of time. 

Beyond features that help you implement PCI DSS, Hyperproof is also built to help you maintain compliance and security over time. Hyperproof provides analytics and dashboards to help security and compliance leaders monitor their controls over time. 

Hyperproof makes it easy to see whether someone has dropped the ball on a control and re-assign control ownership as needed. For instance, with Hyperproof you can specify that John, an IT Security Analyst, needs to coordinate with an Approved Scanning Vendor to conduct a scan of your network on a quarterly basis and penetration testing once a quarter. 

Then, through Hyperproof’s dashboards, you can easily see if evidence has been provided that demonstrates the network scan has been performed. A compliance manager can also easily re-assign this task to someone else if John — the original control performer — has left your organization or is out of the office. If you’re interested in learning more about how to use Hyperproof to get started with PCI DSS,  we’d love to talk.