PCI DSS for hotels is not a checklist problem. It is a scoping problem, and it is a harder one than almost any other merchant faces, because a hotel is several different kinds of merchant wearing one brand. The booking engine is an e-commerce business. The reservations line is a mail-order and telephone-order business. The front desk is a face-to-face retailer. The restaurant, the bar and the spa are three more. The events team bills companies weeks after the guest has left. Every one of those is a separate payment channel with its own rules.
Most guidance written about PCI DSS for hotels quietly assumes you are one of those things. You are all of them at once, which is why so many UK operators reach for the shortest questionnaire, tick it, file it, and discover during a forensic investigation that they were never eligible for it.
This guide is written for UK hotel operators and hospitality groups running one to twenty properties, with a small in-house IT function or none at all. It covers what the standard actually says, where card data hides in a hotel, which self-assessment questionnaire you are genuinely allowed to use, the controls that became mandatory on 31 March 2025, a fully costed four-property worked example with 340 bedrooms, and how all of it interacts with UK GDPR.
There are five tables, three charts, a 90-day plan and a reference list of primary sources. Where a requirement is quoted, it is quoted from the PCI Security Standards Council’s own questionnaire documents rather than paraphrased from a vendor blog. Where a figure is given, the arithmetic that produced it is shown.
Our companion pieces cover the neighbouring ground: the hotel cyber security checklist sets out the twenty controls behind all of this, hotel PMS cyber security goes deeper on the reservation system itself, and Cyber Essentials for hotels covers the UK certification that sits alongside it.
Table of contents
- Why PCI DSS for hotels is a scoping problem, not a checklist
- What PCI DSS v4.0.1 is and what changed on 31 March 2025
- Where card data actually lives in a hotel
- Merchant levels: which one does your hotel fall into?
- The SAQ trap: why no single questionnaire fits a hotel
- Card on file, guarantees and no-show charges
- Telephone bookings: the hardest channel in PCI DSS for hotels
- The booking engine, e-skimming and requirements 6.4.3 and 11.6.1
- POS, PMS and the room-charge interface
- Payment terminals: requirement 9.5.1 at the front desk
- Scope reduction: what P2PE and tokenisation are actually worth
- The v4.0.1 controls that catch UK hotels out
- What PCI DSS for hotels costs a UK group
- PCI DSS for hotels and UK GDPR are not the same obligation
- Fraud, chargebacks and what non-compliance actually costs
- A 90-day plan for PCI DSS for hotels
- Frequently asked questions about PCI DSS for hotels
- References
Why PCI DSS for hotels is a scoping problem, not a checklist
Every merchant has to answer one question before any other, and PCI DSS for hotels is no exception: what is in scope? For a card shop with one till, the answer takes ten seconds. For a hotel it takes a fortnight, and getting it wrong is the single most expensive mistake in the whole exercise.
PCI DSS for hotels starts with at least five payment channels
A 120-bedroom property with a restaurant typically takes payment through the brand website’s booking engine, through online travel agencies, over the telephone for group and corporate bookings, at the front desk on a chip-and-PIN terminal, at the restaurant and bar tills, at a spa or leisure desk, and on an invoice raised weeks later for an event. That is seven touchpoints before you count car parking or vending. PCI DSS for hotels has to account for every one of them separately, because the standard validates by payment channel, not by company.
PCI DSS for hotels mixes channels other merchants never mix
This is the structural difference. A pure e-commerce retailer never takes a card face to face. A market trader never takes one online. A hotel does both, on the same day, for the same guest, sometimes for the same stay — a deposit taken online, a balance taken at the desk, an incidental charged to the room and settled at checkout. The questionnaires published by the PCI Security Standards Council are each written for one of those worlds, and each explicitly excludes the others.
PCI DSS for hotels is contractual, and your acquirer enforces it
There is no Act of Parliament behind any of this. PCI DSS is not UK law; it is a contractual obligation that reaches you through your merchant agreement with your acquiring bank, which is in turn obliged by Visa, Mastercard and the other schemes to hold its merchants to the standard. That has two practical consequences. Your acquirer, not a regulator, decides what evidence you must submit and when. And a failure is a commercial event first — non-compliance fees, higher transaction charges, liability shift — before it is anything else.
Compliance is a state you validate annually, not a certificate you own
The output of PCI DSS for hotels is an Attestation of Compliance, signed by you, covering a defined scope, at a point in time. Requirement 12.5.2 makes the scope itself an annual exercise: PCI DSS scope must be “documented and confirmed by the entity at least once every 12 months and upon significant change to the in-scope environment”. Open a new spa, swap booking engines, or add a self check-in kiosk, and the scope changes that day.
In PCI DSS for hotels, bad scope costs more than the audit fee
If you complete the wrong questionnaire, you have attested to something untrue. The document does not become correct because your acquirer accepted it. It becomes the first thing examined after an incident, and it is the reason PCI DSS for hotels should always start with a data-flow exercise rather than a control list.
What PCI DSS v4.0.1 is and what changed on 31 March 2025
Version confusion is common, and it matters, because the version you are assessed against determines which controls are optional and which are not. Anyone quoting v3.2.1 rules at you on PCI DSS for hotels is working from a version that was retired in 2024.
PCI DSS for hotels means v4.0.1, the only active version
PCI DSS v4.0 was published in March 2022 and retired on 31 December 2024. PCI DSS v4.0.1, a limited revision published in June 2024 to address stakeholder feedback and clarification requests, is the only active version of the standard. There is no transition window left and no earlier version that remains valid, so any PCI DSS for hotels programme running today is a v4.0.1 programme.
The 51 future-dated requirements now bind PCI DSS for hotels
When v4.0 was published, 51 of its requirements were flagged as best practice until 31 March 2025. That date has passed. Every one of them is now in force and must be fully considered during an assessment. The scale is easy to underestimate: in the v4.0 Self-Assessment Questionnaire D for Merchants alone, the phrase “best practice until 31 March 2025” appears 39 times.
The new controls hit hospitality harder than most sectors
Several of the future-dated requirements land squarely on how hotels actually work, and they are the ones that make PCI DSS for hotels feel newly expensive. Multi-factor authentication for all access into the cardholder data environment. Twelve-character passwords. Automatic malware scanning of removable media. Automated audit log review. Payment page script inventories. Periodic inspection of payment terminals, at a frequency you have to justify in writing. None of those were required under v3.2.1, and all of them are awkward on a shared front desk.
Who writes the rules for PCI DSS for hotels, and who enforces them
The PCI Security Standards Council writes and publishes the standard, the questionnaires, the terminal approval programmes and the validated solution lists. It does not enforce anything. The card schemes set the merchant levels and the validation requirements, and your acquirer applies them to you. When those three sources appear to disagree, the acquirer’s instruction is the one that governs your paperwork.
The standard is deliberately outcome-based
v4.0 introduced the customised approach, which lets an entity meet a requirement’s stated objective by a different method, documented and validated. It is genuinely useful for large estates with unusual architecture. For most UK hotel groups it is a distraction, because the customised approach requires a targeted risk analysis, a documented control design and, in practice, a Qualified Security Assessor to validate it. The defined approach is cheaper.
Where card data actually lives in a hotel
Before choosing a questionnaire, map the data. This is the part operators skip, and it is the part that determines everything else about PCI DSS for hotels. Nothing else in the programme survives a wrong map.
PCI DSS for hotels begins at the booking engine and brand website
If a guest types a card number into a page served from your domain, your website is in scope even when the number itself goes straight to a payment service provider. That is not an interpretation; it is stated in the questionnaire. The merchant website “impacts how the account data is transmitted, even though the website itself does not receive account data”.
Online travel agencies and channel managers
An OTA booking usually arrives as a virtual card number or a bank-transfer settlement, which is the easiest outcome PCI DSS for hotels can give you. What is not helpful is the pattern where a booking arrives with a real card number embedded in the reservation record, gets pulled into the property management system by the channel manager, and sits there until someone charges it. That card number is now yours, stored on your systems, and it drags the PMS into scope.
The reservations telephone line under PCI DSS for hotels
A guest reads sixteen digits, an expiry date and a security code down a phone line to an agent. That agent has a headset, a screen, a keyboard and, in far too many hotels, a notepad. If the call is recorded, the recording contains sensitive authentication data. If the agent types into the PMS, the PMS is in scope. If the agent writes it down and shreds it later, the paper is in scope while it exists.
PCI DSS for hotels at the front desk and the pre-authorisation
Chip-and-PIN at check-in is the best-behaved channel in the building, provided the terminal is a PCI-listed approved PIN Transaction Security point-of-interaction device and it talks only to the acquirer. The moment it is integrated with the PMS so that the pre-authorisation posts against the reservation, the segmentation story changes.
Food and beverage, spa and room service
Every till is a payment channel that PCI DSS for hotels has to account for. Every one of them typically posts to a room account, which means every one of them touches the PMS. A group with four restaurants and two spas across four properties has a dozen payment applications feeding one central system, and PCI DSS for hotels has to reconcile all of them into a single scope statement.
Groups, events and post-stay billing in PCI DSS for hotels
Corporate and events billing is where stored card data accumulates. A company card on file to guarantee a room block, a delegate card for extras, a card retained for a no-show charge on twenty rooms. These arrive by email as often as not, which puts the mailbox in scope and creates a retention problem nobody owns.
Kiosks, parking and vending
Self check-in kiosks, EV chargers, car park barriers and vending machines all take cards, and they are all typically installed by a third party on the hotel’s own network. They are the touchpoints most often missing from a first attempt at PCI DSS for hotels. Whether they are in scope depends on the architecture, but they are never out of scope by default, and they are almost never on the data-flow diagram.
| Touchpoint | Channel type | Typical system | Scope impact |
|---|---|---|---|
| Brand website booking engine | E-commerce | Booking engine, PSP | Website in scope even with a hosted form |
| OTA reservation with card number | Card not present | Channel manager, PMS | PMS stores a PAN, full scope |
| Reservations telephone line | MOTO | Telephony, PMS, recordings | Call recording captures SAD |
| Front desk chip and PIN | Card present | PTS POI terminal | Minimal if standalone, wide if integrated |
| Restaurant, bar and spa tills | Card present | EPOS, room posting interface | Links every till to the PMS |
| Events and group billing | MOTO and card not present | Email, sales system, PMS | Mailbox and stored card on file |
| Kiosks, parking, vending | Card present | Third-party devices on site LAN | In scope unless segmented and evidenced |
Merchant levels: which one does your hotel fall into?
Your merchant level determines how you validate PCI DSS for hotels, not what you have to comply with. Every merchant that accepts cards has to meet the standard. The level decides whether you self-assess or pay for an audit.
Visa’s four merchant levels and what they mean for PCI DSS for hotels
Visa defines Level 1 as merchants processing over six million Visa transactions annually across all channels. Level 1 requires an annual Report on Compliance by a Qualified Security Assessor, a quarterly network scan by an Approved Scanning Vendor and an Attestation of Compliance.
Level 2 is one million to six million transactions annually, validated by an annual Self-Assessment Questionnaire plus quarterly ASV scans. Level 3 is 20,000 to one million Visa e-commerce transactions annually, on the same validation basis.
Level 4 is fewer than 20,000 Visa e-commerce transactions annually and all other merchants processing up to one million Visa transactions annually. At Level 4 the annual SAQ is recommended and the validation requirements are set by your acquirer. Most independent UK properties sit here, and most groups doing PCI DSS for hotels properly discover they do not.
Hotel groups cross the Level 3 threshold on e-commerce alone
This is the trap that catches PCI DSS for hotels programmes early. A group can be comfortably under a million total transactions and still be Level 3, because the Level 3 threshold counts e-commerce transactions only, and it starts at 20,000. Push half your direct bookings through your own website and a mid-sized group passes it without noticing. Any serious approach to PCI DSS for hotels counts the e-commerce channel separately before assuming Level 4.
PCI DSS for hotels counts levels per scheme, not per group
The thresholds are Visa transactions, and Mastercard runs its own equivalent programme with its own definitions. If your Visa and Mastercard mixes differ materially, you can sit at different levels with different schemes, and your acquirer will reconcile that for you. Ask them in writing rather than assuming.
Level 4 is not permission to ignore PCI DSS for hotels
Level 4 changes who checks your homework. It does not change the homework. The requirements applicable to your environment apply in full, and the acquirer can still ask for the SAQ, the AOC and the scan reports at any time.
| Visa level | Threshold | Validation | Typical UK hotel |
|---|---|---|---|
| Level 1 | Over 6m Visa transactions a year, all channels | Annual ROC by a QSA, quarterly ASV scans, AOC | National brands and large estates |
| Level 2 | 1m to 6m Visa transactions a year | Annual SAQ, quarterly ASV scans, AOC | Large regional groups |
| Level 3 | 20,000 to 1m Visa e-commerce transactions a year | Annual SAQ, quarterly ASV scans, AOC | Groups with a busy direct booking engine |
| Level 4 | Under 20,000 e-commerce, up to 1m total | Annual SAQ recommended, ASV scan if applicable, acquirer defines | Single properties and small groups |
The SAQ trap: why no single questionnaire fits a hotel
This section is the reason the article exists, because it is where PCI DSS for hotels stops being a checklist and becomes a decision. The eligibility criteria below are quoted from the PCI Security Standards Council’s own questionnaire documents, and read together they rule out every shortcut a hotel might want to take.
Why SAQ A cannot carry PCI DSS for hotels on its own
SAQ A covers merchants with account data functions completely outsourced, and its wording ends the argument for most PCI DSS for hotels programmes: “SAQ A merchants may be either e-commerce or mail/telephone-order merchants (card-not-present)” and “This SAQ is not applicable to face-to-face channels.” A hotel with a front desk terminal has a face-to-face channel. That single sentence disqualifies the questionnaire that most small operators are told to complete.
SAQ A-EP is e-commerce only
SAQ A-EP is for e-commerce merchants whose website does not receive account data but does affect the security of the transaction. Its scope note is equally blunt: “This SAQ is applicable only to e-commerce channels.” It covers the booking engine and nothing else in the building.
Card-present questionnaires exclude the channel PCI DSS for hotels needs most
SAQ B, SAQ B-IP, SAQ C, SAQ C-VT and SAQ P2PE each carry the line “This SAQ is not applicable to e-commerce channels.” Every one of them. So the moment a hotel has a working booking engine, no card-present questionnaire can cover the business as a whole.
SAQ B-IP breaks on integrated terminals
SAQ B-IP requires that “the standalone, IP-connected PTS POI devices are not connected to any other systems within the merchant environment” and that “the PTS POI device does not rely on any other device (e.g., computer, mobile phone, tablet, etc.) to connect to the payment processor”. A terminal integrated with the PMS so the pre-authorisation posts to the folio fails both tests. It also excludes Secure Card Readers and Secure Card Readers for PIN outright.
SAQ C fails any multi-property group
SAQ C is for merchants with payment application systems connected to the internet, and it requires that “the physical location of the POS environment is not connected to other premises or locations, and any LAN is for a single store only”. A group with a shared WAN, a central PMS or a head-office finance system reaching into each property fails that criterion at the first hurdle.
The two honest answers for PCI DSS for hotels
Either you complete a separate SAQ for each payment channel — for example SAQ A-EP for the booking engine and SAQ P2PE for the card-present estate — with your acquirer’s agreement, or you complete SAQ D for Merchants, which covers everything. Both are legitimate. What is not legitimate is picking the shortest one and hoping the channels you left out never come up. Getting this decision right is the whole game in PCI DSS for hotels.
| Questionnaire | Intended merchant | Requirement families | Why it usually fails for a hotel |
|---|---|---|---|
| SAQ A | Fully outsourced card not present | 2, 3, 6, 8, 9, 11, 12 | Not applicable to face-to-face channels |
| SAQ A-EP | Partially outsourced e-commerce | 1 to 12 | Applicable only to e-commerce channels |
| SAQ B | Imprint or standalone dial-out terminals | 3, 7, 9, 12 | No e-commerce; dial-out terminals only |
| SAQ B-IP | Standalone IP-connected PTS POI devices | 1, 2, 3, 6, 7, 8, 9, 11, 12 | Terminals must not connect to other systems |
| SAQ C-VT | Isolated virtual payment terminal | 1 to 9 and 12 | One isolated device, no card readers attached |
| SAQ C | Internet-connected payment applications | 1 to 12 | Single-site LAN only, no e-commerce |
| SAQ P2PE | Validated PCI-listed P2PE solution only | 3, 9, 12 | No e-commerce; every terminal must be in the solution |
| SAQ D for Merchants | Everyone else | 1 to 12 | Does not fail, but it is the longest by a distance |
The gap between the shortest and longest questionnaire is not marginal, and it is the strongest argument for spending money on scope reduction rather than on paperwork.
Card on file, guarantees and no-show charges
Storing a card to guarantee a booking is normal hospitality practice, and PCI DSS for hotels permits it entirely. What is not permitted is how most hotels do it.
What PCI DSS for hotels lets you store, and what it never does
Cardholder data — the primary account number, cardholder name, expiry date and service code — may be stored if you have a business need and you protect it. Sensitive authentication data may not. Requirement 3.3.1 is unambiguous: “SAD is not retained after authorization, even if encrypted. All sensitive authentication data received is rendered unrecoverable upon completion of the authorization process.” Sensitive authentication data means full track data, the card verification code and PINs or PIN blocks.
The security code is the one everyone gets wrong
Reservations teams write the three digits into the notes field because a future no-show charge might need them. It never legitimately does, and the practice turns a routine reservation record into a compliance failure and a breach-notification event waiting to happen. Any programme of work on PCI DSS for hotels should start by searching the PMS notes and comment fields for stored card numbers and security codes.
Retention has to be written down and enforced
Requirement 3.2.1 requires account data storage to be kept to a minimum through retention and disposal policies covering all locations of stored account data, limiting storage amount and retention time to what is required legally or for business reasons, with specific retention requirements and a defined process for secure deletion. A policy that says “we keep cards until checkout plus 90 days” is fine. A policy nobody applies to the events mailbox is not.
Tokenisation is the practical answer in PCI DSS for hotels
Replacing the card number with a token held by your payment service provider lets you charge a no-show, take a balance and refund a deposit without ever holding a PAN again. It is the highest-value single change in PCI DSS for hotels. It is the single highest-value change available to most operators, and it removes an entire class of finding from any assessment.
Written cardholder authorisation
Separately from PCI DSS, taking a later charge against a stored card needs the guest’s clear authorisation, captured at the time and retrievable afterwards. That is a chargeback-defence issue as much as a compliance one, and the two controls belong in the same process.
Telephone bookings: the hardest channel in PCI DSS for hotels
The reservations line is where PCI DSS for hotels programmes go to die, because the control that fixes it costs money per agent and the risk it removes is invisible until it is not.
MOTO sits outside SCA, so PCI DSS for hotels carries the channel alone
Under the UK’s Payment Services Regulations 2017 and the FCA’s SCA rules, strong customer authentication applies to electronic payment transactions. Mail-order and telephone-order payments are not initiated electronically by the cardholder, so SCA does not apply to them. That makes the phone line the softest fraud target you operate, and it means the only protections on that channel are the ones you build yourself.
Call recordings capture sensitive authentication data
If your telephony records calls for training or dispute purposes and an agent reads back a security code, that recording now contains sensitive authentication data, retained after authorisation. Requirement 3.3.1 does not carve out audio. The recording platform, its storage and everyone with access to it are in scope until you fix it.
Agent screens, notepads and shift handovers
A reservations desk with a paper pad is storing account data on paper. That is not automatically fatal — several questionnaires explicitly contemplate paper receipts — but it is only acceptable if the paper is controlled, retained deliberately and destroyed securely. A card number on a sticky note passed across a shift change is none of those things.
DTMF masking and pause-and-resume in PCI DSS for hotels
The two mainstream fixes are pause-and-resume, which stops the recording while the number is read, and DTMF masking, where the guest keys the number into their phone and the tones are suppressed so the agent never hears or sees it. DTMF masking is stronger, because it takes the agent and the recording out of scope together. It is also the line item that most often decides whether a UK operator’s approach to PCI DSS for hotels is genuine or theoretical.
Do not forget the ancillary lines
Room service, the spa, the events office and the group reservations team all take cards by phone, and PCI DSS for hotels treats every one of those as the same channel. Whatever control you deploy has to cover them, or the scope reduction you paid for does not exist.
The booking engine, e-skimming and requirements 6.4.3 and 11.6.1
Two of the future-dated requirements are aimed squarely at payment-page attacks, and they are the ones that hospitality e-commerce most often fails. Neither is optional in PCI DSS for hotels any more.
What requirement 6.4.3 actually says
It requires that “all payment page scripts that are loaded and executed in the consumer’s browser are managed” by three specific means: a method to confirm each script is authorised, a method to assure the integrity of each script, and an inventory of all scripts with written justification as to why each is necessary. It applies to scripts loaded from your environment and from third and fourth parties.
What requirement 11.6.1 actually says
It requires a change- and tamper-detection mechanism deployed “to alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the HTTP headers and the contents of payment pages as received by the consumer browser”. In plain terms: something has to watch your booking page from the browser’s point of view and shout when it changes.
Iframes did not save you, and v4.0.1 said so
The most consequential change for hotel e-commerce came with the SAQ A eligibility criteria. Under PCI DSS v4.0.1, SAQ A merchants must confirm that “the merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s)”.
The Council’s FAQ 1588 explains that this applies to merchants using embedded payment pages or forms — iframes — rather than full redirects. It can be satisfied either by deploying protective techniques such as those in Requirements 6.4.3 and 11.6.1, or by obtaining written confirmation from a compliant third-party service provider that its embedded solution protects against script attacks when properly implemented. For PCI DSS for hotels, that written confirmation is the cheapest evidence in the whole pack.
What that means for PCI DSS for hotels in practice
Hotel booking journeys are script-heavy, which is precisely why PCI DSS for hotels now has a script requirement: analytics, tag managers, chat widgets, rate-comparison overlays, remarketing pixels, review widgets and consent platforms. Each of those is a script that can reach the payment page. Either move to a full redirect and take the page out of the browser’s shared context, or accept that you now need a script inventory and client-side monitoring. There is no third option that survives an assessment.
What to ask your booking engine vendor, in writing
Ask for the vendor’s current Attestation of Compliance, the exact integration method your site uses, whether the payment form is an iframe or a redirect, and — if it is an iframe — the written confirmation the FAQ describes. Requirement 12.8.4 already obliges you to monitor third-party service providers’ PCI DSS compliance status at least once every 12 months, so you need the paperwork anyway.
POS, PMS and the room-charge interface
The property management system is the centre of gravity in any hotel estate, and it is the reason PCI DSS for hotels rarely stays small.
The room-charge interface that breaks PCI DSS for hotels segmentation
Room-charge posting means the restaurant till talks to the PMS. Pre-authorisation posting means the front-desk terminal talks to the PMS. Channel management means the OTA feed talks to the PMS. Each link is defensible on its own. Together they mean that if account data touches the PMS anywhere, a very large part of the estate is in the cardholder data environment.
Look for stored PANs where nobody expects them
A PCI DSS for hotels discovery exercise should search reservation notes, guest profile free-text, folio comments, exported reports, nightly audit files, email confirmations sitting in a shared mailbox, spreadsheets on the finance share, and backups of any of the above. Requirement 3.4.2 is relevant here: when remote-access technologies are used, technical controls must prevent copying or relocation of PAN except for those with documented, explicit authorisation and a legitimate business need — and the applicability note is explicit that storing or relocating PAN onto local drives or removable media brings those devices into scope.
Third-party providers under PCI DSS for hotels and requirement 12.8
Requirement 12.8.1 requires a maintained list of all third-party service providers with which account data is shared or that could affect its security, including a description of each service. Requirement 12.8.2 requires written agreements, and Requirement 12.8.4 requires you to monitor their compliance status annually.
For PCI DSS for hotels that list means the PMS vendor, the booking engine, the channel manager, the EPOS supplier, the payment gateway, the telephony provider, the spa system and whoever manages the network. The applicability note is blunt about what their compliance buys you: “the use of a PCI DSS compliant TPSP does not make an entity PCI DSS compliant”.
Franchise, brand and management-company complexity
In a franchised or managed property the brand mandates the PMS, the owner holds the merchant ID, and a management company runs the staff. PCI DSS for hotels has to name one of them as the responsible entity. The obligation follows the merchant agreement, so the entity that owns the merchant ID owns the compliance. Establish that in writing before the assessment, not during it.
Legacy systems are the quiet failure
An unsupported PMS version or an EPOS running on an out-of-support operating system fails vulnerability management outright and cannot be patched to a passing state. This is the same structural risk we cover in the hotel disaster recovery plan guide, and it needs a replacement budget, not a compensating control.
Payment terminals: requirement 9.5.1 at the front desk
Physical device security is where PCI DSS for hotels meets the reality of a 24-hour lobby, and it is one of the few requirements a hotel can fail on a single unlucky Tuesday.
What requirement 9.5.1 asks of PCI DSS for hotels
Requirement 9.5.1 requires that POI devices capturing card data by direct physical interaction “are protected from tampering and unauthorized substitution”, including maintaining a list of POI devices, periodically inspecting them for tampering or substitution, and training personnel to be aware of suspicious behaviour and to report it.
The POI inventory every PCI DSS for hotels programme needs
Requirement 9.5.1.1 requires an up-to-date list including make and model, location, and serial number or other unique identification. For a group this is a spreadsheet with every front-desk, restaurant, bar, spa, room-service and mobile terminal on it, reconciled when devices are swapped by the acquirer or the EPOS supplier.
Periodic inspection, and the risk analysis behind it
Requirement 9.5.1.2 requires POI device surfaces to be “periodically inspected to detect tampering and unauthorized substitution”, and 9.5.1.2.1 — one of the requirements that became mandatory on 31 March 2025 — requires the frequency and the type of inspection to be defined in a targeted risk analysis performed according to Requirement 12.3.1. You choose the frequency, and then you justify it in writing.
Training the people who would actually notice
The night porter is more likely to spot an overlay than the IT manager, because the night porter looks at that terminal every shift. This is the part of PCI DSS for hotels that lives on a shift checklist rather than in a policy. Build the inspection into the shift checklist, with photographs of what each device should look like, and make reporting a tampered device a no-blame action.
Terminals that move
Mobile terminals used for room service, weddings and outside catering leave the building and come back. They belong on the inventory, they need a check-in and check-out record, and they are the ones most likely to be substituted without anyone noticing.
Scope reduction: what P2PE and tokenisation are actually worth
Nothing else in PCI DSS for hotels delivers as much return per pound as taking systems out of scope in the first place. Every requirement you never have to answer is a requirement you can never fail.
Validated P2PE is the strongest card-present control in PCI DSS for hotels
SAQ P2PE covers merchants who “process account data only via a validated PCI-listed P2PE solution”, who “do not have access to clear-text account data on any computer system”, and who have “implemented all controls in the P2PE Instruction Manual (PIM) provided by the P2PE Solution Provider”. Card data is encrypted inside the terminal and is never available in clear text on the hotel’s network. The questionnaire drops to three requirement families: 3, 9 and 12.
The word “validated” is load-bearing
A terminal that encrypts is not the same as a PCI-listed validated P2PE solution. Only solutions on the Council’s list qualify, the listing can expire, and the exclusion applies to the whole estate — one non-P2PE terminal in the spa and the group no longer meets the eligibility criteria. Check the listing, and check it again at renewal.
In PCI DSS for hotels, tokenisation removes storage but not transmission
Tokenisation stops you holding card numbers. It does not by itself take the point of capture out of scope: something still accepts the card before the token exists. Used together — P2PE for card present, a hosted redirect for e-commerce, DTMF masking for the phone, tokens for everything stored — the three channels of a hotel can each be reduced to something manageable.
Redirect beats iframe on the booking engine
A full redirect to the payment service provider’s own page takes your website out of the payment page’s browser context and out of the new SAQ A script criterion. It costs a little conversion and saves a great deal of assessment. For most independent operators it is the right trade, and it is the change we most often recommend first.
Segment the network, and evidence the segmentation
Guest WiFi must never be able to reach a payment terminal, an EPOS till or the PMS. That is a network design job, covered in detail in our hotel guest WiFi VLAN segmentation guide, and the evidence for it is what an assessor asks for first.
The v4.0.1 controls that catch UK hotels out
These are the requirements where hospitality operations and PCI DSS for hotels collide most often. All of them are now mandatory.
PCI DSS for hotels now requires MFA into the cardholder data environment
Requirement 8.4.2 requires that “MFA is implemented for all access into the CDE”. The applicability note excludes application or system accounts performing automated functions, and user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction. It does not exclude the duty manager logging into the PMS from a back office, or an administrator connecting remotely.
Twelve-character passwords on shared logins
Requirement 8.3.6 requires passwords used as authentication factors to have “a minimum length of 12 characters (or IF the system does not support 12 characters, a minimum length of eight characters)” and to contain both numeric and alphabetic characters. On a shared front-desk account this is exactly the control that gets undermined by a note taped under the keyboard, which is why shared accounts should be replaced with named ones wherever the PMS allows.
Automated audit log review under PCI DSS for hotels
Requirement 10.4.1.1 requires automated mechanisms to perform audit log reviews. Nobody in a hotel reads logs manually; the honest answer is a log management service or a managed detection provider, and it is a real line in the budget.
Removable media scanning
Requirement 5.3.3 requires the anti-malware solution to scan removable media automatically when inserted, connected or mounted, or to perform continuous behavioural analysis. Back-office PCs in hotels see USB sticks constantly — supplier menus, function sheets, photographs. This one is cheap to fix and easy to forget.
Annual scope confirmation keeps PCI DSS for hotels honest
Requirement 12.5.2 requires scope to be documented and confirmed at least once every 12 months and on significant change, and the validation must include “identifying all data flows for the various payment stages (for example, authorization, capture settlement, chargebacks, and refunds) and acceptance channels (for example, card-present, card-not-present, and e-commerce)”. For a hotel that is a genuinely useful exercise rather than a paperwork one.
Targeted risk analyses
Requirement 12.3.1 requires every requirement that allows flexibility in frequency to be supported by a documented targeted risk analysis identifying the assets protected, the threats, the factors affecting likelihood and impact, and a justified frequency. In a hotel that means at minimum one for terminal inspections and one for lower-risk vulnerability remediation under Requirement 11.3.1.1.
| Requirement | What it demands | What it means in a hotel |
|---|---|---|
| 3.3.1 | SAD not retained after authorisation, even encrypted | No security codes in PMS notes, no unmasked call recordings |
| 3.4.2 | Prevent copy or relocation of PAN over remote access | Controls on remote PMS sessions and support connections |
| 5.3.3 | Automatic scanning of removable media | USB sticks at the back office and in the events team |
| 6.4.3 | Authorise, assure integrity of and inventory payment page scripts | Every tag and widget on the booking journey |
| 8.3.6 | Minimum 12-character passwords with letters and numbers | Shared front-desk and duty-manager logins |
| 8.4.2 | MFA for all access into the CDE | Back-office PMS access and all remote support |
| 9.5.1.1 and 9.5.1.2 | POI inventory plus periodic tamper inspection | Every terminal in every outlet, on the shift checklist |
| 10.4.1.1 | Automated audit log review | A log platform or a managed detection service |
| 11.6.1 | Change and tamper detection on payment pages | Client-side monitoring of the booking engine |
| 12.5.2 | Annual scope confirmation with data flows | A refreshed channel map every year and on change |
| 12.8.1 to 12.8.4 | TPSP list, written agreements, annual monitoring | PMS, booking engine, EPOS, gateway, telephony, spa |
| 12.10.1 | Incident response plan naming brands and acquirers | Who calls the acquirer at 03:00, and from what number |
The incident response requirement is more specific than most people realise
Requirement 12.10.1 requires a plan ready to be activated that includes roles, responsibilities and communication and contact strategies “including notification of payment brands and acquirers, at a minimum”, specific containment and mitigation procedures for different incident types, business recovery and continuity procedures, data backup processes, analysis of legal reporting requirements, and coverage of all critical system components. A hotel’s plan has to work at 03:00 with a duty manager holding it.
What PCI DSS for hotels costs a UK group
Every operator asks what PCI DSS for hotels costs first and gets a vague answer. Here is a specific one, built on stated arithmetic so you can substitute your own numbers.
The PCI DSS for hotels worked example
A four-property UK group with 118, 96, 74 and 52 bedrooms — 340 bedrooms in total. Each property has a front desk, a restaurant, a bar and either a spa or a leisure desk. Bookings come through the group’s own website, three OTAs, and a reservations team of twelve who take telephone bookings for groups and corporate accounts.
Transaction volumes, and the merchant level they produce
At 340 bedrooms the group has 340 × 365 = 124,100 available room-nights a year. At 72% occupancy that is 89,352 room-nights sold. With an average stay of 1.8 nights, that is 89,352 ÷ 1.8 = 49,640 stays, and therefore 49,640 room-account card transactions. Food, beverage and spa add roughly 165 card transactions per property per day, or 165 × 365 × 4 = 240,900. Total card transactions: 49,640 + 240,900 = 290,540 a year — comfortably under a million.
But 46% of stays are booked and guaranteed through the group’s own booking engine: 49,640 × 0.46 = 22,834 e-commerce transactions. That is above the 20,000 threshold, so this group is Visa Level 3, not Level 4, and owes an annual SAQ plus quarterly ASV scans. Nothing about the group feels large. The arithmetic disagrees, and this is the most common surprise in any first-year programme of work on PCI DSS for hotels.
The year-one cost model
Nine lines of spend carry the first year: scanning, assessment support, terminals, telephony, monitoring, logging, testing, training and internal time. Figures are UK indicative, ex VAT, for a group of this shape, and they are the ones a PCI DSS for hotels business case has to survive.
| Line item | Basis | Year one |
|---|---|---|
| Internal staff time | 0.4 FTE at £42,000 | £16,800 |
| P2PE terminal rental | 36 devices at £22 a month | £9,504 |
| Scoping and gap analysis | 8 consultant days at £1,150 | £9,200 |
| Penetration testing | Requirement 11.4, four sites plus booking engine | £6,500 |
| Secure telephone payment | 12 agent seats at £39 a month | £5,616 |
| Log management and review | Requirement 10.4.1.1, managed service | £4,800 |
| Payment page script monitoring | Requirements 6.4.3 and 11.6.1 | £2,400 |
| Training and awareness | Requirement 12.6.3, all card-handling staff | £1,450 |
| ASV quarterly scanning | Four sites, four scans | £995 |
| Total year one | 340 bedrooms, 290,540 transactions | £57,265 |
PCI DSS for hotels: cost per bedroom and per transaction
£57,265 across 340 bedrooms is £168.43 a bedroom for the first year. Spread across 290,540 card transactions it is 19.71p per transaction. Framed the second way, most boards approve it in the meeting. Framed as a lump sum, it stalls — which is a presentation problem rather than a budget one.
Year two is materially cheaper
The gap analysis does not repeat, and internal time falls once the evidence pack exists. Terminals, telephony, logging, scanning, testing and training continue: £9,504 + £5,616 + £4,800 + £2,400 + £1,450 + £995 + £6,500 = £31,265, plus a reduced internal allocation. Budget the first year as a project and every year after as an operating cost.
PCI DSS for hotels and UK GDPR are not the same obligation
Operators routinely treat these as one programme. They overlap, but PCI DSS for hotels and data protection law answer to different masters and they fail in different ways.
The ICO can act on a PCI DSS for hotels failure whatever the schemes do
Card data is personal data. A breach that exposes it engages UK GDPR and the Data Protection Act 2018, and the Information Commissioner’s Office can act entirely separately from anything Visa, Mastercard or your acquirer decide. The hospitality sector already has the reference case: the ICO fined Marriott International £18.4 million in October 2020 over the Starwood guest-reservation breach.
Article 32 and appropriate measures
UK GDPR Article 32 requires appropriate technical and organisational measures, judged against the state of the art, cost, and the risk to individuals. It names no standard, but a regulator assessing a card-data breach will reasonably ask whether the merchant met the industry standard that exists for exactly that data. Non-compliance with PCI DSS is not automatically an Article 32 breach — it is simply very hard to argue around.
Different clocks
UK GDPR gives you 72 hours to notify the ICO of a notifiable personal data breach. The schemes have their own timelines through your acquirer, and requirement 12.10.1 requires your plan to name them. Build one incident process with two notification tracks, not two processes.
Where they genuinely reinforce each other
Data minimisation, retention limits, access control, encryption, logging and supplier due diligence appear in both frameworks in near-identical language. A good tokenisation project satisfies parts of both at once, which is the strongest budget argument available to a general manager who has to fund it. The wider cybersecurity posture behind both is the same one.
Fraud, chargebacks and what non-compliance actually costs
The case for funding PCI DSS for hotels is easier to make when the loss numbers sit next to it.
The UK fraud picture behind PCI DSS for hotels
UK Finance’s Annual Fraud Report 2026 recorded £1.28 billion lost to payment fraud in 2025, up 4%, across more than four million confirmed cases. Unauthorised fraud accounted for £703.4 million, down 5%, with £1.68 billion prevented. Remote purchase fraud — a criminal using stolen card details for a card-not-present purchase — rose 3% to £423.5 million across 3.2 million cases, up 13%, and remained the most common fraud type. The report frames the scale as eight people defrauded every minute, with nearly £2,500 stolen each minute.
Non-compliance fees are small and permanent
UK acquirers commonly apply a monthly non-compliance charge where the annual questionnaire is not submitted. It is a modest sum on its own, it recurs indefinitely, and it is the cheapest possible signal to your acquirer that your estate is not being managed.
The real cost arrives after an incident
A suspected account data compromise brings a forensic investigator appointed under the schemes’ rules, at the merchant’s cost, alongside card reissue costs, scheme assessments, chargebacks and the operational disruption of running a hotel while the investigation proceeds. The difference between a validated scope and a guessed one shows up here, because the investigation begins by asking what you attested to.
Reputational damage lands differently in hospitality
Guests choose hotels on trust and reviews. A card-data incident is a story that travels, and it arrives at the same moment as the operational disruption. That is the argument that usually persuades a board that PCI DSS for hotels deserves a standing budget line rather than an annual scramble.
A 90-day plan for PCI DSS for hotels
You cannot fix everything at once, and you should not try. This PCI DSS for hotels sequence puts the decisions that cost nothing before the purchases that cost money.
Days 1 to 30 of PCI DSS for hotels: find the card data
Interview every team that touches a card: reservations, front office, food and beverage, spa, events, finance. Draw the data flow for every channel. Search the PMS, the shared mailboxes and the finance shares for stored card numbers and security codes. List every POI device with make, model, location and serial number. List every third-party service provider. Confirm your merchant IDs, your transaction volumes by channel and, from your acquirer, your merchant level.
Days 31 to 60: decide the PCI DSS for hotels scope and questionnaire
With the data flows in front of you, decide honestly which questionnaire each channel qualifies for and whether you are running multiple SAQs or a single SAQ D. Confirm that decision with your acquirer in writing. Establish whether your booking engine uses a redirect or an iframe and get the vendor’s Attestation of Compliance. Delete every stored security code you found. Write the retention and disposal policy, and start the targeted risk analysis for terminal inspections.
Days 61 to 90: buy the scope reduction and start the evidence pack
Order the changes that shrink scope: validated P2PE for the card-present estate, a redirect or monitored payment page for e-commerce, DTMF masking for the reservations line, tokenisation for anything stored. Turn on MFA into the cardholder data environment. Book the ASV scans and the penetration test. Put terminal inspection on the shift checklist. Write the incident response plan with the acquirer’s out-of-hours number in it, and start collecting evidence in a single folder rather than an email trail.
What to do in month four and beyond
Run the annual PCI DSS for hotels cycle: scope confirmation, questionnaire, scans, testing, training and supplier monitoring. Treat every change — a new outlet, a new booking engine, a new kiosk — as a scope event on the day it happens. If you want the estate-wide view that this sits inside, our hotel cyber security checklist covers the twenty controls around it, and the ransomware continuity guide covers what happens when the PMS stops.
Frequently asked questions about PCI DSS for hotels
Is PCI DSS for hotels a legal requirement in the UK?
No. It is a contractual obligation imposed through your merchant agreement with your acquiring bank, which the card schemes require. The legal exposure comes separately through UK GDPR and the Data Protection Act 2018 if a breach exposes personal data.
Can a small hotel just complete SAQ A?
Almost never. SAQ A states that it “is not applicable to face-to-face channels”, and any hotel with a front-desk terminal has one. It is the single most common mistake in PCI DSS for hotels.
Can we store a card number to charge a no-show?
You may store the primary account number, name and expiry date if you have a documented business need, a retention policy and protection in place. You may never store the security code or track data after authorisation. In practice, use a token from your payment service provider instead.
Do call recordings really matter?
Yes. If an agent reads back a security code and the call is recorded, you are retaining sensitive authentication data after authorisation, which requirement 3.3.1 prohibits outright. Pause-and-resume or DTMF masking fixes it.
How often does PCI DSS for hotels require terminal inspections?
At a frequency you define and justify in a targeted risk analysis under Requirement 12.3.1, per Requirement 9.5.1.2.1. There is no fixed number in the standard, so most operators land on a documented per-shift visual check plus a formal monthly record.
Does a compliant PMS or booking engine deliver PCI DSS for hotels?
No. The standard’s applicability note is explicit that “the use of a PCI DSS compliant TPSP does not make an entity PCI DSS compliant, nor does it remove the entity’s responsibility for its own PCI DSS compliance.”
Who signs the attestation for a franchised property?
Whoever holds the merchant ID. Establish this in writing between the owner, the brand and any management company before assessment season, because the obligation follows the merchant agreement rather than the sign above the door.
What does PCI DSS for hotels cost a single property?
Scale the worked example above. A single 120-bedroom hotel with one restaurant typically avoids the multi-site consultancy overhead and the group logging cost, and lands well below the four-property figure, but still needs terminals, secure telephone payment, scanning and internal time.
References
PCI Security Standards Council
Just Published: PCI DSS v4.0.1
FAQ Clarifies New SAQ A Eligibility Criteria for E-commerce Merchants
Self-Assessment Questionnaire A and Attestation of Compliance
Self-Assessment Questionnaire D for Merchants and Attestation of Compliance
Self-Assessment Questionnaire P2PE and Attestation of Compliance
Visa: Validation of Compliance and Merchant Levels
UK Finance Annual Fraud Report 2026
