Hotel ransomware is not really a data story. It is an operations story. When the encryption lands at 04:00, nobody on the duty rota asks what was taken — they ask whether the 14:00 arrivals can be checked in, whether the restaurant can take a card, and whether the room keys cut yesterday still open a door tonight. Those three answers decide whether the property trades through the week or turns guests away at the door.
That is what makes hotel ransomware different from ransomware anywhere else. An accountancy firm that loses its systems for six days sends everyone home and catches up. A hotel cannot. The guests are already in the building, more are arriving on a train, the kitchen has food that expires, and the OTA channels keep selling rooms whether or not you can see them. Our hotel cyber security checklist covers the controls that stop an intrusion; this article assumes prevention has already failed and asks the only question that matters afterwards — how do you keep trading?
What follows is a continuity guide for UK operators: what a hotel ransomware attack actually takes down, what verified incidents at Omni, MGM, Washington Hotel and others tell us about the blast radius, how to run the front desk, the POS and the reservation channels while the systems are gone, what the NCSC says about backups that survive, and what readiness costs per bedroom. There are five tables, four charts, a costed three-property worked example, a per-system RTO and RPO schedule and a 90-day plan. None of it assumes you employ a security team.
Table of contents
- What a hotel ransomware attack actually shuts down
- Verified hotel ransomware incidents and what they teach
- How hotel ransomware gets into a property
- Keeping the PMS running: hotel ransomware continuity at the front desk
- Keeping POS running when hotel ransomware hits
- Protecting reservations and revenue during a hotel ransomware outage
- Backups that survive a hotel ransomware attack
- Setting RTO and RPO per system, not per property
- The hotel ransomware decision nobody wants: paying
- What hotel ransomware readiness costs: a worked example
- A 90-day hotel ransomware readiness plan
- Who does what: a hotel ransomware role card
- Hotel ransomware questions to ask your PMS and EPOS vendors
- Hotel ransomware: frequently asked questions
- References and Further Reading
What a hotel ransomware attack actually shuts down
The first hour of a hotel ransomware incident is spent discovering how many systems you did not realise were connected. Hospitality estates are unusually interdependent: almost everything authenticates against, posts to, or reads from the property management system, so an attack that reaches one platform tends to surface everywhere at once.
The PMS goes dark first, and takes the arrivals list with it
The property management system is the operational core, and hotel ransomware that reaches it removes the arrivals list, the in-house list, the room status board, the rate plan and the folio in a single stroke. Front desk staff lose the ability to see who is due, which rooms are clean, what the guest paid and what they are owed. Our guide to hotel PMS cyber security covers protecting that system; here the point is that it is also the single system whose loss stops the building.
Hotel ransomware stops the POS and the food and beverage floor
The EPOS estate is a separate platform, but it usually posts room charges back to the PMS. During a hotel ransomware event, tills either stop entirely or keep ringing sales that can no longer be posted to a room. Restaurants, bars, room service and the spa all move to cash, standalone card terminals or a paper tab — and every one of those choices has a reconciliation cost you pay later.
Reservations, channel manager and the booking engine keep selling
This is the failure mode that catches most operators out. The channel manager and booking engine are frequently cloud services that are not encrypted by the attack at all. They carry on distributing inventory that you can no longer see, confirm or fulfil. A three-day hotel ransomware outage with a live channel manager produces overbooking on the fourth day, on top of everything else.
Hotel ransomware reaches door locks, lifts and the physical estate
Electronic locking systems normally run their own server, and in many properties that server sits on the same flat network as everything else. When hotel ransomware reaches it, staff cannot cut new keys, guests cannot get into rooms, and lift access control may fail with them. Omni Hotels lost door locks in exactly this way in 2024.
Hotel ransomware in the back office: email, payroll and reporting
Finance, HR and procurement systems are usually the last thing anyone worries about during a hotel ransomware attack and the first thing that causes a second crisis. Payroll runs on a fixed date, supplier payments have terms, and if email is gone you cannot tell staff, guests or your bank anything.
| System | What stops immediately | Manual fallback that works | Realistic tolerance |
|---|---|---|---|
| Property management system | Arrivals, in-house, room status, folio | Printed arrivals pack and paper folios | Hours, not days |
| EPOS and payments | Till transactions, room charge posting | Standalone terminals and written tabs | One service period |
| Channel manager | Nothing — it keeps selling | Manual stop-sell at the extranet | Minutes |
| Electronic door locks | Key encoding, lift and back-of-house access | Emergency mechanical override keys | Hours |
| Guest WiFi | Portal authentication, sometimes the whole SSID | Open fallback SSID with rate limiting | A day |
| Email and collaboration | Guest, OTA and supplier communication | Pre-agreed out-of-band channel | Hours |
| Finance and payroll | Supplier payments, wages, reporting | Bank portal and last exported ledger | Days |
Verified hotel ransomware incidents and what they teach
Vendor marketing about hospitality risk is easy to dismiss. Documented incidents are harder to argue with, and four of them between 2024 and 2026 describe the operational blast radius better than any threat report.
Omni Hotels: reservations, door locks and POS in one weekend
On Friday 29 March 2024, Omni Hotels and Resorts was hit by a cyberattack. Its own statement read: “Since Friday, March 29, Omni Hotels & Resorts has been responding to a cyberattack on its systems. Upon learning of this issue, Omni immediately took steps to shut down its systems to protect and contain its data.” Reporting confirmed the outage brought down reservations, hotel room door locks and point-of-sale systems, with front desk staff unable to process credit card payments, take new reservations or modify existing ones.
All 50 locations stayed open throughout. The IT team restored affected systems manually, and staff were told systems would return the following Thursday — a working week of degraded operation across roughly 23,550 rooms.
The Omni aftermath: the hotel ransomware double hit
Two weeks later the Daixin Team added Omni to its leak site, claiming 3,539,089 visitor records from 2017 onward containing names, email addresses and mailing addresses. This is the standard hotel ransomware shape in 2026: an operational outage first, then a data-theft claim afterwards, so the property fights a continuity crisis and a disclosure crisis in sequence rather than together.
MGM Resorts: a ten-minute phone call and roughly $100 million
MGM Resorts attributed approximately $100 million of third-quarter 2023 earnings impact to its incident. Entry was reportedly a ten-minute call to the IT help desk after identifying an employee on LinkedIn, escalating to administrative control of the identity platform. Slot machines, ATMs and electronic payment systems failed, digital room keys stopped working and staff reverted to manual check-in. No exploit kit was needed — the cheapest route into a hotel ransomware scenario was a conversation.
Washington Hotel: card terminals down across thirty properties
Hackers breached Washington Hotel’s network in Japan on Friday 13 February 2026 at 22:00 local time. The group runs 30 properties, 11,000 rooms and serves close to five million guests a year. IT staff immediately disconnected servers from the internet to stop the spread; credit card terminals became temporarily unavailable at some properties. Guest data sat on separately managed servers and was not compromised — a direct, verifiable argument for segmentation, and the same logic behind guest WiFi VLAN segmentation inside the property network.
Huntington Hotel Group: the theft-only variant
In January 2026 the Termite group claimed it had taken close to 39GB of data from the US hospitality management company, publishing screenshots as proof. No encryption event was reported. Data-theft-only extortion is now common enough that a hotel ransomware plan which only covers “our systems are encrypted” covers roughly half of the scenarios you will actually face.
What the hotel ransomware pattern says
Across these incidents, the systems that failed were payments, reservations, door locks and front desk — in that order of frequency. That is not a coincidence, and it matches independent research into what attackers target in hospitality.
Hotel systems most often targeted, by share of hotels naming them
Source: VikingCloud, Peak Season, Peak Risk: The 2025 State of Hospitality Cyber Report. The same research found 82% of North American hotels suffered a successful attack in summer 2024 and 58% were hit five or more times.
How hotel ransomware gets into a property
You cannot write a continuity plan without knowing which door the attacker used, because the entry route determines how much of the estate is contaminated and therefore how long recovery takes. Sophos surveyed 3,400 IT and cybersecurity leaders across 17 countries, all of whom had been hit in the previous year, and the ranking of root causes is stable.
Exploited vulnerabilities are the number one hotel ransomware route
Exploited vulnerabilities accounted for 32% of attacks — the most common technical root cause for the third consecutive year. In hospitality that lands hard, because hotel systems are patched around occupancy rather than around risk. A hotel ransomware incident that begins with an unpatched internet-facing service usually means the attacker had weeks inside before anything encrypted.
Hotel ransomware by telephone: credentials and the help desk reset
Compromised credentials caused 23% of attacks, down from 29%. The MGM route — social engineering the service desk into a password or MFA reset — remains the cheapest and is specific to industries with 24-hour help lines and high staff turnover. A hotel ransomware tabletop that does not include a fake call to your own help desk is not testing the most likely scenario.
Reservation-themed phishing is the hotel ransomware lure that works
Malicious email accounted for 19% of attacks and phishing 18%. Hospitality has a particular version: a message themed around a booking, a cancellation or a guest complaint, sent to an address that is contractually obliged to open attachments from strangers. Campaigns through 2025 and 2026 used fake reservation lures to run malicious commands on front desk machines, which is how a hotel ransomware foothold gets established without anyone clicking anything that looks wrong.
The integrator, the vendor and the remote support tool
Every interface into the PMS has an account, and most were created by a third party with a remote support tool attached. Otelier’s 2024 breach began with an infostealer-harvested login to an Atlassian server, then S3 credentials scraped from support tickets. Third-party involvement now features in roughly half of breaches, which is why vendor management belongs in a hotel ransomware plan and not only in procurement.
Guest-facing networks give hotel ransomware a route into production
Guest WiFi is the second most-targeted hotel system, and a flat network turns a guest-side compromise into a production-side one. If a laptop on the guest SSID can reach the PMS server, the door lock server or a till, you do not have a guest network — you have an unauthenticated seat on your production LAN. Our hotel WiFi security guide and the analysis of hotel WiFi captive portal attacks both cover the boundary that has to hold here.
Technical root causes of ransomware attacks, all sectors
Source: Sophos, The State of Ransomware 2025 — 3,400 IT and cybersecurity leaders in 17 countries, all hit by ransomware in the previous year.
Keeping the PMS running: hotel ransomware continuity at the front desk
The front desk is where a hotel ransomware outage becomes visible to guests, and it is also the easiest place to prepare, because everything the desk needs for 48 hours fits in a ring binder. The discipline is printing it before you need it.
The offline arrivals pack is your hotel ransomware safety net
Every property should produce, automatically and daily, a printed or offline pack containing tomorrow’s arrivals with rate and payment method, tonight’s in-house list by room, the room status board, group and event rooming lists, and the next seven days of committed occupancy. Store it on paper at the desk and as a PDF on a device that does not authenticate against the corporate domain. During a hotel ransomware event that pack is the only version of the truth you have.
Manual check-in during hotel ransomware without a second breach
Paper check-in is workable. Paper check-in done badly creates a data breach on top of the hotel ransomware incident, because staff under pressure write card numbers on registration cards. The rule is absolute: card details are never written down, ever. Take payment on a standalone terminal, write the terminal’s authorisation reference on the card, and shred the card once the folio is re-keyed. Anything else converts an availability incident into a reportable personal data breach.
Room allocation and housekeeping during a hotel ransomware outage
Housekeeping can run from a printed room list with a marker pen — it did for decades. What breaks is the linkage between a departure, a clean and a fresh arrival. Nominate one person per shift as the board owner, keep a single physical whiteboard as the authoritative room status, and forbid parallel lists. Two competing room boards during a hotel ransomware outage will cause a double allocation before the end of the first day.
The paper folio and re-keying afterwards
Every charge taken while the systems are down has to reach a folio eventually. Use pre-numbered paper folio slips, one per room, capture the charge, the outlet, the time and the authorisation reference, and store them in room order. Budget for the re-keying: a 186-bedroom estate running at high occupancy generates several hundred slips a day, and re-entry is a night-audit task that competes with the recovery itself.
How long the desk can run blind in a hotel ransomware outage
Honestly, about 72 hours. Beyond that the printed arrivals pack has drifted from reality, the paper folios are unmanageable, and the reconciliation debt exceeds the value of continuing. That number should drive your recovery time objective for the PMS, not the other way round — an estate-wide RTO of five days is meaningless if the desk collapses on day three.
Keeping POS running when hotel ransomware hits
Payment and point-of-sale is the most targeted hotel system at 72%, and it is also the one with the best built-in resilience — if it is configured for it. Most operators have never checked whether theirs is.
Yellow mode, red mode and what your EPOS does in a hotel ransomware outage
Modern hospitality POS platforms are designed for network loss. Oracle’s Simphony documentation defines the states plainly: “A workstation that can communicate with the database to post transactions is online.” In yellow mode, “the workstation can communicate with other workstations and services” — typically a property that has lost the WAN — and “the workstation directs transaction information and timekeeping information to the Offline Cache.” In red mode, “the workstation cannot communicate with other workstations or services” and “stores all transaction and timekeeping information in its local DataStore.”
The on-premise service that keeps the tills alive
Simphony’s Check and Posting Service is “a required service that runs on-premises at the property” and “acts as the bridge between the Enterprise and the property, providing resiliency.” Critically: “In the event of a WAN outage, POS clients are largely unaffected as they continue to post transactions to the on-premises CAPS.” Two operational conclusions follow for hotel ransomware planning. First, if your outage is connectivity-only, the tills should keep trading. Second, if the on-premise service is itself encrypted, you fall to red mode and every workstation becomes an island.
Store-and-forward and the card payment fallback
Store-and-forward lets a terminal capture and encrypt a card locally, queue it, and submit when connectivity returns. It is genuinely useful during a hotel ransomware outage, with two caveats worth stating to your finance director before the incident, not during it. Offline transactions are only provisionally accepted — real authorisation happens on reconnection, so the decline risk sits with you. And offline card storage has to be handled by PCI-validated point-to-point encryption devices, not by anything improvised.
Standalone terminals are the cheapest hotel ransomware insurance
A small number of standalone, separately connected card terminals — ideally on mobile data rather than the property network — is the single highest-value hotel ransomware continuity control per pound spent. They are independent of the PMS, independent of the EPOS, and independent of your LAN. Nine terminals across a three-property group costs less than a day of lost trade.
Stock, allergens and the kitchen
The forgotten dependency. Allergen data, recipe specifications and supplier ordering frequently live in the same back-office platform as everything else. Print the current allergen matrix quarterly and keep a laminated copy in each kitchen. A hotel ransomware outage is not a defence to a food safety obligation.
Reconciling afterwards
Build the reconciliation plan before the incident: which system is authoritative for revenue when the till, the paper tab and the terminal batch disagree? Decide now that the acquirer’s settlement file is the source of truth for money taken, and that the PMS is re-keyed to match it. Arguing this out during recovery costs days.
| Payment path | Works when the PMS is down? | Works when the LAN is down? | Main limitation |
|---|---|---|---|
| PMS-integrated gateway | No | No | Fails with the system it is integrated to |
| EPOS-integrated terminal | Yes | Only in yellow mode | Room charge posting is lost |
| Store-and-forward on the terminal | Yes | Yes, for a limited queue | Provisional acceptance, decline risk |
| Standalone terminal on mobile data | Yes | Yes | Manual entry into the folio later |
| Payment link sent to the guest | Yes | Yes | Needs a working out-of-band channel |
| Cash | Yes | Yes | Float, security and banking limits |
Protecting reservations and revenue during a hotel ransomware outage
Rooms revenue is the part of the business most operators forget to protect, because the reservation channels usually survive the attack. That survival is a trap rather than a relief.
The channel manager is your hotel ransomware lifeline and your biggest risk
If the channel manager is a cloud service and your hotel ransomware incident is confined to on-premise systems, it will keep distributing inventory you can no longer honour. Within the first hour, someone has to decide whether to close availability or continue selling blind. There is no universally right answer, but there is a universally wrong one, which is not deciding.
Stop-sell and overbooking control during hotel ransomware
Write the stop-sell procedure now, with named credentials that do not depend on your own single sign-on. It should specify how to close inventory directly at each OTA extranet, at the booking engine and at the GDS, in what order, and who is authorised to do it. Practise it once a year. During a hotel ransomware event, five minutes of stop-sell prevents a week of overbooking compensation.
Talking to OTAs, corporate accounts and groups
Corporate contracts and group bookings need individual handling, and the contact details for them normally live in the CRM that just went down. Keep an offline contact sheet for your top 20 corporate accounts, your top 10 group organisers and your OTA market managers. That single sheet is worth more during a hotel ransomware incident than most security tooling.
Guest communication that does not become a phishing gift
The moment you tell guests about a cyber incident, criminals impersonate you. Reservation-themed phishing already targets hospitality guests using details from compromised hotel accounts. So publish through channels guests can verify — your own website, your own domain — never ask for payment details in an incident message, and say plainly that you will never do so. Coordinate that wording with whoever runs your incident response before the first message goes out.
The revenue decision nobody documents
Somebody must be authorised to walk guests, waive charges, honour rates you cannot verify and take bookings you cannot confirm. Name that person and give them a limit. Otherwise every judgement call escalates to a general manager who is already in an incident bridge, and the queue at the desk becomes the story.
Backups that survive a hotel ransomware attack
Backups are the difference between a five-day outage and a five-week one, and hospitality has a structural weakness here: much of the estate is vendor-hosted, so operators assume backup is somebody else’s job. Sophos found backup use fell to a four-year low of 53%, while 49% of victims paid a ransom to recover data.
Six NCSC principles that define hotel ransomware backup resilience
The NCSC sets out six principles for ransomware-resistant on-premise backups: make it possible to isolate your backup solution; update your backup solution; backups should be resilient to destructive actions; restoration from an earlier backup is possible even if later versions become corrupted; have robust key management for data-at-rest protection; and trigger alerts if significant changes are made or privileged actions attempted. Read them as a hotel ransomware specification, because that is what they are.
The five principles for cloud backups
For cloud backups the NCSC lists five: backups should be resilient to destructive actions; the system should be configured so it is not possible to deny all customer access; the service allows restoration from a backup version even if later ones are corrupted; robust key management for data-at-rest is in use; and alerts trigger on significant changes or privileged actions. Ask your PMS and EPOS vendors to answer against these five in writing.
Isolation, separate credentials and immutability
Three controls do most of the work. Backups must use “admin accounts and credentials that are separate from those used to administer the rest of your network” — if your domain admin can delete the backups, so can whoever owns your domain admin. Write-once, read-many storage and soft-delete retention stop destructive actions. And the NCSC is explicit that backup media should not be permanently connected: “devices containing your backup … are not permanently connected to your network.” Our guide to the 3-2-1-1-0 immutable backup strategy sets out how that looks in practice.
Your vendor’s backup is not your hotel ransomware backup
A cloud PMS vendor almost certainly backs up its platform. That protects the vendor against its own failures; it does not necessarily give you a restorable copy of your property’s data at a point in time of your choosing, on demand, in a usable format. Until you have exercised a restore and looked at the output, you have a contractual assurance rather than a backup. The distinction between backup, disaster recovery and high availability matters most here.
Rehearse the restore, because hotel ransomware punishes untested recovery
The NCSC guidance is blunt on two points that hotels get wrong: “Scan backups for malware before you restore files” and test restoration regularly. Restoring a clean PMS into a network you have not yet cleaned simply re-encrypts it. Schedule two full restore rehearsals a year, time them, and record the actual elapsed hours — that number, not the vendor’s brochure, is your true recovery time. A structured disaster recovery test is the cheapest way to find out.
Setting RTO and RPO per system, not per property
A single estate-wide recovery objective is the most common planning error in hospitality. The front desk cannot wait five days; the business intelligence warehouse can wait a fortnight and nobody will notice. Recovery planning for hotel ransomware has to be per-system, and the numbers have to be defensible.
Why one estate-wide hotel ransomware number is useless
If you set a 24-hour RTO for everything, you will pay for continuity capability on systems that do not need it and still miss the target on the two that do. Splitting the estate lets you spend the money where an hour actually costs you revenue. Our RTO and RPO explainer sets out how to derive these from business impact rather than from instinct.
A worked recovery schedule for a hotel
The table below is a defensible starting point for a mid-market UK property. Adjust it against your own occupancy and outlet mix, but keep the shape: payments and the PMS first, reporting last.
Recovery sequencing is part of the objective
An RTO means nothing without an order. Identity comes back first, because everything else authenticates against it. Then payments, then the PMS, then door locks, then EPOS, then email, then everything else. Publish that order in the plan and rehearse it, because during a hotel ransomware recovery every department will insist theirs is critical.
| System | Target RTO | Target RPO | Recovery order | Why |
|---|---|---|---|---|
| Identity and directory | 2 hours | 15 minutes | 1 | Everything else authenticates against it |
| Card payment capture | 1 hour | Zero | 2 | Standalone terminals make this achievable |
| Property management system | 8 hours | 15 minutes | 3 | The desk runs blind for roughly 72 hours |
| Electronic door locks | 4 hours | 24 hours | 4 | Mechanical override does not scale past a shift |
| EPOS estate | 12 hours | 1 hour | 5 | Offline cache covers one service period |
| Channel manager and booking engine | 4 hours | 15 minutes | 6 | Overbooking risk compounds hourly |
| Email and collaboration | 8 hours | 1 hour | 7 | Needed for guest and supplier communication |
| Finance, payroll and procurement | 72 hours | 24 hours | 8 | Fixed dates, but not same-day |
| Reporting and BI | 10 days | 24 hours | 9 | Nobody trades on last month’s ADR |
The hotel ransomware decision nobody wants: paying
At some point in a serious incident, somebody will ask whether paying is faster. The honest answer involves law, evidence and insurance, and it should be settled in a boardroom long before it is settled at 02:00.
Where UK hotel ransomware law is heading
The Home Office consulted from 14 January to 8 April 2025 on three ransomware proposals: a targeted payment ban for the public sector and regulated critical national infrastructure, a payment prevention regime, and mandatory incident reporting. The consultation document set out reporting windows of an “initial report within 72 hours” and a “full report within 28 days.” The government published its response on 22 July 2025 and confirmed it intends to progress all three. Independent hotels sit outside the proposed ban today, but the reporting regime is the part likely to reach every business, so build a hotel ransomware plan that can produce a structured report inside 72 hours.
What the NCSC and law enforcement say
The position is unambiguous: “Law enforcement do not encourage, endorse, nor condone the payment of ransom demands”, and “even if you pay the ransom, there is no guarantee that you will get access to your computer, or your files.” Paying also does not remove your UK GDPR obligations, and it does not un-publish data that has already been exfiltrated.
What the data says about paying a hotel ransomware demand
Sophos found 49% of victims paid and recovered data, that 97% of organisations with encrypted data recovered it by some route, and that among 826 organisations which negotiated the average payment was 85% of the initial demand — 53% paid less than demanded, 29% matched it and 18% paid more. Consumer-facing sectors do worse: in retail, 58% paid, the median demand doubled to $2 million, and average payments rose 5% to $1 million. Recovery costs excluding any ransom averaged $1.53 million.
Insurance, negotiators and the 72-hour clock
If you carry cyber insurance, the policy usually dictates who you may appoint and when you must notify, and an unauthorised engagement can void cover. Read the notification clause now, keep the broker’s out-of-hours number on the printed contact sheet, and check whether business interruption cover starts at hour 8, 12 or 24 — in hospitality that waiting period is most of the loss. An incident response retainer often satisfies the insurer’s panel requirement at the same time.
Hotel ransomware reporting: ICO, Action Fraud, card schemes and guests
A hotel ransomware incident involving personal data is reportable to the ICO within 72 hours of becoming aware unless it is unlikely to result in risk. Report the crime to Action Fraud, notify your acquirer if cardholder data may be involved, and remember that guest notification obligations are separate from regulatory ones. Assign each of these to a named person in the plan, because in practice they are all due at once.
What hotel ransomware readiness costs: a worked example
Continuity spending is easier to approve when it is compared to the cost of the outage it prevents. Here is a fully stated model for a small UK group, using only arithmetic set out on this page.
The estate this hotel ransomware model covers
Three properties of 84, 62 and 40 bedrooms — 186 bedrooms in total, with two restaurants, one bar and one small conference suite. One cloud PMS, one EPOS platform with 14 tills, 9 card terminals, three door-lock servers, one channel manager and one booking engine.
The revenue at risk
186 bedrooms × 365 nights = 67,890 available room nights. At 74% occupancy that is 50,238 sold room nights, and at an average rate of £108 that is £5,425,704 of rooms revenue. Food and beverage at 22% of rooms revenue adds £1,193,655, for a total of £6,619,359 — an average of £18,135 of revenue per day.
The cost of the incident you did not prepare for
Assume a six-day operational outage, in line with the 53% of organisations that recover within a week, and assume 45% of revenue is lost across those days: 6 × £18,135 × 0.45 = £48,965. Add incident response at £22,000, forensics and legal at £14,000, overtime and agency cover at £9,600 and rebuild effort at £18,000 — £63,600. The total is £112,565, or £605 per bedroom.
The hotel ransomware readiness bill
One-off: immutable backup rebuild £4,800, printed offline runbooks and arrival packs £900, nine standalone P2PE terminals £1,620, a facilitated tabletop exercise £2,400 and network segmentation work £3,600 — £13,320. Annual: immutable backup storage at £310 a month £3,720, managed detection and response at £640 a month £7,680, two restore rehearsals at £950 each £1,900, terminal rental at £14 a month across nine devices £1,512 and an annual exercise £1,800 — £16,612.
Cost per bedroom, and the ratio that gets it approved
Year one is £13,320 + £16,612 = £29,932, which is £160.92 per bedroom. Every year after that is £16,612, or £89.31 per bedroom. Against a modelled incident cost of £112,565, year-one readiness is 3.8 times cheaper than the single event it is designed to shorten — and that comparison excludes the reputational and lawsuit exposure that hoteliers themselves rank highest.
Where the £29,932 year-one readiness budget goes
Worked example only: a three-property, 186-bedroom UK group. Year one totals £29,932, or £160.92 per bedroom.
A 90-day hotel ransomware readiness plan
Nothing in this article requires a security team or a capital programme. It requires 24 discrete actions and somebody to own them. Split across three months, a small group can complete the lot alongside normal operations.
Days 1 to 30: map the hotel ransomware blast radius and print what you need
Nine actions. Inventory every system the property cannot trade without and name an owner for each. Produce the daily offline arrivals and in-house pack and confirm it prints unattended. Build the printed contact sheet — insurer, broker, IR provider, acquirer, OTA market managers, top corporate accounts, PMS and EPOS vendor emergency lines. Confirm whether your EPOS supports offline mode and which one. Order standalone terminals. Write the stop-sell procedure with credentials held outside single sign-on. Verify that backup accounts are separate from domain admin. Confirm one backup copy is genuinely offline or immutable. Print the allergen matrix.
Days 31 to 60: reduce the blast radius
Eight actions. Segment guest WiFi from every production system and prove it with a test from a guest device. Remove standing local administrator rights on front desk and back-office machines. Enforce MFA on the PMS, the EPOS back office, email and every remote access path. Rebuild the help desk identity verification procedure so a phone call cannot reset a password. Inventory every third-party remote support tool and disable the ones nobody can name an owner for. Patch the internet-facing estate and set a monthly cadence. Turn on alerting for bulk export and mass permission changes. Move door-lock and PMS servers off the flat network.
Days 61 to 90: prove it works
Seven actions. Run a full restore rehearsal of the PMS and record the elapsed hours. Run a hotel ransomware tabletop exercise with the general manager, front office, F&B, finance and your IT provider in the room. Include a service desk social engineering scenario. Test the stop-sell procedure against one OTA extranet. Run one shift of paper check-in on a quiet night and time it. Publish the per-system RTO and RPO schedule and get it signed off. Diarise the next rehearsal. A facilitated cyber tabletop exercise is the fastest way to find what the plan missed.
Cumulative completion across the 24-action plan
Nine actions in month one, eight in month two and seven in month three — 24 in total, none of which requires a dedicated security hire.
Who does what: a hotel ransomware role card
Plans fail on ownership rather than on content. Assign these roles by job title, print the card, and laminate one for each duty manager’s desk.
The five hotel ransomware roles that must be named
Incident lead — usually the operations director — owns the decision to close availability, walk guests and escalate. Technical lead owns containment and recovery sequencing. Communications lead owns guests, staff, OTAs and press. Compliance lead owns ICO, Action Fraud, the acquirer and insurer notification. Property lead owns the physical estate: keys, safes, lifts and access.
Deputies matter more than principals
A hotel ransomware attack will not wait for your operations director to return from leave. Every role needs a named deputy who has actually read the plan, and both names go on the printed card. Estates that skip this discover on the night that the only person who knows the stop-sell credentials is on a flight.
The hotel ransomware escalation clock
Define, in hours, when the incident lead must be told, when the board must be told, when the insurer must be notified and when the 72-hour regulatory clock is considered to have started. Ambiguity here is what turns a manageable security incident into a compliance failure on top of an operational one.
The out-of-band channel
Agree, in advance, how the incident team communicates when corporate email is unavailable — a pre-created group on a separate platform, with personal devices enrolled and tested twice a year. Sorting this out during a hotel ransomware event means the first two hours are spent exchanging phone numbers.
| Role | Owns | First action | Decision authority |
|---|---|---|---|
| Incident lead | Overall response and trading decisions | Convene the bridge, declare the incident | Close availability, walk guests |
| Technical lead | Containment and recovery order | Isolate affected servers from the network | Disconnect systems, approve restores |
| Communications lead | Guests, staff, OTAs, media | Issue the holding statement on own domain | All external wording |
| Compliance lead | ICO, Action Fraud, acquirer, insurer | Start the 72-hour assessment log | Notification timing |
| Property lead | Keys, safes, lifts, physical access | Locate mechanical override keys | Physical security posture |
Hotel ransomware questions to ask your PMS and EPOS vendors
Most of your recovery time is in somebody else’s hands. These questions surface that dependency before an incident rather than during one, and they belong in every renewal.
Eight hotel ransomware questions worth putting in writing
Ask each vendor: what is your contractual RTO and RPO for our property; can we obtain a full export of our data on demand and in what format; do you support restoration to a specific point in time and how far back; are your backups immutable and administered with credentials separate from your production estate; how are your remote support accounts into our estate authenticated and logged; what is your notification commitment to us if you are breached; does your platform run in an offline or degraded mode and what functions survive; and when did you last test a restore for a customer of our size?
What a good answer looks like
Specific numbers, named formats, a documented degraded mode and a date for the last restore test. Vague reassurance about enterprise-grade security is not an answer. The reason this matters for hotel ransomware planning is that a vendor RTO of “best endeavours” quietly becomes your RTO, and your guests will hold you responsible either way.
Where the answers go
Into the plan and into the contract. Our approach to managed IT services for hospitality treats vendor recovery commitments as a documented control, reviewed annually, rather than as a procurement footnote nobody reads twice.
| Control | Stops the attack | Shortens the outage | Relative cost |
|---|---|---|---|
| Offline arrivals pack | No | Yes, immediately | Negligible |
| Standalone card terminals | No | Yes, immediately | Low |
| Immutable, isolated backups | No | Yes, decisively | Medium |
| MFA everywhere | Yes | Indirectly | Low |
| Network segmentation | Partly | Yes, substantially | Medium |
| Managed detection and response | Often | Yes | Medium |
| Patching internet-facing systems | Yes | Indirectly | Low |
| Help desk verification procedure | Yes | Indirectly | Negligible |
| Annual tabletop exercise | No | Yes, materially | Low |
Hotel ransomware: frequently asked questions
Can a small independent hotel realistically be a hotel ransomware target?
Yes, and disproportionately. More than two-thirds of ransomware attacks in 2024 and 2025 targeted businesses under 500 employees, and 88% of small business breaches involve ransomware compared with 39% for large companies. Attackers are not choosing hotels by brand recognition; they are choosing by exposure. A single unpatched internet-facing service at a 40-bedroom property is as attractive as one at a chain.
If our PMS is in the cloud, are we safe from hotel ransomware?
Safer, not safe. Cloud hosting removes the on-premise PMS server as an encryption target, which is a genuine gain. It does not protect your identity platform, your EPOS, your door-lock server, your file shares or your endpoints, and it does not stop an attacker who has your administrator credentials from operating inside the cloud tenant. The Microsoft 365 for hotels security checklist covers the tenant side of that boundary.
How long should a hotel ransomware outage last?
Sophos found 53% of organisations fully recovered within a week and 18% took more than a month. Plan for six days of degraded operation as a working assumption, and design the front desk fallback to survive 72 hours without the PMS. If your restore rehearsal has never been timed, you do not have an estimate — you have a hope.
Should we pay a hotel ransomware demand?
Law enforcement does not endorse it, there is no guarantee of recovery, and the UK is legislating towards a targeted ban and a payment prevention regime. Decide the position at board level in advance, document it, and tell your insurer. The decision you make under pressure at 02:00 with a queue in reception is not the decision you would make calmly.
Does Cyber Essentials help against hotel ransomware?
It addresses the controls that block the most common entry routes — patching, access control, malware protection, secure configuration and firewalls — which is exactly where 32% exploited vulnerabilities and 23% compromised credentials live. It is a floor rather than a ceiling, and it is often a contractual requirement for corporate accounts. Our Cyber Essentials for hotels guide covers scoping a hospitality estate.
Who should own hotel ransomware readiness in a group with no IT team?
The operations director owns the plan and the trading decisions; an external provider owns detection, backup verification and recovery. That split works because continuity decisions are commercial, not technical. Our IT support for hotels and hospitality service exists for exactly this shape of estate, and monitoring plus managed detection and response are the two pieces most small groups cannot staff themselves.
References and Further Reading
NCSC — Mitigating malware and ransomware attacks
NCSC — Ransomware-resistant backups
NCSC — Principles for ransomware-resistant on-premises backups
NCSC — Principles for ransomware-resistant cloud backups
NCSC — What you need to know about ransomware
NCSC — 10 Steps to Cyber Security
NCSC — Supply Chain Security Guidance
NCSC — Cyber Essentials Overview
NCSC — Small Organisations Guide to Cyber Security
Home Office — Ransomware legislative proposals
Cyber Security Breaches Survey 2025/2026
Sophos — The State of Ransomware 2025
Sophos — Retailers struggle with ransomware
BleepingComputer — Omni Hotels confirms cyberattack behind ongoing IT outage
BleepingComputer — Daixin ransomware gang claims attack on Omni Hotels
BleepingComputer — Washington Hotel in Japan discloses ransomware incident
BleepingComputer — Otelier data breach exposes hotel reservations of millions
The Register — Cyberattack hits Omni Hotels, taking down systems for days
The Record — MGM Resorts says cyberattack cost $100 million
VikingCloud — 2025 State of Hospitality Cyber Report
VikingCloud — Ransomware statistics and trends
Oracle — Simphony online and offline communication modes
Oracle — Simphony Check and Posting Service
Oracle — Property Interfaces: IFC8, FIAS and XML_POS
Oracle — Critical Patch Updates and Security Alerts
PCI Security Standards Council — PCI DSS
PCI Security Standards Council — Point-to-Point Encryption
ICO — Personal data breaches: a guide
ICO — A guide to data security
Action Fraud — Reporting cyber crime
NIST SP 800-61r3 — Incident Response Recommendations
NIST SP 800-207 — Zero Trust Architecture
