Payment Card Industry (PCI) compliance is required for organizations that receive, process, or transmit card payment data. The PCI compliance process protects sensitive card payment data from threats and risks while helping organizations strengthen overall cybersecurity. Read on for a step-by-step guide.
How Can You Achieve PCI Compliance?
Although the PCI compliance process broadly applies to all organizations that process card payment data, every organization must define organization-specific approaches to meeting PCI compliance goals.
The typical PCI compliance steps include:
- Understanding basics of PCI DSS
- Defining PCI DSS scope
- Completing PCI DSS self-assessment
- Remediation of PCI DSS vulnerabilities
- Reporting PCI DSS compliance
Step 1: Understanding Basics of the PCI Compliance Process
The basics of the PCI compliance process include:
- The goal of PCI DSS compliance
- Types of PCI sensitive data
- PCI Levels
Understanding key aspects of this process helps simplify PCI compliance steps.
Download Our PCI DSS Checklist
What is the PCI DSS Framework?
The PCI Data Security Standards (DSS) guides sensitive data security protections for organizations that process card payments. Broken into six goals and 12 Requirements (see below), the PCI DSS framework outlines best practices for organizations to achieve PCI compliance and secure global card payment transactions.
The PCI Security Standards Council (SSC)—formed by Founding Members Visa, Mastercard, American Express, Discover, and JCB International—oversees the overall implementation of the PCI compliance process.
What is PCI Sensitive Data?
The PCI DSS stipulates protections for sensitive card payment data, which include:
- Cardholder data (CHD), broken into:
- Primary account number (PAN)
- Cardholder name
- Service code
- Expiration date
- Sensitive authentication data (SAD), broken into:
- Full magnetic stripe data
- Card verification code (e.g., CAV2, CVC2, CVV2, CID)
- Personal identification number (PIN)
Protecting CHD and SAD is of the utmost importance in the PCI compliance process. Note that aside from the specific subgroup of payment card issuers, SAD storage is explicitly not permitted by merchants in any capacity once it is used to verify cardholder identities.
What are the PCI Levels for Merchants?
A merchant’s PCI Level is dependent on the volume and level of its transactions. PCI Level also determines the PCI compliance process for assessing and reporting compliance (see below).
According to Visa’s PCI DSS compliance guide, the four PCI levels (based on merchant transactions processed across all payment channels or global merchants) are:
- Level 1 – Over 6 million Visa transactions
- Level 2 – 1 to 6 million Visa transactions
- Level 3 – 20,000 to 1 million Visa transactions
- Level 4 – Less than 20,000 Visa transactions
The breakdown of Levels slightly varies per payment card company but generally follows the same transaction volumes for each of the four. Determining your organization’s PCI Level helps define PCI DSS scope and compliance reporting, simplifying the overall PCI compliance process.
What are the PCI Levels for Service Providers?
The PCI Levels for service providers also depend on the volume of transactions for services. Per Mastercard’s compliance guide, the service-provider PCI levels (based on third-party processing and related services) include:
- Level 1 – 300,000 or more Mastercard transactions annually
- Level 2 – 300,000 or fewer Mastercard transactions annually
Similar to the guidelines for merchants, the PCI SSC requires service providers to report compliance. Therefore, determining PCI Levels for service providers is essential to the overall PCI compliance process.
Step 2: Defining DSS Scope for the PCI Compliance Process
PCI DSS scope is simply the collection of environments, networks, and processing capabilities that store or interact with CHD in any manner. The DSS Requirements must be adhered to regarding these IT resources and their activities to ensure compliance. To reduce PCI compliance scope, organizations can implement segmentations that contain CHD and similar sensitive data to better secure and manage it.
PCI DSS implementations and annual reporting necessitates defining your organization’s compliance scope as one of the first PCI compliance steps.
Personnel and Elements Involved in PCI Sensitive Data Processing
The PCI compliance process mandates the institution of specific security policies and controls to address all aspects of adherence for the various personnel, entities, and IT resources involved in card payment processing, which oversee:
- Individuals assigned to various responsibilities and processing points, including:
- Personnel operating point-of-service terminals
- Cybersecurity teams
- Teams managing physical and cloud storage
- Environments containing CHD, including:
- Networks for CHD transmission
- Wireless access points
- Applications used for payment processing, web-hosted or otherwise
- Systems (e.g., databases for CHD storage)
- External organizations involved in CHD processing and similar activities, including:
- Third-party service providers (e.g., cloud storage, encryption)
- Equipment vendors (e.g., point-of-service terminals, physical servers)
- Business partners (e.g., partnerships requiring remote access to CHD environments)
The effectiveness of a PCI compliance process relies on addressing compliance at all stages of card payment processing, especially those with the highest sensitive data exposure risks.
Determining which entities, personnel, and IT resources are involved in your organization’s card processing operations helps simplify the PCI compliance steps, especially with the help of a PCI compliance partner.
What are the PCI DSS Requirements?
The bulk of guidance required for the PCI compliance process is found in the 12 Requirements of the PCI DSS v3.2.1. Further broken into sub-requirements, the PCI DSS Requirements address all aspects of PCI compliance and are a springboard for protecting CHD and SAD from threat risks.
The 12 Requirements of the PCI DSS (categorized by goals) include:
- Building network and system security
- R1: Configure firewalls to secure cardholder data
- R2: Avoid the use of vendor-supplied defaults for security parameters
- Protecting cardholder data
- R3: Secure stored cardholder data
- R4: Encrypt cardholder transmission over open, public networks
- Managing vulnerabilities
- R5: Secure systems against malware
- R6: Protect systems and applications
- Strengthening access control
- R7: Implement business need-to-know restrictions for access to cardholder data
- R8: Limit access to system components via user identification and authentication
- R9: Control physical access to cardholder data
- Monitoring and testing networks
- R10: Monitor access to networks and cardholder data
- R11: Test security processes and systems
- Implementing an information security policy
- R12: Establish an organization-wide information security policy
Implementing the guidelines stipulated by the PCI DSS Requirements is essential to the PCI compliance process and helps protect CHD and SAD from breach risks.
Step 3: Completing a PCI Self-Assessment
The main goal of completing a self-assessment in the PCI compliance process is to analyze the overall security of CHD processing. A PCI self-assessment also helps identify vulnerability risks and sets the stage for relevant and appropriate remediation efforts.
PCI DSS Vulnerability Assessment
Within the PCI compliance process, vulnerability assessment helps identify cybersecurity gaps in the technologies and processes involved in CHD processing.
Common vulnerabilities that pose risks to the security of CHD include:
- Poorly configured firewalls – Firewalls are critical to preventing the flow of external malicious traffic into secured CHD environments. Flaws in firewall configurations include:
- Unrestricted connections between the cardholder data environment (CDE) and external unsecured networks
- Lack of perimeter firewalls to deny access to unauthorized traffic into CDE
- Limited personal firewall functionality on personal use devices
- Use of vendor-supplied default passwords – Use of passwords or security parameters provided by vendors during system installation presents security risks. Related access control vulnerabilities include:
- Lack of industry-accepted hardening standards to address system vulnerabilities
- Poor management of cryptography protocols for vendor-supplied security parameters
- Storage of CHD and SAD – Per PCI DSS Requirement 3, CHD should only be stored under specified conditions and strictly for legal, regulatory, or business reasons. Practices that risk the security of CHD and SAD include:
- CHD storage beyond defined retention durations
- SAD storage in any capacity once cardholder authorization processes are complete (aside from payment card issuers)
- Unencrypted CHD transmission – Transmission of CHD across open, public networks risks unauthorized exposure. Specific vulnerabilities include:
- CHD transmission over public networks (e.g., Internet, 802.11 wireless, Bluetooth)
- Sending unencrypted PANs via end-user technologies (e.g., email, SMS)
Identifying vulnerabilities that present risks to payment card data security informs vulnerability assessment efforts and ensures optimal PCI compliance.
Completing a Self-Assessment Questionnaire (SAQ)
The PCI compliance process requires all PCI-eligible organizations (except those required to submit a Report on Compliance (ROC)) to complete a Self-Assessment Questionnaire (SAQ).
SAQs primarily require completing a series of “yes” or “no” questions to assess compliance to each PCI DSS Requirement and consists of two components:
- Questions to determine PCI DSS compliance
- Attestation of Compliance (AOC) to confirm compliance self-assessment
- Per Visa, organizations categorized as Levels 2 and 3 must submit AOCs, whereas Level 4 organizations are only obligated to complete an SAQ.
Merchants must fill out the appropriate SAQ, depending on the environment used to process CHD. SAQ classification depends on:
- Provision of third-party card payment services
- Storage of CHD
- Presence of card during transactions
- Type of transaction processed (e.g., e-commerce, mail order telephone order (MOTO))
- Physical or virtual terminals used for CHD collection
After completing the SAQ, the next step in the PCI compliance process is verification of the self-assessment by a Qualified Security Assessor (QSA) (see below).
However, any vulnerabilities or risks to CHD identified during the self-assessment must be remediated before completing the PCI DSS certification process.
Step 4: Remediation of PCI Vulnerabilities
Vulnerability assessment, whether internally (via SAQ completion) or externally (via QSA assessment), can reveal gaps in your organization’s PCI data security. Additionally, the DSS Requirements stipulate that merchants must have an Approved Scanning Vendor (ASV) perform quarterly vulnerability scans. Therefore, vulnerability remediation is critical to the PCI compliance process and helps close security gaps.
Your organization can employ commonly used vulnerability remediation techniques to best address PCI security gaps.
Also known as ethical hacking, penetration testing is one of the best practices for identifying remediable vulnerabilities in PCI data security. Pen-testing helps identify existing and unknown vulnerabilities within an organization’s systems by simulating threat attacks.
As part of the PCI compliance process, the PCI DSS requires organizations to implement penetration testing methodologies that address:
- Coverage of the entire CDE perimeter, including critical systems, applications, and networks
- Network testing of:
- Operating system components
- Network function components
- Internal and external networks
- Application testing to cover commonly exploited vulnerabilities (e.g., web application vulnerabilities)
- Assessment of threats and vulnerabilities experienced in the last 12 months, ensuring:
- Pen-testing at least once each year and after changes to the CDE
- Remediation of vulnerabilities and retesting systems post-remediation
- Testing of segmentation controls where applicable to protect CDE from external traffic
- Retention of data from penetration testing
Penetration testing helps identify vulnerabilities immediately, preventing materialization into breach risks. Working with a qualified Approved Scanning Vendor (ASV) will help your organization determine best practices for penetration testing in the PCI compliance process.
Threat Detection and Mitigation
Threat detection and mitigation supports vulnerability remediation efforts should an attack manage to find and exploit one. Specific tools for threat detection and subsequent mitigation in the PCI compliance process include:
- Intrusion detection/prevention – Ongoing monitoring of security threats to the CDE helps inform intrusion detection and prevention. Specifically, intrusion detection and prevention systems must address:
- Vulnerabilities in firewalls at CDE access points
- Processes for notifying relevant security personnel of suspected compromises
- Updated security components for all intrusion detection and prevention engines (including signatures and baselines)
- Incident response protocols – Timely response and mitigation of threat incidents are critical to protecting CHD and SAD. Incident response protocols must address:
- Change detection mechanisms that trigger security alerts for any changes to critical files, applications, or systems
- Comparison of critical files to identify unauthorized modifications
- Fast and efficient response processes to minimize compromise risks, should a data breach occur
Robust threat detection and mitigation tools can help your organization address vulnerabilities to PCI data security and simplify the PCI compliance process.
Step 5: Submitting PCI Compliance Reports
Compliance reporting is the final step of the PCI DSS certification process. PCI DSS reporting must be performed annually to maintain compliance.
Reporting by PCI Level
Depending on an organization’s PCI level (see above), certification of compliance requires submission of the completed reporting documentation (i.e., some combination of an SAQ, Attestation of Compliance (AOC), and Report on Compliance (ROC)). A QSA must fill out both AOCs and ROCs; while QSA involvement is not mandatory for SAQ completion, it significantly streamlines reporting efforts.
The PCI DSS certification process for merchants, based on Visa’s compliance guidance, is as follows:
- Level 1 – Required to file a ROC and AOC each year, but not an SAQ.
- Level 2 – Required to file an SAQ along with an AOC each year
- Level 3 – Required to file an SAQ along with an AOC each year
- Level 4 – Required to file just an SAQ each year
Determining your organization’s PCI Level will ensure completion of the appropriate PCI DSS certification process, especially with the help of an experienced QSA.
Role of a QSA in PCI DSS Certification
Working with a leading QSA is critical to a smooth PCI DSS certification process. Essential points to consider for discussions with a QSA include:
- Specific organization goals and needs
- Critical assets involved in processing card payments (e.g., data, systems, applications)
- Process of completing relevant documentation (e.g., ROC, AOC)
- Vulnerability assessment and remediation
- PCI DSS certification process
With the help of a QSA, your organization will protect CHD from data breaches, which have significant legal, financial, reputational consequences.
RSI Security is an experienced QSA and ASV that will guide you throughout the PCI compliance process and help minimize PCI data breach risks.
Optimize Compliance Processes, Gain PCI DSS Certification
The PCI compliance process helps protect CHD and SAD from data breaches and demonstrates your commitment to PCI data security. Virtually all organizations that collect, process, transmit, or store CHD must maintain and demonstrate compliance with the DSS.
Experienced as a QSA and ASV, RSI Security will help your organization achieve PCI compliance and gain PCI DSS certification. Contact RSI Security today to learn more.