What Are PCI Compliance Requirements? (w/Examples) + FAQs

PCI compliance means your business follows the Payment Card Industry Data Security Standard (PCI DSS)—a set of 12 core requirements and over 300 sub-requirements designed to protect credit card data from theft and fraud. If you accept, process, store, or transmit cardholder data, you must comply with these security standards, regardless of your business size.

The PCI DSS 4.0 standard, which became fully mandatory on March 31, 2025, creates specific obligations for businesses handling payment card information. Failing to meet these requirements exposes your organization to penalties ranging from $5,000 to $100,000 per month depending on your transaction volume and how long you remain non-compliant. According to industry research, businesses that fail to maintain PCI DSS standards on at least a quarterly basis are significantly more likely to experience data breaches.

Here’s what you’ll learn in this article:

• 🔐 The 12 core PCI DSS requirements and how each protects your business
• 📊 How to determine your PCI compliance level (1-4) and which SAQ applies to you
• ⚠️ Common mistakes that lead to compliance failures—and how to avoid them
• 💰 Real consequences of non-compliance, including fines and data breach liability
• ✅ Step-by-step guidance on achieving and maintaining PCI compliance

What Is PCI DSS and Who Must Comply?

The Payment Card Industry Data Security Standard applies to every organization that handles cardholder data. This includes merchants, service providers, payment processors, and any third party that can affect the security of credit card transactions. No business is too small for PCI compliance—if cardholder data passes through your system at any point, you must follow these standards.

The PCI Security Standards Council (PCI SSC), founded by major payment brands including Visa, Mastercard, American Express, Discover, and JCB, develops and maintains these requirements. While PCI DSS is not a federal law, payment card brands enforce compliance through contractual agreements with acquiring banks and payment processors.

The Cardholder Data Environment (CDE)

Your cardholder data environment includes every system, person, and process that stores, processes, or transmits cardholder data. This encompasses servers, point-of-sale systems, workstations, network devices, and even paper records containing card information.

Understanding your CDE is critical because it defines your PCI scope—the boundaries of what you must protect. Systems that connect to your CDE or could impact its security also fall within scope, including backup servers, patch management systems, antivirus servers, and authentication systems.

The 12 PCI DSS Requirements Explained

PCI DSS organizes its requirements into six control objectives. Understanding each requirement helps you build a comprehensive security program.

Build and Maintain a Secure Network (Requirements 1-2)

Requirement 1: Install and Maintain Network Security Controls

Your network security controls—including firewalls, VPNs, and other policy enforcement points—serve as your first line of defense against attackers. PCI DSS 4.0 expanded beyond traditional firewalls to encompass cloud-based “network security controls” that regulate traffic between trusted internal networks and untrusted external networks.

You must document your network topology, harden firewall rules, and implement proper segmentation to isolate your CDE from other network areas. Firewall rules require review at least twice per year to ensure they remain appropriate.

Requirement 2: Avoid Vendor-Supplied Defaults

Default passwords and security parameters are widely known and easily exploited. Changing these defaults immediately makes your systems harder to compromise. This requirement applies to all system components, including routers, servers, applications, and point-of-sale terminals.

Protect Cardholder Data (Requirements 3-4)

Requirement 3: Protect Stored Cardholder Data

This requirement mandates encryption, truncation, masking, or hashing of stored cardholder data. At minimum, the Primary Account Number (PAN) must be rendered unreadable anywhere it is stored—including portable media, backups, and logs.

Sensitive authentication data (SAD)—including CVV codes, PINs, and magnetic stripe data—must never be stored after transaction authorization, even in encrypted form. This prohibition exists because SAD can be used to create counterfeit cards if compromised.

Requirement 4: Encrypt Transmission Across Open Networks

When transmitting cardholder data over public networks, you must use strong cryptography such as TLS 1.2 or higher. This protects data in transit from interception by attackers monitoring network traffic.

Maintain a Vulnerability Management Program (Requirements 5-6)

Requirement 5: Protect Against Malware

Deploy and regularly update anti-malware software on all systems commonly affected by malicious software. This includes workstations, servers, and any system within your CDE.

Requirement 6: Develop and Maintain Secure Systems

This requirement encompasses vulnerability identification, patching, change management, and secure software development. PCI DSS 4.0 added significant new requirements for e-commerce payment pages.

Under Requirement 6.4.3, you must manage all payment page scripts executed in consumers’ browsers. This includes maintaining an inventory of all scripts, ensuring each is authorized, and assuring their integrity. Requirement 11.6.1 requires mechanisms to detect unauthorized modifications to HTTP headers and scripts on payment pages.

Implement Strong Access Control (Requirements 7-9)

Requirement 7: Restrict Access by Business Need

Limit cardholder data access to only those individuals whose job responsibilities require it. This principle of “least privilege” reduces the number of potential access points for attackers.

Requirement 8: Identify and Authenticate Access

Assign unique identifiers to every person accessing your systems. PCI DSS 4.0 significantly expanded multi-factor authentication (MFA) requirements.

MFA is now required for all access to the CDE, not just administrator access. This means any user—regardless of role—must use MFA every time they attempt to access the cardholder data environment. MFA must use at least two independent factors from different categories: something you know (password), something you have (token), or something you are (biometric).

Under PCI DSS 4.0, passwords must be at least 12 characters long, increased from the previous 7-character minimum.

Requirement 9: Restrict Physical Access

Protect physical access to servers, data centers, and any location housing cardholder data. Media containing cardholder data requires strict controls over storage, access, distribution, and destruction.

Regularly Monitor and Test Networks (Requirements 10-11)

Requirement 10: Track and Monitor All Access

Implement comprehensive logging that tracks access to network resources and cardholder data. Logs must be reviewed daily to identify anomalies and suspicious activities, with at least three months of data available for immediate analysis and one year retained in archives.

Requirement 11: Regularly Test Security Systems

PCI DSS requires multiple testing activities:

• Quarterly internal vulnerability scans by qualified personnel
• Quarterly external vulnerability scans by a PCI-Approved Scanning Vendor (ASV)
• Annual penetration testing of both network and application layers
• Wireless analyzer scans to detect unauthorized access points quarterly

External vulnerability scans must show no vulnerabilities with a CVSS score of 4.0 or higher to pass. Internal scans must address all “high risk” vulnerabilities before achieving a passing status.

Maintain an Information Security Policy (Requirement 12)

Requirement 12: Establish Security Policies

Create and maintain a comprehensive information security policy that governs protection of cardholder data. This policy must address risk assessment, acceptable use of technologies, personnel screening, incident response, and third-party service provider management.

PCI DSS 4.0 requires organizations to validate their PCI scope at least annually—or every six months for service providers. You must maintain a list of all third-party service providers (TPSPs) that could affect the security of account data and ensure written agreements acknowledge their security responsibilities.

PCI Compliance Levels: Which Applies to Your Business?

Your compliance level determines validation requirements. Levels are based on annual transaction volume.

Level 1: Large Merchants

Level 1 applies to merchants processing over six million card transactions annually. These merchants require an annual Report on Compliance (ROC) conducted by a Qualified Security Assessor (QSA) through an on-site audit. Any business that suffers a data breach involving cardholder data may also be elevated to Level 1 regardless of transaction volume.

Level 2-4: Mid-Size and Small Merchants

Levels 2 through 4 merchants complete a Self-Assessment Questionnaire (SAQ) to validate compliance. The specific SAQ depends on your payment processing method. Level 4 covers most small businesses, requiring an SAQ, quarterly network scans (at the acquiring bank’s discretion), and an Attestation of Compliance (AoC).

SAQ Types: Which Self-Assessment Questionnaire Do You Need?

Choosing the correct SAQ is critical—selecting the wrong one can lead to failed assessments or a false sense of security.

SAQ A: Fully Outsourced E-Commerce

SAQ A applies to merchants that completely outsource payment processing. Card data never enters your environment—customers are redirected to a payment page hosted entirely by your PCI-compliant service provider.

Under PCI DSS 4.0, SAQ A merchants must either implement adequate script protection controls or obtain written confirmation from their payment processor that the processor’s solution protects against script attacks.

Eligibility criteria:

• All payment processing fully outsourced
• No electronic storage of cardholder data
• Payment pages entirely hosted by compliant TPSP

SAQ A-EP: E-Commerce with Partial Outsourcing

SAQ A-EP applies to e-commerce merchants who have partially outsourced payment processing. Your website may control how payment data is collected (such as through an iframe or direct post), even though the actual processing occurs on a third-party server.

This SAQ has more requirements than SAQ A because your systems can affect the security of the payment transaction.

SAQ B: Imprint Machines or Dial-Out Terminals

SAQ B covers merchants using standalone, dial-out terminals or imprint machines with no electronic cardholder data storage. These terminals must not be connected to the internet.

SAQ B-IP: IP-Connected Terminals

SAQ B-IP applies to merchants using standalone, IP-connected PTS-approved terminals. The devices must be segmented from other systems, cannot rely on another device (computer, tablet, phone) to connect to the payment processor, and merchants cannot store cardholder data electronically.

SAQ C-VT: Web-Based Virtual Terminals

SAQ C-VT covers merchants using web-based virtual terminals—web pages hosted by validated service providers that allow manual transaction entry. Two key requirements apply: the workstation must be dedicated solely to payment processing, and no magnetic card readers can be used.

Key benefit: SAQ C-VT eliminates quarterly vulnerability scan requirements if you meet all eligibility criteria.

SAQ C: Payment Applications Connected to Internet

SAQ C applies to merchants with payment application systems connected to the internet but without electronic cardholder data storage. This covers more complex setups than standalone terminals.

SAQ D: Everything Else

SAQ D is the comprehensive “catch-all” assessment. It applies to merchants storing, processing, or transmitting cardholder data who don’t qualify for other SAQs, and to all service providers. SAQ D covers all 12 PCI DSS requirements and includes 329 questions.

SAQ P2PE: Point-to-Point Encryption

Merchants using a PCI-validated P2PE solution can complete the shortest questionnaire—just 21 questions under PCI DSS 4.0. P2PE encrypts cardholder data at the point of interaction in a PCI-approved device, with decryption occurring only at the processor’s secure environment.

Real-World Data Breach Scenarios: Lessons from Target, Home Depot, and Equifax

Understanding how major breaches occurred helps you identify vulnerabilities in your own environment.

Scenario 1: Target (2013)—Third-Party Vendor Compromise

Attackers gained access to Target’s network using credentials stolen from a third-party HVAC vendor, Fazio Mechanical. The vendor had network access to monitor energy consumption—not to access payment data. Target’s failure to properly segment their payment systems allowed attackers to pivot from the vendor environment to the point-of-sale network.

Target had been certified PCI compliant just months before the breach. This demonstrates that compliance is a snapshot in time—security must be maintained continuously.

Scenario 2: Home Depot (2014)—RAM-Scraping Malware

Attackers used stolen third-party vendor credentials to access Home Depot’s network. They exploited a zero-day Windows vulnerability to pivot to the corporate environment, then installed memory-scraping malware on over 7,500 self-checkout POS terminals.

Scenario 3: Equifax (2017)—Unpatched Vulnerability

Equifax was aware of a critical vulnerability in their Apache Struts software and sent an internal alert to apply the patch. However, the patch was never applied to their online dispute resolution portal. Attackers exploited this vulnerability to access 147 million consumer records, including 209,000 credit card numbers.

Equifax paid a $425 million settlement for this breach.

Penalties and Consequences for Non-Compliance

PCI DSS penalties escalate based on the duration and severity of non-compliance.

Monthly Non-Compliance Fines

Additional Breach-Related Costs

Beyond monthly fines, data breaches trigger additional financial consequences:

• $50-$90 per compromised card imposed by payment processors
• Forensic investigation costs through a PCI Forensic Investigator (PFI)
• Card reissuance fees charged back to the merchant
• Increased transaction fees or terminated processing agreements
• Legal costs, settlements, and class action lawsuits
• Reputational damage and lost customer trust

State Data Breach Notification Laws

All 50 states have data breach notification laws requiring businesses to notify affected individuals. Requirements vary by state:

California has among the strictest requirements. Under SB 446 (effective 2025), businesses must disclose breaches within 30 calendar days of discovery. The California Consumer Privacy Act (CCPA) allows civil penalties of $2,500 per violation or $7,500 per intentional violation, plus consumers can sue for $100-$750 per person per incident for data breaches caused by inadequate security.

Many states require notification to state attorneys general if breaches affect more than 500 residents. Some states mandate providing credit monitoring services if Social Security numbers are compromised.

Common PCI Compliance Mistakes to Avoid

Mistake 1: Improper Scope Definition

Many organizations fail to identify all systems that handle or impact cardholder data. Your scope includes not just systems that directly process cards, but also supporting systems like authentication servers, NTP servers, patch servers, and administrative workstations.

Consequence: Incomplete scope leads to unprotected systems that attackers can exploit as entry points.

Mistake 2: Storing Sensitive Authentication Data

PCI DSS explicitly prohibits storing CVV codes, PINs, and full track data after authorization. Many compromised organizations were unaware their systems stored this data.

Consequence: Storing SAD violates PCI requirements and dramatically increases breach impact since this data enables card counterfeiting.

Mistake 3: Selecting the Wrong SAQ

Organizations often assume they qualify for a simpler SAQ than their environment requires. For example, e-commerce merchants frequently start with SAQ A only to discover their payment environment requires SAQ D.

Consequence: Failed compliance assessments, false sense of security, and potential penalties if a breach occurs.

Mistake 4: Weak Authentication Practices

Common failures include not using MFA for administrator access, using weak passwords that don’t meet complexity requirements, and storing hard-coded credentials in application code.

Consequence: Weak authentication makes it easier for attackers to gain access to your cardholder data environment.

Mistake 5: Failing to Change Vendor Defaults

Using default passwords and security parameters provides attackers with an easy entry point.

Consequence: Default credentials are widely known and enable trivial system compromises.

Mistake 6: Neglecting Third-Party Service Provider Management

PCI DSS requires maintaining a list of all TPSPs, ensuring written agreements acknowledge security responsibilities, and validating their compliance annually. Many organizations fail to properly assess and monitor their service providers.

Consequence: As Target and Home Depot demonstrated, compromised third parties provide attackers a path into your environment.

Do’s and Don’ts for PCI Compliance

Do’s

1. Do verify PCI compliance of all third parties who process your customers’ payment cards. Have clear access and password protection policies.
2. Do mask PAN when displayed and restrict access to cardholder data on a need-to-know basis.
3. Do encrypt cardholder data using strong cryptography during transmission over public networks.
4. Do implement MFA for all CDE access as required by PCI DSS 4.0.
5. Do document your PCI scope annually and update data-flow diagrams whenever significant changes occur.
6. Do run quarterly vulnerability scans and address identified issues before your compliance deadline.

Don’ts

1. Don’t store CVV, PIN, or full track data after authorization—ever.
2. Don’t send cardholder data via unencrypted email, instant messaging, or chat.
3. Don’t locate servers or payment storage devices outside of locked, access-controlled rooms.
4. Don’t permit unauthorized people to access stored cardholder data.
5. Don’t assume compliance is one-time—maintain security controls continuously.
6. Don’t rely solely on third-party compliance—your organization remains responsible for ensuring proper controls.

Tokenization vs. Encryption: Reducing Your PCI Scope

Both tokenization and encryption protect sensitive data, but they work differently and affect PCI scope differently.

Encryption uses mathematical algorithms to encode data, which can later be decrypted with a key. Encrypted cardholder data is still considered sensitive data, so systems handling encrypted PANs remain in PCI scope.

Tokenization replaces card data with a non-sensitive placeholder (token) that has no mathematical relationship to the original value. Tokens cannot be reverse-engineered. When implemented correctly, tokenized data falls out of scope for many PCI requirements because it’s no longer considered cardholder data.

Most robust payment architectures use both: encrypt data as it moves and tokenize it once it lands.

The QSA Assessment and Report on Compliance Process

Level 1 merchants and service providers must undergo an annual on-site assessment by a Qualified Security Assessor (QSA).

What QSAs Evaluate

The QSA conducts a thorough review of your technical and operational practices against all applicable PCI DSS requirements. This includes:

• Reviewing your systems, controls, and security practices
• Collecting logs, policies, network diagrams, and test results
• Interviewing personnel with security responsibilities
• Testing configurations and security controls
• Documenting findings and any gaps identified

The Report on Compliance (ROC)

The ROC is a comprehensive document detailing your compliance status. It includes:

• Scope and boundaries of your cardholder data environment
• Details on business operations and payment processing methods
• Systematic assessment of each PCI DSS requirement
• Evidence and documentation supporting compliance
• Summary of any gaps and remediation actions

The ROC serves as official evidence of your compliance status and is submitted to acquiring banks or payment brands.

Service Provider Compliance Requirements

Service providers have their own compliance levels:

PCI DSS 4.0 places additional requirements on service providers:

• Must validate PCI scope every six months (vs. annually for merchants)
• Must have processes to detect and report failures of critical security controls in a timely manner
• Must acknowledge in writing their responsibility to protect cardholder data

Service providers can only use SAQ D for Service Providers—no other SAQ types apply.

Approved Scanning Vendors (ASVs) and Quarterly Scans

An Approved Scanning Vendor (ASV) is an organization certified by the PCI SSC to conduct external vulnerability scans. ASV scans identify known weaknesses in your network structures from an external perspective.

What ASV Scans Cover

• Public IP addresses and domains
• Known vulnerability checks
• Misconfiguration detection
• Services, protocols, and ports exposed to the internet

Passing Requirements

To pass an external ASV scan, your environment must have no vulnerabilities with a CVSS score of 4.0 or higher. If vulnerabilities are found, you must remediate them and rescan until achieving a passing status.

ASV scans are required quarterly (every 90 days) and after any significant infrastructure changes.

PCI DSS 4.0: Key Changes You Must Address

PCI DSS 4.0 introduced 47 new requirements, all of which became mandatory as of March 31, 2025.

Expanded MFA Requirements

MFA is now required for all access to the CDE, not just administrators. Users must be challenged with MFA every time they access the CDE, including from cloud environments, hosted systems, workstations, and servers.

Enhanced Password Standards

Passwords must be at least 12 characters long. Passwords for system and application accounts must be changed at least every 12 months.

Payment Page Script Management

For e-commerce environments, requirements 6.4.3 and 11.6.1 mandate management and monitoring of all scripts on payment pages. You must maintain an inventory of all scripts, ensure each is authorized, and implement mechanisms to detect unauthorized modifications.

Targeted Risk Analysis

PCI DSS 4.0 introduces Targeted Risk Analyses (TRAs) for specific requirements where flexibility is allowed. These documented, evidence-based justifications must explain why your chosen approach manages risk effectively and require annual review.

Authenticated Internal Scans

Internal vulnerability scans must now use authenticated scanning—credentials that access system resources for more thorough analysis. This became mandatory on March 31, 2025.

FAQs

Does my small business need PCI compliance?

Yes. If your business accepts credit or debit cards in any form, you must comply with PCI DSS regardless of size or transaction volume.

What happens if I’m not PCI compliant and there’s no breach?

Yes, you can still face consequences. Payment processors may charge monthly non-compliance fees of $20-$50, increase transaction fees, or terminate your processing agreement.

Can I outsource PCI compliance entirely to my payment processor?

No. While using compliant processors reduces your scope, you retain responsibility for controls in your environment and must complete applicable SAQ requirements.

Do I need penetration testing for Level 4 compliance?

No. Level 4 merchants completing SAQs A, B, B-IP, or C-VT are not required to perform penetration testing. SAQ D merchants must complete annual penetration tests.

Is PCI compliance a one-time certification?

No. PCI compliance requires continuous maintenance. Security controls must operate effectively year-round, with annual validation and quarterly scans.

What’s the difference between an SAQ and ROC?

No, they’re not interchangeable. An SAQ is a self-assessment for smaller merchants. A ROC is a detailed report from a QSA audit required for Level 1 merchants.

Does encryption alone remove data from PCI scope?

No. Encrypted cardholder data remains in scope. However, systems performing encryption/decryption and tokenization can reduce scope when implemented correctly.

Can I be PCI compliant and still experience a breach?

Yes. Compliance represents a point-in-time assessment. Target, Home Depot, and Equifax were all certified compliant before their breaches.

Are cloud environments subject to PCI DSS?

Yes. Cloud-based systems storing, processing, or transmitting cardholder data fall within PCI scope. You must ensure your cloud provider is compliant and clearly document responsibility allocation.

How long do I need to retain PCI compliance records?

Records and audit logs must be retained for at least one year, with three months immediately available for analysis.