Ask ten payment processors whether PCI compliance is required by law in the US and you'll get ten hedged answers. Here's the straight one: there's no federal PCI statute — and it doesn't matter, because three other forces do the enforcing. Your processor bills you for lapses, three states wrote card security into their own law, and the FTC treats sloppy card handling as an unfair business practice. Let's take them in order of how likely they are to reach you.
The short answer: no federal law, but three enforcers#
PCI DSS is a private industry standard, written by the PCI Security Standards Council — the body the major card brands set up. Congress never passed it, and no federal agency audits merchants against it. If you're looking for the statute, it doesn't exist.
What exists instead is a web of contracts. When you signed your merchant agreement, you agreed to comply with PCI DSS. Your processor made the same promise upstream to the card brands. That chain of contracts is how a "voluntary" standard becomes something you can be billed, fined, and dropped over. If you want the full picture of the standard itself, start with what PCI DSS actually is.
Who actually enforces PCI DSS in the US#
For most businesses, enforcement arrives as a line on the monthly processing statement. Miss your annual Self-Assessment Questionnaire and most US processors add a recurring non-compliance fee — often somewhere between $20 and $100 a month depending on the processor — and it repeats every month until you file. Plenty of merchants pay it for years without noticing.
After a breach, the machinery gets heavier. Card brands assess penalties against your acquirer, your acquirer passes them down to you, and you're funding a forensic investigation and card reissuance on top. We've covered what non-compliance actually costs in detail — the short version is that the monthly fee is the cheap part.
The three states that wrote card security into law#
This is where the US differs from most of the world, and where "PCI isn't law" stops being fully true.
Nevada went furthest. Its security statute, NRS 603A, directly requires businesses that accept payment cards to comply with PCI DSS when handling cardholder data. In Nevada, the industry standard effectively is the law.
Minnesota's Plastic Card Security Act (Minn. Stat. 325E.64) takes a different route. It prohibits retaining card security codes, PINs, and magnetic stripe data after a transaction is authorized — and if you violate that and get breached, you're on the hook to the banks for the costs of the breach, card reissuance included.
Washington's RCW 19.255 flips the incentive around: businesses and processors can be held liable to financial institutions for breach costs — but the law provides a safe harbor if the card data was encrypted or the business was certified PCI-compliant at the time of the breach. In Washington, your compliance status is literally a legal defense.
Sell across state lines — which is every US business with a website or a phone line — and the practical conclusion is simple: you're subject to the strictest state you sell into, so the "is it law" debate is academic. Our guide to state data-breach laws for payment companies maps the wider patchwork.
Where the FTC and state attorneys general come in#
The Federal Trade Commission doesn't enforce PCI DSS by name. What it enforces is Section 5 of the FTC Act — the ban on unfair and deceptive practices — and it has repeatedly treated weak card-data security as exactly that. If your privacy policy says customer data is protected and a breach shows it wasn't, that gap is the FTC's way in. State attorneys general run parallel plays under their own consumer-protection and breach-notification laws.
Neither needs PCI to be "law" to act. But in practice, documented PCI compliance is the strongest evidence you can put forward that your security was reasonable — which is why it shows up in settlements and consent orders even though the statute books never mention it.
What your processor requires — and bills you for#
Whatever the law says, your processor's requirements are the ones with your name on them. Expect three things: an annual Self-Assessment Questionnaire matched to how you take payments, vulnerability scans if your setup requires them, and an annual renewal. Which SAQ you're on is the single biggest lever — the difference between answering a handful of questions and proving hundreds of controls across every system that touches card data.
The cost side has its own logic, and we've broken down the full cost of PCI compliance separately. The pattern to remember: doing it properly costs less than lapsing, and lapsing costs far less than breaching.
Merchant levels: who has to prove what#
Enforcement also scales with size. The card brands sort US merchants into four levels by annual transaction volume. Level 1 — above six million transactions a year, or any merchant that's already been breached — has to bring in a Qualified Security Assessor for a full on-site audit and a Report on Compliance. Levels 2 through 4 self-assess with an SAQ, which is where the vast majority of American businesses sit.
Which SAQ matters more than which level. SAQ A is the short form, for merchants who've fully outsourced card handling so no cardholder data ever touches their systems. SAQ D is the long form — hundreds of controls — for anyone whose environment stores, processes, or transmits card data. Everything in between (A-EP, B, C and the rest) tracks how much of the payment path runs through your own equipment. The strategic question for any US merchant isn't "how do I pass SAQ D?" It's "how do I arrange my payments so SAQ D doesn't apply to me?"
How we cut phone payments down to SAQ A#
Phone payments are where compliance scope balloons, because a spoken card number drags your agents, screens, recordings, and network into scope. For a contact center, that's the difference between SAQ A and the long-form nightmare — we've written up PCI DSS v4 for US contact centers if that's your world.
We've been a PCI DSS Level 1 certified service provider since 2016, audited independently every year, with offices in London and New York. When your customer types their card number on their phone keypad, our DTMF masking converts the tones so your agent never hears the digits and the number never reaches your systems or recordings. Card data goes straight to us and on to your processor. Your environment stays out of scope, and you land on SAQ A — the shortest questionnaire.
And because the annual paperwork is its own grind, we built Paytia Comply — a free app covering all 966 PCI DSS v4.0.1 requirements, with the official wording intact and photo evidence captured on your phone. Talk to us about descoping your card payments — we'll show you exactly what changes.
