At two sites, securing card payments is largely a checklist exercise. You pick a terminal vendor, you put the till on a sensible network, you complete the SAQ that your acquirer points you at, and you move on. Twice a year someone in the office remembers to ask whether anything has changed, and the answer is usually no.

At twenty sites - across two or three brands, possibly with more than one acquirer, almost certainly with more than one EPOS configuration - none of that holds. Card payment security stops being a project with an end date and becomes an ongoing programme. Different sites have different terminals, different network topologies, different staff turnover patterns and different vendors with remote access. The risks compound, the controls drift, and the moment you stop actively managing it, the estate starts to slide.

This post is for the FDs and operations directors of multi-site restaurant groups who know payment security matters but are not sure how to think about it at scale. It is not a PCI primer - we have written separately about PCI DSS 4.0 in detail - it is a piece on what changes when you have more than a handful of venues and what good actually looks like.

The attack surface in a real restaurant

When operators picture a card breach, they usually picture the payment terminal itself. In practice, that is rarely where the trouble starts. The attack surface in a multi-site restaurant is a lot wider:

  • Payment terminals themselves, including their firmware, their network interfaces and any management portal the vendor provides.
  • EPOS integrations - the software bridge between the till and the terminal, often involving middleware that nobody on site can name.
  • Back-office servers and PCs that handle reconciliation, reporting and sometimes credentials for the payment platform.
  • Staff devices - managers’ laptops, tablets used for stock or rota apps, phones connecting to the office network.
  • Guest Wi-Fi that has, somehow, ended up bridged to the same VLAN as the till. This is more common than anyone wants to admit.
  • Firmware on tills, kitchen printers and label printers that has not been touched since installation, because nobody wants to be the one who broke service on a Friday night.
  • Third-party remote access - the EPOS vendor, the payment vendor, the loyalty integration, the booking platform. All have ways in, and all of them are part of your security perimeter whether you treat them that way or not.

Any one of these can be the entry point. In multi-site groups, an attacker who finds a weakness at one venue often finds the same weakness at all the others.

The three architectures for taking card payments

Most restaurant groups use one of three broad approaches. The right one for you depends on your operating model, your EPOS, your average ticket size and the working preferences of your team. None of them is universally better - but the security trade-offs are different, and worth understanding.

1. Standalone terminals at the table. Devices from providers like Dojo, SumUp, Square or Zettle, operated independently of the EPOS. Staff key in or read the bill total, the customer taps, the receipt prints. The terminal handles the entire card transaction itself and reports back to the vendor’s platform. From a PCI perspective this is the simplest model, because the cardholder data never touches your network at all - the terminal is on the vendor’s mobile data or a segregated SSID, and the EPOS just records that a payment happened. The trade-off is that reconciliation is more manual and integration with reporting is thinner.

2. Integrated terminals driven by the EPOS. The till sends the bill total directly to a terminal, the customer pays, and the result flows back into the EPOS automatically. This is a much smoother service experience and gives you proper itemised reporting. The price is that the EPOS, the local network and the integration middleware are all now adjacent to the payment flow, which means more of your environment is in or near PCI scope. Done well, with a properly segmented network and a vendor that uses point-to-point encryption, this is fine. Done badly, it pulls everything into scope.

3. Hosted or tokenised payments via a payment service provider. Used heavily for online ordering, deposits, gift cards and pre-authorisation against no-shows. The customer’s card data is captured in a vendor-hosted page or via a tokenisation service, and your systems only ever see a token. From a PCI standpoint this is by far the cleanest model for the data you are storing, and it is the right approach for anything that is not face-to-face.

In practice, any group of scale runs all three at once. The standalone or integrated terminals handle the in-venue experience; the PSP handles the digital side. That is fine - it just means three sets of controls to keep aligned.

Segmentation, properly understood

The single most important security principle for card payments is segmentation. PCI DSS calls the part of your environment that handles card data the cardholder data environment, or CDE, and the standard expects it to be isolated from everything that is not in scope. In practice, in a restaurant, that means:

  • Payment terminals and till hardware sit on a dedicated VLAN with their own IP range.
  • That VLAN can talk to the acquirer and to the EPOS server it needs, and nothing else. No general internet, no guest Wi-Fi, no music streaming, no CCTV.
  • The firewall enforces this with explicit allow rules, not “default permit”.
  • Guest Wi-Fi is on a completely separate VLAN with no route into the CDE at all, as we discuss in our work on managed networks for hospitality.
  • Back-office machines that need to talk to the CDE are themselves protected: hardened operating system, MFA, no shared logins.

Segmentation is not optional under PCI DSS 4.0, and it is the control that does the most to limit the consequences if anything else fails. The failure mode at multi-site groups is that segmentation is in place at the head office and at the flagship site, but somewhere out at site number twelve, an electrician plugged a printer into the wrong port two years ago and nobody has checked since.

Which SAQ actually applies

Operators often ask which Self-Assessment Questionnaire fits their group. The honest answer is that it depends on exactly how you take payments at every venue, and your acquirer is the body that confirms it. At multi-site scale, there are a few things worth knowing:

  • If every site uses standalone terminals from a P2PE-listed provider and no card data ever touches your network, you may be eligible for SAQ P2PE - the shortest of them all.
  • If you have integrated terminals using validated point-to-point encryption, SAQ B-IP is the usual fit.
  • If your environment is more complex than that - multiple architectures, custom integrations, card-not-present flows - you may end up on SAQ C, SAQ D, or pushed into a full Report on Compliance.
  • The transaction volume thresholds for being designated Level 1 (and therefore needing a ROC and a Qualified Security Assessor) are set by the card schemes and applied by your acquirer. Ask them. Anyone who tells you the answer without asking your acquirer is guessing.

The reason this matters at multi-site scale is that the SAQ you complete has to honestly reflect every site, not just the ones you remembered when you filled it in. If three of your venues have a slightly different setup, the SAQ for the rest of the estate does not cover them.

The controls that matter most across an estate

Once segmentation is in place, the controls that genuinely move the needle for multi-site groups are:

  • Tokenisation and P2PE wherever possible. Anything that removes raw card data from your environment shrinks your scope and your risk in the same move.
  • Per-site firewalls and segmentation, built consistently to the same template. If every venue’s network looks different, you will never be able to assert that controls are in place across the estate.
  • A real inventory of payment terminals. Make, model, serial number, firmware version, location, supplier, contract end date. If you cannot produce this list in five minutes, you do not have one. Skimming devices and swap-outs are detected by inventory discipline, not by hope.
  • Centralised logging and monitoring. Logs from firewalls, EPOS servers and key endpoints flowing into one place, reviewed on a documented cadence. At twenty sites, local log review is fiction.
  • Consistent patching. Firmware on tills, terminals, printers and routers, on a schedule, with a record. Out-of-date firmware is the easiest control gap to find and the most boring to fix, which is why it is usually wide open.
  • Centralised identity and access. One directory, MFA on everything that touches the CDE, no shared accounts, joiners-movers-leavers process that actually runs. The “one manager login per site” model is finished under PCI DSS 4.0.

None of these are exotic. The challenge is making them stick across every venue, every week, for years.

The mistakes we see most often

When we audit a multi-site group’s payment environment for the first time, the same handful of issues come up repeatedly:

  • Flat networks at one or more sites, with the till sharing a subnet with the guest Wi-Fi, the kitchen tablet and the office PC.
  • Shared passwords for EPOS administration, manager overrides and remote access - often the same password across the entire estate.
  • No terminal inventory. Nobody can produce a definitive list of payment devices in service, where they are, or who owns them.
  • Stale firmware on tills, terminals and printers, because nobody scheduled the updates and nobody wants to be blamed for downtime.
  • Consumer-grade routers at smaller sites, deployed by a local installer years ago and never replaced.
  • Forgotten remote access for vendors who no longer work with the group, with credentials still active.
  • Inconsistent SAQ scope between what the head office filed and what each site actually does.

Each of these is fixable in isolation. The reason they accumulate is that nobody owns payment security as a programme - it sits in the gap between the EPOS supplier, the acquirer, the IT provider and the operations team, and everybody assumes someone else has it covered.

How we approach it

CloudMatters works with multi-site hospitality groups across London and the South East to bring payment security under proper management. Our approach is unglamorous and deliberately so:

  • Site-by-site hardening, working through the estate to bring every venue up to a consistent network, firewall and identity baseline.
  • Centralised logging, monitoring and patch management, so that the controls keep working between visits without depending on local heroics.
  • Vendor coordination - talking directly to your EPOS supplier, your payment provider and your acquirer, so the security model is agreed across all parties rather than each one pointing at the others.
  • Documentation that holds up to an SAQ or a QSA visit, kept current as the estate changes.

The aim is straightforward. Take payment security off your operations team’s plate, run it as a programme rather than a series of fire drills, and make sure that on the day something goes wrong at one site, the consequences stop at that site.

If you are running a multi-site restaurant group and your payment environment has not had a proper review in the last eighteen months, talk to our cyber security team. We will tell you honestly what we find, what to prioritise, and what it will cost to put right.