Hotel disaster recovery is the discipline of deciding, in advance and in writing, how a property keeps trading when the systems it depends on stop. Not if, but when. A fibre cut in the street, a flooded plant room, a failed host in the comms cupboard, a supplier outage two thousand miles away and a ransomware payload all arrive at the same front desk, with the same queue of arrivals, and they all pose the same question: can we check these people in? A plan that answers that question in minutes is worth more than any amount of resilience marketing.
Most hospitality estates already own the parts. Backups run somewhere. The tills have an offline mode. Somebody keeps a mobile hotspot in a drawer. What they do not own is the sequence. Which system comes back first, who is allowed to declare an incident, and how many hours of reservation data can the business actually afford to lose? Our guide to disaster recovery testing covers the rehearsal side of that question, and backup vs disaster recovery vs high availability explains why those three words are not interchangeable.
This article builds a plan around the four systems that decide whether the doors stay open: the property management system, the point of sale, the guest and back-of-house WiFi, and the booking stack that keeps selling rooms whether or not you can see them. There are six tables, five charts, a per-system RTO and RPO schedule, a costed three-property worked example, a testing calendar and a 90-day rollout. It assumes a UK operator with no in-house IT team.
Table of contents
- What a hotel disaster recovery plan actually has to cover
- Setting hotel disaster recovery targets: RTO and RPO by system
- Hotel disaster recovery for the property management system
- Hotel disaster recovery for POS, payments and food and beverage
- WiFi, connectivity and the network layer in hotel disaster recovery
- Hotel disaster recovery for booking systems and the revenue path
- Hotel disaster recovery when the disaster is not yours
- Hotel disaster recovery backups that survive the event
- Writing the hotel disaster recovery plan document
- Testing the hotel disaster recovery plan
- What hotel disaster recovery costs: a worked example
- A 90-day hotel disaster recovery implementation plan
- Frequently asked questions about hotel disaster recovery
- Bringing the hotel disaster recovery plan together
- References and Further Reading
What a hotel disaster recovery plan actually has to cover
A plan that lists servers is an asset register. A plan that lists guest-facing outcomes is a recovery plan. The difference shows up in the first thirty minutes, when the duty manager needs to know what to tell a coach party in reception rather than which virtual machine is unresponsive.
The four systems hotel disaster recovery has to protect
Every hospitality estate has hundreds of moving parts, but only four of them stop the building. The PMS holds the arrivals list, the room status board and the folio. The POS takes money on the food and beverage floor. The network carries both, plus the guest WiFi that half your reviews mention. The booking stack keeps inventory flowing to the OTAs. Hotel disaster recovery planning that covers those four properly is worth more than a plan that covers forty systems shallowly.
Hotel disaster recovery is not the same as your backup policy
Backups answer one question: can we get the data back? Recovery answers a harder one: can we run the business while we are getting the data back? A property with flawless nightly backups and no printed arrivals list still cannot check anybody in at 15:00. The backup is a component of the plan, not the plan itself.
Hotel disaster recovery covers far more than cyber attacks
Ransomware gets the headlines, and our hotel ransomware continuity guide covers that scenario in depth. It is not the most common cause of a lost trading day. Power failure, water ingress, a broken broadband circuit, a botched vendor update and a regional cloud outage between them account for far more downtime across a portfolio. Uptime Institute’s 2026 analysis names power as “the leading cause of impactful outages”, with UPS systems, transfer switches and generators as the dominant failure points.
Why hotel disaster recovery is harder than in most sectors
An accountancy practice that loses its systems sends people home and catches up. A hotel cannot. The guests are already in the building, more are on a train, the kitchen holds stock that expires, the night shift is two people, and the channel manager keeps selling rooms you can no longer see. The same principles shape disaster recovery for any 24-hour operation, but the tolerances here are tighter: the plan has to work at 03:00, with the staff who happen to be on shift, and without a technical audience.
The one-page test for an existing hotel disaster recovery plan
Hand your current document to a duty manager who was not involved in writing it. If they cannot, within five minutes, find who to call, how to check a guest in on paper, how to take a card payment and how to stop the OTAs selling, the hotel disaster recovery plan is a compliance artefact rather than an operational one. That test costs nothing and fails most plans.
| System | What stops | What the guest sees | Manual fallback that works |
|---|---|---|---|
| Property management system | Arrivals, in-house list, room status, folio, rates | A queue at check-in and no room allocation | Printed arrivals pack and paper folios |
| Point of sale | Till transactions and posting charges to a room | Bar and restaurant cannot close a bill | Offline till mode, written tabs, cash float |
| Payment estate | Card authorisation and settlement | “Sorry, we can only take cash” | Standalone GPRS terminals on a separate SIM |
| Guest and staff WiFi | Internet access, portal logins, handheld devices | A one-star review before they reach the room | Cellular failover on the core circuit only |
| Booking engine and channel manager | Nothing stops. It keeps selling. | A confirmed booking for a room you sold twice | Manual stop-sell in each extranet |
| Door locks and key encoding | Cutting new keys, lift and staff area access | Guests escorted to rooms by a member of staff | Mechanical override keys held by duty manager |
| Back office and email | Payroll, purchase ledger, group communications | Nothing today. A great deal by day four. | Out-of-band contact list and personal devices |
Setting hotel disaster recovery targets: RTO and RPO by system
Recovery targets are the spine of the plan. Without them, every decision during an incident becomes a debate, and debates during an incident are expensive. With them, the technical work has a finish line and the commercial side knows what it is buying.
The three hotel disaster recovery terms worth knowing
ISO 22301 gives three terms worth knowing. The maximum tolerable period of disruption is the point at which the impact becomes unacceptable to the organisation. The recovery time objective is the target time within which an activity must be resumed, and it must always sit inside the MTPD with a margin, because recovery rarely goes exactly to plan. The recovery point objective is how much data you are prepared to lose, measured backwards from the moment the lights went out. Our RTO and RPO explainer works through the arithmetic with a calculator.
The PMS needs the tightest RPO in the building
Reservation data changes continuously and cannot be reconstructed from anywhere else. A 24-hour RPO on the PMS means losing a full day of bookings, amendments, cancellations, folio postings and housekeeping status. In practice a hotel disaster recovery plan should target an RPO of one hour or better on the PMS, which for most operators means transaction log shipping or a cloud platform with continuous replication rather than a nightly dump.
POS and payments tolerate a longer RTO but almost no RPO
Sales data is different. If the tills fall over for two hours during a quiet afternoon, the business survives. If two hours of completed transactions vanish, you have lost revenue you cannot invoice and stock you cannot reconcile. Hotel disaster recovery targets for the tills therefore split: set a longer RTO than the PMS and a near-zero RPO, then verify that the offline cache on each till genuinely persists to local storage rather than to a server that may also be down.
WiFi is a reputational RTO, not a financial one
Guest internet rarely appears in a business impact analysis, which is a mistake in a sector where connectivity shows up in reviews. Hotel disaster recovery should treat it as a four-hour RTO with a cellular fallback that carries the essentials, and be explicit that the fallback will not carry a full house streaming video. Our hotel WiFi security guide covers the design that makes this survivable.
Booking and channel connectivity is measured in minutes
The channel manager is the one system where the recovery target is not about restoring a service you lost. It is about stopping a service that never stopped. Every minute the OTAs sell inventory you cannot fulfil adds a compensation cost and a review. A 15-minute target for a manual stop-sell across every channel belongs in the hotel disaster recovery plan, with the extranet credentials stored somewhere reachable without the network.
Door locks, lifts and the physical estate
Most electronic locking systems fail in a usefully safe direction: the locks themselves are battery-powered and hold their credentials, so existing keys keep working. What stops is the encoder, because it depends on a server and often on the PMS interface. Hotel disaster recovery planning should confirm that assumption per property rather than inherit it, and record where the mechanical override keys live.
A worked hotel disaster recovery schedule you can adopt
The schedule below is a starting position for an independent or small-group UK property. Adjust it against your own revenue profile rather than treating it as a standard, and get it signed off by the operations director, not by the person who maintains the servers.
| System | RTO target | RPO target | Recovery order | Why |
|---|---|---|---|---|
| Network core and internet | 1 hour | n/a | 1 | Everything else depends on it |
| Identity and directory | 2 hours | 1 hour | 2 | No logins, no applications |
| Payment terminals | 1 hour | 0 | 3 | Cash-only trading has a hard ceiling |
| Property management system | 4 hours | 1 hour | 4 | Reservation data is irreplaceable |
| Point of sale | 4 hours | 15 minutes | 5 | Offline cache buys the gap |
| Channel manager and booking engine | 15 minutes to stop-sell | 0 | 6 | It sells while you are blind |
| Key encoding | 4 hours | 4 hours | 7 | Escorting guests does not scale |
| Guest WiFi | 4 hours | n/a | 8 | Reputational, not transactional |
| Back office, email, payroll | 24 hours | 4 hours | 9 | Painful on day two, not day one |
| Reporting and BI | 72 hours | 24 hours | 10 | Can be rebuilt from source systems |
Hotel disaster recovery tiers and what each one costs
Not every system deserves the same investment. A three-tier model keeps the budget honest: hot systems fail over automatically, warm systems have a standby that needs a decision to activate, and cold systems are rebuilt from backup when there is time. Putting the PMS in the hot tier and the reporting stack in the cold tier is a rational hotel disaster recovery decision. Putting everything in the hot tier is a budget that never gets approved.
| Tier | Typical RTO | How it works | Relative cost | Hotel systems that belong here |
|---|---|---|---|---|
| Hot | Minutes | Replicated and running, automatic failover | High | Internet, identity, PMS on a resilient platform |
| Warm | 1 to 4 hours | Standby exists, a human decides to switch | Medium | POS estate, key encoding, file services |
| Cold | 1 to 3 days | Rebuild from backup onto new infrastructure | Low | Reporting, archives, CCTV retention, HR |
Hotel disaster recovery for the property management system
The PMS is the system whose absence stops the building, so it earns the most detailed section of the plan. It is also the system where cloud and on-premises deployments produce completely different recovery work.
Cloud and on-premises PMS need different hotel disaster recovery plans
An on-premises PMS makes you the recovery team: you own the backups, the restore target, the database and the interfaces. A cloud PMS makes you the co-ordinator: the vendor owns recovery, and your job is to know their published targets, to hold your own export of the data and to have a way of trading while they work. Neither model removes the need for a hotel disaster recovery plan. They change who does what in it.
The contingency print pack that keeps the front desk trading
The single highest-value item in the entire hotel disaster recovery plan costs nothing. Every property should print, at the same time each evening, a pack containing tomorrow’s arrivals with rate and payment method, the current in-house list by room, the departures list, room status by floor, any allergy or accessibility notes, and the on-call contact sheet. It lives in a physical folder at reception. When the PMS is gone, that pack is the hotel.
The OPERA Cloud reports worth scheduling for hotel disaster recovery
If the estate runs Oracle Hospitality OPERA Cloud, the reports already exist. “Arrivals and Checked In Today” (arrchkinbyroom) displays all expected guests due to arrive today and those who have already checked in. “Arrivals: Detailed” (res_detail) provides a detailed view of all arrivals for the selected date range. “Routing Details” (routing_details) shows every reservation with a comp, room or window routing attached. Schedule them to print and to email as PDF, so a copy survives on a phone as well as in the folder.
Restoring a PMS in the hotel disaster recovery order that works
Restoring a PMS out of order wastes hours. The sequence that works is: network, then identity, then the database, then the application, then the interfaces, then the printed reconciliation. Bringing the interfaces up before the database is stable produces a queue of failed postings that someone unpicks later. Note that scanning backups for malware before restoring is explicit NCSC guidance, not an optional step.
Reconciling the paper record back into the system
Every hour on paper creates a backlog. Plan for it: a named person, a quiet room, a defined order (check-ins, then charges, then payments, then departures) and a cut-off after which the paper record is authoritative for audit. Groups that skip this step spend the following month arguing with their own accounts. Building the reconciliation into the hotel disaster recovery plan converts a chaotic week into a scheduled task.
Data protection duties do not pause during an incident
UK GDPR Article 32 requires “the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services” and “the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident”. It also requires “a process for regularly testing, assessing and evaluating the effectiveness” of those measures. That is a legal basis for the testing budget, and our hotel PMS cyber security guide covers the protective side.
Hotel disaster recovery for POS, payments and food and beverage
The tills are the part of the estate most likely to keep working through an incident, because point of sale vendors have spent decades designing for a network that fails. Knowing exactly how far that design carries you is a hotel disaster recovery task, not a hopeful assumption.
Offline mode is a design feature, not an accident
Oracle Simphony documents three communication states for a workstation. 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”, which typically means the property has lost contact with the central database over the wide area network, 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 it “stores all transaction and timekeeping information in its local DataStore”.
The on-premises service that makes the difference
Simphony’s Check and Posting Service is described by Oracle as “a required service that runs on-premises at the property” that “acts as the bridge between the Enterprise and the property, providing resiliency”. Oracle is explicit about the consequence: “In the event of a WAN outage, POS clients are largely unaffected as they continue to post transactions to the on-premises CAPS.” That single architectural fact changes what a WAN failure means for your restaurant, and it is worth confirming the equivalent for whichever POS you run.
What POS offline mode does not cover in hotel disaster recovery
Offline tills still ring sales. What they usually cannot do is post a charge to a guest room, because that requires the PMS interface. So a POS outage is survivable, and a PMS outage turns every room charge into a manual note that someone reconciles later. Test both scenarios separately. Most properties have only ever tested the first, which is why hotel disaster recovery rehearsals so often produce a surprise.
Standalone terminals and the limits of store-and-forward
Integrated payment terminals lose their route to the acquirer when the network goes. Standalone terminals on a mobile data connection do not, which is why a small number of them, held charged and tested quarterly, is the cheapest single item in most hotel disaster recovery budgets. Store-and-forward has floor limits, per-transaction caps and a settlement window; know yours before you rely on it, and never fall back to writing card numbers on paper.
What PCI DSS expects from a hotel disaster recovery plan
PCI DSS requirement 12.10.1 asks for a documented incident response plan covering roles and responsibilities, communication and contact strategies including how you notify acquirers and payment brands, containment and mitigation procedures, business continuity and recovery processes, data backup, legal reporting obligations and all critical system components. Requirement 12.10.2 then asks you to “review and test the plan, including all elements listed in Requirement 12.10.1, at least annually”. A hotel disaster recovery plan that already exists satisfies most of this with one extra section.
Cash handling, tabs and the reconciliation cost
Trading on cash and paper tabs is possible for a service period and painful for a day. Plan the float, the safe drops, the two-signature rule on written tabs and the till reconciliation before you need any of it. Then price the aftermath honestly: the labour cost of rekeying two days of covers is real money, and it belongs in the hotel disaster recovery business case alongside the lost revenue.
WiFi, connectivity and the network layer in hotel disaster recovery
Connectivity is the dependency underneath everything else, which is why it sits first in the recovery order. It is also the layer where a modest investment removes the largest single class of outage.
One circuit is one point of failure
A single broadband or leased line is the most common unaddressed risk in an independent hotel. Uptime Institute reports that external infrastructure failures are becoming more prominent in publicly reported outages, with fibre and connectivity issues rising and more likely to result in extended disruptions. A second circuit from a genuinely different carrier, entering the building on a different path, is the single highest-value hotel disaster recovery fix at this layer. Two products from the same wholesale network in the same duct is not diversity.
Cellular failover and what it genuinely carries
A 4G or 5G failover router is cheap and effective for the things that matter: card authorisation, the PMS if it is cloud-hosted, the channel manager, email and the booking engine. It is not a replacement for a full house of guests streaming video, and the hotel disaster recovery plan should say so plainly. Configure it to prioritise business traffic explicitly, cap or block guest SSIDs while it is active, and put that behaviour in writing so nobody spends an outage wondering why the WiFi is slow.
DHCP, DNS, RADIUS and the captive portal in hotel disaster recovery
Hotels lose networks to services, not just to cables. If DHCP, DNS or the RADIUS server that authenticates devices runs on one box in one cupboard, the guest network dies with that box even though the internet is fine. Hotel disaster recovery planning should list these services by name with an owner and a fallback. Our guide to captive portal attacks on hotel WiFi covers the security angle on the same components.
Power, UPS runtime and the Storm Eowyn lesson
Storm Eowyn on 24 January 2025 left around a million homes and businesses without power at the peak across the UK and Ireland, with over 93,000 outages in Northern Ireland alone. By 27 January, 99% of customers had been reconnected while 5,200 remained without power and work continued to repair the damage. A comms cupboard with 20 minutes of UPS runtime is not a plan for that. Know your runtime, test it under load, and record in the hotel disaster recovery plan which circuits the generator carries.
Segmentation makes hotel disaster recovery faster, not just safer
A flat network means one compromised device is an estate-wide problem and one recovery decision affects every system at once. Segmented networks let you bring back the payment VLAN without waiting for the guest network to be declared clean. Our VLAN segmentation guide for hotel guest WiFi sets out the design, and it pays for itself twice: once in security and once in recovery speed.
Wireless coverage is part of the hotel disaster recovery estate
Handhelds for housekeeping, room service tablets and mobile card terminals all ride the wireless network. If the access point layer is at end of life, an outage becomes an outage plus a coverage problem. Our hotel WiFi upgrade cost guide sets out realistic per-bedroom budgets for that work.
Hotel disaster recovery for booking systems and the revenue path
This is the section most plans forget, and the one that generates the largest bill after the incident is over. Every other system fails by stopping. The booking stack fails by continuing.
The channel manager keeps selling while you are blind
Channel managers and booking engines are usually cloud services that are entirely unaffected by a problem inside your building. They carry on distributing whatever availability they last held. Three days of that produces a fourth day of arrivals for rooms that are already occupied, at full compensation cost. Hotel disaster recovery planning has to treat unstopped selling as an active failure mode with its own countermeasure.
Manual stop-sell is the 15-minute action that saves the week
The countermeasure is unglamorous: log in to every extranet and close availability, or set inventory to zero. It works only if somebody can do it. That means the extranet credentials for every OTA, the channel manager and the booking engine live in a password manager reachable from a phone on mobile data, with a named deputy. Rehearse it as part of hotel disaster recovery and it takes fifteen minutes. Discover it during an incident and it takes half a day.
Direct booking engine and payment gateway dependencies
Your direct booking path usually has more dependencies than you think: the website, the booking engine, the payment gateway, the interface that writes the reservation into the PMS, and the confirmation email service. Any one of them can break the funnel while the other four look healthy. Map that chain in the hotel disaster recovery plan, then decide which single failure you would accept and which one you would pay to remove.
API connections, XML batches and how fast a mistake spreads
Modern channel connections exchange data in near real time and update within seconds of a change, while older XML batch connections push on a schedule and leave short gaps where availability is out of date. That distinction matters during recovery: a real-time link propagates your stop-sell almost immediately, while a batch link may leave a window in which the OTA is still selling. Know which type each of your channels uses before you need to rely on it.
GDS, corporate accounts and the contracts nobody reads
Corporate and agency business often arrives through channels with commitments running in the other direction: you have promised availability and loaded rates. Check what your corporate contracts say about failing to honour a booking, because that clause, rather than the OTA policy, is usually the expensive one.
Rebuilding inventory after a multi-day outage
Coming back is its own hotel disaster recovery project. Reopen availability channel by channel rather than all at once, reconcile the reservations that arrived during the blackout, resolve duplicates against the paper record, and only then restore rates and restrictions. A group that reopens everything simultaneously discovers its overbookings at the front desk instead of in a spreadsheet.
Hotel disaster recovery when the disaster is not yours
An increasing share of hospitality downtime originates outside the property, in a data centre or a vendor release you have no control over. The plan still has to work, and hotel disaster recovery has to assume you are a spectator for part of it.
The AWS lesson: a regional outage with a very long tail
On 19 and 20 October 2025, Amazon Web Services suffered a major disruption in its US-EAST-1 region. AWS attributed it to “a latent race condition in the DynamoDB DNS management system that resulted in an incorrect empty DNS record for the service’s regional endpoint”. Impact ran from 11:48pm PDT on 19 October to 2:20pm PDT on 20 October, roughly 14.5 hours, across three overlapping phases affecting DynamoDB, EC2 launches and Network Load Balancers, and it touched well over a hundred AWS services. The hotel disaster recovery lesson is blunt: a third-party outage has no escalation path you control.
The CrowdStrike lesson: your vendor’s update is your outage
On 19 July 2024 at 04:09 UTC, CrowdStrike distributed a faulty configuration update for its Falcon sensor. It was reverted at 05:27 UTC, roughly 78 minutes later, and Microsoft estimated that 8.5 million devices were affected, which it said was less than one percent of all Windows devices. Hotels were squarely in the blast radius: properties could not encode key cards, staff escorted arriving guests to rooms individually, and at least one property photocopied credit cards in order to complete check-outs. Hotel disaster recovery has to assume a routine vendor update can be the disaster.
Reading a vendor SLA for what it actually promises
Cloud hospitality contracts often specify an RTO, an RPO and a target service availability level, then exclude non-production environments and, critically, exclude the availability target in the event of a declared disaster. Read that clause. It means the number you were sold is the steady-state number and the disaster number is a different, longer one. A hotel disaster recovery plan should record the contracted figures per vendor and the gap between those and your own targets.
Concentration risk across the hospitality stack
Check how many of your systems ultimately sit in the same cloud region or depend on the same identity provider. Many hospitality vendors are built on the same handful of platforms, so a PMS, a channel manager and a payment gateway that look like three independent suppliers can share a single point of failure. Concentration risk is invisible on an org chart and obvious during an outage.
Five questions to ask every hospitality supplier
Ask for the contracted RTO and RPO in writing. Ask when they last performed a full failover test and what the result was. Ask how you extract your own data, in what format and how often. Ask how they notify you during an incident, and through which channel if email is down. Ask what happens to your data when the contract ends. Suppliers who answer these quickly are the ones who have done the work.
Hotel disaster recovery backups that survive the event
Every hotel disaster recovery plan rests on a backup that still exists after the thing that caused the disaster. That is a higher bar than a backup that runs successfully, and it is where most estates are quietly exposed.
The NCSC principles for on-premises backups
The NCSC sets out six principles for ransomware-resistant on-premises backups: isolate the backup solution from the rest of the network, keep it updated, make it resilient to destructive actions, ensure restoration from an earlier version is possible even if later versions are corrupted, apply robust key management for data at rest, and generate alerts on significant changes or privileged actions. It also states that backup administrator accounts should be separate from those used to administer the rest of the network, and that backup devices should not be permanently connected to it.
The NCSC principles for cloud backups
For cloud backups the NCSC lists five: resilient to destructive actions, unable to deny all customer access, able to restore from an earlier version, robust key management, and alerting on changes or privileged actions. The practical translation for hotel disaster recovery is short. Immutable retention, a separate identity for backup administration, and a restore path that does not depend on the same login your attacker just used.
Scan backups before a hotel disaster recovery restore
NCSC guidance is explicit that you should scan backups for malware before restoring files. This matters more than it sounds: a restore that reintroduces the original payload turns a three-day incident into a three-week one, and it is a step that gets skipped precisely when the pressure to restore is highest. Put it in the runbook as a named gate with a named approver.
SaaS data is your responsibility, not your vendor’s
A cloud PMS, a cloud POS and Microsoft 365 all replicate your data for their availability, not for your recovery. Retention policies are not backups, and a deletion or a corrupt import replicates just as reliably as a legitimate change. Our guide to Microsoft 365 data retention versus backup unpacks that distinction, and our Microsoft 365 security checklist for hotels covers the tenant-side controls.
Restore rehearsals beat backup reports
A green backup report proves a job ran. It proves nothing about whether the data is usable, whether the restore fits inside your RTO, or whether anyone on shift knows how to start it. Two rehearsed hotel disaster recovery restores a year, timed and documented, are worth more than a year of clean reports. Sophos found in its 2025 research that 53% of organisations hit by ransomware fully recovered within a week, up from 35% the year before, while 18% took over a month, down from 34%.
The 3-2-1 rule, restated for hotel disaster recovery
Three copies of the data, on two different media, with one held off site and offline or immutable. For a property that means the live system, an on-site copy for fast restores, and an immutable off-site copy that survives a fire, a flood or an attacker with domain administrator rights. If your third copy lives on a NAS in the same plant room as the server, you have two copies and a longer sentence.
Writing the hotel disaster recovery plan document
A plan that exists only in someone’s head fails on their day off. The document itself has a shape that works, and it is shorter than most people expect.
Who is allowed to declare an incident
Name the roles, not the people, and name a deputy for each. The general manager or duty manager should be able to invoke the hotel disaster recovery plan without waiting for a director, because the first hour is where the plan earns its money. Write down what invoking it actually authorises: emergency spend up to a limit, switching to manual trading, closing channels, and calling the provider.
The five-role hotel disaster recovery incident card
One side of A4 per role beats a fifty-page binder. Incident lead owns the decisions and the log. Front of house owns guests, check-in and the printed pack. Food and beverage owns the tills, the tabs and the float. Technical liaison owns the provider relationship and the recovery order. Communications owns guests, staff, owners, OTAs and, if relevant, the regulator. Every card lists its first three actions.
Communications: guests, staff, OTAs, banks and insurers
Decide in advance who says what, and write it into the hotel disaster recovery plan. Guests need to know what works and what does not, in plain language, at the door and on the phone line. Staff need a channel that does not depend on the corporate email that may be down. Your acquirer, your insurer and your OTA partners each have notification expectations, and the insurer’s are often time-bound in the policy.
Offline copies of the hotel disaster recovery plan
Print the plan. Store a copy at reception, a copy in the duty manager’s office and a copy off site. Keep the contact list, the extranet credentials process, the mechanical override key location, the supplier account numbers and the emergency card terminals together. A hotel disaster recovery plan stored only on the file server that just went down is a well-written irrelevance.
Legal, regulatory and contractual reporting
If personal data is affected, the ICO clock starts. Payment card compromise brings acquirer and brand notification duties. Some corporate contracts require notification within a stated window. List the obligations, the trigger, the deadline and the owner in one hotel disaster recovery table, so nobody is reading contracts at 2am.
Keeping the hotel disaster recovery plan alive after version one
A plan is out of date the moment a supplier changes, a system is replaced or a manager leaves. Schedule a review twice a year and after any significant change, and make the review an agenda item with an owner rather than a diary reminder that gets dismissed. Ten minutes of maintenance beats a rewrite after the next incident.
| Scenario | Most likely trigger | First action in the first 15 minutes | Systems affected |
|---|---|---|---|
| Internet circuit failure | Street works, carrier fault | Confirm cellular failover is carrying payments | Cloud PMS, payments, booking, WiFi |
| Power loss | Storm, grid fault, plant failure | Check UPS runtime and shed non-critical load | Everything, in runtime order |
| Water ingress in the comms room | Burst pipe, roof failure | Isolate power safely, then start the rebuild clock | On-premises PMS, POS, network core |
| Server or hypervisor failure | Hardware age, failed update | Print the contingency pack before it is unreachable | PMS, key encoding, file services |
| Vendor or cloud outage | Regional fault, bad release | Open the vendor status page and start the log | Whichever service is hosted there |
| Ransomware or intrusion | Phishing, exposed remote access | Isolate, do not power off, call the provider | Potentially all of them at once |
| Loss of the building | Fire, flood, structural | Guest welfare first, then relocation agreements | Physical estate and everything in it |
Testing the hotel disaster recovery plan
An untested plan is a hypothesis. Testing converts it into a capability, and it is the cheapest part of the whole programme because most of the cost is people’s time in a quiet week.
Four hotel disaster recovery test types, and what each proves
A walkthrough proves the document is understandable. A tabletop proves the decisions are agreed. A component test proves one system restores inside its RTO. A full failover proves the whole thing works under time pressure. Run them in that order the first year, then keep all four in rotation. Our guide to running a cyber tabletop exercise sets out the format.
A hotel disaster recovery tabletop scenario you can reuse
Friday, 16:30, 92% occupancy, a wedding party arriving at 18:00. The PMS is unreachable and the provider cannot yet say why. Card terminals are declining. The channel manager is still live. Give the room ninety minutes and one facilitator, and record every question the plan could not answer. Those questions are the output. Nobody should be scored.
Component hotel disaster recovery tests you can run undisturbed
Restore a single PMS table into a sandbox and prove the data is readable. Pull a POS end-of-day report from backup and reconcile it against the original. Fail one internet circuit at 06:00 on a Tuesday and confirm cellular takes over. Each of these takes under an hour and each one has found a real fault in properties we have worked with.
The full failover test, and how to survive it
Once a year, stand the critical systems up somewhere else and run against them. Book it for the quietest week you have, publish the window, agree an abort trigger, and treat a failure as the point of the exercise rather than an embarrassment. A failed test costs a morning. A failed hotel disaster recovery costs a month.
What a hotel disaster recovery test pass looks like
A test passes when the RTO is met, the RPO is met, the runbook was sufficient without improvisation, and the people who ran it were not the people who wrote it. Anything else is a rehearsal with a friendly audience. Record the measured times, because next year’s improvement is only visible against this year’s numbers.
| Test | Scope | Frequency | Time needed | Evidence to keep |
|---|---|---|---|---|
| Contingency print check | Front desk pack is present and current | Weekly | 5 minutes | Signed checklist at reception |
| Single-record restore | One PMS table into a sandbox | Monthly | 30 minutes | Restore log with timings |
| Payment fallback test | Standalone terminals, live transaction | Quarterly | 20 minutes | Receipt and settlement confirmation |
| Circuit failover test | Primary WAN pulled, cellular takes over | Quarterly | 45 minutes | Time to restore and services carried |
| Stop-sell drill | Close availability on every channel | Twice a year | 30 minutes | Timestamped screenshots per channel |
| Tabletop exercise | Management team, one scenario | Twice a year | 90 minutes | Facilitator notes and action list |
| Full failover | Critical systems stood up elsewhere | Annually | One day | Measured RTO and RPO per system |
| Plan review | Contacts, suppliers, systems, targets | Twice a year | 60 minutes | Version history and sign-off |
What hotel disaster recovery costs: a worked example
Numbers make the case that adjectives cannot. The model below uses one three-property group and states every assumption, so you can substitute your own figures without re-deriving the method.
The three-property model
A UK group of three properties: 96, 74 and 58 bedrooms, so 228 bedrooms in total. That gives 228 x 365 = 83,220 available room nights a year. At 76% occupancy the group sells 63,247 room nights. At an average daily rate of £112 that is £7,083,664 of rooms revenue. Food and beverage adds 24% of rooms revenue, or £1,700,079. Total revenue is therefore £8,783,743, which is £24,065 a day. Those figures drive every hotel disaster recovery number that follows.
Revenue at risk during an outage
Assume a serious systems outage costs the group 40% of revenue for its duration, because the properties keep trading manually but lose walk-ins, cancel some arrivals, restrict food and beverage and refund a proportion of stays. One day costs £9,626. Three days cost £28,878. Five days cost £48,130. Seven days cost £67,382. That is the number that sits opposite the readiness budget.
The direct response costs nobody budgets for
Lost revenue is only part of the bill. Model a five-day event with emergency engineering at £11,400, agency cover and overtime at £6,300, OTA compensation and rebooking at £4,800, reconciliation and audit work at £5,200, and guest goodwill and refunds at £7,500. That is £35,200 of direct cost on top of £48,130 of lost revenue, so the modelled incident totals £83,330, or £365.48 per bedroom. Hotel disaster recovery budgets are argued against that total, not against the revenue line alone.
One-off hotel disaster recovery readiness costs
Building the capability costs the group £16,150 once: £2,600 to write the plan and inventory the systems, £5,400 to rebuild backups with immutable off-site retention, £2,850 to install a second circuit at each of the three sites, £1,320 for three cellular failover routers, £780 for runbooks and contingency print packs, and £3,200 for the first supervised full failover test.
Annual hotel disaster recovery running costs
Keeping it working costs £15,158 a year: £4,320 for backup storage and licensing, £5,040 for second-circuit line rental across three sites, £648 for cellular data plans, £2,100 for two restore rehearsals, £1,850 for the annual tabletop exercise, and £1,200 for plan maintenance and review.
Cost per bedroom and the comparison that matters
Year one therefore costs £16,150 + £15,158 = £31,308, which is £137.32 per bedroom. Every year after that costs £15,158, or £66.48 per bedroom. Set against a modelled incident of £83,330, the year-one hotel disaster recovery budget is 2.66 times cheaper than the event it is designed to absorb, and that comparison ignores the reputational cost entirely.
| Line item | One-off | Annual | What it buys |
|---|---|---|---|
| Plan writing and system inventory | £2,600 | £1,200 | A document a duty manager can use |
| Immutable backup rebuild | £5,400 | £4,320 | A copy that survives the event |
| Second circuits, three sites | £2,850 | £5,040 | Removes the single-carrier risk |
| Cellular failover routers and data | £1,320 | £648 | Payments and cloud keep working |
| Runbooks and contingency print packs | £780 | Included above | The front desk trades on paper |
| Full failover test | £3,200 | Included in testing | Proof the targets are real |
| Restore rehearsals and tabletop | Included above | £3,950 | Keeps the capability alive |
| Total | £16,150 | £15,158 | £137.32 per bedroom in year one |
A 90-day hotel disaster recovery implementation plan
Twenty-seven actions, ten in the first month, nine in the second and eight in the third. None of them requires a security team, and the first ten cost almost nothing.
Days 1 to 30: know what you have and buy the cheap wins
List every system with an owner, a vendor and a hosting location. Record the contracted RTO, RPO and availability figures from each vendor contract. Set draft RTO and RPO targets and get the operations director to sign them. Start the nightly contingency print pack at every property. Put the extranet credentials into a password manager with a named deputy. Buy and test standalone card terminals. Confirm where the mechanical override keys are held. Print an out-of-band contact list. Verify the last successful backup of each critical system. Run a walkthrough of the draft plan with duty managers.
Days 31 to 60: remove the single points of failure
Order a second circuit from a different carrier for each property. Install and configure cellular failover with business traffic prioritised. Rebuild backups to meet the NCSC principles, with a separate administrator identity and immutable off-site retention. Separate the payment and management networks if they still share a VLAN. Document the recovery order and the restore procedure for the PMS. Write the five incident role cards. Agree the declaration authority and the emergency spend limit. Run the first single-record restore test. Run the first stop-sell drill against every channel.
Days 61 to 90: prove it, then keep proving it
Run a full tabletop with the management team using the Friday-evening scenario. Perform a supervised failover of the critical systems and measure the actual RTO and RPO. Fix whatever the test broke and re-test that component. Publish the final plan, printed, at three locations. Book next year’s test calendar into the diary now. Add hotel disaster recovery to the twice-yearly management agenda. Brief every new starter as part of induction. Review the vendor answers and escalate any supplier who could not produce theirs.
Frequently asked questions about hotel disaster recovery
How long does a hotel disaster recovery plan take to write?
For one property with a clear system list, a usable first version takes two or three working days, most of which is interviewing the people who actually operate each system. The hotel disaster recovery document itself is not the hard part. Agreeing the RTO and RPO targets, and getting somebody senior to own them, is what takes the calendar time.
Does a cloud PMS remove the need for hotel disaster recovery?
No. It changes the plan rather than removing it. You still need the contingency print pack, the payment fallback, the stop-sell procedure, your own data export and a route to trade while the vendor recovers. Cloud moves the technical recovery to someone else and leaves the operational recovery entirely with you.
How often should we test hotel disaster recovery?
Small tests often, big tests annually. Weekly print checks, monthly single-record restores, quarterly payment and circuit failover tests, a stop-sell drill and a tabletop twice a year, and one full failover a year. PCI DSS separately requires the incident response plan to be reviewed and tested at least annually, and UK GDPR Article 32 requires a process for regularly testing the effectiveness of your measures.
What is a realistic RTO for a hotel PMS?
Four hours is achievable for most properties and defensible as a hotel disaster recovery target, because a printed contingency pack covers that window at the front desk. Anything under an hour usually requires a genuinely resilient hosting arrangement, and anything over a day means you are trading on paper through at least one full check-in and check-out cycle.
Who should own hotel disaster recovery in a group with no IT team?
The operations director owns the plan, the targets and the trading decisions. An external provider owns backup verification, restore testing and technical recovery. That split works because the expensive decisions during an incident are commercial rather than technical. Our IT support for hotels and hospitality service is built for exactly this shape of estate, alongside managed IT services for the day-to-day.
Is insurance a substitute for hotel disaster recovery?
It is a complement, not a substitute. Policies typically require you to demonstrate reasonable precautions, they carry notification deadlines measured in days, and they reimburse money rather than restoring a trading week. Read the cyber and business interruption sections alongside the hotel disaster recovery plan, and check the waiting period, because a 48-hour excess makes short outages entirely your own problem.
What does good hotel disaster recovery look like six months in?
Every property prints the pack nightly without being reminded. A duty manager can stop-sell every channel from a phone. Standalone terminals work because someone tested them last quarter. Two restores have been completed and timed. The plan has a version number, a date and an owner. None of that is exotic, and all of it is visible in an audit.
Bringing the hotel disaster recovery plan together
Hotel disaster recovery is not a technology project with an operations footnote. It is an operations capability with a technology footnote, and the properties that recover fastest are rarely the ones with the largest budgets. They are the ones where the printed pack exists, the fallback terminals are charged, somebody knows how to close the channels, and the restore has been rehearsed by the people who will have to run it at three in the morning.
Five hotel disaster recovery actions worth doing this week
Print the contingency pack tonight. Put the extranet credentials somewhere reachable from a phone. Charge and test a standalone card terminal. Ask each vendor for their contracted RTO and RPO in writing. Book ninety minutes in the diary for a tabletop. That is a week’s work and it removes most of the improvisation from your next hotel disaster recovery event.
Where hotel disaster recovery fits with the rest of your controls
Hotel disaster recovery is the last line, not the first. It sits behind the preventive work covered in our hotel cyber security checklist and the certification route in our Cyber Essentials for hotels guide. Good cybersecurity reduces how often you need the plan. Nothing reduces it to zero, which is why the plan exists.
Getting hotel disaster recovery help without hiring a team
Most independent operators do not need a permanent IT department to reach a defensible position. They need someone to own backup verification, run the tests on a calendar and answer the phone at 03:00. Our disaster recovery guide for property management companies covers the same discipline in an adjacent sector, and cloud adoption is often the cheapest route to a resilient PMS for a small group.
References and Further Reading
NCSC — Ransomware-resistant backups
NCSC — Principles for ransomware-resistant on-premises backups
NCSC — Principles for ransomware-resistant cloud backups
NCSC — Incident Management collection
NCSC — Small Business Guide: Response and Recovery
NCSC — 10 Steps to Cyber Security
NCSC — Mitigating malware and ransomware attacks
NCSC — Small Organisations Guide to Cyber Security
AWS — Amazon DynamoDB service disruption, October 2025
Uptime Institute — Annual Outage Analysis 2026
Uptime Institute — Annual Outage Analysis 2025
2024 CrowdStrike-related IT outages
Oracle — Simphony workstation online and offline modes
Oracle — Simphony Check and Posting Service
Oracle — OPERA Cloud arrivals reports
Oracle — Property interfaces: IFC8, FIAS and XML_POS
Oracle — Hospitality cloud service descriptions
UK GDPR — Article 32, Security of processing
ICO — Personal data breaches: a guide
ICO — A guide to data security
PCI Security Standards Council — PCI DSS
PCI Security Standards Council — Point-to-Point Encryption
ISO 22301:2019 — Business continuity management systems
Sophos — The State of Ransomware 2025
Energy Networks Association — Storm Eowyn power cut information
Met Office — Storm Eowyn warnings
NIST SP 800-61r3 — Incident Response Recommendations
NIST SP 800-34r1 — Contingency Planning Guide for Federal Information Systems
