PCI Compliance for Restaurants: What You Actually Have to Do
Small restaurants are Level 4: one self-assessment a year, a scan in some setups. Find the SAQ for your terminal, POS and ordering page, and clear the fee.
Updated Sep 21, 2026
TLDR
A restaurant with one to five locations is a Level 4 merchant under Mastercard's table and a Level 3 merchant under Visa's current three-level table. Both brands ask for one self-assessment questionnaire (SAQ) a year, collected by your processor, and a quarterly external scan only for some setups: an internet-connected terminal, a POS on your network, or an online ordering page. Square and Toast both say most of their customers do not need to file an SAQ. The PCI non-compliance fee on a statement is a processor charge, usually $20 to $100 a month, and it stops once you finish the SAQ in the processor's portal, which takes 20 to 60 minutes for a simple setup. The riskiest thing most small restaurants still do is write card numbers on paper for phone orders.
TLDR
A restaurant with one to five locations is a Level 4 merchant under Mastercard's table and Level 3 under Visa's. Both want one self-assessment questionnaire (SAQ) a year, collected by your processor, plus a quarterly external scan only for some setups: an internet-connected terminal, a POS on your network, or an online ordering page. Square and Toast say most of their customers do not need to file one. The PCI non-compliance fee on a statement is a processor charge, usually $20 to $100 a month, and it stops once you finish the SAQ in the processor's portal, about 20 to 60 minutes for a simple setup. The riskiest thing most small restaurants still do is write card numbers on paper for phone orders.
A small restaurant is PCI compliant when it completes the one self-assessment questionnaire that matches its card setup each year, runs a quarterly scan only if that SAQ asks for one, and keeps card numbers off paper and off the back-office PC.
This is for an owner with one to five locations who takes cards at the counter, online and over the phone, and who just got a letter from the processor or spotted a "PCI non-compliance fee" on a statement. It is not a review of any vendor's security and not a POS buying guide; for that, see what to look for in a restaurant POS system.
What is PCI DSS and who enforces it?
PCI DSS is the card industry's baseline set of security rules for any business that stores, processes or transmits card data, written by the PCI Security Standards Council and enforced by the card brands through your processor or acquiring bank, not by any government agency.
Three plain sentences. The PCI Security Standards Council calls PCI DSS "a set of baseline technical and operational requirements designed to protect payment account data" and says it applies to merchants "regardless of their size or transaction volume." The Council was set up in 2006 by American Express, Discover, JCB International, Mastercard and Visa, and its about page says: "We do not monitor the implementation of standards." Whether you must comply "is at the discretion of organizations that manage compliance programs, such as a payment brand, acquirer, or other entity."
Visa's compliance page says "Visa manages all data security compliance enforcement and validation initiatives" through issuers and acquirers, and Mastercard's SDP program FAQ says "it is your acquirer who will manage your PCI DSS compliance." The letter you got is your processor doing the brands' job.
What PCI level is a small restaurant?
A restaurant with one to five locations is a Level 4 merchant under Mastercard's table and a Level 3 merchant under Visa's current table, which at either brand means one self-assessment questionnaire a year, collected by your acquirer, rather than an outside audit.
| Level | Mastercard (Mastercard and Maestro combined) | Visa (current U.S. table) | What you file each year |
|---|---|---|---|
| Level 1 | Over 6 million transactions | Over 6 million transactions | Report on Compliance by an assessor |
| Level 2 | Over 1 million up to 6 million | 1 million to 6 million | SAQ (Mastercard adds an assessor sign-off for SAQ A, A-EP or D) |
| Level 3 | Over 20,000 e-commerce, up to 1 million | Under 1 million transactions | SAQ |
| Level 4 | All other merchants | Folded into Level 3 | SAQ |
Sources: Mastercard's Site Data Protection page and the Visa page above. Mastercard's Level 4 footnote says validation "to Mastercard is not required," but the acquirer "must validate to Mastercard that they have a risk management program in place" for its small merchants, which is why your processor keeps asking for the SAQ even though Mastercard never sees it. Worked example, illustrative numbers: one restaurant doing $1.5 million a year at a $25 average ticket runs about 60,000 transactions; five locations at $2 million each and a $30 ticket run about 333,000. Both sit far below the 1 million line.
Which SAQ does my restaurant need?
The SAQ you need depends on how card data physically moves in your restaurant, not on your size: a phone-line terminal is SAQ B, an internet terminal is SAQ B-IP, a POS on your network is SAQ C, an ordering page that hands the card form to the processor is SAQ A, and a page that touches card data itself is SAQ D.
The rules come from the Council's SAQ Instructions and Guidelines v4.0.1 r1 (April 2025, in the PCI SSC document library under the SAQ filter) and the forms themselves, such as SAQ A. The scan column shows whether Requirement 11.3.2, an external scan every three months by an Approved Scanning Vendor (ASV), is in that SAQ.
| Your setup | SAQ | Quarterly ASV scan | Size |
|---|---|---|---|
| Standalone terminal on a phone line, not on the internet | SAQ B | No | Short, about 30 requirements |
| Standalone terminal on internet or cellular data, not wired to the POS | SAQ B-IP | Yes | Medium, about 50 requirements |
| Terminal in a PCI-listed P2PE solution, phone orders keyed into it | SAQ P2PE | No | Short, about 25 requirements |
| POS system on your network, single store, no card storage | SAQ C | Yes | Long, plus MFA into the card environment |
| Online ordering that redirects to, or embeds, the processor's payment form | SAQ A | Yes, for the server hosting that page | 27 requirements |
| Online ordering page whose own code builds the card form | SAQ A-EP | Yes | 139 requirements |
| Online ordering page that receives card numbers on your server | SAQ D | Yes | All requirements |
| Phone orders keyed into a web virtual terminal on an isolated computer | SAQ C-VT | No | Medium |
Three rows trip restaurants up. Cellular terminals: a SIM card is still an IP connection, so assessors such as the PCI Ramblings blog place them under B-IP, though some acquirers accept SAQ B; ask your processor and get it in writing. SAQ C is single store only: if your locations share a network or back-office server, ask which SAQ the processor wants; the fallback is SAQ D. Online ordering: if any element of the payment page comes from your own site, "SAQ A does not apply; however, SAQ A-EP may be applicable," and 27 requirements become 139. That gap is why a hosted checkout matters more than any other single choice; the POS and online ordering integration guide covers how the pieces connect.
If Square or Toast handles every card you take, you may owe nothing. Square says a seller who uses Square for all storage, processing and transmission of card data does not need to validate compliance to Square or pay PCI fees. Toast: "most Toast customers do not need to submit such PCI compliance documentation or engage a company to complete vulnerability scans. Toast does not send out emails asking you to complete any of these documents." An SAQ email on those systems is from a second processor you also use, or it is phishing.
What changed in PCI DSS v4.0.1 that a small restaurant will notice
Version 3.2.1 was retired on 31 March 2024, v4.0.1 became the only active version on 31 December 2024, and 51 future-dated requirements became mandatory on 31 March 2025. What a small restaurant feels: longer passwords, multi-factor authentication in more places, scans for e-commerce merchants who never had them, and script rules for payment pages.
The dates are from the Council's blog: v3.2.1 retirement, v4.0.1 publication on 11 June 2024 with "no new or deleted requirements," and the 51 future-dated requirements out of 64 new ones. Checked against the v4 SAQ forms:
- Passwords are 12 characters minimum (Requirement 8.3.6) in SAQ A, A-EP, C and C-VT. MFA for all access into the card data environment (8.4.2) is in SAQ C, so a POS on its own network needs MFA on the back-office and admin logins that reach it; SAQ B-IP requires MFA for remote access from outside (8.4.3).
- Quarterly ASV scans came to SAQ A. Per the Council's ASV resource guide (July 2024), they apply to the server hosting the page that redirects to, or embeds, the processor's form.
- Payment page script rules. Requirement 6.4.3 (an inventory of every script on the payment page, each authorized and integrity-checked) and 11.6.1 (an alert on unauthorized changes to the page, checked at least every seven days) became mandatory on 31 March 2025 for SAQ A-EP and SAQ D e-commerce merchants, because, per the Council's March 2025 supplement, e-skimming attacks "have increased significantly."
- SAQ A got lighter, then gained a condition. On 30 January 2025 the Council removed 6.4.3 and 11.6.1 from SAQ A, effective 31 March 2025, and added an eligibility line: the merchant must "confirm their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)." FAQ 1588 limits that to pages with the processor's embedded form or iframe, not redirects, and accepts "obtaining confirmation from the merchant's PCI DSS compliant" processor that its solution protects the page. If your ordering page embeds the processor's fields, ask the processor for that letter.
What is the PCI non-compliance fee on my statement?
A PCI non-compliance fee is a monthly charge your processor adds when it has no current SAQ on file for you, usually $20 to $100 a month, and it stops once you complete the questionnaire in the processor's compliance portal. It is not a card brand fine; SecureTrust notes that real "PCI non-compliance fines are larger enforcement actions generally initiated by the card brands" and passed through the acquiring bank, typically after a breach.
Reported amounts: Merchant Maverick (August 2024) puts the typical non-compliance fee at $20 to $30 a month and names CardConnect at $29.95, TSYS at $94.95 and Flagship at $30, on top of annual compliance fees of $259.99, $99.50 and $119. NerdWallet (April 2026) reports Dharma Merchant Services at $39.95 a month and notes that Square, Stripe and PayPal charge no PCI fee. Brookside Payments (May 2026) and Clearly Payments (November 2025) both report $20 to $100 for small merchants. It is charged per merchant ID, so a restaurant with a counter account and a separate online ordering account can pay it twice.
To make it go away:
1. Find the portal. Your processor's welcome email or statement names it. Common ones are run by SecurityMetrics, Trustwave, Viking Cloud (formerly Sysnet), Aperia, or First Data's PCI Rapid Comply.
2. Answer the SAQ for your real setup. The portal asks how you take cards and routes you to the right form. Brookside estimates about 22 questions and 15 to 20 minutes for SAQ A, about 41 questions and 20 to 30 minutes for SAQ B; Swipesum says "the assessment should take less than an hour." Fix anything "not in place" before you attest, and run the scan if your SAQ requires one.
3. Check the next statement, then calendar next year. If the fee is still there, ask for a credit. Attestations expire after 12 months and the fee comes back, as Swipesum warns, "a year later when the certification expires."
What actually gets restaurants breached
Restaurants get breached through boring doors: an always-on remote access tool on the POS back-office PC, a default or shared password, POS or router software nobody patched, and card numbers written on paper for phone orders. None of these needs a sophisticated attacker.
The 2026 Verizon Data Breach Investigations Report analyzed more than 22,000 confirmed breaches. "Exploitation of vulnerabilities is now the most common initial access vector for breaches," at 31%, up from 20% the year before, with credential abuse at 13%. In its small and medium business section (under 1,000 employees, which is every independent restaurant group), System Intrusion, Basic Web Application Attacks and Social Engineering account for 100% of breaches, and "about 96% of Ransomware victims were SMBs." Table 3 counts 250 confirmed breaches in Accommodation and Food Services for the year covered.
Mapped onto a restaurant:
- Remote access left on. The Council's Guide to Safe Payments (v3.0, April 2024) warns that "many remote access programs are always on, or always available by default," that "hackers can access your systems too since many vendors use commonly-known passwords for remote access," and names VNC and LogMeIn. Have the vendor switch it off when not in use.
- Default or shared passwords. The same guide says equipment "including your payment terminal" ships with defaults like "password" or "admin," which "are commonly known by hackers and are a frequent source of small merchant breaches."
- Unpatched software. Verizon found only 26% of critical known-exploited vulnerabilities were fully fixed in 2025, with a median fix time of 43 days. For a restaurant that is the back-office PC, the router and the ordering platform.
- Card numbers on paper. Its own section below, because no software fixes it.
None of the four doors costs money to close.
The one-page PCI checklist for a restaurant
| Task | How often | Who does it |
|---|---|---|
| List every processor and merchant ID and ask each whether you owe an SAQ | Once, then when you add a processor | Owner |
| Complete the SAQ in each processor's portal and save the attestation | Every 12 months | Owner or GM, 20 to 60 minutes |
| Run the ASV scan if your SAQ includes 11.3.2 | Every 3 months | Processor's scanning vendor; owner reads the report |
| Change default passwords; one 12-character login per employee; MFA on admin and remote logins | At install, and when staff leave | Manager, with the POS vendor |
| Remote support access off by default, on only by request | Once, confirm yearly | POS vendor |
| Install POS, router and back-office updates when released | Monthly, or as notified | POS vendor and manager |
| Keep the payment network separate from guest Wi-Fi and the office PC | At install, and when the network changes | Network installer or POS vendor |
| Inspect terminals for tampering against a list with serial numbers and photos | Weekly | Shift manager |
| Remove any paper with card numbers; shred it, or black out the number | Daily | All staff; manager checks |
| Confirm every vendor that touches card data is PCI DSS compliant | Every 12 months | Owner (Requirement 12.8) |
| One-page incident plan: who to call, what to unplug, where the attestation lives | Once, review yearly | Owner |
| Train staff on card handling, tampering signs and fake "PCI" emails | On hire and yearly | Manager |
Print it, initial and date the margin, and keep it with the attestation. If you are shopping for a new POS partly to shrink this list, the POS system cost guide covers what the major systems charge.
Phone orders: the riskiest habit most restaurants still have
Taking a card number over the phone and writing it on a ticket is the single most exposed thing a small restaurant does, because the moment it is written down it becomes stored card data, and the security code on that paper is data you are never allowed to keep after the charge goes through.
The Council's Protecting Telephone-Based Payment Card Data supplement (v3.0, November 2018) says the call itself is generally out of scope, but if "the person answering the call writes down the account data, then the collection of account data in the scenario would be considered 'storage,' and the entity's processes and environment would be considered in scope for PCI DSS." If the security code is recorded, the entity "MUST render all data unrecoverable upon completion of the authorization process." A stack of tickets with full card numbers and CVVs in the drawer by the phone fails both at once.
Safer options, cheapest first:
1. Key it in live, write nothing. Enter the card into the terminal or the POS keyed-entry screen while the customer is on the line, read back the last four digits, and hang up. Keyed "directly and only into" a PCI-listed P2PE terminal, the Council's guidelines say, a phone order can even stay inside SAQ P2PE.
2. Send a pay-by-link text or email. The customer enters the card on a secure page and nobody in the kitchen hears it. The telephone supplement describes exactly this: a "secure link provided via SMS or e-mail, thus preventing the entity from being exposed to the cardholders' account data." Most processors and POS systems offer it.
3. Move the order online. Point the caller to your ordering site, where the processor's hosted fields take the card and your scope stays at SAQ A. If phone volume makes that a staffing problem, the phone ordering system buyer guide covers tools that answer and take payment for you.
Never accept card numbers by email or text either; the Council's small merchant guide says to process the payment, delete the email immediately, and tell the customer not to send details that way. And clear the drawer today: shred every ticket with a full card number, or black the number out with a thick marker first.
Where DirectOrders fits
DirectOrders is a hosted online ordering platform, so the card fields on a restaurant's ordering page are served by the payment processor rather than by the restaurant's own systems. That keeps the restaurant's own PCI scope small, the SAQ A end of the table rather than A-EP or D, while the restaurant keeps its customer data and gets same-day payouts. It does not replace your annual SAQ, the counter terminal, or the phone habits above. How payments and data are handled is on the trust page.
Sources
- PCI Security Standards Council: Merchants and About us, checked September 2026.
- PCI SSC Document Library, SAQ Instructions and Guidelines v4.0.1 r1 (April 2025), checked September 2026.
- PCI DSS v4.0 SAQ forms A, B, B-IP, C and P2PE, used to confirm which requirements each SAQ contains, checked September 2026.
- PCI SSC blog: v3.2.1 retirement, v4.0.1 published, future-dated requirements, SAQ A updates, FAQ 1588, ASV resource guide, payment page security supplement, all checked September 2026.
- PCI SSC: Guide to Safe Payments v3.0, April 2024, and Protecting Telephone-Based Payment Card Data v3.0, November 2018, checked September 2026.
- Visa: Account Information Security program and PCI, checked September 2026.
- Mastercard: Site Data Protection program and SDP FAQ, June 2024, checked September 2026.
- Square: PCI compliance guide, June 2026; Toast: PCI compliance overview, updated September 2026; Stripe: integration security guide; Clover Security: PCI Rapid Comply FAQ, all checked September 2026.
- Fee reporting: Merchant Maverick, August 2024; NerdWallet, April 2026; Swipesum, October 2024; Brookside Payments, May 2026; Clearly Payments, November 2025; SecureTrust, July 2026, all checked September 2026.
- PCI Ramblings: SAQ B and SAQ B-IP common misconceptions, checked September 2026.
- Verizon 2026 Data Breach Investigations Report, checked September 2026.
Bottom line
For a restaurant with one to five locations, PCI compliance is one questionnaire a year per processor, a quarterly scan only if your terminal is on the internet, your POS is on your network, or you run an ordering page, and a short list of habits: unique 12-character passwords, MFA on admin and remote logins, remote support off by default, patches installed, and no card numbers on paper. The non-compliance fee is a processor charge, not a fine, and it disappears the month you finish the SAQ. And whatever else you do this week, shred the phone-order tickets.
Frequently Asked Questions
No law names PCI DSS. It is a contract requirement. The five card brands founded the PCI Security Standards Council in 2006, and the Council writes the standard but does not enforce it. Your merchant agreement with your processor or acquiring bank is what obligates you, and the brands enforce it through those banks. As NerdWallet puts it, the government does not require PCI compliance; your payment processor does.
Related resources
Related Articles
"I'd like to order a large pepperoni pizza"
"Perfect! That's $18.99. Pickup in 20 min?"
How to Take Phone Orders at a Restaurant: Script and Checklist
A restaurant phone order script, a training checklist for new staff, the safe way to take card payments by phone, and how to count the calls you miss.
Pankaj Avhad
Restaurant Customer Retention: 10 Strategies That Actually Work
Proven customer retention strategies for restaurants. Learn how to keep guests coming back, increase repeat orders, and build long-term revenue without spending more on acquisition.
Pankaj Avhad
+43%
More Orders
2hrs/day
Save Time
+$8K/mo
Higher Revenue
+67%
More Customers
Benefits of Online Restaurant Ordering for Your Business
Online ordering increases ticket sizes by 15-20%, cuts phone errors, and gives you customer data you can actually use. Here is what changes when you add a real ordering system.
Pankaj Avhad