Who Is Responsible for PCI Compliance? (w/Examples) + FAQs

Every business that accepts credit card payments is responsible for PCI compliance. This includes merchants, payment processors, banks, and third-party service providers. The Payment Card Industry Data Security Standard (PCI DSS) is not a federal law, but a contractual security standard enforced through merchant agreements with acquiring banks and payment processors. Violating these contractual requirements can result in monthly fines ranging from $5,000 to $100,000, termination of your ability to accept credit cards, and placement on the MATCH list—a database that can effectively blacklist your business from payment processing for five years.

A staggering 60% of small businesses that suffer a data breach close within six months of the attack. The average cost of a data breach reached $4.45 million in 2023, according to IBM’s Cost of a Data Breach Report.

In this article, you will learn:

📋 Who exactly bears responsibility for PCI compliance—from your business to your bank to your payment processor—and how these responsibilities are divided

💰 The specific financial penalties and escalating fine structures for non-compliance, including real-world breach settlements totaling hundreds of millions of dollars

🔐 How the four merchant levels determine your validation requirements and what Self-Assessment Questionnaire (SAQ) applies to your situation

⚠️ Critical mistakes to avoid that commonly lead to compliance failures and data breaches, even for businesses that believe they are compliant

🛡️ The new PCI DSS 4.0 requirements effective April 1, 2025, and how they impact your ongoing compliance obligations

The Chain of Responsibility: Who Must Comply with PCI DSS

Understanding who holds responsibility for PCI compliance requires understanding the entire payment ecosystem. The PCI Security Standards Council defines multiple parties that share compliance obligations.

The PCI Security Standards Council vs. Enforcement Bodies

The PCI Security Standards Council (PCI SSC) was formed in 2006 by the five major payment card brands: Visa, Mastercard, American Express, Discover, and JCB. This council develops, maintains, and publishes the security standards. However, the PCI SSC does not enforce compliance.

Enforcement falls to the individual payment card brands. Each brand maintains its own compliance programs and penalties. When violations occur, Visa and Mastercard impose fines on acquiring banks, which then pass those fines down to the merchants responsible for the violation.

The Acquiring Bank: Your Judge and Jury

Your acquiring bank—also called your merchant bank—holds enormous power over your PCI compliance fate. The acquiring bank is the financial institution that processes your credit card transactions and deposits funds into your business account.

The acquiring bank’s responsibilities include:

Determining your merchant level. Based on your transaction volume, your acquirer classifies you into one of four levels. This classification determines whether you need a full third-party audit or can self-assess.

Specifying your validation method. Your acquirer decides whether you must complete a Self-Assessment Questionnaire (SAQ) or undergo a full Report on Compliance (ROC) assessment by a Qualified Security Assessor.

Enforcing compliance deadlines. The acquiring bank sets due dates for submitting your compliance documentation. Missing deadlines can trigger penalties.

Imposing penalty fees. If you fail to validate compliance, your acquirer can charge monthly non-compliance fees that accumulate until you achieve compliance.

Terminating your merchant account. In severe cases, your acquiring bank can revoke your ability to accept credit cards entirely. This action will likely result in placement on the MATCH list.

Your merchant agreement with your acquiring bank contains language stating that you are responsible for adhering to and being compliant with PCI DSS at all times. Even if your bank never asks for proof of compliance, that contractual obligation remains. If a breach occurs, your bank will reference that agreement to establish your liability.

Merchant Responsibility: The Buck Stops Here

As a merchant, you bear primary responsibility for protecting cardholder data in your environment. This responsibility cannot be delegated, even when you outsource payment functions.

According to PCI DSS and guidance from McDermott Will & Emery, “Outsourcing card functions does not relieve a merchant of PCI DSS obligations”. Even if your organization outsources card processing to third-party platforms and does not store card numbers, you must still:

• Complete an annual PCI Self-Assessment Questionnaire (SAQ)
• Document an Attestation of Compliance (AOC)
• Verify your service providers’ compliance annually
• Maintain written agreements defining security responsibilities

The Four Merchant Levels: Determining Your Compliance Requirements

PCI DSS categorizes merchants into four levels based on annual transaction volume. Your level determines the rigor of compliance validation required.

Level 1 Merchants: Maximum Scrutiny

Level 1 merchants include any business processing more than 6 million Visa or Mastercard transactions annually. Additionally, any merchant that has experienced a data breach resulting in account compromise is automatically elevated to Level 1, regardless of transaction volume.

Level 1 validation requires:

• An on-site assessment by a PCI-certified Qualified Security Assessor (QSA)
• A formal Report on Compliance (ROC) document
• Quarterly external vulnerability scans by an Approved Scanning Vendor (ASV)
• Annual penetration testing of the cardholder data environment

The cost of Level 1 compliance can be substantial. Per-transaction PCI compliance costs for Level 1 merchants have been calculated at approximately $0.24 per transaction when amortizing the total compliance program cost.

Level 4 Merchants: Simplified but Not Optional

Level 4 represents the smallest merchants—those processing fewer than 20,000 e-commerce transactions annually or up to 1 million total transactions. Most small businesses fall into this category.

The validation requirements for Level 4 merchants typically include:

• Completion of the appropriate Self-Assessment Questionnaire
• Quarterly network vulnerability scans (as required by your acquirer)
• Attestation of Compliance form

Do not mistake simplified validation for simplified compliance. The actual security requirements—implementing firewalls, encrypting data, maintaining access controls—are identical across all merchant levels. Level 4 merchants must implement the same controls as Level 1 merchants; the difference lies only in how compliance is validated and reported.

Self-Assessment Questionnaires: Choosing the Right SAQ

The Self-Assessment Questionnaire is how most merchants document their compliance status. There are nine different SAQ types, each designed for specific payment environments.

SAQ A: The Minimum Burden (With Strings Attached)

SAQ A represents the simplest compliance path, designed for merchants that completely outsource their payment functions to PCI-compliant third parties. To qualify, you must either:

• Have an e-commerce site entirely hosted and managed by a PCI-compliant vendor
• Redirect customers to a PCI-compliant vendor’s website for payment
• Use an embedded iframe from a PCI-compliant vendor

Under PCI DSS 4.0, even SAQ A merchants must now conduct quarterly external vulnerability scans using an Approved Scanning Vendor. Additionally, merchants must confirm that their site is not susceptible to script-based attacks.

SAQ D: The Catch-All Assessment

SAQ D applies to merchants and service providers that store, process, or transmit cardholder data and don’t meet the eligibility criteria for other SAQ types. This comprehensive questionnaire covers all 12 PCI DSS requirements and includes 329 questions.

Common scenarios requiring SAQ D:

• Storing card numbers in your own database
• Using a payment application that stores cardholder data locally
• Processing card-present transactions without P2PE encryption
• Any situation where you directly handle card data

Choosing the wrong SAQ type is one of the most common compliance mistakes. Selecting SAQ A when your environment requires SAQ D creates a false sense of security and can result in significant penalties during a breach investigation.

Third-Party Service Provider Responsibilities

When you engage third-party service providers (TPSPs) to handle payment functions, your compliance burden is reduced but not eliminated.

What Service Providers Must Do

Service providers with access to cardholder data must comply with PCI DSS for the services they provide. Depending on their transaction volume, service providers are classified as:

• Level 1 Service Providers: Must undergo annual ROC assessment by a QSA
• Level 2 Service Providers: May complete SAQ D for Service Providers

Service providers must also:

• Acknowledge in writing their responsibility for protecting cardholder data
• Provide Attestations of Compliance (AOC) to their merchant customers
• Under PCI DSS 4.0, validate their PCI DSS scope every six months

Your Responsibilities Regarding Service Providers

Even when using compliant service providers, merchants must:

The hidden risk: Even if a third party claims PCI compliance, that doesn’t automatically reduce your compliance burden. You remain responsible for verifying that the scope and relevance of their compliance aligns with your risk posture. When a breach occurs, regulators and card brands will call you first—not your vendor.

PCI Fines, Penalties, and Consequences

PCI non-compliance triggers a cascade of financial and operational consequences. Understanding these penalties helps quantify the risk of cutting corners on compliance.

Escalating Monthly Fines

Non-compliance fines increase over time:

For smaller merchants who simply haven’t submitted their SAQ or completed scans, non-compliance fees typically range from $20 to $100 per month. However, these fees escalate dramatically for larger merchants or those with longer compliance gaps.

Data Breach Costs

If a breach occurs while non-compliant, additional consequences apply:

• $50 to $90 per compromised cardholder in fines
• Forensic investigation costs of $5,000 to $50,000+
• Card reissuance fees of $2.50 to $10 per card
• Fraud recovery assessments covering actual fraudulent transactions
• Lawsuits from affected customers and financial institutions

Any breach involving cardholder data automatically elevates your merchant level to Level 1, requiring expensive annual QSA assessments going forward.

The MATCH List: Payment Processing Purgatory

The MATCH list (Member Alert to Control High-Risk Merchants)—formerly called the Terminated Merchant File—is Mastercard’s database of merchants whose accounts have been terminated for risk-related reasons.

MATCH Reason Code 12 specifically addresses PCI-DSS Non-compliance. If your merchant account is terminated due to PCI violations, you will likely be added to MATCH with this code.

Consequences of MATCH listing:

• Information shared globally across payment networks
• Most businesses remain listed for five years
• New payment processors will check MATCH before approving your application
• Many processors will decline to work with MATCH-listed merchants

The only way to be removed from MATCH for PCI non-compliance is to achieve compliance and obtain a certificate from a Mastercard-certified forensic examiner confirming your compliant status.

Real-World Breach Examples: The Cost of Non-Compliance

Examining actual breach settlements illustrates the devastating financial impact of PCI failures.

Scenario 1: The Target Breach (2013)

Situation: Cybercriminals gained access to Target’s gateway server using credentials stolen from a third-party HVAC vendor. Despite being certified PCI compliant in September 2013, Target had failed to properly segment their systems that handled payment card data from the rest of the network.

Lesson: Target was certified compliant shortly before the breach, demonstrating that compliance is a snapshot in time. Security gaps can emerge quickly if requirements are not continuously maintained.

Scenario 2: Heartland Payment Systems (2008)

Situation: Hackers used SQL injection to breach Heartland Payment Systems, a payment processor handling transactions for 175,000 merchants. The attack compromised up to 130 million debit and credit cards.

Lesson: Even payment processors—companies whose entire business involves handling card data—can suffer catastrophic breaches. The 14-month ban from processing payments nearly destroyed the company.

Scenario 3: Small Restaurant Breach (Bellingham, WA)

Situation: A restaurant owner purchased a non-compliant payment application on eBay. The software had been listed on a Visa Alert identifying it as improperly storing cardholder data. Hackers compromised just 22 credit card numbers.

Lesson: The breach of just 22 cards cost this small business $12,000 in direct costs plus months of lost revenue. The owner described it as costing him “my dream.”

PCI DSS 4.0: New Requirements Effective April 1, 2025

As of April 1, 2025, all future-dated requirements in PCI DSS 4.0 became mandatory. Organizations can no longer treat these requirements as “best practices.”

Key Mandatory Changes

Scope Validation: Organizations must annually define and document the scope of their PCI DSS assessment. Service providers must validate scope every six months.

Payment Page Script Controls: Organizations must implement controls for all payment page scripts executed in consumers’ browsers to prevent unauthorized modifications. This addresses e-skimming attacks like Magecart.

Automated Web Application Protection: Automated technical solutions must continuously detect and prevent web-based attacks. Manual vulnerability assessments are no longer sufficient.

Targeted Risk Analyses: Organizations must conduct granular risk assessments for specific controls, documenting justifications for their chosen approaches.

Enhanced Authentication: Multi-factor authentication requirements have expanded, and passwords must be at least 12 characters with complexity rules.

Defined Approach vs. Customized Approach

PCI DSS 4.0 introduces the Customized Approach as an alternative to the traditional Defined Approach.

The Customized Approach requires extensive documented targeted risk analysis, significantly increasing assessment costs. Organizations can use either approach—or both—for different requirements within the same assessment.

Common Mistakes to Avoid

Even well-intentioned organizations fail PCI compliance due to these recurring errors.

Mistake 1: Believing PCI Doesn’t Apply Because You Don’t “Store” Card Data

PCI scope is based on storing, processing, or transmitting cardholder data—or having the ability to impact its security. If a customer ever hands you a card or enters card details on your website, PCI applies.

Negative Outcome: Assuming you’re exempt leads to zero security controls, making you an easy target for attackers and guaranteeing maximum penalties when a breach occurs.

Mistake 2: Scoping Too Narrowly

PCI DSS 4.0 expands the definition of in-scope systems to include service providers, cloud environments, and connected systems that could affect cardholder data security, even indirectly.

Negative Outcome: Missing third-party integrations, APIs, or virtual machines in your scope assessment means those systems remain unprotected—and become attack vectors.

Mistake 3: Treating PCI as a One-Time Project

Many businesses pass their annual assessment and then ignore security until the next year. Compliance is an ongoing process, not an annual checkbox.

Negative Outcome: Security controls degrade between assessments. Target was certified compliant in September 2013 and breached in December 2013.

Mistake 4: Non-Compliant Third-Party Service Providers

Failing to verify that your service providers maintain their own PCI compliance creates liability. If your vendor suffers a breach affecting your customer data, you face the consequences.

Negative Outcome: The Target breach originated from a third-party HVAC vendor. Target paid over $200 million despite the initial compromise occurring outside their direct systems.

Mistake 5: Storing Prohibited Data

PCI DSS mandates that businesses should not store sensitive authentication data after authorization, such as full track data or CVV codes.

Negative Outcome: TJX was found to be improperly storing prohibited data and storing card data on servers connected to the internet, resulting in 94 million compromised accounts and $256 million in costs.

Do’s and Don’ts of PCI Compliance

Do’s

Don’ts

State Data Breach Notification Laws

While PCI DSS is a contractual standard rather than law, state data breach notification laws create legal obligations that complement PCI requirements.

2025 Notification Requirements

As of 2025, California and New York now require breach notification within 30 calendar days of discovery. Other states, such as Florida and Colorado, also mandate strict 30-day deadlines.

For businesses operating across multiple states, compliance requires meeting the notification requirements of each state where affected customers reside.

The Interplay Between PCI and State Law

When a breach occurs, merchants must:

1. Notify their acquiring bank and payment processor immediately
2. Cooperate with a PCI Forensic Investigator (PFI)
3. Preserve all evidence related to the incident
4. Comply with state notification timelines for affected consumers

Failing to meet state notification requirements can result in civil penalties, lawsuits, and even suspension of business licenses. Companies that demonstrate transparency and follow PCI DSS reporting protocols often receive more lenient treatment from regulators.

Frequently Asked Questions

Is PCI compliance required by federal law?
No. PCI DSS is a contractual standard enforced through merchant agreements with acquiring banks and payment card brands, not a federal law. However, violating these contractual requirements can result in fines, lawsuits, and termination of payment processing privileges.

Can I avoid PCI compliance by using a third-party payment processor?
No. Even when outsourcing all payment functions to a PCI-compliant provider, you remain responsible for completing annual compliance validation and verifying your provider’s compliance status.

Does PCI compliance guarantee I won’t be breached?
No. PCI compliance reduces risk but does not eliminate it; Target was certified compliant shortly before their 2013 breach that compromised 110 million customers.

What happens if I’m added to the MATCH list?
Your ability to accept credit cards is severely compromised. Most payment processors check MATCH before approving new merchant accounts; listings remain for five years unless successfully disputed or compliance is restored.

Do I need penetration testing for my small business?
It depends on your SAQ type. SAQ A merchants typically do not require penetration testing, but SAQ C and SAQ D merchants must conduct penetration tests at least annually.

How often must I complete vulnerability scans?
Quarterly. All merchants required to complete an SAQ must conduct external vulnerability scans by an Approved Scanning Vendor (ASV) every three months.

Can my merchant account be terminated for PCI violations?
Yes. Acquiring banks can terminate merchant accounts for non-compliance, which typically results in MATCH listing and difficulty obtaining payment processing from other providers.

What is the difference between an SAQ and a ROC?
Scale and validation method. SAQs are self-assessments for smaller merchants; ROCs are formal reports prepared by Qualified Security Assessors for Level 1 merchants.

Are e-commerce businesses subject to different PCI requirements?
No, but different SAQ types apply. E-commerce businesses must comply with the same 12 PCI DSS requirements, though they may qualify for simplified SAQ types like SAQ A if they fully outsource payment processing.

Who pays the fines when PCI violations occur?
Ultimately, the merchant. Card brands fine acquiring banks, who pass fines to payment processors, who pass them to merchants under their contractual agreements.