You take card payments. That means PCI DSS applies to you.

It applies whether you run one site or twenty, whether you use a full EPOS system or a card terminal on the bar, and whether anyone has ever asked you about it or not.

Most restaurant operators know the acronym. Far fewer could say what it actually requires, and even fewer know where their business currently stands. That is not a criticism. It is a standard written by the card industry, in the card industry’s language, and nobody in hospitality signed up to become a security specialist.

This guide explains what PCI DSS compliance for restaurants actually involves, where multi-site operators tend to slip, and what to do about it without turning it into a six-month project.

What is PCI DSS?

PCI DSS stands for the Payment Card Industry Data Security Standard. It is a set of security requirements created by the major card brands to protect cardholder data.

It is not law. It is a contractual obligation that sits inside your merchant agreement with your acquirer or payment provider. Which in practice means it carries real consequences: monthly non-compliance fees, higher transaction charges, and in the event of a breach, fines and liability that fall on you rather than the bank.

The current version is v4.0.1. Since 31 March 2025, requirements that were previously treated as future-dated best practice have been mandatory, and assessments now cover the full standard.

The bigger shift is philosophical. The standard has moved away from an annual point-in-time validation model towards continuous evidence that controls are actually working across the year.

That matters for hospitality more than most sectors, because a restaurant group changes constantly. New sites, new staff, new devices, new suppliers. A snapshot taken in January tells you very little about July.

What does PCI DSS actually require?

The standard runs to twelve requirement areas. For a typical restaurant or restaurant group, the ones that bite in practice are these.

Network security. Your payment devices should not sit on the same network as guest Wi-Fi, back office machines, or the smart TV in the bar. Segmentation is the single most valuable thing most operators can do, because it shrinks the amount of your estate that falls in scope.

Access control. Every person with access to payment systems needs their own login. Shared accounts, generic manager logins, and the password written inside the till drawer all fail. Multi-factor authentication is now expected for access into the cardholder data environment, not just for administrators.

No storing what you do not need. Card numbers should not be written on paper for phone bookings, stored in a spreadsheet, or kept in a booking note field. If you do not store it, you cannot lose it.

Patching and anti-malware. Every device in scope needs to be current. That includes the EPOS terminals, the back office PC, and the router.

Logging and monitoring. You need to be able to show what happened and when. This is the requirement most operators discover they cannot meet, usually at the worst possible moment.

Policy and training. Someone has to own this, staff need to know the basics, and it needs to be written down.

You can read the full requirement set on the PCI Security Standards Council website, though be warned that it is written for assessors rather than operators.

Where multi-site restaurant groups go wrong

This is the part that catches good businesses out.

Head office has strong processes. The finance team knows what it is doing. The policy exists and it is a genuinely decent policy.

Then you look across the estate and every site is running slightly differently.

Different EPOS versions because site four was refurbished two years later. Different network configurations because three different installers did three different fit-outs. Different Wi-Fi setups because one landlord insisted on their own provider. Different people, with different levels of understanding, doing broadly the same job in slightly different ways.

None of that is anyone’s fault. It is what happens when a business grows one site at a time, with technology decisions made in the moment by whoever was closest to the problem.

But PCI DSS does not assess your best site. It assesses your business. If site nine has a flat network and a shared admin login, that is your compliance position, regardless of how good site one is.

Consider a nine-site group with an average of 600 covers a week per site. That is a lot of card transactions passing through nine different configurations. The risk is not evenly spread, and until someone maps it, nobody knows where it sits.

The SAQ question

Most restaurants validate compliance through a Self-Assessment Questionnaire rather than a full assessor-led audit. Which SAQ applies depends on how you take payments.

If you use a standalone terminal with a dial-up or dedicated line and no electronic cardholder data storage, you are likely in the simplest bracket. If your EPOS is integrated, connected to your network, and handling card data, the questionnaire gets considerably longer.

Two things worth knowing.

First, the SAQ is a declaration. Signing it says the controls are in place. If they are not and a breach follows, that signature matters.

Second, your acquirer decides which SAQ applies, not you. If you are unsure which one you should be completing, ask them directly. It is a five-minute email and it removes a lot of guesswork.

Making compliance part of how the business runs

The operators who find PCI DSS manageable are the ones who stopped treating it as an annual event.

Practically, that looks like a handful of habits.

Segment the payment network at every site. Same design, every time, so a new opening inherits the standard rather than reinventing it.
Review user access quarterly. People change roles and leave. Access rarely follows them out of the door.
Standardise the build. One EPOS configuration, one network design, one documented setup. Site twelve should look like site one.
Keep the evidence as you go. Patch reports, access reviews, and change records collected through the year rather than reconstructed in the week before the SAQ is due.
Give it an owner. One named person, at head office, responsible for the whole estate.

That last one is the difference between a group that is compliant and one that hopes it is.

This is the work we do with multi-site operators as part of ongoing cybersecurity support and our wider hospitality practice: building the same strong foundation into every site so that compliance is a by-product of good infrastructure rather than a separate project bolted on afterwards.

If you are also planning new openings, it is worth reading how we approach IT for multi-site hospitality businesses, because the two problems are closely related. Getting the build right at site level is what makes the compliance position hold across the estate.

Where to start this week

You do not need a major project to make progress. You need thirty minutes and three answers.

Ask your acquirer which SAQ applies to your business.
Ask whoever manages your network whether payment devices are segmented at every site, not just head office.
Review who currently has administrator access to your EPOS and back office systems, and remove anyone who no longer needs it.

If any of those three questions produces an uncomfortable silence, that is useful information. It tells you exactly where to start.

One business. One standard. Every site.

Not sure where your estate stands?

We work with multi-site hospitality operators across the UK to build compliance-ready infrastructure that holds up at every location.

Book a free 30-minute IT review or call 0330 313 0966 and we will tell you straight whether we are the right fit.

PCI DSS Compliance for Restaurants: Your 2026 Guide