Compliance
PCI DSS for restaurants and hotel groups: the practical checklist
A practical PCI DSS checklist for multi-site restaurants and hotels: who enforces it, scope reduction, segmentation, phone orders and v4.x deadlines.
PCI DSS compliance for restaurants is a contractual obligation enforced by the card brands and your acquiring bank, not by a government regulator. Every requirement in version 4.x has been mandatory since 31 March 2025. MicroNet Global helps hospitality groups in the UK, US and UAE reduce card data scope, segment payment networks and evidence the controls acquirers ask for.
Why hospitality is a high-value target for card fraud
Hospitality concentrates everything a card fraudster wants: high transaction volume, terminals in public rooms, seasonal staff, and a technology footprint that grew site by site rather than to a plan. A group with forty venues often has three EPOS versions, two acquirers and one site still taking card details on paper.
The back office is the second problem. Reservations, events and finance handle card data in ways the payment estate never sees, and those channels rarely reach the first draft of a scope document.
What is PCI DSS?
PCI DSS is the Payment Card Industry Data Security Standard, a set of technical and operational requirements that any business storing, processing or transmitting payment card data must meet. It is maintained by the PCI Security Standards Council and enforced contractually by the card brands and acquiring banks. The current version is v4.0.1, a limited revision published in June 2024.
Who enforces it, and why that matters
Most operators assume PCI DSS is a law with a regulator behind it. It is not. The PCI Security Standards Council writes the standard, the card brands mandate it, and your acquirer polices it through your merchant agreement. The consequences are contractual, not criminal: non-compliance fees, higher assessment rates, brand fines passed down after a breach, forensic investigation costs, and in the worst case losing your ability to take cards.
What counts is the evidence you can produce for your acquirer on request. Separately, a card breach involving guest data triggers UK GDPR reporting to the Information Commissioner's Office, which **is** a statutory regulator.
Where v4.x stands: there is no runway left
Version 3.2.1 was retired on 31 March 2024. Of the 64 new requirements in v4.x, 51 were future-dated best practice until 31 March 2025, when they became mandatory. Every v4.x requirement is now in force.
If your last validation leaned on "future-dated, not yet required", that language no longer applies. Two changes catch hospitality in particular: the annual scope confirmation under Requirement 12.5.2, and tightened e-commerce expectations, with SAQ A merchants now facing quarterly ASV scanning expectations. Booking engines and gift voucher pages sit in that territory.
Merchant levels, SAQ and ROC
Merchant levels are set by each card brand according to annual transaction volume, counted by brand rather than by site. Level determines how you validate, not how much of the standard applies; the standard applies in full either way.
Most single-brand restaurant groups validate with a Self-Assessment Questionnaire and an Attestation of Compliance. Larger estates, and anyone who has suffered a breach, validate with a Report on Compliance produced by a Qualified Security Assessor. The trap for growing groups is silent escalation: ten new sites or a new delivery channel can push volume over a threshold.
Scope reduction is the highest-value move
Every control applies to systems in scope, so shrinking the scope shrinks the work permanently rather than buying compensating controls every year.
Point-to-point encryption (P2PE) and tokenisation do exactly that. With validated P2PE, card data is encrypted inside the terminal and your network never sees it in readable form, which takes the terminal estate and much of the connected infrastructure out of scope. Tokenisation replaces stored card numbers in the PMS, booking engine or CRM with tokens that are useless if stolen.
Map every place card data enters the business, move each one onto a P2PE or tokenised channel, then decommission the old path. Our [[IT consultancy team]{.underline}](about:blank) usually finds the path left open "just in case" is what undoes the work.
Segmentation: guest Wi-Fi and the payment estate
If the payment network is reachable from the guest network, the guest network is in scope. A flat site network puts every access point, signage player and back-office PC inside your assessment.
Proper segmentation means separate VLANs with enforced firewall rules, not just a different SSID, and rules tested rather than assumed. That is the discipline that makes [[guest Wi-Fi in hotels and restaurants]{.underline}](about:blank) both fast and defensible, and a core part of how we approach [[networking and Wi-Fi]{.underline}](about:blank).
The card-not-present channels operators forget
Card-present transactions get the attention. The quiet risk is elsewhere:
Emailed card details are a common breach vector and a reliable way to drag your whole mail platform into scope. The fix is procedural first: a secure payment link or IVR payment line, and a standing instruction that card details arriving by email are deleted, never actioned.
- Deposits and no-show charges taken by phone at reception or
- reservations
Physical terminals, people and the annual scope check
Terminal tampering and swap-outs still happen, usually where terminals sit on a bar and turnover is high. Keep a serial-number inventory, check devices against it on a cycle, and train staff to challenge anyone servicing a terminal without a job reference.
Requirement 12.5.2 requires you to confirm PCI scope at least annually and after any significant change: a new site, a new EPOS version, a new payment channel or an acquirer switch. Tie that check to your opening process, the way the [[IT critical path for a new venue opening]{.underline}](about:blank) forces the questions early.
The multi-site PCI checklist
| Control area | What good looks | Who typically owns |
|---|---|---|
| Card acceptance mapping | Every channel documented per site, phone and events included | Finance / Group Ops |
| Terminals | Validated P2PE, serial inventory, scheduled tamper checks | IT partner + GM |
| Stored card data | Tokenised in PMS, EPOS and CRM; no readable PANs at rest | IT partner + vendors |
| Segmentation | Payment VLAN firewalled from guest, back office and AV; tested | IT partner |
| Guest Wi-Fi | Separate VLAN, isolated egress, no route to payment | IT partner |
| Remote access and logging | MFA on vendor and admin access, time-limited, centrally logged | IT partner |
| Phone and email orders | Payment links or IVR; emailed details deleted | Reservations / Events |
| Physical security | Locked comms rooms, controlled back-of-house access | GM + IT partner |
| Staff training | Role-specific at induction and annually, with records | HR + Group Ops |
| Third parties | Current AOCs from EPOS, PMS, acquirer, booking platforms | Finance / Procurement |
| Scope confirmation | Reconfirmed annually and after significant change (12.5.2) | Group Ops + IT partner |
Where this needs a professional
This is general guidance, not a compliance assessment. Merchant level, SAQ type and the boundary of your cardholder data environment depend on your acquirer agreement and your estate, and a Qualified Security Assessor should confirm scope before you rely on it. No product or service makes a business compliant. What an IT partner builds are the technical conditions for a good outcome: segmentation, tokenisation, access control, logging and evidence, alongside [[cyber security services]{.underline}](about:blank) and [[IT support for restaurants and bars]{.underline}](about:blank).
Frequently asked questions
Yes. The merchant agreement is with you, so the obligation stays with you even when a provider handles encryption and processing. A good provider sharply reduces your scope and the number of requirements you validate against, but you still complete an SAQ or ROC, keep providers' attestations on file, and confirm scope annually.
Written by the MicroNet Global team. If you are working through any of this for your own estate, the specialists here are happy to talk it through.