A cyberattack is not the end of a hotel. What happens next decides everything.

Opening

It is 03:47 on a Tuesday morning. The night manager at a boutique property in the Randstad receives a phone call, but not from a guest. From a systems engineer on the night shift at their MSP, who has been watching the PMS console for the last twenty minutes with an increasingly uneasy expression.

Reservations from three days ago are being modified. A supplier login is active from an IP address the property has never seen before. Files on the shared drive have started renaming themselves with an extension nobody recognises.

By 09:30 the same morning, the property is on manual check-in. Card readers are down. The reservations system is offline. The IT director is at the property with an incident response team. And a decision needs to be made in the next hour: cancel tonight’s arrivals to contain the situation, or keep bookings open and manage guests case by case.

Every hotel operating at any scale eventually finds itself in a version of this scenario. The industry has passed the point where “we will not be targeted” is a viable strategy. The question stopped being whether. It became when, and what happens after.

What follows is not a marketing document, although we obviously benefit if hotels choose our services after reading it. It is a summary of the operational reality as we see it after twenty-five years of watching this industry evolve, and specifically after the last three years of watching hospitality cybersecurity move from an IT concern to an existential business question.

Chapter 01

The old model of hotel cybersecurity treated attacks as exceptional events. The security stack was built like a castle wall: high, thick, and expensive. Everything valuable lived inside the wall. The assumption was that the wall would hold. When it did not, the fallback plan was often written on a paper document that nobody had read since it was ratified.

That model no longer describes the world hotels operate in. In summer 2024 alone, VikingCloud’s 2025 State of Hospitality Cyber Report documented that 82% of North American hotels experienced at least one successful cyberattack. 58% were targeted five or more times.^[1] This is not a spike. It is a plateau. The hospitality industry has become one of the most consistently targeted verticals in cybercrime, behind only healthcare and financial services.

The reasons are not mysterious. Hotels handle exactly the data that criminals want: payment cards, personal identification, travel patterns, corporate expense information. They operate at scale, with staff turnover that makes training a permanent job rather than an event. They depend on integrations with dozens of third-party suppliers, each of which is a potential doorway. And they are highly visible: a breach at a hotel is news, which increases both the pressure to pay ransoms and the reputational cost of not.

The average cost of a hospitality data breach reached $3.86 million in 2024, up from $3.62 million in 2023.^[2] That number climbs further when you include lost bookings during recovery, legal fees, insurance premium increases, and the years of trust rebuilding that follow. The industry-agnostic global average sits at $4.88 million. For hospitality specifically, the number sits below that global average, but the reputational leverage on trust means the qualitative damage often exceeds what the balance sheet reflects.

There is a second, more sobering number in the same reporting. Of hospitality businesses that experienced a breach, 89% experienced one or more repeat breaches.^[3] The first attack is not just a bad day. It is a diagnostic that reveals architectural weaknesses which, if not addressed, guarantee the second attack. This is where the “we already got hit, we should be fine now” thinking fails catastrophically.

Under the NIS2 directive, cybersecurity accountability at hotels of a certain size sits with the operator, and personal liability attaches to the board. The old defence “we outsourced that to our IT provider” no longer works. If your loyalty integration leaks guest data, the personal liability lands on your board members, individually, not on your PMS vendor. Not on your central reservation platform. Not on your insurance broker. On the individual directors who signed off on the arrangement.

This is the baseline. Not the exception, not the future, not something to plan for eventually. This is the environment every hotel of a certain size is now operating in. The response has to match.

Chapter 02

When an attack lands, two clocks start running simultaneously. The first is the containment clock: how fast can we stop this from spreading through the network. The second is the operations clock: how do we keep the hotel running while we do it. Getting one right at the expense of the other is how a bad hour becomes a bad week.

Someone notices something is wrong. It could be a member of staff seeing a screen behave strangely. It could be a monitoring alert firing. It could be a guest complaint about a broken card reader. In the best cases, it is one of your own systems: the endpoint detection catching the encryption process before it finishes, or the network monitoring seeing a data exfiltration attempt in progress.

The moment that recognition happens, the incident response plan should activate. This is a document written months earlier by people who were not panicking. It names the incident commander (usually the CIO or CISO). It names the escalation path. It lists the people who need to be informed and in what order: the executive team, the insurer, the legal team, the DPA when required, the PR team, the front-line staff, and eventually, the guests.

The plan should also name what does not happen in the first hour. No public statements. No communications to guests about what has happened. No email to affected suppliers. Facts before communication. Always.

This is when the technical work happens. Compromised systems are isolated. The extent of the intrusion is mapped. If backups exist, they are verified. If they do not, the calculation becomes different: what can be rebuilt, at what cost, in what time.

Simultaneously, the operational fallback runs. Reception moves to paper check-in and manual key issuance. Card readers switch to standalone mode if possible. The kitchen prints its orders. Everything that was digital becomes analog again, for as long as it takes. This is where the years of “we could not possibly go back to paper” get tested against reality, and where most hotels discover they can, if they must, but it hurts.

This is the moment when staff training pays off or fails. A hotel that has rehearsed this scenario in tabletop exercises moves through the transition without dramatic guest impact. A hotel that has not, produces the complaints that end up in reviews for months.

By this point, decisions need to be made that were unthinkable the day before. Do we cancel tonight’s arrivals? Do we call in extra staff? Do we notify our corporate clients now, or wait until we have more information? Do we pay the ransom, if there is one?

These are not just IT decisions. They are business decisions with legal and reputational consequences. They require the presence of the executive team, the legal counsel, the insurer, and often external forensic specialists. The role of the IT team here is to give the business the clearest possible picture of what has happened and what is still happening, so that the business can make its calls with information rather than instinct.

The critical rule for the entire twenty-four hours: document everything. Every decision, every timestamp, every log. The audit later depends on it. So does the insurance claim. So does the eventual regulatory review under NIS2. The temptation, in the fog of an active incident, is to stop taking notes because there is real work to do. That is the temptation to resist most firmly.

Chapter 03

The metaphor is old but genuinely useful. An eggshell defence has one hard outer layer. Once cracked, everything inside is exposed. An onion defence has many layers, each of them imperfect, but each of them buying time and limiting the reach of an attacker who has crossed the outer one.

For decades, hotel cybersecurity was designed as an eggshell. The firewall was the wall. The VPN was the gate. Beyond that, everything was one flat internal network: PMS, back office, guest WiFi, IPTV, payment systems, all reachable from each other. This is the architecture that produces the 89% repeat breach number Trustwave documented. When the first attack succeeds, the network has no internal boundaries, so recovery is impossible without a full rebuild. Attackers who breach once know exactly how to breach again.

The onion model rebuilds the environment with internal boundaries at every level. It has six essential layers, which are worth walking through in more detail than a bullet list allows.

Guest WiFi does not touch the PMS network. The PMS network does not touch payment processing. The IPTV network sits on its own VLAN. The back office is separate from the front. Each boundary requires explicit permission to cross. If an attacker compromises the guest WiFi, they see only the guest WiFi. They cannot pivot to the PMS. This is the layer most eggshell environments never had, and it is the single highest-ROI security investment a hotel of any size can make.

Segmentation is not glamorous. It does not sound like an innovation. It is fifteen-year-old network engineering practice that most hospitality environments still have not implemented properly, because the flat network was always cheaper and faster to deploy. The cost of that shortcut is exactly the 89% repeat breach rate.

Multi-factor authentication on every account that touches anything sensitive. Not just email and VPN, but every admin login, every third-party integration, every supplier connection. Least privilege access: staff only get to what they need to do their job. Third-party suppliers with a login to your PMS get audited access with time-limited credentials, not shared passwords sent by email that persist for years.

Every account is a potential entry point. Every account needs its own hardening. In practice, the accounts that get missed are the old ones: a supplier who has not touched the PMS in two years but still has a login, a former staff member whose account was never deactivated, a service account with admin rights that was created for a one-off integration and never removed. The audit of these accounts is unglamorous work. It is also where the highest concentration of unmanaged risk lives.

Every laptop, every server, every point-of-sale terminal has active detection running. Not just antivirus signatures, which catch yesterday’s attacks. Behavioral analytics that catches unusual patterns in real time: a process that suddenly starts encrypting files, an account that logs in from three countries in an hour, an executable that arrived through email and is now writing to system directories.

This is the layer that catches ransomware in the encryption phase, before the entire filesystem is locked. The difference between “endpoint detection caught it at 3:47” and “we noticed the ransom note at 09:15” is often the difference between a two-hour incident and a two-week rebuild.

Backups that are tested regularly, immutable (cannot be modified or deleted by an attacker), and separated from the production environment so that a compromise of the network does not also compromise the backups. The difference between “we lost yesterday’s data” and “we lost the last three months of data” is whether backups were part of the security architecture or an operational afterthought.

Modern ransomware specifically targets backup systems, because the attackers know that a viable backup makes the ransom demand pointless. The defence has to specifically protect them. This means immutable storage, air-gapped copies for critical data, and regular restore tests that actually verify the backup is usable, not just present.

Something is watching, all the time, and it knows what normal looks like on your specific environment. Alerts get triaged before they hit the operations team, so the operations team is not overwhelmed with false positives that they eventually start ignoring. This is the layer that separates “we noticed the breach three months later” from “we contained it in twenty minutes.”

Statistically, the difference in cost between these two scenarios is roughly a factor of ten. Most hotels cannot justify a 24/7 in-house security operations team. Most hotels can, however, justify managed detection and response as a service from a partner who runs one across many clients. This is one of the strongest arguments for the managed services model in security specifically.

Written down. Rehearsed. Updated after every drill. The layer that turns panic into procedure on the worst day. This is also the layer NIS2 auditors will ask for first. A plan that exists as a PDF but has never been read out loud by the incident commander is not a plan. It is a compliance artifact. Under NIS2, the difference is being measured.

Chapter 04

Technology stops attempts. Trained people stop the attempts that technology misses. Together, they define the security posture of an organization. Individually, neither is enough.

In 2025, 48% of hotel IT and security leaders reported low confidence in their staff’s ability to detect AI-driven threats like deepfake voice calls and hyper-personalized phishing.^[1] This is not a training gap. It is a training model gap. The threats evolved. Most training programs did not. A phishing simulation designed in 2019 does not prepare a front desk agent for a synthetic voice call from someone claiming to be the general manager, using cloned audio, at two in the morning.

Working programs share three characteristics.

The traditional model of security training was one webinar per year, mandatory, mostly ignored. The modern model runs continuously: micro-modules of five to ten minutes distributed monthly, with quarterly deep-dives on specific topics and annual tabletop exercises for the leadership team. Twenty minutes a month beats two hours a year, every year. The former builds pattern recognition. The latter builds resentment.

Phishing tests that use current tactics: AI-generated emails, spoofed voices, fake supplier requests using publicly available information about the hotel. The point of a phishing simulation is not to shame staff who click. It is to measure improvement over time and to give front-line teams muscle memory for the attacks they will eventually see for real. A simulation that never catches anyone is not testing anything. A simulation that always catches the same people is a training design problem, not a personnel problem.

Staff who fear punishment for admitting they clicked a suspicious link will hide the click. This is the worst possible outcome, because it prevents early containment. Staff who know that reporting suspicious activity early is celebrated will report every one. The cultural work required to produce the second behavior is more valuable than any single technical tool.

At a well-run hotel, catching one attempted phishing attack is a shift-standup story. The person who caught it gets recognized publicly. The near-miss becomes training material for others. This is the culture that lifts an entire organization’s security posture without any additional technology investment. It is also the culture that is hardest to build, because it requires management to genuinely mean what they say about not punishing mistakes made in good faith.

Chapter 05

Every hotel we have helped through a serious incident tells us the same thing afterwards: the environment they run now is nothing like the environment they were breached in. Not because they threw money at the problem. Because the incident gave them the mandate to fix what they had already known was broken.

Segmentation projects that had been on the roadmap for two years got done in two weeks. Multi-factor authentication that IT had been asking for got signed off by the board on the second day. Response plans that had never been rehearsed became quarterly drills. Vendor access that had accumulated over the years got audited and cut back to what was actually needed. In other words, the breach became the trigger for the transformation that should have happened without it.

This is why our Secure360 service starts with the same question whether a hotel has been breached or not: what is your environment ready to survive? The hotels that answer honestly build the onion architecture on their own schedule, under their own budget, without the pressure of an active incident. The hotels that discover the answer during an actual breach build the same architecture under regulatory pressure, guest scrutiny, and board panic. Both end up in the same place. Only one of them has to explain the delay to a board of directors, an insurer, a room full of concerned guests, and eventually, to a regulator.

NIS2 has made the “discover the problem during the breach” option significantly more expensive. Personal liability at board level. Documented cybersecurity across every layer. Evidence of ongoing training. These are no longer competitive advantages. They are the baseline. The hotels that internalised this before the audit are running mature architectures right now. The rest will build the same architectures, under regulatory pressure, in the next two to three years. The work is the same. The narrative around it changes considerably.