Why Hotels Are Soft Targets, Not Collateral Damage
A hotel is an unusually attractive target, and most operators have never been told why. You hold dense personal data on thousands of strangers: names, home addresses, passport and ID scans, dates of travel, payment details, sometimes health and dietary notes. You run a building full of guest devices on your network. You operate around the clock with a front desk staffed by people trained to be helpful to strangers, which is the exact instinct a social engineer exploits. And you depend on a stack of always-on systems, the property management system that runs the folio and stores guest data, the channel manager, the door locks, the point of sale, that cannot tolerate downtime without the business stopping. Attackers know all of this. They do not stumble onto hotels by accident; they choose them. The systems that hold your guests' data, starting with the property management system, are the crown jewels an attacker is actually after.
For years cybersecurity was treated as an IT department's problem, or, in an independent hotel with no IT department, nobody's problem until something broke. That posture is no longer tenable in 2026 for two converging reasons. The first is ransomware, which has industrialised into a service business that disproportionately hits mid-sized operators with valuable data and weak defenses, exactly the profile of an independent hotel. The second is NIS2, the EU's network and information security directive, which has turned cybersecurity from a discretionary IT spend into a legal duty with personal accountability for management. Even your payment flow is part of the picture: the way you handle card data through your payment system decides how much usable data an attacker can actually steal when, not if, they get inside.
I write for Prostay, and our team spends a lot of time on the boundary between the hotel systems we build and the security obligations our customers now carry, so the threat patterns, regulatory deadlines, and control priorities below come from the published NIS2 framework, the incident data security firms report on hospitality, and the practical reality of helping properties recover when something goes wrong. This article is written for the general manager and the owner, not the security engineer. It explains whether NIS2 applies to you, how a hotel breach actually happens, the reporting clock you must hit, the handful of controls that genuinely reduce risk, and a 30-day plan to get from exposed to defensible. None of it requires a computer science degree. Most of it requires deciding that this is your job now, because legally and practically, it is.
What NIS2 Actually Is, and Whether It Covers Your Hotel
NIS2 is the second version of the EU's Network and Information Security Directive. The first NIS directive (2016) covered a narrow set of critical operators: energy, water, big digital infrastructure. NIS2, which member states were required to transpose into national law by 17 October 2024, widens the net dramatically, raises the baseline of required security measures, tightens incident reporting, and, crucially, attaches real penalties and personal management accountability. It is not a hospitality-specific law, which is precisely why so many hoteliers have not registered that it might apply to them.
Whether it applies depends on three things: your sector, your size, and your country's transposition. Hotels are not on the headline list of "essential" sectors the way energy and healthcare are, so a standalone hotel is not automatically a regulated entity in most countries. But the boundaries are fuzzier than that summary suggests, the size thresholds catch larger properties and groups directly, and the supply-chain provisions reach much further down than the formal scope. The result is a landscape where some hotels are directly in scope, many more are indirectly bound through partners, and almost none are genuinely exempt from the underlying expectation to manage cyber risk.
Essential vs Important Entities, and the Size Test
NIS2 splits regulated organisations into two tiers. Essential entities are the highest-criticality operators and face the strictest supervision. Important entities are a larger group that still must meet the security and reporting duties but are supervised more lightly, typically after an incident rather than proactively. The split matters mainly for how hard a regulator leans on you and how large the maximum fines run.
Layered on top is a size filter. The directive's obligations are built for medium and large organisations, broadly those with 50 or more employees, or annual turnover and balance sheet over 10 million euros, operating in the covered sectors. A small seaside hotel with 18 staff usually falls under that floor and is not directly designated. A 250-room city conference hotel, or a management company running a dozen properties, can easily clear the threshold and find itself directly in scope. The key point for planning is that size is assessed at the level of the legal entity and sometimes the wider group, so a small property owned by a larger operator may inherit obligations it would not carry alone. Confirm your specific position with a local advisor, because the transposition details and the exact sector mapping vary by member state.
The Supply-Chain Clause That Pulls Small Hotels In
Here is the part that catches independents off guard. NIS2 makes supply-chain and supplier security an explicit obligation of the entities that are in scope. A regulated hotel group, a travel platform, a corporate travel buyer, or a management company has to manage the security of its suppliers and partners, and the cleanest way to discharge that duty is to push requirements down by contract. So a 40-room independent that takes corporate business from a regulated company, operates under a franchise flag, or connects into a regulated platform will increasingly be handed a security addendum: enforce MFA, keep tested backups, report incidents to us within X hours, let us audit you. You meet NIS2-shaped controls not because a regulator knocked, but because losing the contract is not an option.
This is why "we are too small for NIS2" is the wrong way to think about 2026. The realistic question is not whether the directive names your property; it is when the controls reach you, through direct designation, through your group, or through a partner's contract, and whether you would rather build them calmly now or scramble under a deadline imposed by someone else. The rest of this article assumes you will need them, because for the large majority of operators with any business custom, you will.
The Hotel Attack Surface, Mapped
To defend a hotel you have to see it the way an attacker does: as a set of doors, most of which you forgot you left open. The attack surface is wider than the front desk PC, and naming each part is the first step to closing it.
The human front desk. Reception staff are trained to trust and assist. A convincing phone call ("this is head office IT, we need you to install a quick update") or a well-crafted email invoice is often all it takes. Phishing and social engineering are the single most common initial entry point across every industry, and hospitality's helpful culture makes it worse.
Remote access. Someone has to reach the PMS from off-site: an owner, a night manager, a software vendor doing support. Too often that access is raw Remote Desktop exposed straight to the internet, protected by one reused password. It is the most reliably exploited weakness in small-business ransomware, full stop.
Third-party connections. Your channel manager, booking engine, payment gateway, door-lock system, and maintenance contractors all connect into your environment. Each is a potential path in, and a breach at a vendor can become a breach at you. This is the supply-chain risk NIS2 obsesses over, viewed from your side.
Guest and operational networks. If guest Wi-Fi, the booking systems, the payment terminals, and the back-office machines all share one flat network, then a guest's compromised laptop or a malware-laden device in the lobby can reach the PMS. Flat networks turn a small intrusion into a total one.
Unpatched and forgotten devices. The door-lock controller running ten-year-old firmware, the POS terminal no one updates, the old PC in the back office still on an operating system that stopped getting security fixes. Attackers scan for exactly these and walk through them. The hotel attack surface is not one big wall to defend; it is dozens of small ones, and the attacker only needs one to be weak.
How a Hotel Breach Actually Unfolds
Ransomware does not detonate the instant someone clicks a bad link. It unfolds in stages over hours or days, and understanding the sequence tells you where you still have a chance to stop it.
It usually starts with initial access: a phished credential, an exposed RDP login cracked by trying common passwords, or a foothold inherited from a compromised vendor. The attacker is now inside as one user, often without anyone noticing. Next comes escalation and lateral movement: they hunt for an administrator account, move from the front-desk machine toward the servers, and map what you have. This is the quiet phase, sometimes lasting days, and it is where good monitoring and network segmentation can still catch and contain them.
Then exfiltration: modern ransomware crews steal a copy of your guest data before they encrypt anything, because stolen data is leverage even if your backups are perfect. This is the shift to so-called double extortion. Only at the end comes encryption and the ransom note: files locked, the PMS unusable, a demand on screen, and a front desk that suddenly cannot check anyone in or out. The reason this sequence matters is that the loud, obvious part (the lock screen) is the last act, not the first. By the time you see it, the attacker has usually been in your environment for a while and has already taken what they wanted. Defenses that only react to the encryption are reacting too late; the wins come earlier, at access and lateral movement.
The Economics of a Hotel Ransomware Hit
Operators fixate on the ransom figure, but the ransom is rarely the largest cost. Add up what a serious incident actually does to a hotel and the number that matters is total business interruption, not the demand on the screen.
Start with downtime. If the PMS is encrypted, the front desk reverts to pen and paper if it can, the channel manager stops syncing, OTAs keep selling rooms you cannot see, and you are double-booking and walking guests within hours. A multi-day outage during a busy period can cost more in lost and mishandled bookings than any ransom. Then recovery cost: incident response specialists, forensic investigation, rebuilding systems from clean backups, and the staff overtime to run manually in the meantime. Then the regulatory and legal layer: NIS2 penalties for in-scope entities run high (for essential entities, fines can reach 10 million euros or 2 percent of global annual turnover, whichever is higher), GDPR exposure if guest data was breached, and the cost of notifying and supporting affected guests.
And then the cost no spreadsheet captures cleanly: reputation. "This hotel leaked my passport and card details" is the kind of story that follows a property in reviews and press for years. Paying the ransom does not fix any of this reliably either; decryption tools provided by criminals are often slow or incomplete, paying marks you as a soft target for the next crew, and it does nothing about the data already stolen. The economic case for prevention is overwhelming precisely because the downside is so much larger and messier than the headline ransom number suggests. Spending a few thousand on MFA, backups, and segmentation is cheap insurance against a six- or seven-figure bad month.
The Reporting Clock: 24 Hours, 72 Hours, One Month
For in-scope entities, NIS2 does not just ask you to be secure; it dictates how fast you tell the authorities when you are not. The timeline is tighter than most operators assume, and it starts the moment someone at the property realises a significant incident is underway.
Within 24 hours: the early warning. Once you are aware of a significant incident, you owe your national authority or CSIRT a rapid early warning, even before you fully understand what happened. The point is speed, not completeness; the regulator wants to know early that something serious is in progress.
Within 72 hours: the incident notification. A fuller report follows, with an initial assessment of severity, impact, and any indicators of compromise. By now you should have engaged your incident response and have a working picture of scope.
Within one month: the final report. A detailed account of the incident, the root cause, the measures taken, and the impact. This closes the loop with the regulator. Running in parallel, if personal data was exposed (and in a hotel breach it almost always is), the GDPR 72-hour clock to notify the data protection authority applies too, and you may have to inform affected guests directly. These are separate obligations to separate authorities, and they overlap in time, which is exactly why you cannot work out who calls whom during the incident itself.
The operational lesson is blunt: the reporting decisions have to be pre-made. Who declares an incident, who contacts the authority, which authority, with what information, on what number, all of it belongs in a written plan you can execute at 3 a.m. without a lawyer on speed dial. A property that has never thought about this will blow the 24-hour window simply because nobody knew it was their job to make the call.
Management Liability and Why the GM Cannot Delegate This
The change in NIS2 that should most concern owners and general managers is not technical at all. It is that the directive puts cybersecurity governance squarely on the management body and makes that accountability personal. Management has to approve the organisation's cyber risk-management measures, oversee their implementation, and can be held liable for failures to do so. The directive also expects managers to undergo cybersecurity training so they can actually understand the risks they are signing off on.
In plain terms: a general manager can no longer say "that's IT's job" and consider the matter closed. You can delegate the work to an internal team or an external provider, but the responsibility for ensuring it happens, and the consequences if it does not, stay with you. National transpositions back this with the threat of significant fines and, in some cases, the possibility of temporarily barring individuals from management roles for serious failings. That is a deliberate design choice by the EU: experience showed that security got under-resourced as long as it lived two levels below the people holding the budget, so NIS2 dragged it up to the top of the organisation chart.
For an independent hotel this is less about fear and more about ownership. Someone with authority has to own cyber risk the way they own fire safety or food hygiene: as a named responsibility with a budget, a plan, and periodic review, not an afterthought that surfaces only when something breaks. The good news is that the controls that satisfy this duty are mostly mundane and affordable, which is the subject of the rest of this article. The duty is serious; meeting it is not exotic.
The Controls That Actually Move the Needle
Cybersecurity marketing wants to sell you a wall of acronyms. The truth is that a small number of unglamorous controls stop the large majority of real attacks on hotels, and they matter far more than any single product. Here are the ones worth your attention and budget first.
Identity, MFA, and the RDP Problem
Most hotel breaches are not clever; they are a valid password used somewhere it should not have worked. Two fixes neutralise the bulk of that. First, enforce multi-factor authentication on every account that matters: PMS logins, email, remote access, admin accounts, the lot. With MFA, a stolen password on its own is useless. Second, get Remote Desktop off the open internet. If staff or vendors need remote access, put it behind a VPN or a zero-trust gateway with MFA, and never expose RDP directly. Pair that with basic password hygiene (no shared logins, no "Welcome2024" on the admin account, a password manager so people can have strong unique passwords) and you have closed the door the most common attacks walk through. This is the highest-return security work a hotel can do, and it costs very little.
Backups You Can Actually Restore From
Backups are what decide whether a ransomware attack is a bad week or the end of the business. But the detail that catches people is that the backup has to be both offline or immutable and tested. Attackers specifically hunt for and encrypt connected backups before they trigger the ransomware, so a backup drive permanently plugged into the server is no protection at all. You want copies the attacker cannot reach: offline, or in immutable cloud storage that cannot be altered or deleted within a retention window. And you have to test a restore, on a schedule, because the worst time to discover your backups are corrupt or incomplete is the morning you actually need them. A backup you have never restored from is a hope, not a plan.
Segmenting the PMS, POS, and Guest Wi-Fi
Network segmentation is the control that limits how far an intrusion can spread. The principle is simple: things that do not need to talk to each other should not be on the same network. Guest Wi-Fi must be isolated from everything operational, so a guest's infected laptop cannot reach the PMS. Payment terminals belong on their own segment. The back-office and PMS systems should be separated from general staff browsing. When the front-desk machine is compromised, segmentation is what stops the attacker from reaching the servers and the payment systems in one hop. It turns a potential total breach into a contained one, and it is mostly a matter of configuring equipment you already own correctly rather than buying anything new.
Payment Data, Tokenization, and Shrinking the Blast Radius
The most dangerous data to hold is the data you do not need to hold. Raw card numbers are the clearest example. If your systems store or even briefly handle full card details, a breach exposes them and your liability is severe. The fix is tokenization: your payment processor holds the real card data in its secured vault and hands your PMS a meaningless token that represents the card without being usable if stolen. Done properly, the sensitive card number never lives on your network at all.
This is the security logic behind PCI DSS, and it is why a modern, tokenized payment setup is a security control as much as a payments convenience. When the attacker breaks in and goes looking for card data to steal, there is nothing usable to take. That single architectural choice removes the most attractive and most heavily regulated category of data from your risk entirely. It does not make you invincible, because the rest of the guest record (passports, addresses, stay history) is still valuable and still has to be protected, but it takes the crown jewels off the table. Any hotel still letting full card numbers touch its PMS or sit in a spreadsheet should treat fixing that as an emergency, not a roadmap item.
Vendors, the Channel Manager, and Third-Party Risk
Your security is only as strong as the weakest vendor with a connection into your systems, and a hotel has many. The channel manager, the booking engine, the payment gateway, the door-lock platform, the marketing tools, the IT support firm: each holds access or data, and a breach at any of them can become a breach at you. NIS2 formalises this as a duty to manage supplier risk, but it is just good sense regardless of whether the directive names your property.
Managing it does not require a procurement department. It requires asking your critical vendors a short, pointed set of questions and acting on the answers. Where is our data stored, and is it encrypted? Do you enforce MFA on access to our environment? Have you had a breach, and how did you handle it? What certifications or independent security assessments can you show me? How quickly will you tell us if you are compromised? A serious vendor answers these readily and may volunteer a security overview or a recognised certification. A vendor that gets defensive or vague is telling you something important. Favour partners who treat security as a feature they are proud of rather than a question they resent, because in a connected stack their hygiene becomes your risk.
Writing an Incident Response Plan a Night Auditor Can Run
The single document that separates a controlled incident from a chaotic one is a written response plan that a non-technical staff member can follow at the worst possible hour. Attacks do not respect business hours; they often hit overnight and on holidays precisely because the skeleton crew is least prepared. So the plan has to be usable by whoever is actually on shift, not just the IT contractor who is asleep.
Keep it concrete. The plan should name the first three steps anyone can take: disconnect affected machines from the network (unplug the cable, disable Wi-Fi) to stop the spread without powering them off, which can destroy forensic evidence; call the named incident contact; and start a simple written log of what was seen and when. It should list who to call, with real names and phone numbers: the internal owner, the IT provider or incident response retainer, the cyber-insurer's hotline, and the relevant authority for the legal report. It should remind staff what not to do: do not pay anything, do not negotiate, do not wipe machines, do not talk to the press. And it should cover operational continuity: how to check guests in and out manually, how to take payment if the system is down, how to stop OTAs overselling rooms you can no longer see.
Then do the thing almost nobody does: rehearse it. A 30-minute tabletop exercise where you walk the front-desk team through "the PMS is locked and there's a ransom note, what now?" surfaces the gaps while they are cheap to fix. A plan that has never been read aloud is a plan that will be found, unread, during the one event it was written for. Print it. Put a copy at the front desk. Make sure the overnight staff know it exists and where it is.
A 30-Day Cyber-Readiness Plan
A month is enough to move a typical independent from exposed to genuinely defensible, without a consultant and without a big budget. One manager with authority can drive it, pulling in the IT provider for the technical steps.
Days 1 to 5: see what you have. List every system that holds guest data or touches payments, every account with remote or admin access, and every vendor with a connection in. You cannot protect what you have not inventoried, and this list is also the foundation of the risk assessment NIS2 expects. Note which machines run software that no longer receives security updates.
Days 6 to 12: close the common doors. Turn on MFA everywhere it is available, starting with email, remote access, and the PMS. Get RDP off the open internet. Kill shared logins and reset weak admin passwords. This week alone removes the most heavily exploited weaknesses, and it is mostly configuration, not procurement.
Days 13 to 18: fix backups. Confirm you have backups of the PMS and critical systems that are offline or immutable, and then actually test a restore. If the only backup is a drive plugged into the server, fix that first. Document the restore steps so they can be followed under pressure.
Days 19 to 23: segment and patch. Separate guest Wi-Fi from operational systems, put payments on their own segment, and apply outstanding security updates to the systems that can take them. Plan replacement for anything running end-of-life software that cannot be patched.
Days 24 to 28: write the incident plan and check vendors. Draft the one-page response plan with real names and numbers, and send your critical vendors the short security questionnaire. Decide whether cyber insurance makes sense for your size and risk.
Days 29 to 30: assign ownership and rehearse. Name the person accountable for cyber risk, put a quarterly review on the calendar, and run a 30-minute tabletop exercise with the front-desk team. At the end of the month you will not be invulnerable, no one is, but you will have closed the doors that real attacks use and you will have a plan for the day one slips through. That is the realistic definition of done.
Where Prostay Fits, Briefly and Honestly
I write for Prostay, so here is the straight version. A property management system sits at the centre of this picture because it holds the guest data attackers want and it is the system whose downtime stops the business. So the security posture of your PMS vendor is part of your risk whether you think about it that way or not. Prostay runs as a cloud platform with the controls you would expect a serious vendor to carry: encryption of data in transit and at rest, MFA on access, tokenized payments so raw card data never lands in the property's environment, audited infrastructure, and managed backups, so a chunk of the burden above is carried by the platform rather than left on the front desk. None of that is unique to Prostay; reputable cloud PMS vendors like Mews and Cloudbeds make similar commitments, and you should ask all of them the same hard questions from the vendor section above.
The honest argument for a modern cloud platform over a legacy on-premise server in the back office is that it moves a lot of the hardest security work (patching, infrastructure hardening, backup, payment data handling) to a provider who does it full time, which is exactly what a 40-room hotel with no IT department cannot do well alone. That does not erase your obligations; you still own MFA on your accounts, your incident plan, your staff training, and your vendor management. But it shrinks the surface you personally have to defend. If you want to see how the Prostay PMS handles guest data and payments, the product detail is there, and if you would rather have our team walk through your current stack against the readiness checklist above, book a demo and we will go through the real questions rather than sell you a fear-driven upgrade.
Frequently Asked Questions
Five questions independent hoteliers ask most about cybersecurity and NIS2, answered against the directive and the way attacks actually play out rather than vendor scare copy.
