Saturday, 02:14, Ransomware
At 02:14 on a Saturday, the night manager finds a ransom note on a PMS terminal at the flagship of a six-property group. Within four hours, three properties report the same. The PMS database is encrypted; the semi-integrated payment terminals still authorise because card data never traverses the PMS, but check-in, room assignment and folios are down and the property is running on paper. The most recent verified backup is 11 weeks old; the nightly job has been reporting 'success' because it writes a log regardless of outcome. Offline media exist at one property only. The franchise agreement requires breach notification to the brand within 24 hours. Cyber insurance covers forensics through a panel of three firms, with a $50,000 retention.
1. Set out the first four hours. Who decides what, and what would you deliberately not do?
Read the worked answer
Separate the three clocks: safety and guest operations, evidence preservation, and notification. They are owned by different people and should not be run by one improviser.
Incident commander - the most senior available IT leader, with explicit authority to take systems offline - supported by a scribe keeping a timestamped log, which will be needed for insurance and any notification.
Order of operations.
- Isolate: pull affected systems off the network and disable remote-access paths, including vendor support tunnels, without wiping anything.
- Stabilise operations: paper check-in, manual folio, pre-printed key envelopes, and confirm that door-lock and life-safety systems do not depend on the PMS. If lock credentials are PMS-derived, that becomes the top priority.
- Call the insurer's panel firm immediately - the panel exists to be used, and the retention is payable whether or not you call.
- Preserve: hash and retain logs and disk images before any rebuild. Advise the property not to 'clean up' terminals.
- Escalate to GM, legal counsel and the brand relationship owner.
Deliberately not do: rebuild servers before imaging; contact the attacker or reply to the note; issue a guest-facing statement before counsel frames it; and assume card data was in scope - verify from the architecture, because a semi-integrated estate may avoid a costly forensic investigation entirely if scope exclusion is documented.
2. The backup is 11 weeks old and the ransom is demanded. How do you reason about restore versus pay, and what should be decided in parallel?
Read the worked answer
Restore versus pay is not a two-way choice. Three options, not two: restore from the 11-week-old backup, reconstruct from a combination of the backup plus paper records plus downstream data held by the CRS, channel partners and the credit-card processor, or pay.
Quantify the loss before deciding. An 11-week-old restore loses reservation and rate history for that period; much of it is recoverable from the central reservation system, OTA channels and the payment processor's transaction record. That reconstruction is tedious but usually cheaper and more certain than payment, which buys no guarantee - decryption keys frequently fail on corrupted or partially encrypted databases, and paying funds and encourages the next attack. There are also sanctions exposure if the payment route touches a designated entity. State plainly that you do not recommend paying, and that the decision sits with the owners and counsel if they overrule that.
In parallel, decide: whether the 11-week gap triggers a legal notification even if the restore succeeds; what the brand requires at the 24-hour mark, which is contractual and independent of any statutory duty; and how to communicate with guests whose stays are in the missing window.
The root cause is the backup process, not the attacker. A job that writes 'success' without verifying a restore is a design defect; fix and test-restore quarterly across all six sites, not just the flagship.