If your business is involved in the processing of credit card payments, you are likely required to comply with the Payment Card Industry Data Security Standards (PCI DSS). Navigating the questions around PCI DSS compliance and what you need to do as a part of this mandate can be overwhelming. Taking these questions one at a time will help you sift through all the requirements and guidance for PCI DSS compliance.
What is PCI DSS Compliance?
PCI DSS compliance requirements promote cardholder data security and foster the adoption of consistent data security measurements on a global scale. The baseline technical and operational requirements are applied to all entities involved in credit card processing, including merchants, processors, acquirers, issuers, and third-party service providers.
There are two critical components to understanding PCI DSS compliance: differentiating types of data when PCI DSS refers to “account data” and defining the scope of what needs to be compliant. Account data is not just the account number or PIN, but is broken down into two categories: Cardholder Data and Sensitive Authentication Data.
Examples of Account Data
1. Cardholder Data
- Primary Account Number (PAN)
- Cardholder Name
- Expiration Date
- Service Code
2. Sensitive Authentication Data
- Full track data (magnetic-stripe data or equivalent on chip)
- Card Verification Code
- PINs/PIN blocks
Across the PCI DSS requirements there are references to account data, cardholder data, and sensitive authentication data. PCI DSS does not consider these terms interchangeable, so it’s important when reviewing PCI DSS requirements to understand which data is being referenced.
Understanding the types of account data you deal with is a critical first step in understanding the scope of your environment. PCI DSS requirements apply to the Cardholder Data Environment (CDE) which is the system components, people, and processes that store account data. It also includes systems that may have nothing to do with the storage or processing of account data but have unrestricted connectivity to or could impact the security of the CDE.
Determining how you deal with account data applicable to your organization, and where it’s stored, processed or transmitted across your environment is important in defining and limiting the scope of items that are required to be compliant to this standard.
Overview of PCI DSS Requirements
Now that we’ve established what data PCI DSS compliance pertains to, take a look at the standards themselves. The standards provide a baseline of technical and operational requirements designed to protect account data. There are 12 principal requirements across 6 areas that the standard organizes their controls.
PCI Data Security Standard – High Level Overview |
|
| Area | Requirement |
| Build and Maintain a Secure Network and Systems | 1. Install and Maintain Network Security Controls
2. Apply Secure Configurations to All System Components |
| Protect Account Data | 3. Protect Stored Account Data.
4. Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks |
| Maintain a Vulnerability Management Program | 5. Protect All Systems and Networks from Malicious Software
6. Develop and Maintain Secure Systems and Software |
| Implement Strong Access Control Measures | 7. Restrict Access to System Components and Cardholder Data by Business Need to Know
8. Identify Users and Authenticate Access to System Components 9. Restrict Physical Access to Cardholder Data |
| Regularly Monitor and Test Networks | 10. Log and Monitor All Access to System Components and Cardholder Data
11. Test Security of Systems and Networks Regularly |
| Maintain an Information Security Policy | 12. Support Information Security with Organizational Policies and Programs |
Each of the 12 PCI DSS requirements listed above has sub-sections with a total of 250 detailed controls that correlate with each principal requirement. The standard has undergone numerous updates since its inception with the most recent being version 4.0, released March 2022.
One of the most significant feature differences in version 4.0 is giving organizations the option to choose a “customized approach” instead of the standard approach which requires evaluation against all controls within the principal requirements.
This customized approach allows entities to implement controls to meet the requirement’s stated Customized Approach Objective. This customized approach is an innovative and unique method to allow flexibility to customers with varied environments to maintain the PCI DSS objectives without strict adherence to the defined controls. Although flexible, the method does have its own challenges. There are no defined testing procedures as the controls that an entity will choose will be customized. This requires assessors to create testing procedures based on this design. PCI SSC has intended this customized approach model for risk-mature entities that have robust risk management programs capable of evaluating and mitigating their unique risk environments.
PCI Compliance Checklist Based on Merchant Levels
What you must do to show PCI DSS compliance depends on the payment brands you work with and what level or tier of merchant your organization is. The merchant levels range from 1-4 and have similar criteria across the payment brands based upon how many transactions of that payment brand are processed annually.
| Merchant Level* | Criteria | Compliance Requirement |
| Level 1 |
|
|
| Level 2 |
|
|
| Level 3 |
|
|
| Level 4 |
|
|
* Neither Discover, American Express, or JCB has a Level 4 designation. Discover and American Express stop at Level 3; JCB has just two merchant levels.
As listed in the chart above, any merchant that is considered a Level 1 must obtain an external assessment by a Qualified Security Assessor (QSA). This QSA will allow you to complete a Report on Compliance (ROC) which is the reporting tool used to document the results of your PCI DSS assessment. For any of the other merchant levels that either don’t have enough transactions to be considered level 1 or have not experienced a cyber security breach can evidence compliance with the Self-Assessment Questionnaire (SAQ).
There are multiple versions of the SAQ to meet various merchant scenarios (eg., e-commerce, and manual entry). All organizations, regardless of level, are required to submit an Attestation of Compliance (AOC). The AOC is the official PCI SSC form for merchants and service providers to attest to the results of a PCI DSS assessment, as documented in a SAQ or ROC from a QSA. The last thing all organizations must provide is a quarterly external vulnerability scan that’s been performed by an Approved Scanning Vendor (ASV).
How to Be PCI Compliant
The process for how to be PCI compliant can be intricate but if you strip it down to the critical components and follow one step at a time, any organization can become PCI compliant.
- Where is my organization currently?
- Find out where your organization stands in the process to becoming PCI DSS compliant. Are you starting from scratch and know your merchant level or are you part way there?
- Perform a Gap Assessment.
- Evaluate what PCI DSS requirements you have in place and what documentation you need to support those requirements.
- Develop a roadmap or action plan to address identified gaps.
- Implement missing security controls and security awareness training.
- Based on your gap assessment implement any missing security controls or documentation for those controls to evidence compliance.
- Protecting cardholder data is not the job of one person, educate your organization on the importance of this objective and help educate.
- Obtain your vendor scans and audits.
- Once you’ve addressed your control gaps, it’s time to get your quarterly vulnerability scans performed.
- If you’re a Level 1 merchant, have a QSA perform an audit of your environment or conduct an internal audit to evaluate your environment.
- Submit documentation and continuously improve.
- Once you have your required scans and assessments completed, you can submit documentation based on your compliance level.
- Each time an evaluation is completed is an opportunity for you to review any gaps or opportunities for improvement and make changes for the next evaluation.
Protecting cardholder data and showing your PCI DSS compliance is not a small feat, but can be made easier with the right tools and processes in place. Once you have an understanding of what is required and the preventative controls in place, the secondary challenge can often be in demonstrating that compliance.
This is where tools like security information and event management (SIEM) have a unique ability to not only fulfill many of the monitoring requirements of PCI DSS, but showcase your compliance by demonstrating a record of what has and has not occurred in your Cardholder Data Environment.
LogRhythm has been providing PCI DSS support for over a decade. If you need help evidencing your PCI DSS journey, check out how LogRhythm can help you.