IT security risks specific to hospitality – and how to address them

Why hospitality is a target

Hotels and hospitality businesses sit at an unusual intersection of risk factors. They hold payment card data at high volume – guests check in, order room service, use the spa and check out, each transaction a point of exposure. They hold personal data: names, addresses, passport numbers in some markets, stay history and preferences. And they operate networks that are, by design, accessible to hundreds of unknown users at any time.

The sector also has structural vulnerabilities that make security harder to maintain. High staff turnover means access credentials change hands constantly. Seasonal fluctuations compress hiring and onboarding timelines. Many properties run on-premise systems that were installed years ago and haven't been updated since. And multi-property operators often end up with inconsistent security postures across their estate – strong controls at the flagship, weaker ones at the regional properties.

Attackers know all of this. Hospitality has been a consistent target for payment card theft, ransomware and data breaches. The controls required to address these risks are well-established. What's often missing is consistent implementation.

Guest Wi-Fi security

Guest Wi-Fi is one of the most important – and most commonly misconfigured – security boundaries in a hotel. Guests expect fast, free internet access. What they don't need, and what creates serious risk, is any network path from that guest Wi-Fi to your back-of-house systems.

The requirement is straightforward: guest Wi-Fi must be completely isolated from your operations network. A guest on the hotel Wi-Fi should have no network path to your Property Management System (PMS), your point-of-sale terminals, your CCTV, your access control systems or any other internal infrastructure. This isolation is achieved through VLANs (Virtual Local Area Networks) – logically separated network segments that prevent traffic from crossing between them without explicit permission.

Within the guest VLAN itself, per-client isolation should be enabled. This prevents one guest's device from communicating with another guest's device on the same network – protecting both your guests and reducing the network's usefulness as an attack platform.

A captive portal – the login page guests see before accessing the internet – provides a basic layer of authentication and terms acceptance. It also gives you a mechanism to record that a guest accepted your acceptable-use policy, which matters if your network is later used for something it shouldn't be.

Regular penetration testing of the guest Wi-Fi network, specifically testing whether the guest VLAN isolation is effective, should be part of your annual security review.

PCI DSS compliance for hospitality

PCI DSS – the Payment Card Industry Data Security Standard – is the security framework that applies to any organisation that stores, processes or transmits payment card data. If your hotel takes card payments, PCI DSS applies to you.

PCI DSS compliance is not optional. Non-compliance exposes you to fines from your acquiring bank, increased transaction fees and, in the event of a breach, liability for fraudulent transactions and the cost of a forensic investigation.

The most common mistake hospitality operators make with PCI DSS is underestimating scope. PCI DSS scope isn't just the payment terminal – it covers all systems that store, process or transmit cardholder data, and all systems that are connected to those systems. If your payment terminals are on the same network segment as your front desk computers, those front desk computers are in scope. If your PMS passes card data to your payment gateway, the PMS and its infrastructure are in scope.

The practical implication is that network segmentation – isolating payment systems on their own network segment, completely separated from other systems – is both a security best practice and a scope-reduction strategy. Properly segmented payment environments are smaller, easier to manage and cheaper to audit.

Cloud-based payment solutions with point-to-point encryption (P2PE) can significantly reduce PCI scope for hospitality operators – the card data is encrypted at the terminal and never touches your systems in a form that creates compliance obligations.

PMS and booking system security

Your Property Management System is the operational heart of a hotel. It holds guest personal data – names, contact details, identification documents in some markets, stay history and preferences. It also typically holds or processes payment card tokens. And it integrates with a growing number of third-party systems: OTAs (online travel agencies), channel managers, revenue management tools, IPTV systems and more.

The security posture of your PMS depends heavily on whether it's cloud-hosted or on-premise. Cloud PMS providers like Mews and Opera Cloud invest significantly in security – regular penetration testing, SOC 2 compliance, encryption at rest and in transit, and managed patching. On-premise PMS installations are a different story. Older on-premise systems are frequently running on out-of-date operating systems, haven't been patched in years and have weak or shared credentials.

Regardless of your PMS architecture, some controls are non-negotiable:

• MFA (multi-factor authentication) for all administrative access to the PMS
• Role-based access control – front desk staff should not have the same access as system administrators
• PMS infrastructure on a separate, restricted network segment
• Logging of all access and administrative actions, with logs retained for a minimum period
• A clear process for revoking access when staff leave

Integration security matters too. Every system integrated with your PMS is a potential attack vector. API credentials should be unique per integration, with the minimum necessary permissions. Review your active integrations regularly – old integrations for systems no longer in use are a common oversight.

Access control and high staff turnover

Hospitality has among the highest staff turnover rates of any sector. Seasonal hiring, zero-hours contracts and frequent role changes mean that the list of people who have or have had access to your systems is long – and often poorly maintained.

The security consequence of this is straightforward. A single shared password for a till system, used by 20 staff members over three years, is a security problem. You have no audit trail, no ability to attribute actions to individuals and no confidence that former employees no longer have access. When a breach occurs – and it will occur – investigation is significantly harder.

Individual credentials for every system, for every member of staff, are the baseline. Where systems don't support individual credentials – some older POS systems don't – that's a system replacement decision, not a reason to accept shared passwords indefinitely.

Offboarding processes are as important as onboarding. When a member of staff leaves – for any reason, including termination – their access to all systems should be revoked the same day, ideally the same hour. This means having a clear, documented offboarding checklist that covers every system that person had access to: PMS, POS, email, Wi-Fi management, CCTV, building access and anything else relevant to your operation.

Centralised identity management – a single directory (such as Microsoft Entra ID) from which access to multiple systems is provisioned and deprovisioned – makes this significantly more manageable. When an account is disabled in the directory, access is revoked everywhere simultaneously.

Third-party vendor and system access

A modern hotel has a significant number of third-party relationships that involve remote access to its systems. OTAs and channel managers connect to your PMS. Payment processors have access to your payment infrastructure. IPTV providers access your network to manage guest entertainment systems. Maintenance companies may have remote access to building management systems. Each of these is a potential entry point.

Third-party access should be controlled, time-limited and logged. "Controlled" means access is granted through a defined mechanism – a VPN with individual credentials, not a shared account or a firewall rule left open permanently. "Time-limited" means access is granted for the duration of a specific task and then revoked, not left open indefinitely because it might be needed again. "Logged" means you have a record of who accessed what, and when.

The practical starting point is an audit of your current third-party access arrangements. Who has remote access to your systems right now? What mechanism do they use? Are those credentials still valid, and are they still with the right people? In most hotels that haven't done this exercise recently, the answer will include at least one arrangement that should have been closed months or years ago.

Multi-property security management

For operators running more than one property, security management becomes structurally more difficult. Each property has its own attack surface – its own network, its own PMS instance, its own staff – and the standards applied at each can vary significantly depending on when it was built, who manages it locally and how much central oversight exists.

The instinct is often to manage security on a property-by-property basis, with local IT contacts responsible for each site. This approach produces inconsistency. The property that had good IT management three years ago may have had three changes of local contact since, and the controls that were in place may have quietly degraded.

Central management through an MSP (managed service provider) with multi-site visibility is more effective. A single view of security events across all properties, consistent configuration management, and centralised patch management all become possible. Security incidents at one property can be identified and responded to without relying on local staff to notice and escalate.

For operators with a significant property estate, a security baseline – a defined minimum standard that every property must meet – is the foundation. Auditing properties against that baseline, on a defined cycle, ensures the standard is maintained rather than assumed.

Building a hospitality security posture

The controls described in this article aren't novel – they're the established baseline for hospitality IT security. The challenge in the sector is consistent implementation across an environment that changes constantly: staff turn over, systems are replaced, new properties are acquired and new integrations are added.

A useful starting point is an honest security assessment. Not a tick-box exercise – a genuine review of your current state against the controls that matter: network segmentation, PCI DSS scope, access management, third-party access and patching. Most hospitality operators who go through this process find at least a handful of material gaps, and often a few significant ones.

From there, the priority is closing the gaps that carry the highest risk – typically guest Wi-Fi isolation, PCI scope and offboarding processes – before addressing the longer-tail items. Security doesn't require perfection. It requires knowing where you stand and making consistent progress.