If your last serious look at PCI compliance was back in 2022, you are working from an out-of-date rulebook. PCI DSS 4.0 has been mandatory since March 2024, and the additional future-dated requirements became enforceable on 31 March 2025. That is not a deadline on the horizon - it is a deadline already in the rear-view mirror. For restaurant operators who took card payments through the festive season and into 2026 on an estate that has not been reviewed in a couple of years, this is the moment to put it right.
I have these conversations with restaurant groups every week. The good news is that PCI DSS 4.0 is workable. The bad news is that the casual approach a lot of operators have taken historically - tick the SAQ, file it, forget it - does not survive contact with the new standard. Let me walk you through what has changed, where compliance tends to break in hospitality, and what a sensible response looks like.
What PCI DSS 4.0 actually is
PCI DSS - the Payment Card Industry Data Security Standard - is the rulebook published by the PCI Security Standards Council that governs how any business handling card data must protect it. It is not UK law in itself, but it is contractually binding on you through your acquirer (the bank or processor that takes your card transactions). If you take card payments, you are in scope. There is no version of “we are too small” that exempts you.
Version 4.0 replaced 3.2.1 and is now the only version in force. It was designed to address how dramatically payment environments have changed: cloud POS, tablet ordering, third-party integrations, delivery platforms, QR code menus, pay-at-table - none of which existed in their current form when 3.2.1 was written. The new standard is more flexible in some ways and significantly more demanding in others.
The five changes hospitality operators should care about
There are dozens of new and clarified requirements. These are the ones that bite in restaurants:
1. Multi-factor authentication, expanded. Under 3.2.1, MFA was effectively required only for remote access into the cardholder data environment. Under 4.0, MFA applies to all access into the cardholder data environment, including from inside your own network. If your back-office PC logs into your EPOS management portal with a username and password alone, that no longer cuts it.
2. Stronger authentication requirements. Password length minimums have moved up, account lockout thresholds are tighter, and shared accounts are now explicitly restricted. The “everyone uses the manager login” model that is endemic in hospitality is no longer defensible.
3. The customised approach. This is one of the genuinely useful changes. PCI 4.0 lets you meet a control objective in a way that suits your environment, provided you can document the risk analysis and prove it works. For a multi-site operator with a non-standard architecture, that flexibility is worth having - but it requires real documentation, not hand-waving.
4. Anti-phishing and awareness controls. There are new requirements around protecting staff from phishing and ensuring training is in place. Given that almost every breach in hospitality starts with a phished credential or a social-engineered email to head office, this is overdue.
5. Targeted risk analysis. Several requirements now ask you to perform and document a risk analysis to set the frequency of certain activities (log reviews, vulnerability scans, and so on). You can no longer just say “we do it sometimes” - you need a written rationale.
Where compliance breaks in real restaurants
When we audit a new hospitality client, the same handful of issues come up almost every time:
- Flat networks. The EPOS terminals, the back-office PC, the guest Wi-Fi, the kitchen tablets and the music streaming box are all sitting on the same network. PCI DSS expects you to isolate the cardholder data environment from everything else. Without proper network segmentation, your scope expands to cover every device on site - which is both a compliance nightmare and a real security risk.
- Shared logins. “Manager1” with a password the whole team knows. Multiple managers using the same EPOS admin account. No way to attribute an action to a person. Under 4.0 this is a clear failure.
- Consumer-grade kit in commercial use. Tablets bought from the high street, an off-the-shelf router from a home broadband contract, a back-office PC that has not had a firmware update since it was unboxed. None of this passes muster.
- Unpatched till hardware. EPOS terminals running old operating systems because “the supplier said not to touch them”. That excuse does not appear anywhere in the standard.
- No segmentation between sites. Multi-site operators connecting all their venues over a flat VPN with no separation. One compromised back office and the attacker has the entire estate.
- Third parties with the keys. EPOS vendors, loyalty platforms, booking systems, delivery integrations - all with remote access, often with credentials that have not been rotated since installation.
None of this is unusual. All of it is fixable.
SAQ or ROC - which one applies to you?
The level of scrutiny you face depends on your annual card transaction volume and how you take payments. Most independent restaurants and smaller groups will be eligible for a Self-Assessment Questionnaire (SAQ) - typically SAQ B-IP or SAQ C, depending on your setup. The SAQ is not trivial, but you complete it yourself.
Larger groups - and anyone the acquirer pushes into Level 1 - need a full Report on Compliance (ROC), which means engaging a Qualified Security Assessor (QSA) to audit your environment annually. The threshold and the exact requirements vary by card scheme and by acquirer, so the right answer is to ask your acquirer directly which level you fall into and what evidence they expect. Anyone who tells you the answer without checking with your acquirer is guessing.
What a hospitality IT partner actually does for PCI
Compliance is not a piece of paper. It is a set of operational controls that have to keep working between visits. When we take on a hospitality IT support engagement with PCI in scope, the work typically covers:
- Network segmentation - building a properly isolated cardholder data environment so that EPOS traffic is separated from guest Wi-Fi, back office, kitchen displays and everything else. This usually shrinks your PCI scope dramatically and makes everything else cheaper.
- EPOS hardening - working with your till vendor to make sure terminal firmware, operating systems and configurations meet the standard, and that remote access is locked down.
- MFA on admin access - covering EPOS portals, back-office systems, cloud dashboards and anything else that touches cardholder data.
- Logging and monitoring - collecting logs from EPOS, firewalls and key systems, reviewing them on a documented cadence, and being able to evidence that you did so.
- Vulnerability management - regular internal and external scans, patch cycles, and a clear record of what was found and what was fixed. A proper SOC covers both.
- Staff awareness training - short, regular, role-appropriate training so the team can spot phishing and social engineering.
- Documentation - policies, risk analyses, network diagrams, asset inventories. The boring stuff that turns “we do this” into “we can prove we do this”.
Most of this overlaps directly with sensible cyber security hygiene - PCI is essentially a hospitality-specific subset of good security practice with payment data at its centre.
The cost of getting this wrong
I am going to be careful here, because anyone quoting you a specific fine number is making it up. The actual penalties are commercial, set by your acquirer and the card schemes, and they vary. What I can tell you is the shape of the consequences:
- Acquirer fines for non-compliance, which typically escalate the longer you stay non-compliant.
- Card scheme assessments if you are involved in a breach, which can be substantial.
- Loss of the ability to process card payments, which for a restaurant is existential. If your acquirer pulls the plug, you cannot trade.
- Reputational fallout if customer card data is exposed. Hospitality lives and dies on trust, and a card breach makes the local press very quickly.
- The cost of forensic investigation, which falls on you, not the card scheme.
The boring truth is that the cost of doing PCI properly is a small fraction of the cost of being on the wrong side of it.
What to do next - a practical checklist
If you are running a restaurant or a multi-site group and you are not certain where you stand, here is a sensible order of operations:
- Call your acquirer. Confirm which compliance level you fall under and what evidence they want this year.
- Locate your last completed SAQ or ROC. If you cannot find it, or it is more than 18 months old, treat that as the starting line.
- Inventory your card-handling environment. Every terminal, every back-office machine, every device that touches the EPOS network, every third-party vendor with access.
- Map your network. Where is the segmentation? Where is it missing? Where is guest Wi-Fi versus EPOS traffic?
- Audit user accounts. Get rid of shared logins. Check who has admin rights to what.
- Check MFA coverage. Anywhere that touches cardholder data, including from inside the network.
- Review your third parties. Rotate credentials, document who has access, and make sure remote access is auditable.
- Get help if you need it. A few days of expert review now is far cheaper than discovering gaps after an incident.
Where we come in
CloudMatters works with restaurant groups across London and the South East to take PCI compliance off the operator’s plate and make it run as part of a managed IT service. We will tell you honestly what is in scope, what is not, where your real risks sit, and what it costs to fix them. No sales theatre, no scare tactics, just the work.
If your last PCI review was a long time ago, or you have grown your estate without revisiting the question, get in touch with our hospitality IT team and we will arrange an initial review. It is the cheapest insurance policy you can buy against a very expensive problem.