Compliance Cybersecurity Hospitality

PCI DSS for hotels: why compliance is harder than it looks

A hotel takes card payments through more channels than almost any other retail business: booking engine, front desk, restaurant, spa, phone reservations, and pre-authorisations. PCI DSS is not UK law, but the fines and the operational disruption of losing card processing facilities make it one of the most consequential compliance obligations a hotel carries.

18 September 2026
11 min read
Key takeaways
  • PCI DSS is not UK law. It is a contractual obligation imposed by the card networks through your acquiring bank agreement, and fines for non-compliance can reach £100,000 a month
  • A hotel's payment scope is wider than most retailers: booking engine, front desk, restaurant and bar, spa, phone bookings, and recurring pre-authorisation charges each count
  • Which Self-Assessment Questionnaire (SAQ) applies depends on how you take payments, and ranges from 22 requirements at the simplest level to over 300 at the most demanding
  • Version 4.0, in force since March 2024, made multi-factor authentication mandatory and added new requirements to monitor third-party scripts on payment pages
  • The most effective way to cut compliance burden is to reduce scope: hosted checkout, tokenisation, and network segmentation take entire systems out of PCI DSS scope

PCI DSS is not UK law, but it is contractually mandatory

The Payment Card Industry Data Security Standard is not enacted by Parliament and no UK regulator enforces it directly. It is a private contractual standard set by the major card networks (Visa, Mastercard, American Express, Discover, and JCB) and passed down to merchants through the agreement you sign with your acquiring bank or payment processor. That distinction matters less than hotel operators sometimes assume, because the enforcement mechanism is your ability to keep taking card payments at all.

Non-compliance fines are levied by the acquiring bank, typically ranging from £5,000 to £100,000 a month depending on merchant level and the severity of the gap, and they compound the longer the non-compliance continues. In the most serious cases, particularly following a confirmed card data breach, the acquirer can suspend or terminate your ability to process card payments altogether. For a hotel, losing card processing is closer to an existential threat than a fine.

The current version of the standard, PCI DSS v4.0, has been in effect since March 2024 and fully replaced the older v3.2.1. Acquirers and payment processors now assess hotels against v4.0 requirements, including a set of provisions that only became mandatory from March 2025.

Why scope is more complex in a hotel than a typical retailer

A high street shop usually has one till and one payment channel. A hotel has several, and each one is a separate point where cardholder data can be captured, stored, or transmitted:

  • Booking engine. Your website or third-party booking platform captures card details at the point of reservation, often storing them for a guarantee against no-shows.
  • Front desk and check-in. Card present transactions at check-in and check-out, plus manual card entry for phone or walk-in bookings.
  • Restaurant, bar, and spa. Each outlet with its own till or card terminal is a separate cardholder data environment unless properly segmented.
  • Telephone reservations. Staff taking card numbers over the phone and entering them manually into a booking system, one of the highest-risk channels because it often bypasses point-to-point encryption.
  • Recurring charges and pre-authorisations. Holding card details on file for incidentals, damage deposits, or no-show charges extends the period cardholder data sits in your systems.

Merchant levels and which SAQ applies to your hotel

Your merchant level, set by your acquirer based on annual transaction volume, and how you take payments together determine which Self-Assessment Questionnaire (SAQ) you complete. Most hotels fall under Merchant Level 4, the lowest-volume tier, but the SAQ that applies still depends entirely on your payment architecture.

A
SAQ A · 22 requirements
Applies where all card processing is fully outsourced to a PCI DSS validated third party, such as a hosted booking engine checkout page. Your systems never touch cardholder data directly, which keeps the requirement count lowest.
B-IP
SAQ B-IP · 83 requirements
Applies to hotels using standalone, IP-connected payment terminals that are not connected to any other systems. Common at front desks using a dedicated card machine with no integration into the property management system.
C
SAQ C · 160 requirements
Applies where payment application systems are connected to the internet but the hotel does not store cardholder data electronically. Typical of properties with an integrated point-of-sale system across front desk and outlets.
D
SAQ D · 300+ requirements
Applies to any hotel that stores, processes, or transmits cardholder data without full network isolation from the rest of its IT environment. This is the most comprehensive and demanding SAQ, and the default for hotels that have not deliberately reduced scope.

The 12 PCI DSS requirements applied to hotel operations

Regardless of which SAQ applies, the standard rests on 12 core requirement areas: install and maintain network security controls with firewalls segmenting payment systems from guest Wi-Fi and general hotel IT; never use vendor-supplied default passwords on point-of-sale terminals or back-office systems; never store the card verification code (CVV/CVV2) after authorisation, a common failure point when staff note it down for phone bookings; encrypt cardholder data in transit and at rest; keep systems patched against known vulnerabilities, particularly on property management and point-of-sale software that is often left on outdated versions; restrict access to cardholder data on a need-to-know basis by job role; assign a unique login to every staff member with system access rather than shared front desk credentials; restrict physical access to card readers, back-office servers, and any location where card data is processed; log and monitor all access to systems handling cardholder data; test security systems and processes regularly, including penetration testing appropriate to your SAQ level; and maintain a documented information security policy covering all staff, including seasonal and agency workers who are common in hospitality.

What changed in version 4.0

MFA
now mandatory for all access to the cardholder data environment
12
characters, the new minimum password length under v4.0
Mar 2025
deadline after which the newer v4.0 controls became mandatory, not just recommended

Version 4.0 made multi-factor authentication mandatory for all access into the cardholder data environment, not only for remote or administrative access as under the previous standard. It raised the minimum password length to 12 characters and introduced the option of targeted risk analysis, letting organisations justify specific control frequencies based on their own risk assessment rather than a single fixed timeframe for every merchant.

The most operationally significant change for hotels is requirements 6.4.3 and 11.6.1, which require an inventory of all scripts running on payment pages and monitoring for unauthorised changes to those scripts. This directly targets Magecart-style skimming attacks, where a compromised third-party script (a chat widget, an analytics tag, a booking engine plugin) silently captures card data as guests type it into your booking page. A hotel relying on a third-party booking platform needs to confirm that platform's own script inventory and change-monitoring controls, not just its own.

Third-party scripts are a live risk

If your booking engine or website embeds chat widgets, analytics tags, or marketing pixels on the same page as the payment form, each one is a potential skimming vector. Under v4.0 you are required to know what runs on that page and to be alerted when it changes without authorisation.

How to reduce your compliance scope

The single most effective compliance strategy for a hotel is reducing scope rather than fully securing a wide one. A hosted checkout page for online bookings, where the guest enters card details directly into your payment provider's page rather than your own, removes your systems from PCI DSS scope for that transaction entirely. Tokenisation, which replaces the actual card number in your systems with a non-sensitive token, achieves a similar effect for stored guarantee and pre-authorisation data.

Network segmentation, isolating point-of-sale and payment systems from guest Wi-Fi and general hotel IT on separate VLANs, is required to claim the reduced scope of SAQ B-IP or SAQ C rather than defaulting to SAQ D. For further detail on isolating guest-facing networks, see our guide to guest Wi-Fi network segmentation for hotels. At the front desk, using a certified external payment gateway rather than capturing and keying card numbers directly into the property management system removes another large chunk of scope. For a broader look at the sector's threat landscape, see our overview of cybersecurity risks in hospitality. Full technical detail on all current requirements is published by the PCI Security Standards Council.

Disclaimer

This article provides general information and does not constitute legal, regulatory, or compliance advice. PCI DSS requirements and SAQ eligibility depend on your specific payment architecture and should be confirmed with your acquiring bank or a qualified security assessor.

Frequently asked questions

Is PCI DSS a legal requirement in the UK?

No. PCI DSS is a contractual requirement imposed by the card networks through your acquiring bank agreement, not a UK statute. Non-compliance is enforced through fines written into that contract, and in serious cases through withdrawal of card processing facilities, which for most hotels is more disruptive than a regulatory fine.

Why is PCI DSS scope more complex for a hotel than a typical retailer?

A hotel takes card data through more channels than a single till: the booking engine, front desk check-in, restaurant and bar tills, spa bookings, telephone reservations, and recurring or pre-authorisation charges for no-shows and incidentals. Each channel is a separate point where cardholder data can be captured, stored, or transmitted.

Which SAQ applies to my hotel?

It depends on how you take payments. A hotel using a fully outsourced, hosted checkout for online bookings typically qualifies for SAQ A. One using physically isolated IP-connected terminals may qualify for SAQ B-IP. A hotel with internet-connected systems that do not store card data typically falls under SAQ C, while properties that store, process, or transmit cardholder data without full network isolation fall under the more demanding SAQ D.

What changed in PCI DSS version 4.0?

Version 4.0, in effect since March 2024, made multi-factor authentication mandatory for all access to the cardholder data environment, introduced requirements to inventory and monitor third-party scripts on payment pages (6.4.3 and 11.6.1) to prevent skimming attacks, raised the minimum password length to 12 characters, and introduced targeted risk analysis in place of some fixed timeframes.

How can a hotel reduce its PCI DSS compliance scope?

The most effective methods are moving to a hosted checkout page for online bookings, using tokenisation so raw card numbers never touch your systems, segmenting the network so payment systems are isolated from guest Wi-Fi and general hotel IT, and using a certified external payment gateway at the front desk rather than capturing card data directly.

Ryland Deakin
About the author
Lead Consultant, Cyvra · CISM · CompTIA Security+ · MCP

Ryland has delivered cybersecurity, compliance, and IT management programmes for regulated organisations across the UK and the Netherlands for over 20 years, including senior roles at Microsoft, ING, IPsoft, PPHE and more. View full profile

Talk to Cyvra

Not sure which SAQ applies to your hotel?

We help hospitality businesses scope, assess, and reduce their PCI DSS compliance burden without disrupting guest-facing operations.