PCI DSS v4.0 for UK Hotels:
What You Must Do Now

Hotels handle card data in more ways than almost any other type of business. A single stay can involve a booking engine payment, an OTA virtual card, a pre-authorisation at check-in, a restaurant bill, a spa treatment and a final settlement at checkout — each touching a different system, and often a different member of staff.

That complexity is exactly why PCI DSS (the Payment Card Industry Data Security Standard) matters so much in hospitality, and why the move to version 4.0 has caught many UK hotels off guard. The transition period is over. If you have not reviewed your Self-Assessment Questionnaire (SAQ) since before 2025, this guide explains what has changed and what to do about it.

The PCI DSS v4.0 Timeline: Where We Are Now

PCI DSS is maintained by the PCI Security Standards Council, which was founded by the major card brands. The key dates are:

• March 2022: PCI DSS v4.0 published, replacing v3.2.1 after a transition period.
• 31 March 2024: PCI DSS v3.2.1 retired. From this date, all assessments had to be carried out against v4.0.
• June 2024: PCI DSS v4.0.1 published — a limited revision that clarifies wording and corrects errors but adds no new requirements.
• 31 December 2024: v4.0 retired in favour of v4.0.1.
• 31 March 2025: the "future-dated" requirements — dozens of new controls that were treated as best practice during the transition — became mandatory.

In short: there is no longer a grace period. Every requirement in v4.0.1 that applies to your environment must be in place now, and your next SAQ or assessment will be measured against all of them.

Why Hotels Are a Special Case

Most retailers take cards in one or two ways. A typical UK hotel takes them in many, and each route needs to be considered:

• Front desk: card-present payments and pre-authorisations on payment terminals, sometimes alongside manual key entry when a card will not read.
• Phone and email bookings: card-not-present transactions taken by reservations staff — historically one of the riskiest areas, because card details end up on notepads, in emails and in call recordings.
• OTA virtual cards: online travel agents frequently pay hotels with single-use virtual cards. These are still payment cards, and the screens and systems used to view and charge them are in scope.
• Online booking engine: your website's payment page, or the page your site redirects to, is a target for card-skimming scripts.
• PMS and payment integrations: many property management systems store card details or tokens for guaranteed bookings and no-show charges, and connect to payment gateways, POS and channel managers.
• Outlets: restaurant, bar, spa and events payments, often on separate POS systems with their own terminals.

Every one of these channels can bring systems, people and processes into PCI scope. The good news is that most of them can also be taken out of scope with the right technology choices.

Understanding Your Scope (and How to Shrink It)

Your cardholder data environment (CDE) is every system that stores, processes or transmits cardholder data, plus anything connected to it or able to affect its security. The larger your CDE, the more requirements apply and the harder compliance becomes. The single most effective PCI strategy for a hotel is to make the CDE as small as possible.

Segment guest WiFi and staff networks from the CDE

If payment terminals, the PMS and back-office PCs share a flat network with guest WiFi, CCTV and smart TVs, then in principle all of those devices are in scope. Network segmentation is not strictly mandated by PCI DSS, but without it you will struggle to reduce scope at all. In practice that means:

• Separate VLANs for guest WiFi, staff/corporate devices, payment systems and building systems
• Firewall rules that only allow the specific traffic payment devices need (typically outbound to the payment processor)
• Client isolation on guest WiFi so guests cannot reach each other or hotel systems
• Regular testing to prove the segmentation works — PCI DSS requires penetration testing of segmentation controls where you rely on them to reduce scope

Our firewall and network security service designs and maintains exactly this kind of segmented hotel network.

Use P2PE and tokenisation

Point-to-point encryption (P2PE) encrypts card data inside the payment terminal, so your network and systems never see readable card numbers. Using a solution listed by the PCI SSC as a validated P2PE solution can dramatically reduce the requirements you need to meet at the front desk and in outlets.

Tokenisation replaces a card number with a token that is useless to an attacker. When your PMS stores a token from your payment provider instead of the card number itself, the PMS holds far less sensitive data. Ask your PMS and payment providers specifically how card data flows between them, where (if anywhere) full card numbers are stored, and what their own PCI compliance status is.

Key v4.0 Requirements That Affect Hotels

PCI DSS v4.0 contains a large number of changes. These are the ones we see causing the most work for hotels.

Multi-factor authentication for CDE access

Requirement 8.4.2 extends multi-factor authentication (MFA) to all access into the CDE, not just remote or administrator access. If staff log in to systems that sit inside your CDE, those logins now need MFA unless an applicable exception applies. Remote access into your network from outside — for example, by a support vendor — must also use MFA.

Longer passwords and no shared accounts

Where passwords are used, v4.0 requires a minimum length of 12 characters (or 8 if a system genuinely cannot support 12), containing both letters and numbers. Every user must have a unique ID — shared front desk logins such as "reception1" are not acceptable for systems in scope, because you cannot tell who did what.

Targeted risk analysis

v4.0 gives more flexibility in how often some controls are performed, but in return you must document a targeted risk analysis justifying the frequency you choose. For a hotel this might cover, for example, how often you inspect payment terminals for tampering. It does not need to be a lengthy document, but it does need to exist and be reviewed.

E-commerce script management for booking engines

Requirements 6.4.3 and 11.6.1 target web-skimming attacks, where malicious JavaScript is injected into a payment page to copy card details as guests type them. They require an inventory and authorisation of scripts on payment pages, integrity checks, and a mechanism to detect unauthorised changes to the payment page.

How this applies depends on how your booking engine takes payment. In early 2025 the PCI SSC revised SAQ A so that these two requirements no longer appear in it, replacing them with an eligibility criterion that the merchant's website is not susceptible to script-based attacks that could affect the payment process. If your booking engine uses an embedded payment form (iframe) or redirect, ask your booking engine provider what they recommend and confirm the current SAQ wording with your acquirer.

Phishing and security awareness

v4.0 requires technical anti-phishing protection and security awareness training that specifically covers phishing and social engineering. This is highly relevant to hotels: fake "guest complaint" emails with malicious attachments and booking-platform impersonation scams are a common route into hotel systems, as we covered in our article on cybersecurity threats facing UK hotels.

Which SAQ Does a Hotel Fill In?

Most hotels are not large enough to need an on-site assessment by a Qualified Security Assessor (QSA) and instead validate compliance with a Self-Assessment Questionnaire. Which SAQ applies depends on how you take payments. Your acquirer decides which SAQ and validation level apply to you, so always confirm with them — the table below is a general guide only.

Many hotels combine channels and end up needing to complete more than one SAQ, or default to SAQ D. Reducing scope through P2PE, tokenisation and outsourced online payments is often what moves a hotel from SAQ D — the most demanding questionnaire — to something far more manageable.

Common PCI Mistakes We See in Hotels

• Card details in emails and notes: guests and agents email card numbers, staff forward them, and they sit in inboxes for years. Card numbers also appear in PMS comment fields and reservation notes.
• Storing the security code: the three-digit card security code (CVV/CVC) is sensitive authentication data and must never be stored after authorisation — not on paper, not in the PMS, not in call recordings.
• Paper booking forms: card details written down during phone calls and left at the desk or filed rather than securely destroyed.
• Shared logins: generic front desk and back-office accounts that everyone uses, with passwords that never change.
• Flat networks: payment terminals on the same network as guest WiFi.
• Unchecked terminals: no regular inspection of payment devices for tampering or substitution.
• Vendor remote access: PMS or POS suppliers with always-on remote access tools and no MFA.

Your PCI DSS v4.0 Action Checklist

1. Map every payment channel — front desk, phone, email, OTA, booking engine, outlets, events and payment links.
2. Draw your card data flows and identify every system that stores, processes or transmits card data.
3. Confirm your SAQ type and merchant level with your acquirer.
4. Reduce scope: move to P2PE terminals and tokenised PMS integrations, and use secure payment links or pay-by-link instead of taking card details by email.
5. Segment your network so guest WiFi and general office devices cannot reach payment systems, and test the segmentation.
6. Enable MFA for all access into the CDE and for all remote access, including vendors.
7. Remove shared accounts and enforce 12-character minimum passwords on in-scope systems.
8. Purge stored card data from inboxes, PMS notes, spreadsheets and paper files, and set a policy to stop it coming back.
9. Review your booking engine payment page with your provider and agree who manages script security.
10. Write your targeted risk analyses for any controls where you set your own frequency.
11. Train staff on card handling, phishing and social engineering — including seasonal and agency staff.
12. Collect compliance evidence from your providers (PMS, payment gateway, booking engine, POS) and keep it on file.

Frequently Asked Questions

Does PCI DSS apply to small independent hotels?

Yes. PCI DSS applies to any business that accepts, processes, stores or transmits payment card data, regardless of size. Smaller hotels usually validate compliance with a Self-Assessment Questionnaire rather than an external audit, but the requirements that apply to their environment are the same.

Are OTA virtual cards in scope for PCI DSS?

Yes. Virtual cards are payment cards, so any system or process used to view, store or charge them is in scope. The safest approach is to have virtual card details passed directly into a tokenised PMS or payment gateway, rather than copied by hand from an extranet.

Can guests send card details by email?

You should discourage it. PCI DSS prohibits sending unprotected card numbers by end-user messaging technologies, and inboxes are hard to secure. Use a secure payment link instead, and if a guest emails card details anyway, process the payment through a secure channel and delete the email.

Who decides which SAQ my hotel completes?

Your acquirer. They determine your merchant level and how you must validate compliance. Use the SAQ eligibility criteria as a guide, but always confirm with your acquirer before you start.

If my PMS is PCI compliant, is my hotel compliant?

No. A compliant PMS or payment provider reduces your risk, but your hotel is still responsible for its own network, devices, user accounts, staff processes and paper records. Ask each provider for evidence of their compliance and a clear statement of which requirements they manage for you.

Getting Expert Help

PCI compliance in a hotel is part technical and part operational. GGG Technologies has supported more than 500 hotels since 2010, and our PCI DSS compliance service covers scoping, network segmentation, MFA rollout, SAQ preparation support and staff guidance. It sits alongside our wider hotel cyber security and managed cyber security solutions, backed by a UK-based 24/7 team. You can request a quote or call us on +44 20 3642 4958.