Office Consumer is reader-supported. We may earn an affiliate commission from qualified links on our site.

Is PCI Compliance Required by Law? (w/Examples) + FAQs

No, PCI DSS compliance is not required by federal law in the United States. However, this answer requires important context because failing to comply with PCI DSS can still result in devastating financial consequences for your business. PCI DSS is an industry-created security standard enforced through contractual agreements between merchants and payment processors, not government agencies.

Credit card fraud in the United States jumped from 275,000 cases in 2019 to nearly 475,000 in 2024, making data security more critical than ever. Several states, including Nevada, Minnesota, and Washington, have incorporated PCI DSS requirements into state law, creating actual legal obligations in those jurisdictions. The bottom line: while no federal agent will knock on your door for PCI violations, your acquiring bank can fine you up to $100,000 per month, and a data breach could cost your business millions.

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

đź“‹ The difference between PCI DSS as a standard versus a law, and why contracts make compliance mandatory in practice

đź’° State-by-state breakdown of where PCI DSS has actual legal force, including Nevada, Minnesota, Washington, Massachusetts, and California

⚠️ Real-world examples of businesses that faced millions in fines for non-compliance, including Target’s $292 million total cost and Home Depot’s $179 million settlement

🔍 The four merchant compliance levels, eight SAQ types, and exactly what validation requirements apply to your business size

🛡️ Common PCI compliance mistakes that lead to breaches and how to avoid them before they destroy your business


What PCI DSS Actually Is (And What It Is Not)

The Payment Card Industry Data Security Standard (PCI DSS) sets security guidelines for companies that store, process, transmit, or could impact the security of cardholder data and sensitive authentication data. The PCI Security Standards Council (PCI SSC), an independent organization formed in 2006 by five major credit card companies—Visa, Mastercard, American Express, Discover, and JCB International—created and maintains these standards. This is not a government agency.

Before PCI DSS existed, each credit card brand maintained its own separate security program. Visa had its Cardholder Information Security Program, Mastercard operated Site Data Protection, and American Express ran its Data Security Operating Policy. The creation of PCI DSS unified these approaches into a single standard that applies across all major card brands.

Why PCI DSS Feels Like a Law (Even Though It Isn’t)

The practical reality is that PCI compliance becomes mandatory through contract law. When you sign a merchant services agreement with your acquiring bank or payment processor—even online providers like Stripe, Square, or PayPal—you agree to adhere to PCI DSS as part of your contract. This agreement is a legally binding contract.

All merchant service agreements include sections on payment security and PCI DSS compliance. Many also contain clauses for indemnification and legal liability, meaning your business accepts financial responsibility if a breach occurs due to non-compliance. The contract outlines all fees, including penalties for PCI violations.

UnderstandingPCI DSS as a “Standard”PCI DSS as “Contractual Obligation”
Who creates it?PCI Security Standards Council (private organization)Terms set by card brands and banks
Who enforces it?Not enforced by governmentEnforced by acquiring banks and payment processors
Legal authorityNo federal law mandates complianceContract law makes it binding
ConsequencesIndustry penaltiesFines, increased fees, loss of processing ability
Can you be sued?Not directly for “PCI violation”Yes, for breach of contract and negligence

Federal Law: No Direct PCI Mandate

The United States has no federal law that explicitly mandates PCI DSS compliance. No government agency is going to send agents to your office to audit your records for PCI compliance. The PCI SSC itself does not enforce compliance with the standard—that responsibility falls to individual payment brands and acquiring banks based on contract terms.

However, federal regulations do touch on data security in ways that overlap with PCI requirements. The Federal Trade Commission (FTC) has authority under Section 5 of the FTC Act to take action against companies that engage in unfair or deceptive practices, including failing to maintain reasonable data security measures after promising to protect customer information.

The FTC’s Role in Data Security Enforcement

The landmark FTC v. Wyndham Hotels case in 2015 established that the FTC can sue companies for inadequate cybersecurity practices under its unfairness authority. Wyndham suffered three data breaches between 2008 and 2010, exposing more than 619,000 consumer payment card account numbers and causing over $10.6 million in fraud losses. The Third Circuit Court of Appeals upheld the FTC’s authority to pursue such cases, with Judge Thomas Ambro famously stating that Wyndham’s situation was like “a supermarket leaving so many banana peels all over the place that 619,000 customers fall.”

The Gramm-Leach-Bliley Act (GLBA) requires financial institutions to develop, implement, and maintain a comprehensive information security program. While GLBA doesn’t reference PCI DSS directly, there is significant overlap between GLBA’s Safeguards Rule and PCI DSS requirements.


While federal law remains silent on PCI DSS specifically, several states have woven PCI DSS requirements into their legal frameworks, making compliance a genuine legal obligation for businesses operating in those jurisdictions.

Nevada: The First State to Require PCI DSS by Law

Nevada made history by becoming the first state to incorporate PCI DSS into its legal code. Under NRS 603A.215, if a data collector doing business in Nevada accepts a payment card in connection with a sale of goods or services, the data collector shall comply with the current version of the PCI Data Security Standard. This language is not a recommendation—it creates an affirmative legal duty.

The Nevada law also provides a significant benefit for compliant businesses. A data collector in Nevada cannot be held liable for damages from a breach of the security of system data if they were in compliance with NRS 603A.215 at the time of the breach and the breach was not caused by gross negligence or intentional misconduct.

Nevada Law (NRS 603A.215)RequirementConsequence
Accept payment cards in NevadaMust comply with current PCI DSS versionCivil liability protection if compliant
Transfer personal information electronicallyMust use encryptionPotential liability for unencrypted transfers
Move data storage devicesMust use encryptionPotential liability if breached
Gross negligence or intentional misconductCompliance does not provide protectionFull liability exposure

Minnesota: The Plastic Card Security Act

Minnesota took a different approach with its Plastic Card Security Act (Minn. Stat. § 325E.64), enacted in 2007. Rather than requiring full PCI DSS compliance, Minnesota adopted specific portions of the standard by prohibiting the retention of card security code data, PIN verification code numbers, or full magnetic stripe data beyond 48 hours after transaction authorization.

The Minnesota law provides remedies specifically to financial institutions, not individual consumers. When a data breach occurs and a business violated the Minnesota statute, financial institutions can recover costs including card cancellation and reissuance, account closures and reopenings, refunds for unauthorized transactions, and cardholder notification expenses.

Washington State: PCI Compliance as a Safe Harbor

Washington State enacted legislation in 2010 that links PCI DSS compliance to data breach liability. Under RCW 19.255.020, businesses that suffer a data breach but were PCI DSS compliant at the time may have a legal defense against certain types of lawsuits.

The Washington law applies to businesses processing more than six million credit and debit card transactions annually. A processor, business, or vendor is not liable if its PCI DSS compliance was validated by an annual security assessment conducted no more than one year prior to the breach. This creates a powerful incentive for large retailers to maintain current PCI DSS compliance.

Massachusetts: 201 CMR 17.00 Data Security Regulations

Massachusetts takes a broader approach to data security through 201 CMR 17.00, which requires any company storing personal information about Massachusetts residents to implement and maintain reasonable security measures. While this regulation doesn’t reference PCI DSS directly, its requirements parallel many PCI DSS controls, including encryption requirements, access controls, and written security programs.

A civil penalty of $5,000 may be levied for each violation of Massachusetts data security laws. Under the data disposal provisions, businesses can face fines up to $50,000 for each instance of improper disposal of personal information.

California: CCPA and Data Breach Liability

California’s Consumer Privacy Act (CCPA) and California Privacy Rights Act (CPRA) create additional layers of liability for data breaches. Civil penalties range from $2,663 for each violation to $7,988 for intentional violations as of 2025. Consumers can sue businesses for data breaches under the CCPA if certain conditions are met, with statutory damages ranging from $107 to $799 per consumer per incident.

StateLawPCI DSS ReferenceKey Provision
NevadaNRS 603A.215Direct requirementMust comply with current PCI DSS
MinnesotaMinn. Stat. § 325E.64Partial adoptionProhibits retention of specific data
WashingtonRCW 19.255.020Safe harborPCI compliance provides liability defense
Massachusetts201 CMR 17.00Similar requirementsComprehensive security program required
CaliforniaCCPA/CPRAIndirectBreach liability and penalties

How PCI DSS Compliance Is Actually Enforced

Understanding the enforcement mechanism reveals why PCI compliance feels mandatory even without federal law. The enforcement chain works through a specific hierarchy that ultimately places all financial consequences on your business.

The Enforcement Chain

When a data breach occurs at a merchant that is not PCI compliant, the following process unfolds:

  1. The card network (Visa, Mastercard, etc.) launches an investigation through a forensic audit
  2. If non-compliance is discovered, the card network fines your acquiring bank
  3. Your acquiring bank passes those fines to your business under the terms of your merchant agreement
  4. Additional costs may include forensic investigation fees, card reissuance costs, and increased processing fees
Timeline of Non-ComplianceMonthly Fine Range (Low-Volume)Monthly Fine Range (High-Volume)
Months 1-3$5,000/month$10,000/month
Months 4-6$25,000/month$50,000/month
Month 7 and beyond$50,000/month$100,000/month

The exact amounts vary by processor and card brand, but the escalating structure ensures that prolonged non-compliance becomes financially unsustainable.

Card Brand Enforcement Programs

Visa manages compliance through its Account Information Security (AIS) Program. According to Visa, compliance validation is required of all entities that store, process, or transmit Visa cardholder data, including financial institutions, merchants, and service providers.

Mastercard operates its Site Data Protection (SDP) Program with similar validation requirements. All merchants that store, process, or transmit cardholder data must be PCI compliant, unless otherwise exempt. Mastercard recommends merchants contact their acquiring bank to complete the validation process.


The Four PCI DSS Merchant Levels Explained

PCI DSS classifies merchants into four levels based on annual credit card transaction volume. Your level determines the validation requirements and the intensity of the compliance process you must complete.

Level 1: The Highest Scrutiny

Level 1 applies to merchants processing more than six million transactions per year across all channels, or any merchant that has experienced a data breach or attack resulting in account data compromise. Any merchant identified by a card brand as Level 1 also falls into this category.

Validation Requirements:

  • Annual Report on Compliance (ROC) conducted by a Qualified Security Assessor (QSA)
  • Quarterly network scans by an Approved Scanning Vendor (ASV)
  • Attestation of Compliance (AOC) form

The cost for Level 1 compliance typically reaches tens of thousands of dollars annually due to the requirement for external QSA assessments.

Level 2: Large but Not Largest

Level 2 includes merchants processing between one and six million transactions annually across all channels. As of recent updates, Level 2 merchants completing SAQ A, A-EP, or D must additionally engage a QSA or Internal Security Assessor (ISA) to sign off on their self-assessment.

Validation Requirements:

  • Annual Self-Assessment Questionnaire (SAQ)
  • Quarterly network scans by ASV
  • Attestation of Compliance form

Level 3: E-Commerce Focus

Level 3 applies to merchants processing between 20,000 and one million e-commerce transactions annually. The focus on e-commerce transactions reflects the elevated risk profile of card-not-present transactions.

Validation Requirements:

  • Annual SAQ
  • Quarterly network scans by ASV
  • Attestation of Compliance form

Level 4: Small Business Category

Level 4 encompasses merchants processing fewer than 20,000 e-commerce transactions per year, or up to one million total transactions across all channels. Most small businesses fall into this category, including many restaurants and retail stores.

Validation Requirements:

  • Annual SAQ
  • Quarterly network scans by ASV (as required by acquirer)
  • Attestation of Compliance form
Merchant LevelAnnual TransactionsPrimary Validation MethodTypical Annual Cost
Level 1>6 millionExternal QSA audit (ROC)$50,000-$200,000+
Level 21-6 millionSAQ with QSA/ISA sign-off$10,000-$50,000
Level 320K-1M e-commerceSAQ and ASV scans$5,000-$20,000
Level 4<20K e-commerce or <1M totalSAQ and ASV scans$1,000-$10,000

Understanding Self-Assessment Questionnaires (SAQs)

The Self-Assessment Questionnaire you complete depends on how your business handles cardholder data, not just how much you process. Selecting the wrong SAQ type can lead to failed compliance assessments, a false sense of security, or costly penalties in the event of a breach.

SAQ A: Fully Outsourced Processing

SAQ A applies to merchants that fully outsource payment processing, meaning card data never enters the merchant’s environment. E-commerce merchants using redirected checkout (where customers are sent to the payment processor’s website to enter card details) typically qualify. This SAQ covers only a subset of PCI DSS requirements and has the lowest compliance burden.

Example Scenario: Sarah runs an online boutique. Customers click “checkout” and are redirected to PayPal’s website to complete payment. Card numbers never touch Sarah’s servers, so she qualifies for SAQ A.

SAQ A-EP: E-Commerce with Partial Outsourcing

SAQ A-EP is for e-commerce merchants that partially outsource their payment processing but whose website controls how cardholder data is transmitted to the payment processor. If your website has payment page scripts that execute in customer browsers, you likely need SAQ A-EP rather than SAQ A.

SAQ B and SAQ B-IP: Physical Terminals

SAQ B covers old-school dial-out terminals with no internet connection—the kind that dial a phone number to authorize transactions. SAQ B-IP handles internet-connected standalone terminals. The distinction matters because network connectivity transforms your threat model and security requirements.

SAQ C-VT: Virtual Terminals

SAQ C-VT serves manual entry scenarios where staff enter card details into a virtual terminal on a dedicated computer. The key word is dedicated. If the same computer runs email and web browsing, your business does not qualify for C-VT and likely needs SAQ C or D.

SAQ C: Internet-Connected Payment Systems

SAQ C covers payment systems connected to the internet but not connected to other systems in the merchant’s environment, and where the merchant does not store account data electronically. Most point-of-sale implementations fall here.

SAQ D: The Comprehensive Assessment

SAQ D is the “catch-all” assessment required for merchants and service providers that store, process, or transmit cardholder data directly, or don’t qualify for any other SAQ type. With approximately 329 questions covering all 12 PCI DSS requirements, SAQ D represents the most comprehensive self-assessment.

SAQ TypeWho It’s ForNumber of RequirementsVulnerability Scan RequiredPenetration Test Required
SAQ AFully outsourced e-commerce~30Yes (under v4.0)No
SAQ A-EPE-commerce with website scripts~140YesNo
SAQ BDial-out terminals only~40NoNo
SAQ B-IPIP-connected terminals~80YesNo
SAQ C-VTVirtual terminals on dedicated machines~70YesNo
SAQ CInternet-connected POS without storage~160YesNo
SAQ DAll others/data storage~329YesYes

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

The financial consequences of PCI non-compliance become starkly clear when examining major data breaches. These cases demonstrate that the true cost extends far beyond monthly non-compliance fees.

Target Corporation: $292 Million Total Cost

In 2013, hackers compromised Target’s point-of-sale system during the holiday season, exposing over 40 million customers’ payment card information. The breach became one of the most significant retail data security incidents in history.

Target’s Financial Consequences:

  • $18.5 million multi-state settlement with 47 states and D.C.
  • $10 million class action settlement with affected consumers
  • $19 million to Mastercard
  • $67 million to Visa
  • $39.4 million to banks and credit unions for losses related to the breach
  • $58 million settlement with issuing banks
  • Additional confidential settlements with individual card issuers

Target’s 2016 annual financial report listed the total costs of the breach at $292 million. The company was also required to implement enhanced security measures, employ an executive to oversee information security, and encrypt payment card information.

Home Depot: $179+ Million in Combined Costs

Home Depot’s 2014 breach compromised approximately 56 million payment card numbers when hackers installed malware on self-checkout point-of-sale systems.

Home Depot’s Financial Consequences:

  • $17.5 million multistate settlement with 46 states and D.C.
  • $25 million to financial institutions that had not released claims
  • $2.25 million to financial institutions through MasterCard’s ADC program
  • $134.5 million minimum to credit card companies and banks
  • $13 million consumer settlement
  • Implementation of enhanced security measures for at least two years

Heartland Payment Systems: $140+ Million and Loss of Processing Ability

In 2008, Heartland Payment Systems suffered one of the worst data breaches in history, with attackers stealing as many as 130 million debit and credit card records. The company was PCI compliant at the time of the breach, demonstrating that compliance is a snapshot in time rather than a permanent security guarantee.

Heartland’s Financial Consequences:

  • $60 million to Visa
  • $41 million to Mastercard
  • $5 million to Discover
  • $3.5 million to American Express
  • $26 million in legal fees
  • Banned from processing payments for major credit card providers for 14 months
  • Stock price fell 50% within days, ultimately dropping 77%

The attacker, Albert Gonzalez, was sentenced to nearly 20 years in federal prison.

Equifax: $700 Million Settlement

While not a merchant, Equifax’s 2017 breach demonstrates the potential scale of data security failures. The breach affected approximately 147 million consumers when hackers exploited a known vulnerability in the company’s web application framework.

Equifax’s Settlement:

  • $300 million consumer fund for credit monitoring
  • Up to $125 million additional if initial fund insufficient
  • $175 million to 48 states, D.C., and Puerto Rico
  • $100 million civil penalty to the Consumer Financial Protection Bureau
  • Enhanced security requirements and third-party assessments

PCI DSS 4.0: What Changed and What You Must Do Now

PCI DSS version 4.0 took full effect on March 31, 2024, with additional “future-dated” requirements becoming mandatory on April 1, 2025. Version 4.0.1 provided clarifications but did not change the compliance deadlines.

Key New Requirements Effective April 2025

Defining PCI DSS Scope: Organizations must annually (or every six months for service providers) define and document the scope of their PCI DSS assessment. This involves identifying all system components, people, and processes that interact with cardholder data.

Payment Page Scripts: Organizations must implement controls for all payment page scripts executed in consumers’ browsers to prevent unauthorized modifications. This requirement specifically targets Magecart-style attacks.

Automated Technical Solutions: Organizations must deploy automated solutions for public-facing web applications to continually detect and prevent web-based attacks.

Enhanced Password Requirements: PCI DSS 4.0 increased minimum password length to 12 characters (up from 7) and introduced stricter authentication requirements.

Multi-Factor Authentication (MFA): All access into the cardholder data environment now requires MFA, not just remote access.

Old Requirement (v3.2.1)New Requirement (v4.0)
7-character minimum password12-character minimum password
MFA for remote access onlyMFA for all CDE access
Annual risk assessmentsTargeted risk analyses for multiple controls
No payment page script requirementsInventory and integrity monitoring for all scripts
Point-in-time assessmentsContinuous monitoring emphasis

Industry-Specific Compliance Considerations

PCI DSS applies to any business that accepts credit cards, but certain industries face unique challenges and overlapping regulatory requirements.

Healthcare: Where PCI DSS Meets HIPAA

Healthcare organizations often maintain payment account data alongside Protected Health Information (PHI). If payment data is kept separately from health information in designated record sets, PCI DSS applies to that payment data independently from HIPAA.

A critical mistake healthcare organizations make is assuming PCI compliance equals HIPAA compliance. These are separate standards with different requirements. PCI DSS focuses on payment card data; HIPAA protects health information. When payment workflows include patient names linked to balances, procedure descriptions, or appointment references, that data may qualify as PHI and trigger HIPAA requirements.

Healthcare organizations must:

  • Conduct separate risk assessments for PCI DSS and HIPAA
  • Ensure payment processors sign Business Associate Agreements if they handle PHI
  • Implement controls that satisfy both standards where data overlaps

Restaurants: Point-of-Sale Vulnerabilities

Restaurants face elevated PCI compliance challenges due to high employee turnover and frequent terminal access. PCI DSS 4.0 requires separate accounts for each employee rather than shared logins, which many restaurants historically used.

PCI compliance for restaurants is not required by law, so a restaurant cannot face criminal charges for non-compliance. However, a data breach combined with non-compliance can result in devastating financial consequences that put small restaurants out of business.

E-Commerce: Script Security and Third-Party Risk

E-commerce businesses face unique challenges under PCI DSS 4.0’s requirement for payment page script controls. Even if a business uses a third-party payment processor, any JavaScript running on the checkout page must be inventoried, monitored for integrity, and authorized.


Common PCI Compliance Mistakes to Avoid

Mistake 1: Underestimating Scope

One of the most frequent errors is retailers underestimating the breadth of PCI DSS requirements. Many fall into the trap of thinking, “This doesn’t fully apply to my business.” However, PCI DSS encompasses all systems that store, process, or transmit cardholder data—including systems that can affect the security of the cardholder data environment.

Commonly Missed In-Scope SystemsWhy They’re In Scope
Authentication serversControl access to payment systems
Patch serversUpdate systems handling card data
Log serversStore records of card data access
Administrative workstationsCan access cardholder data
Wireless access pointsProvide network connectivity to CDE
NTP serversSystems in CDE rely on them

Mistake 2: Believing Third-Party Processors Eliminate Compliance

Many businesses believe that using a third-party processor makes them fully covered with PCI compliance. Using third-party processors reduces scope but does not eliminate the requirement. You still must fill out the appropriate SAQ, secure your website and payment forms, and ensure all service providers you work with are PCI compliant.

The Truth: You cannot outsource PCI compliance responsibility. Under PCI DSS 4.0, although merchants are free to use third parties, responsibility for any security liability remains with the merchant.

Mistake 3: “I Don’t Store Card Data, So I’m Safe”

Not retaining data does not get you off the hook. If you transmit cardholder data—even briefly—you must comply with PCI DSS. Hackers frequently target data in transit, making secure connections and encryption mandatory regardless of storage practices.

Mistake 4: Using Weak or Shared Passwords

Weak or compromised passwords remain one of the most straightforward methods for attackers to access protected systems. PCI DSS requires unique logins for each user with proper roles and permissions. Multi-factor authentication (MFA) is now required for all access to the cardholder data environment under PCI DSS 4.0.

Mistake 5: Neglecting Service Provider Compliance

Retailers often overlook the compliance status of their service providers, not realizing they bear responsibility for ensuring their partners’ PCI DSS compliance. PCI DSS Requirement 12.8 specifically addresses third-party vendor management.


Do’s and Don’ts of PCI Compliance

Do’s

Do maintain a current inventory of all system components â€” PCI DSS Requirement 2.4 requires tracking all systems in your PCI scope. Without this inventory, you cannot properly protect what you don’t know exists.

Do conduct quarterly vulnerability scans â€” Required under PCI DSS, these scans help identify security weaknesses before attackers exploit them.

Do encrypt all cardholder data in transit and at rest â€” Requirements 3 and 4 mandate encryption. The Heartland breach demonstrated that encryption at rest alone is insufficient if data travels unencrypted within your network.

Do implement proper network segmentation â€” Segmentation can significantly reduce PCI DSS scope and the cost of compliance. However, segmentation must be verified through testing.

Do document everything â€” Maintain updated policies, procedures, network diagrams, and data flow charts. PCI assessors require documented evidence of your security controls.

Don’ts

Don’t store sensitive authentication data after authorization â€” This includes full magnetic stripe data, CVV codes, and PINs. Storing this data is explicitly prohibited regardless of encryption.

Don’t use vendor-supplied default passwords â€” Requirement 2 mandates changing all default passwords. Attackers know default credentials and specifically target systems that haven’t changed them.

Don’t assume annual compliance means year-round protection â€” Compliance is a point-in-time assessment. Continuous monitoring and maintaining security controls throughout the year is essential.

Don’t ignore incident response planning â€” When (not if) a security incident occurs, having tested incident response procedures reduces damage and demonstrates due diligence.

Don’t delay validation â€” Monthly non-compliance fees of $20-$100 for small merchants quickly add up, and the fees escalate the longer you remain out of compliance.


Pros and Cons of PCI DSS Compliance

Pros

Reduced breach risk â€” Implementing PCI DSS controls significantly lowers the likelihood of a successful attack against your payment systems because the requirements address known attack vectors.

Liability protection in certain states â€” In Nevada and Washington, PCI compliance can provide legal defenses against certain breach-related lawsuits.

Customer trust â€” Demonstrating security commitment helps maintain customer confidence, especially after highly publicized breaches at major retailers.

Lower insurance premiums â€” Many cyber insurance policies offer better rates or broader coverage for PCI-compliant businesses.

Avoidance of monthly fees â€” Eliminating non-compliance fees of $20-$100 per month provides immediate cost savings.

Cons

Significant cost for Level 1 merchants â€” Annual assessments by qualified security assessors can cost $50,000-$200,000+ for large organizations.

Ongoing maintenance burden â€” Compliance is not a one-time achievement but requires continuous effort, monitoring, and documentation.

Complexity for small businesses â€” Understanding which SAQ applies and meeting requirements can overwhelm small business owners without security expertise.

Does not guarantee security â€” The Heartland breach occurred at a PCI-compliant company, demonstrating that compliance is necessary but not sufficient for security.

Scope creep â€” As systems change and new technologies are deployed, the PCI scope can expand unexpectedly, increasing compliance costs.


FAQs

Is PCI DSS compliance required by federal law?

No. PCI DSS is an industry standard created by credit card companies, not a government regulation. However, contracts with payment processors make it mandatory for businesses accepting card payments.

Can I go to jail for PCI non-compliance?

No. You cannot face criminal charges solely for violating PCI DSS because it is not a law. However, you can lose the ability to process payments and face severe financial penalties.

Does using Square or PayPal make me PCI compliant?

No. Using third-party processors reduces your compliance scope but does not eliminate your obligations. You must still complete the appropriate SAQ and follow applicable requirements.

How often must I validate PCI compliance?

Yes, validation is required annually. Businesses must complete their SAQ each year and may need quarterly vulnerability scans depending on their merchant level.

Are PCI fines tax deductible?

No. Generally, fines and penalties are not deductible as business expenses. Consult a tax professional for specific situations.

Does PCI compliance guarantee I won’t be breached?

No. Compliance demonstrates you met standards at assessment time. Heartland Payment Systems was PCI compliant when breached in 2008, losing 130 million card records.

What happens if I’m breached but was PCI compliant?

Yes, you may still face consequences, but in states like Nevada and Washington, compliance provides liability defenses. Card brands may waive certain fines if forensic audit shows compliance.

Can small businesses be exempt from PCI DSS?

No. If your business accepts payment cards, you must comply regardless of size. However, Level 4 merchants have simplified requirements compared to larger businesses.

Is PCI compliance required for e-commerce only?

No. PCI DSS applies to all card transactions including brick-and-mortar stores, phone orders, and e-commerce. Different SAQ types address different payment channels.

How much do PCI non-compliance fees cost small businesses?

Yes, small businesses typically face $20-$100 monthly non-compliance fees from processors. Fees continue until compliance is validated.

Do I need PCI compliance to accept Apple Pay or Google Pay?

Yes. While tokenized mobile payments reduce risk, merchants accepting any form of card payment must maintain PCI compliance.

Can my merchant account be terminated for non-compliance?

Yes. Acquiring banks may terminate merchant relationships for repeated or severe non-compliance, preventing you from accepting card payments.