The card brands never fine you. Your acquirer does

In 2013 a retailer called Genesco sued Visa. The facts are the clearest explanation of PCI liability I've found anywhere.

After an intrusion, Visa collected more than $13.3 million in assessments and Mastercard roughly $2.3 million — not from Genesco, but from Wells Fargo and Fifth Third, its acquiring banks. Genesco's merchant agreements obliged it to indemnify both banks. So it paid, then sued Visa afterward to try to get it back, arguing Visa had no reasonable basis for the non-compliance finding and that no cardholder data had actually been taken for the accounts assessed.

That is the shape of PCI liability. The card brands have no contract with you. They assess your bank. Your merchant agreement makes it yours. And the PCI Security Standards Council — the body that writes the standard — states plainly that it does not receive assessment reports, is not involved in penalties or fines, and does not enforce compliance at all.

Which is why I'd suggest reading PCI DSS as a liability-allocation contract first and a security standard second. The security is real and worth doing. But the decisions that cost you money are about which paperwork regime you fall into, and who is holding the bag when something goes wrong.

What actually changed, and when

The current version is v4.0.1, published June 2024. Version 4.0 retired at the end of 2024. If a vendor tells you the standard changed again and you need remediation, note that 4.0.1 added no new requirements and removed none — it was a clarification release.

What did change is a deadline. Version 4.0 introduced 64 new requirements, 51 of them future-dated to 31 March 2025, with no grace period. The applicability note in the standard reads that each is "a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment."

Three of those 51 apply only to service providers, so a restaurant's real number is smaller than any generic checklist implies. The ones that actually reach a restaurant:

That last-but-one is worth sitting with. PCI SSC made "what to do when you find a PAN where it doesn't belong" a mandatory requirement, which is an acknowledgment that it happens constantly. In restaurants it happens in one specific place — free-text fields. A card number typed into a catering deposit note, a reservation comment, or a shared inbox pulls that system into your card environment. It was never scoped, never scanned, and no SAQ covers it.

Which SAQ you're in decides how much work you do

Almost every restaurant under roughly fifteen locations is a Level 4 merchant — the smallest of the four card-brand tiers. That does not mean exempt. It means self-assessment instead of an on-site audit, and which self-assessment questionnaire you use is the single biggest determinant of effort.

Counting the distinct requirement IDs in each questionnaire gives a rough sense of scale:

Those counts are my own tally rather than an official figure, so treat them as approximate. But the shape is the point: the P2PE path is roughly one-fifth the size of the standard integrated-POS path. That is the concrete version of "P2PE reduces scope," and it beats the "up to 90% fewer requirements" line that circulates in vendor material.

Three eligibility traps sit inside that table.

SAQ C dies when you open a second location. The eligibility text requires that the POS location "is not connected to other premises or locations, and any LAN is for a single store only." A shared WAN, a central back office, or head-office reporting fails it. You fall to SAQ D — the full standard — and nobody sends a notice. Growth silently roughly doubles your compliance work.

SAQ C-VT requires that no card reader is attached to that computer, and no batch or store-and-forward software is installed. Most operators who assume they qualify don't.

You owe an SAQ per payment channel, not per business. A restaurant with an integrated POS and an online ordering page owes two. Nothing in the sales process for either one tells you this.

P2PE, E2EE, tokenization: only one of them counts

These three get used interchangeably and they are not the same thing.

PCI-validated P2PE is a complete solution — device, application, key management, decryption environment, and an instruction manual — assessed and listed by PCI SSC. It is the only one of the three that unlocks a dedicated SAQ and formally removes systems from scope.

E2EE is the same cryptography without the listing. PCI SSC's guidance is that merchants may use non-listed encryption but should consult their acquirer or the payment brands about whether it's acceptable. Scope reduction becomes a negotiation rather than an entitlement.

Tokenization happens after authorization. It reduces what you store, which shrinks your obligations around stored data — but the capture path still handles a live card number.

The short version: P2PE protects the data on the way in and is the only one you can claim scope reduction for. Tokenization protects what you keep afterward. E2EE is P2PE without the paperwork, and the paperwork is the entire point.

One trap worth a calendar reminder: solutions can drop off the validated list when their validation expires, and an expired solution is no longer "validated." Your SAQ P2PE eligibility evaporates with it. The listing is the asset, not the encryption.

Two things Visa requires of you that nobody mentions

Since January 2017, for Level 4 merchants specifically:

Your POS installer is supposed to be QIR-certified. Acquirers are required to ensure Level 4 merchants using third parties for POS application and terminal installation engage only PCI-certified QIR professionals. Ask your integrator. Most restaurants never have, and most integrators are never asked.

There is an exit ramp from annual validation. Visa's Technology Innovation Program lets a merchant discontinue the annual PCI DSS validation assessment if it confirms sensitive authentication data isn't stored after authorization, runs at least 75% of transactions through EMV dual-interface/contactless terminals or a validated P2PE solution, and has no breach history. Almost no small operator has been told this exists.

Also worth knowing: single-use terminals with no internet connectivity are treated as low risk and may be excluded from these requirements entirely.

The line item on your statement

You will see PCI charges from your processor. Two different ones, often both.

A PCI program or compliance fee is charged whether or not you validate. A PCI non-compliance fee is charged for failing to validate — meaning failing to complete the SAQ and scan, not for being insecure.

That distinction matters because the non-compliance fee is levied by your acquirer under a private contract, not by PCI SSC and not directly by a card brand. It is therefore negotiable, and often refundable retroactively once you validate, in a way a card-brand assessment never is. Ask for it back.

I'm deliberately not quoting you a dollar range. Every figure in circulation — and there are several, all confident — traces to payment consultant blogs and processor marketing pages. I could not find a single acquirer-published fee schedule. The same goes for the "$5,000 to $100,000 per month in card brand fines" figure that appears in nearly every PCI article. If you want to know what yours is, it's on your statement, and I wrote about reading those in the merchant statement guide.

EMV liability is a different system entirely

Operators conflate these constantly, so: EMV liability shift allocates chargebacks for card-present counterfeit fraud. PCI DSS governs breach assessments. Being fully EMV-enabled does nothing to reduce a PCI assessment. Being PCI-validated does nothing to move a counterfeit chargeback. Both can bite in the same incident.

One detail inside EMV worth having right, because it's stated wrong almost everywhere: the October 2015 lost-or-stolen liability shift applies to American Express, Discover and Mastercard only — Visa is not in it — and it triggers only for PIN-preferring chip cards. There is no lost-or-stolen shift for ATM at all. The counterfeit shift is the one that covers everyone.

Where restaurants actually fail

A flat network. PCI never mandates segmentation. It just puts everything connected into scope. Guest Wi-Fi on the same segment as the terminals means the guest access point, the menu board, the manager's laptop and the kitchen tablet are all in your card environment — and you are no longer SAQ C eligible, because the payment system is now "connected to other systems."

Vendor default passwords. Published in manuals, indexed by search engines, and still the most exploited weakness in restaurant POS. This is not a new 2025 obligation; it has always been there.

Unmanaged remote access. An always-on support tool with a shared password across a franchise group is one credential that opens every location. Four separate requirements converge here now, including MFA for all non-console access and technical controls against copying card data out of a support session.

Your processor's compliance is not yours. Requirements 12.8.1, 12.8.2 and 12.8.4 make it your job to keep a list of every third party that touches account data, hold written agreements with them, and monitor their compliance status at least every twelve months. Their attestation covers their environment. It does not transfer your liability.

Some perspective on the risk

Verizon's 2026 breach report counted, for accommodation and food services, 319 incidents and 250 confirmed breaches over a twelve-month window — about 1.1% of the 22,625 confirmed breaches in the full dataset. Restaurants are a real target, not the apocalyptic one some vendor material describes.

More useful is what the same report says about retail: incidents involving internal company data rose from 65% to 84% year over year, with the observation that attackers now target any data they can monetize rather than card data specifically. Most restaurant security writing is still fighting the 2014 threat model. Your employee records, your vendor banking details, and your email are now worth stealing on their own — which is the same conclusion I reached from a different direction in the internal fraud post.

What I'd do this week

Find out which SAQ you're actually filing and whether it matches your setup — particularly if you've opened a second location since you last looked. Ask your processor in writing whether your terminals run a validated, currently-listed P2PE solution, and check the listing yourself. Ask whether you qualify for TIP. Get guest Wi-Fi off the terminal network. And search your reservation and catering systems for sixteen-digit strings, because requirement 12.10.7 exists for a reason.

Disclosure: I work at Katalyst. We sell restaurant POS, so the P2PE argument above is one I have an interest in. Which is why the most valuable item on that list costs nothing and involves no vendor: confirming which SAQ you're in, because if you've grown since you filed the last one, the answer has probably changed and the paperwork you owe has roughly doubled.

Related Katalyst products

• See Katalyst Flex POS
• See Katalyst Payments