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 of PCI DSS

PCI DSS consists of 12 requirements organized into six goals. These PCI DSS requirements outline the specific security controls an organization must implement to maintain secure systems.

Goal 1: Build and Maintain a Secure Network and Systems

1. Install and Maintain Network Security Controls

Firewalls acts as the first line of defense, controlling traffic between your internal network and untrusted external networks (the internet). To be PCI compliant, you must configure secure configurations for firewalls and routers.

  • Restrict Traffic: Configure rules to deny all traffic by default and only allow connections necessary for your specific business processes. Review these firewall and router rule sets at least every six months.
  • DMZ Implementation: Place web servers in a Demilitarized Zone (DMZ) to separate them from the internal network where card data resides. No direct connections should occur between the internet and the Cardholder Data Environment (CDE).
  • Document Rules: Maintain a current diagram of your CDE and document the business justification for every open port, protocol, and service allowed through the firewall.

2. Apply Secure Configurations to All System Components

Vendor-supplied default passwords and settings are a primary vector for compromise. Hackers easily guess default credentials.

  • Change Defaults: You must change all vendor-supplied defaults (passwords, SNMP strings) immediately upon installation. This applies to operating systems, databases, applications, and network devices.
  • Hardening: Implement only one primary function per server to prevent vulnerabilities in one service from compromising another. For example, do not host a database and a web server on the same machine.
  • Inventory Management: Maintain a complete and current inventory of all system components within the scope of PCI DSS.
  • Encryption: Encrypt all non-console administrative access using strong cryptography.

Goal 2: Protect Account Data

3. Protect Stored Account Data

Minimizing data retention is the most effective way to reduce risk. You should only store cardholder data if absolutely necessary for business needs.

  • Data Retention: Implement automated processes to delete data when it is no longer needed.
  • Encryption: Render PAN (Primary Account Number) unreadable anywhere it is stored using strong cryptography like AES-256. Secure key management processes must also be in place, requiring dual control and split knowledge to access encryption keys.
  • Truncation: If the full PAN is not needed, store a truncated version (generally only the first six and last four digits).
  • Prohibited Data: Never store sensitive authentication data after authorization. This includes the full magnetic stripe data, the card verification code (CVV/CVC), or the PIN block. Even if encrypted, storing this data is a violation.

4. Protect Cardholder Data with Strong Cryptography During Transmission

When transmitting cardholder data across open, public networks (like the internet or wireless networks), it is vulnerable to interception.

  • Encryption Standards: Use strong cryptography and security protocols such as TLS 1.2 or higher. SSL and early TLS versions are no longer considered secure.
  • Wireless Security: Ensure wireless networks transmitting payment card data use industry-best practices for encryption and authentication. Never send PANs via end-user messaging technologies like email or SMS.

Goal 3: Maintain a Vulnerability Management Program

5. Protect All Systems Against Malware

Malware is a constant threat to data security.

  • Antivirus Software: Deploy anti-malware software on all systems commonly affected by malicious software.
  • Active Scanning: Configure software to perform periodic scans and generate audit logs.
  • Anti-Phishing: Ensure mechanisms are in place to detect and block phishing attacks.
  • System Evaluations: For systems not commonly targeted by malware (like mainframes), perform periodic evaluations to confirm that antivirus software is not required.

6. Develop and Maintain Secure Systems and Software

Vulnerabilities in software applications provide an entry point for attackers.

  • Patch Management: Install critical security patches within one month of release. This applies to operating systems, databases, and third-party applications.
  • Secure Coding: Train developers in secure coding techniques (e.g., OWASP Top 10) to prevent common issues like SQL injection and cross-site scripting (XSS).
  • Environment Separation: strictly separate development/test environments from production environments. Never use live cardholder data for testing or development.
  • Change Control: Follow formal processes for all changes to system components to ensuring security impact is analyzed before deployment.

Goal 4: Implement Strong Access Control Measures

7. Restrict Access to Cardholder Data by Business Need to Know

Access to sensitive cardholder data should be restricted to only those individuals whose job requires it.

  • Least Privilege: Grant users the minimum level of access necessary to perform their job functions.
  • Role-Based Access Control (RBAC): Define access rights based on job classification and function rather than identity.
  • Access Control Systems: Configure systems to deny all access unless explicitly allowed.

8. Identify and Authenticate Access to System Components

Every user with access to the CDE must have a unique ID.

  • Unique IDs: Never use shared or group accounts (e.g., “admin” or “root”) for system administration. This ensures that actions can be traced to a specific individual.
  • Multi-Factor Authentication (MFA): Implement multi factor authentication for all non-console access into the CDE for administrators and for all remote network access.
  • Password Policies: Enforce strong password policies, including minimum length, complexity, and rotation that meets PCI requirements.
  • Lockout Mechanisms: Lock out user IDs after not more than six failed attempts. Set the lockout duration to a minimum of 30 minutes or until an administrator resets it.

9. Restrict Physical Access to Cardholder Data

Physical security is as mandatory as digital security. If an attacker can physically access your servers or credit card terminals, they can bypass many digital controls.

  • Access Controls: Use badge readers, cameras, and locks to restrict physical access to sensitive areas like server rooms and data centers.
  • Visitor Procedures: Log all visitors, issue visitor badges, and keep a log of entry and exit times. Retain this log for at least three months.
  • Media Control: Strictly control and track the movement of any media (paper, backup tapes, USB drives) containing cardholder data security.
  • Device Inspection: Periodically inspect Point of Interaction (POI) devices, such as card skimmers or terminals, for tampering or substitution.

Goal 5: Regularly Monitor and Test Networks

10. Log and Monitor All Access to System Components and Cardholder Data

Without logging, you cannot detect or analyze a security compromise.

  • Audit Trails: Link all access to system components to a specific users unique ID.
  • Access Logs: Capture details such as user ID, type of event, date and time, success or failure indication, and origination of the event.
  • Retention: Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis.
  • Review: Regularly review logs for system components that store, process, or transmit sensitive payment data. Use automated tools to detect anomalies.

11. Test Security of Systems and Networks Regularly

New vulnerabilities appear daily. Maintaining PCI compliance requires active testing.

  • Vulnerability Scanning: Run internal and external network vulnerability scans at least quarterly and after any significant change in the network. External scans must be performed by an Approved Scanning Vendor (ASV).
  • Penetration Testing: Perform external and internal penetration testing at least annually to validate that your segmentation and security controls work as intended.
  • File Integrity Monitoring: Deploy file integrity monitoring (FIM) tools to alert personnel to unauthorized modification of critical system files.

Goal 6: Maintain an Information Security Policy

12. Support Information Security with Organizational Policies and Programs

Technology alone cannot secure an environment; you need strong governance.

  • Policy Creation: Establish, publish, and maintain a security policy that addresses all PCI compliance requirements. Review this policy at least annually and update it when the environment changes.
  • Risk Assessment: Perform an annual risk assessment to identify threats to customer data.
  • Personnel Screening: Screen potential hires to minimize the risk of internal attacks (e.g., background checks within the limits of local law).
  • Incident Response: Develop and test an incident response plan to ensure you can respond immediately to a data breach. Designate specific personnel to be available 24/7 for alerts.

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.

Merchant Levels

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.

Service Provider Levels

Level 1

A Level 1 service provider is one that is storing, processing, or transmitting more than 300,000 credit card transactions annually.

.

Level 2

A Level 2 service provider handles fewer than 300,000 transactions per year.

.

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.

Navigating the Validation Process

To validate PCI compliance, organizations must demonstrate they meet the PCI DSS standards.

Self-Assessment Questionnaire (SAQ)

For Level 2-4 merchants, the SAQ is a PCI Compliance checklist used to self-validate compliance. There are different types of SAQs depending on how you accept credit card payments:

  • SAQ A: For merchants who outsource all cardholder data functions to compliant third-party service providers and retain no card data.
  • SAQ D: For merchants who store cardholder data or do not fit into other SAQ categories. This is the most comprehensive type.

Qualified Security Assessor (QSA)

Level 1 merchants and service providers require an onsite audit by a PCI Qualified Security Assessor. The QSA verifies that all controls are in place and effective. They produce the Report on Compliance (RoC), which is submitted to the acquiring bank.

Approved Scanning Vendor (ASV)

Regardless of level, most organizations require quarterly external vulnerability scans. An Approved Scanning Vendor is a company authorized by the PCI SSC to perform these scans to validate that the external-facing IP addresses are free of known vulnerabilities.

Common PCI Compliance Violations

Many organizations fail to maintain compliance due to oversight or negligence. Common violations include:

  • Storing Prohibited Data: While merchants may store the Primary Account Number (PAN) if encrypted, storing “sensitive authentication data” is strictly forbidden. A frequent technical oversight occurs when debug logs or troubleshooting files inadvertently capture the full magnetic stripe data (Track 1 or Track 2 data) or the CVV2/CVC2 values during transaction processing.
  • Weak Access Controls: This often manifests as the use of generic, shared administrative accounts (e.g., “admin,” “root,” or “administrator”) rather than unique user IDs. Additionally, failing to immediately revoke access credentials for terminated employees or vendors creates “orphan accounts” that attackers can exploit.
  • Unencrypted Transmission: Violations occur when credit card data is transmitted over open protocols like FTP, Telnet, or HTTP. This also extends to internal ticketing systems or chat applications (like Slack or Microsoft Teams) where support staff might improperly copy-paste PANs to troubleshoot customer orders.
  • Outdated Software: PCI DSS requirements mandate that critical security patches be installed within one month of release. Organizations often fail this due to a lack of automated patch management for third-party applications (like Java, Adobe Flash, or custom web apps), focusing only on the Operating System.
  • Insecure Wi-Fi: Operating wireless networks that are not properly segmented via firewalls from the cardholder data environment (CDE) is a major violation. Furthermore, failing to perform quarterly scans for unauthorized “rogue” wireless access points allows attackers to attach hardware to the network physically.

Penalties and Consequences for Noncompliance

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.

Maintaining PCI Compliance

Achieving PCI compliance is not a one-time event; it is an ongoing process. To effectively maintain secure systems, you must integrate security into your daily business processes and its recommended to hire internal security assessors.

  1. Continuous Monitoring: Use automated tools to monitor access logs and network traffic 24/7.
  2. Regular Training: Educate employees on data security standard PCI protocols and the importance of protecting sensitive data.
  3. Vendor Management: Verify the compliance status of all third-party payment processor partners and hosting providers.
  4. Scope Reduction: The most effective way to simplify compliance is to reduce the scope. Use tokenization or outsource payment pages to keep payment card industry data off your local networks.

Partnering with a PCI Compliant Hosting Provider

Navigating the Payment Card Industry Security Standards Council regulations requires expertise and infrastructure. Atlantic.Net provides PCI compliant hosting solutions designed to help you meet these rigorous demands.

Our hosting environment addresses key physical and network security requirements, including:

  • Physical Security: Our data centers feature multi-layered access controls, including biometric scanners and 24/7 surveillance, satisfying the requirement to restrict physical access.
  • Network Defense: We provide managed firewalls and intrusion detection systems to protect cardholder data at the network edge.
  • Audit Support: Atlantic.Net is audited by independent third parties for SOC 2, SOC 3, and HIPAA compliance, providing a solid foundation for your compliance efforts.

By choosing a provider that understands PCI compliance standards, you can focus on your core business while ensuring your customer data remains secure.

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].

PCI Compliant Hosting

Authored by Atlantic.Net

GDPR Compliance

Authored by Exabeam

DORA Regulation

Authored by Faddom