The network is the spine of a modern restaurant. That is not marketing language - it is the literal truth of how a site operates on a Friday service. The till talks to the kitchen over it. The card machine talks to the acquirer over it. The booking tablet pulls from a cloud PMS over it. The cameras write to an NVR over it. The staff check rotas on their phones over it. The guests expect to stream music on it. Take the network down for ten minutes on a Saturday at 20:15 and you do not have an IT problem - you have a revenue problem, a service problem and a very cross general manager.

Despite this, most restaurant networks we inherit when a group moves to us are designed like a home network that grew up. A broadband router from the ISP. A consumer WiFi mesh that was cheap on Amazon. A flat single subnet with everything - POS, CCTV, guest phones, the manager’s personal laptop - sharing the same broadcast domain. One WAN. No monitoring. Nobody quite sure which cable goes where. This is not unusual. It is the default state. And it is the thing that has to change first before most of the other conversations about reliability, security or PCI DSS compliance can be had honestly.

This post sets out the site architecture we actually deploy, why each piece is there, and the anti-patterns we remove when we take on a new group.

The standard site architecture we deploy

Every new site we open and every site we remediate follows the same physical and logical pattern. The vendors vary depending on what the group is already invested in, but the shape is consistent.

Business-grade router and firewall

Fortinet FortiGate, Cisco Meraki MX, WatchGuard or equivalent. Never the router the broadband provider supplies, never a consumer box with a brand name you recognise from PC World. The firewall does real work - policy between VLANs, IPS, content filtering, site-to-site VPN back to the group’s hub or to our management platform, and deep logging we can actually query when something breaks. It is also the device that terminates dual WAN and handles failover.

Managed L2/L3 switch with PoE

One managed switch per site as a minimum, stacked or uplinked for larger venues. PoE+ is non-negotiable because it powers the access points, the IP cameras, the desk phones and in many cases the KDS tablets. A managed switch lets us do VLANs properly, mirror ports for troubleshooting, read CDP/LLDP neighbours to map the estate, and push config from a template. Unmanaged switches plugged into each other under the host stand are where site visits go to die.

Wireless access points designed for density

Restaurants are hostile RF environments. Metal ducting, stone walls, guests crammed shoulder to shoulder, forty phones per table on a Saturday night all negotiating 5GHz. We plan for roughly one access point per twenty-five concurrent devices, not per square metre. A 120-cover restaurant with staff devices, guest phones, payment terminals and IoT typically needs three or four APs - not one in the middle of the dining room and a prayer.

Structured cabling to every fixed endpoint

Every till position, every receipt and kitchen printer, every payment terminal dock, every KDS screen, every camera, every AP, every phone gets a Cat6 run back to the comms cabinet. This sounds obvious and expensive. It is both. It is also the single biggest determinant of whether a site is reliable in year three. Wireless POS is possible; wireless POS at the bottom of a busy brunch is a support ticket waiting to happen.

VLAN segmentation

Six VLANs as the default template:

  • Management - switches, APs, firewall, UPS, printers that need remote admin
  • POS - tills, KDS, receipt printers, the POS back-office server
  • Payments - card terminals only, with tightly scoped egress
  • Staff - back-office PCs, staff laptops, office printers
  • Guest - guest WiFi, fully isolated
  • CCTV and IoT - cameras, NVR, sensors, smart plugs, fridge telemetry

Inter-VLAN routing is denied by default and opened with specific rules where a real dependency exists. The POS VLAN cannot reach the staff VLAN. The guest VLAN cannot reach anything except the internet. The payments VLAN can only talk to the acquirer’s IP ranges on the required ports.

Dual WAN for failover

A primary circuit - usually FTTP where it is available - and a secondary on a different carrier and ideally a different medium. 4G or 5G is a perfectly reasonable secondary for a restaurant; it gets card payments and cloud POS back online in seconds even if it is not fast enough for the CCTV upload. The failover is tested, not assumed.

Why segmentation matters

Segmentation is the part operators push back on most often because it adds cost and complexity at install time. It is also the part that pays for itself first.

The PCI DSS argument is the one finance teams understand. If your card terminals share a flat network with every guest who connects to the WiFi, the entire flat network is in scope for PCI. Put the payment terminals on their own VLAN with controlled egress and the scope collapses to that VLAN. That is the difference between a three-page self-assessment and a genuinely painful audit conversation.

The security argument is the one we care about more. A compromised guest laptop on a flat network can scan the POS, brute force the NVR, and exfiltrate whatever it finds on the office file share. On a properly segmented network it cannot even see those devices exist. When we talk about cyber security for hospitality groups, segmentation is the foundation everything else sits on - without it, EDR and MFA are sticking plasters.

The performance argument is the quiet one. CCTV streams and guest video calls are both bandwidth-hungry and latency-sensitive. Keeping them on separate VLANs with QoS applied at the firewall means a guest streaming Netflix does not jitter your card transactions.

The wireless layer, and why we still love cable

Modern APs are extraordinary. Wi-Fi 6 and 6E can genuinely deliver the kind of density a busy restaurant needs. But we still recommend wired connections for every till, every kitchen printer, every payment terminal dock and every KDS screen that can physically take a cable. The reason is simple: these devices do not tolerate intermittence. A guest whose phone drops WiFi for two seconds does not notice. A card terminal that drops association mid-transaction generates a failed payment, an angry customer and a line of diners behind them. Cable is boring and cable is reliable. We accept more runs at install so that we have fewer tickets for the life of the site.

The wireless layer is then free to do what it is good at - guest devices, staff handhelds, roaming ordering tablets, and the growing population of IoT sensors. We use a dedicated SSID per VLAN, PSK rotation on the staff network, and a captive portal with terms of use on the guest network. Guest isolation is on by default so one guest device cannot see another.

Monitoring across the estate

A network you cannot see is a network you cannot run. For every site we take on, we monitor:

  • WAN uplink health - primary and secondary, latency, loss, jitter, failover events
  • AP health - client count, channel utilisation, noise floor, firmware drift
  • Switch port state - link flaps on POS and payment ports trigger alerts immediately
  • POS terminal heartbeat - we ping every till on a schedule and alert if one goes quiet during trading hours
  • Payment terminal connectivity - same principle, tighter threshold
  • DHCP lease pressure - a full pool is a silent outage waiting to happen
  • UPS state - battery health, mains events

Alerts route to our NOC during the day and to on-call overnight. A dropped POS terminal on a Saturday at 19:00 is a phone call to the site manager, not an email they will read on Monday. This is the operational layer our hospitality IT support service exists to deliver - the architecture alone is worth much less without the eyes on it.

Platinum versus standard - when to spec SD-WAN

Not every group needs SD-WAN. For a group of three to eight sites where the policy is simple and the traffic is mostly internet-bound, site-local firewalls with centrally managed templates are usually enough. We run them from a single cloud dashboard, push config consistently, and keep costs sensible.

The point at which we start recommending SD-WAN is normally somewhere around ten sites, or earlier if any of the following are true: the group has a central back-office that staff hit from every site and needs a private path; there is a head office or warehouse with shared resources; the group is running a private applications stack (labour management, stock, reservations middleware) that benefits from a controlled overlay; or compliance is pushing for consistent policy that cannot drift site by site. At that point the value of central policy, per-application steering and rapid site provisioning outweighs the uplift in licence cost.

We are vendor-agnostic on this. Meraki SD-WAN, Fortinet SD-WAN and a couple of the specialist providers all do the job. Pick based on what your engineers are fluent in.

Anti-patterns we rip out

Every remediation engagement turns up the same set of sins. In rough order of how dangerous they are:

  • Flat networks - everything on one subnet, no VLANs, PCI scope is the whole estate
  • Consumer-grade APs and routers - no central management, no firmware discipline, random reboots
  • Single WAN - one circuit, one provider, no failover, no plan
  • POS sharing the guest VLAN - genuinely common, genuinely terrifying
  • Payment terminals with unrestricted egress - talking to the whole internet rather than a small list of acquirer IPs
  • Unmanaged switches daisy-chained under furniture - no port visibility, no remote recovery
  • No DHCP monitoring - pools exhaust silently during a busy week and nobody knows why tills are dropping off
  • No cabling map - nobody can tell you which port goes where, so every fault becomes a half-day investigation
  • Shared PSKs that have not changed since opening - written on the back of the till, known to every ex-employee

We fix these on a priority basis during the transition and bring the site up to the standard build over the first quarter.

The CloudMatters standard build

Pulled together, the standard build for a single restaurant looks like this: business-grade firewall with dual WAN; managed PoE+ switch; three to six Wi-Fi 6 access points depending on floor plan and cover count; structured Cat6 to every fixed endpoint; six-VLAN segmentation with default-deny inter-VLAN; central cloud management; monitored from our NOC against an agreed set of thresholds; UPS on the comms cabinet sized for a thirty-minute ride-through.

That is not a luxury specification. It is the minimum we are willing to put our name against on a site that takes card payments and relies on a cloud POS. Anything less is storing up service incidents.

If you are planning a new opening, or looking at a tired estate and wondering where to start, the CloudMatters managed network service is designed to deliver exactly this architecture across multi-site groups, with the monitoring, change control and on-site response that keep it running once it is in. We would be glad to walk you through a site survey.