Table of Contents
- What Is PCI Compliance?
- Why Is PCI Compliance Important?
- The 12 Requirements for PCI DSS Compliance
- What are the four levels of PCI Compliance?
- PCI DSS Versions
- Is PCI Compliance Legally Required?
- Penalties and Consequences for Noncompliance [QG1]
- How to Implement a Successful Incident Response Plan for PCI DSS
- Get Help with PCI Compliance
What Is PCI Compliance?
The Payment Card Industry (PCI) Security Standards Council (which is backed by the leading credit card institutions) developed a set of standards known as the Payment Card Industry Data Security Standard (PCI DSS), to secure credit card transactions and protect related data.
Payment card companies usually require organizations to comply with PCI standards under their network agreements. PCI standards cover merchant processing and additional requirements such as encryption of Internet transactions.
While there is no specific regulation mandating PCI compliance, court precedent treats it as mandatory for all companies processing payment card data. The Federal Trade Commission (FTC) monitors credit card processing to protect consumers. Organizations processing payment card data must comply with standards to ensure the security of transactions and avoid legal penalties.
This is part of an extensive series of guides about compliance management.
Why Is PCI Compliance Important?
Any organization that handles payment card transactions or data must ensure they comply with PCI DSS and other applicable standards. The data security standards described in PCI DSS help organizations enhance their security profile and protect themselves against the business and legal repercussions of a data breach.
Regardless of an organization’s size, credit card companies such as American Express, Visa, and Mastercard require PCI compliance. Complying with PCI standards:
- Allows organizations to accept payment cards or transmit, process, and store payment card data
- Reduces the risk of payment card data loss
- Reduces the risk of customer identity theft
- Enables organizations to detect, prevent, and remediate data breaches
If an organization fails to maintain PCI compliance, it could result in fines or the inability to accept payment cards and online transactions.
The 12 Requirements for PCI DSS Compliance
1. Use and Maintain Firewalls
Firewalls are essential for controlling access between trusted internal networks and untrusted external networks like the internet. To comply with PCI DSS, organizations must configure firewalls to restrict inbound and outbound traffic to what is necessary for business operations. Specific tasks include:
- Blocking any unauthorized access attempts while allowing legitimate business traffic.
- Ensuring firewalls are placed between the cardholder data environment (CDE) and the internet, as well as between internal segments where necessary.
- Regularly reviewing firewall configurations to ensure they align with security policies.
- Conducting periodic firewall rule reviews to identify and remove outdated or redundant rules.
Firewalls should also be configured to log access and traffic, which helps in auditing and identifying potential security incidents.
2. Proper Password Protections
Passwords are a common entry point for attackers, making proper password policies critical to protecting cardholder data. PCI DSS mandates organizations to:
- Eliminate the use of default passwords that come with hardware and software, as these are easily exploited.
- Implement strong password policies that require a mix of uppercase and lowercase letters, numbers, and special characters.
- Set password expiration policies (e.g., requiring users to change passwords every 90 days) and enforce password history to prevent reuse.
- Limit failed login attempts (e.g., locking out users after six failed tries) and set up automatic lockouts after a period of inactivity.
- Use multi-factor authentication (MFA) for remote access or systems with high privilege accounts.
Organizations should ensure these protections are applied to all users with access to the CDE, including administrators and third-party service providers.
3. Protect Cardholder Data
Protecting cardholder data involves ensuring that sensitive data is not exposed or retained unnecessarily. PCI DSS requires organizations to:
- Store only essential cardholder data and never store sensitive authentication data, such as full magnetic stripe, CVV, or PIN data, after authorization.
- Mask the Primary Account Number (PAN) when displaying it. For example, only the last four digits should be visible to employees unless they have a legitimate business need.
- Use encryption, tokenization, or truncation to protect stored data. PANs should be encrypted with strong algorithms such as AES-256.
- Ensure that cardholder data is stored securely, either in encrypted databases or with restricted access.
- Regularly monitor data retention policies and securely dispose of cardholder data once it is no longer needed.
These measures reduce the risk of unauthorized access to stored cardholder data.
4. Encrypt Transmitted Data
When cardholder data is transmitted over public or unsecured networks, encryption is critical to protecting it from interception. PCI DSS mandates that:
- Cardholder data must be encrypted using strong cryptographic methods (such as TLS 1.2 or higher) when sent over the internet or other open networks.
- Strong encryption keys should be used, and encryption keys must be managed securely with strict access controls.
- Cardholder data should never be transmitted via unencrypted email or messaging services. Any transmission over wireless networks must also be encrypted.
- Organizations must use secure protocols such as IPsec, SSH, or TLS when transmitting data across internal networks.
- Digital certificates should be properly managed and renewed before expiration to ensure the integrity of secure connections.
In addition to encryption, secure transmission protocols help ensure the confidentiality and integrity of data in transit.
5. Use and Maintain Anti-Virus
Malware presents a significant risk to the security of systems that store or process cardholder data. To comply with PCI DSS, organizations must:
- Install and maintain anti-virus or anti-malware software on all systems vulnerable to malware, including workstations, servers, and point-of-sale (POS) devices.
- Ensure that anti-virus software is configured to perform automatic scans of files, applications, and systems at regular intervals.
- Set up automatic updates to the anti-virus software to ensure it can detect the latest known threats.
- Regularly review anti-virus logs and alerts to ensure that potential threats are identified and addressed promptly.
- Implement a process for responding to detected malware, including quarantining infected systems and conducting root-cause analyses to prevent recurrence.
By proactively maintaining anti-virus software, organizations can reduce the risk of malware compromising cardholder data.
6. Properly Updated Software
Keeping software up to date is critical to preventing vulnerabilities from being exploited. PCI DSS requires that:
- Organizations must install security patches for operating systems, applications, and devices within a set timeframe (typically within 30 days of release).
- This includes third-party applications, such as web browsers, database systems, and payment processing software.
- A formal process should be established for evaluating and applying security patches, including tracking available updates, testing them, and deploying them in production environments.
- Legacy software that no longer receives security updates must be phased out or otherwise secured.
- Critical updates should be prioritized to minimize the risk of known vulnerabilities being exploited.
Regular patch management ensures that systems are protected against known vulnerabilities, reducing the attack surface for potential threats.
7. Restrict Data Access
Access to cardholder data must be restricted to only those employees or systems that require it for legitimate business purposes. PCI DSS specifies that:
- Organizations must use role-based access control (RBAC) to grant access to cardholder data based on job responsibilities. Least-privilege principles should be applied, meaning employees only have access to the data they need.
- Access rights should be regularly reviewed and revoked when no longer needed, especially for employees who leave the company or change roles.
- Systems should implement mechanisms to control access based on user roles, job functions, or departments.
- Administrators should have enhanced access controls to restrict their ability to manipulate systems handling sensitive data.
Controlling access in this way helps limit the exposure of cardholder data to unauthorized personnel or external attackers.
8. Unique IDs for Access
Ensuring that every user has a unique identifier (ID) is critical for tracking and accountability. PCI DSS requires organizations to:
- Assign each user a unique ID, ensuring that actions taken on systems handling cardholder data can be traced to a specific individual.
- Avoid the use of shared or generic accounts, as this makes it difficult to trace malicious or unauthorized actions to an individual.
- Implement password policies to enforce strong authentication for each user, including administrators and third-party providers.
- Use multi-factor authentication (MFA) for any remote access to the cardholder data environment and for systems containing sensitive data.
- Log all user access to cardholder data, including successful and failed login attempts, to detect potential security incidents.
Unique IDs ensure that organizations can monitor access to critical systems, aiding in compliance audits and forensic investigations.
9. Restrict Physical Access
Cardholder data is not only vulnerable to cyber attacks but also to physical theft. PCI DSS requires organizations to:
- Restrict access to areas where cardholder data is stored (e.g., server rooms, payment terminals) using measures like locked doors, ID badges, biometric scanners, or security personnel.
- Log and monitor all physical access to sensitive areas, including visitors and maintenance personnel. Visitor access should be limited, and visitors should be escorted by authorized personnel.
- Implement surveillance or monitoring systems in sensitive areas to detect unauthorized physical access.
- Securely store paper records or physical media containing cardholder data, such as backup tapes or printed documents, in locked cabinets or rooms.
- Physically destroy any media containing cardholder data before disposal to prevent unauthorized access.
By controlling who has physical access to sensitive environments, organizations can prevent data theft or tampering.
10. Create and Maintain Access Logs
Logging access to systems that store, process, or transmit cardholder data is essential for detecting suspicious activity. To comply with PCI DSS, organizations must:
- Enable logging mechanisms on all systems that handle cardholder data, including servers, databases, network devices, and payment terminals.
- Ensure that logs capture details of user activity, including successful and unsuccessful login attempts, file access, changes to user permissions, and security events.
- Centralize log management to ensure logs are easily accessible for review and that they are protected from tampering.
- Regularly review and analyze logs to detect anomalies or suspicious activity that may indicate a security incident.
- Retain logs for a minimum period (typically one year), with immediate access to the last three months’ logs as per PCI DSS requirements.
Access logs are crucial for identifying and responding to security incidents, as well as for meeting audit and forensic investigation requirements.
11. Scan and Test for Vulnerabilities
Vulnerability scanning and penetration testing are required to identify and mitigate security weaknesses. To comply with PCI DSS, organizations must:
- Conduct internal and external vulnerability scans at least quarterly and after any significant changes to the cardholder data environment, such as new systems or network configurations.
- Engage an Approved Scanning Vendor (ASV) to perform external vulnerability scans and provide a report on compliance.
- Perform penetration testing at least annually to simulate real-world attacks and identify potential vulnerabilities that may not be captured by automated scans.
- Remediate any vulnerabilities or issues discovered during scans and tests according to a prioritized risk-based approach.
- Document the results of all scans and penetration tests, and maintain records for review by auditors or security assessors.
Regular vulnerability assessments help ensure that security weaknesses are identified and mitigated before they can be exploited by attackers.
12. Document Policies
To ensure PCI DSS compliance, organizations must establish, maintain, and document formal security policies and procedures. These policies should:
- Cover all aspects of PCI DSS compliance, including data security, access control, vulnerability management, and incident response.
- Be regularly reviewed and updated to reflect changes in technology, business processes, or compliance requirements.
- Provide clear guidance to staff on their roles and responsibilities in protecting cardholder data.
- Include a documented incident response plan, outlining steps for detecting, responding to, and recovering from security breaches involving cardholder data.
- Ensure that employees receive regular training on security policies, emphasizing the importance of PCI compliance.
Properly documented policies provide a clear framework for maintaining security and ensuring ongoing PCI DSS compliance throughout the organization.
What are the four levels of PCI Compliance?
Here are the PCI compliance levels that apply to merchants based on the volume of payment card transactions they process.
Level 1
A Level 1 merchant processes 6 million or more transactions per annum (e.g., a large international corporation). This compliance level requires third-party Quality Security Assessors (QSAs) to audit the merchant’s practices. QSAs define the audit scope, review the merchant’s data storage and paper trails, and determine PCI compliance in annual Reports on Compliance (ROCs).
Level 1 merchants must also perform quarterly network scans to complement the yearly audits using Approved Scanning Vendors (ASVs). Each merchant must then submit Attestation of Compliance (AOC) forms.
Level 2
A Level 2 merchant processes less than 6 million but more than 1 million transactions per annum (e.g., a medium-sized corporation). PCI compliance level 2 does not require a third-party auditor, but Level 2 merchants must submit ROCs based on internal audits responding to Self-Assessment Questionnaires (SAQs).
Level 2 merchants must also use ASVs to perform quarterly network scans and submit AOC forms.
Level 3
A Level 3 merchant processes less than 1 million but more than 20 thousand transactions per annum (e.g., a small corporation). The third compliance level does not require external audits or ROCs—only the completion of annual SAQs.
A Level 3 merchant must also perform quarterly network scans and submit AOC forms.
Level 4
A Level 4 merchant processes fewer than 20 thousand transactions annually. This compliance level requires merchants to complete annual SAQs and AOCs, in addition to quarterly network scans performed by ASVs.
A Level 4 merchant must use qualified resellers and integrators to install, integrate, and service point-of-sale applications and terminals.
PCI DSS Versions
PCI DSS 1.0
PCI DSS 1.0 was introduced in December 2004 as the first formal attempt to create a unified set of security standards for the payment card industry. Prior to this, individual credit card brands like Visa and Mastercard had their own security programs.
PCI DSS 1.0 established the foundation for protecting cardholder data by requiring organizations to implement basic security measures such as firewalls, password protection, and encryption. Key requirements included building and maintaining secure systems and networks, protecting stored cardholder data, and maintaining a vulnerability management program.
PCI DSS 2.0
Released in October 2010, PCI DSS 2.0 focused on improving clarity and flexibility in the standards. One of the major changes was the introduction of guidelines for risk-based security approaches, allowing organizations to prioritize remediation efforts based on risk assessments.
Additionally, PCI DSS 2.0 introduced more detailed requirements for encryption, especially around wireless networks, and clarified the responsibilities for third-party service providers in securing cardholder data. This version also expanded on the need for strong access control measures.
PCI DSS 3.0
Launched in November 2013, PCI DSS 3.0 aimed to address emerging security threats and vulnerabilities, particularly those highlighted by high-profile data breaches in the retail sector. Key updates included stricter requirements for authentication mechanisms, the implementation of more detailed guidance on vulnerability management, and the introduction of physical security controls.
PCI DSS 3.0 placed greater emphasis on continuous monitoring of security controls, rather than treating PCI compliance as a point-in-time assessment. The introduction of regular penetration testing and more frequent vulnerability scans helped organizations proactively manage security risks.
PCI DSS 4.0
Introduced in March 2022, PCI DSS 4.0 marked a significant evolution in the framework, reflecting the growing sophistication of cyber threats and changes in payment technologies. The new version introduced greater flexibility for organizations to use customized security approaches, allowing them to meet the intent of PCI DSS requirements through methods that fit their specific environments.
PCI DSS 4.0 also emphasized the need for stronger authentication measures, such as more robust multi-factor authentication (MFA) and password controls. Additionally, this version of PCI DSS emphasizes the requirement for real-time threat detection and response capabilities.
Is PCI Compliance Legally Required?
While there is no specific federal law in the United States mandating PCI compliance, companies that process, store, or transmit payment card data are contractually required to comply with the PCI Data Security Standard (PCI DSS).
Major credit card brands, such as Visa, Mastercard, American Express, and Discover, enforce PCI compliance through their network agreements with merchants and service providers. Failure to comply with these contractual obligations can result in significant financial and operational penalties, making PCI compliance functionally mandatory for businesses handling payment card transactions.
In addition, court rulings and state-level regulations have increasingly treated PCI DSS as a de facto standard for demonstrating due diligence in protecting consumer payment card data. Failure to comply may expose organizations to legal action under consumer protection laws, such as those enforced by the Federal Trade Commission (FTC), which holds businesses accountable for securing sensitive financial data.
Noncompliance could also lead to liability in the event of a data breach, increasing the risk of lawsuits and fines under various privacy and security laws, including the California Consumer Privacy Act (CCPA) and the General Data Protection Regulation (GDPR) in Europe.
Penalties and Consequences for Noncompliance [QG1]
Noncompliance with PCI DSS can lead to severe financial and reputational consequences for organizations. Penalties include:
- Fines: Credit card companies can impose fines ranging from $5,000 to $100,000 per month for PCI DSS violations, depending on the severity of the noncompliance and the size of the business.
- Increased Transaction Fees: Noncompliant businesses may be subject to higher transaction fees, raising operational costs.
- Loss of Payment Processing Privileges: In extreme cases, organizations can lose the ability to process credit card payments, crippling their ability to conduct business.
- Liability for Data Breaches: If a data breach occurs due to noncompliance, the organization could be held liable for damages, including the costs of forensic investigations, notification to affected individuals, card reissuance fees, and compensation for fraud losses incurred by cardholders.
- Reputational Damage: A data breach resulting from noncompliance can significantly harm an organization’s reputation, leading to a loss of customer trust and long-term revenue.
In sum, while PCI compliance is not technically a legal requirement, the contractual, financial, and legal risks associated with noncompliance make it essential for businesses that handle payment card data.
How to Implement a Successful Incident Response Plan for PCI DSS
Two major PCI DSS requirements help organizations implement successful incident response plans—Requirement 10 refers to logging and log management, while Requirement 12 addresses documentation, vulnerability, and risk management.
In addition to considering these two requirements, you should apply the following steps to build a PCI-compliant incident response plan:
- Prioritize assets—locate critical assets such as applications and sensitive data and classify them according to the risk they present. Assign a budget and protection strategy for each risk category.
- Document clear policies—provide employees with clear procedures for responding to incidents, including details such as roles and responsibilities.
- Build your response team—the incident response team can include full-time incident response personnel or other security or IT employees who take on responsibilities. Every individual must have a clear role.
- Educate your employees—regularly train your staff to promote security awareness and safe business practices. Ensure that all employees learn to identify and avoid infiltration attempts such as social engineering attacks.
- Inform stakeholders of the incident response plan—all stakeholders across the organization should be familiar with the incident response plan. Encourage everyone from management, legal, HR, IT, and development departments to contribute to the plan.
- Involve senior management—your incident response plan cannot succeed without the support of senior management. For example, your organization must budget for incident response tools and procedures.
- Test your incident response plan—use realistic tabletop exercises to test the effectiveness of your incident response plan. Testing your plans allows you to identify and address any weaknesses.
The Role of SIEM in PCI DSS Compliance
PCI DSS Requirements 10 and 11.5 include the implementation of regular monitoring of the network and configuration changes. PCI DSS focuses on these two aspects because system logs are critical for investigating and responding to security incidents.
When security auditing is enabled on systems in the cardholder environment, security information and event management (SIEM) systems can be used to monitor systems and generate security alerts. SIEM solutions are able to collect and correlate data from across the IT environment, including a PCI-compliant hosting environment, and from hundreds of security tools. They normalize security data and generate reports in a suitable format for regular reviews and PCI DSS audits.
Get Help with PCI Compliance
Do you need PCI-compliant hosting? Atlantic.Net stands ready to help you attain fast compliance with a range of certifications, such as SOC 2 and SOC 3, HIPAA, and HITECH, all with 24x7x365 support, monitoring, and world-class data center infrastructure. For faster application deployment, free IT architecture design, and assessment, call 888-618-DATA (3282), or email us at [email protected].
HIPAA Compliant Hosting
Authored by Atlantic.Net
- HIPAA-Compliant Hosting
- How to Make a HIPAA Compliant Website: Checklist and Guide
- Your Complete Guide to HIPAA Data Compliance
VPS Hosting
Authored by Atlantic.Net
SIEM
Authored by Coralogix