Hotel PMS Cyber Security: Proven Way to Avoid Data Risk

Hotel PMS cyber security is the part of hospitality IT that nobody wants to own. The property management system is bought by operations, installed by a vendor, integrated by whoever supplied the door locks, and then left alone for a decade because it works. Meanwhile it quietly becomes the single most valuable database in the building: every guest who has ever stayed, every card token, every passport scan, every arrival list, every room number.

If somebody wants to hurt a hotel, they do not need the corporate file server. They need the reservation system. Our hotel cyber security checklist covers the whole estate at control level; this article goes down into one system and stays there, because a hotel PMS has a threat model that no generic security baseline describes. It is internet-facing, it never closes, it is operated by the highest-turnover workforce in the UK, and it exchanges data with a dozen other platforms over interfaces that were designed when a serial cable was a reasonable security boundary.

What follows is a practical guide to hotel PMS security for UK operators: what the system actually stores, how reservation and guest data has genuinely been stolen in verified incidents, where responsibility splits between you and the vendor, and the controls that make the difference. There are seven tables, four charts, a costed four-property worked example, a 90-day plan and a set of vendor questions you can send tomorrow. None of it assumes you have a security team.

Table of contents

What the hotel PMS actually holds
Why the hotel PMS is the highest-value system in the building
The hotel PMS integration surface
How hotel PMS reservation and guest data actually gets stolen
Cloud or on-premise: where hotel PMS responsibility splits
Identity and access control for the hotel PMS
Payment data: keeping the hotel PMS out of PCI DSS scope
Patching a hotel PMS you did not write
Hotel PMS retention: reservation and guest data under UK law
Monitoring and audit for the hotel PMS
Backups and the day the hotel PMS is not there
Choosing and challenging a hotel PMS vendor
What hotel PMS security costs: a worked example
A 90-day hotel PMS hardening plan
Hotel PMS cyber security: frequently asked questions
References and Further Reading

What the hotel PMS actually holds

Before you can protect reservation and guest data you have to be honest about what is in there. Most operators describe the hotel PMS as “bookings”. A hotel PMS is considerably more than bookings, and the extra material is what makes a breach expensive.

The hotel PMS reservation record is more than a name and a date

A single reservation carries the guest name, contact details, home address, arrival and departure dates, room number, rate, market segment, source of booking, party size and any linked reservations. On its own that looks harmless. Aggregated across a year it is a travel-pattern dataset — who was where, with whom, and how often — and that is precisely why reservation data is worth stealing rather than merely embarrassing to lose.

Guest profiles outlive reservations in the hotel PMS

The hotel PMS keeps a profile long after the stay ends, because the commercial value of a repeat guest depends on remembering them. Profiles accumulate preferences, complaint history, loyalty identifiers, company affiliation, dietary and accessibility notes and, in far too many estates, free-text comments written by staff who never expected a subject access request.

The folio is where payment data leaks in

Charges, adjustments, payment methods and card tokens sit on the hotel PMS folio. A well-configured hotel PMS stores a token and nothing else. A badly configured one stores a truncated card number in one field, the full number in a note somebody pasted, and an authorisation code that should have been discarded the moment the transaction settled.

Passport and ID scans are the highest-risk attachment

Many properties attach a scan of a passport or driving licence to the profile at check-in. That single file turns a contact-details breach into an identity-theft breach, and it is usually stored with the same permissions as a housekeeping note.

The notes fields are a shadow database

Every hotel PMS has free-text fields, and every hotel PMS user fills them with things that were never meant to be structured data: card details read out over the phone, VIP arrangements, security concerns about a specific guest, allergy and medical information. Nothing in the system classifies them, so nothing protects them differently.

Data class in the PMS	Typical fields	Why an attacker wants it	What sets the retention
Reservation record	Name, dates, room, rate, source, party	Credible phishing with a real booking reference	Contract and tax records
Guest profile	Address, phone, email, preferences, history	Resale, account takeover, social engineering	UK GDPR minimisation
Folio and payment	Charges, tokens, auth codes, refunds	Card fraud and refund abuse	PCI DSS and chargeback windows
Identity documents	Passport or licence scans, numbers	Identity theft, immigration fraud	Immigration (Hotel Records) Order 1972
Free-text notes	Comments, VIP and security notes	Blackmail material, special category data	Nothing — which is the problem
Operational data	Room status, keys issued, in-house list	Physical access to an occupied room	Operational, days not years

Why the hotel PMS is the highest-value system in the building

Hotel PMS security deserves disproportionate attention because the system sits at a genuinely unusual intersection of value, exposure and weak operational control. Four properties of the hotel PMS make it different from a finance system or a file server.

It knows who is in which room tonight

No other system in the estate can answer that question. A stalker, a fraudster or an opportunist with read access to the in-house list has something no amount of encryption elsewhere compensates for. This is the one dataset where a confidentiality failure creates immediate physical risk to a person.

It is the identity source for the rest of the estate

Door locks, EPOS, the guest network, in-room entertainment and the telephone system all take their view of “who is a guest” from the hotel PMS. Compromise the hotel PMS reservation record and you can create a guest who does not exist, issue that guest a key, and post charges to a room that will never be checked.

It is online and it never closes

A hotel PMS is reachable at 04:00 on a bank holiday because reception is staffed at 04:00 on a bank holiday. There is no maintenance window in the sense an office IT team means it, and there is nobody senior awake when something goes wrong. Attackers know both facts.

The people who use it turn over faster than any other workforce

UK hospitality turnover ran at 67% in the 2025 Pineapple and Sona benchmark, down from 75% the year before but far above almost every other sector. An access review that runs annually is reviewing a workforce that has already changed twice, which is why hotel PMS account hygiene decays faster than anywhere else in the business.

Which hotel systems attackers actually target, by share of hotels naming them

Payment and point-of-sale 72%

Guest WiFi 56%

Front desk systems 34%

Source: VikingCloud, Peak Season, Peak Risk: The 2025 State of Hospitality Cyber Report. The same research found 82% of North American hotels suffered a successful attack in summer 2024 and 58% were hit five or more times.

The hotel PMS integration surface

The single biggest misunderstanding in hotel PMS security is treating the hotel PMS as one application. It is a hub. Everything else in the building either reads from it or writes to it, and each of those connections is an authenticated pathway into the guest record.

Eleven hotel PMS interfaces is a normal number, not an unusual one

A mid-market UK property running a modern hotel PMS will typically have live connections to a channel manager, a booking engine, a payment gateway, EPOS, door locks, the guest WiFi or high-speed internet access platform, a revenue management system, a CRM or email marketing tool, an accounting export, a business intelligence feed and a housekeeping application. That is eleven, before anything sector-specific like spa, golf or conference software.

FIAS, IFC8 and the serial-era protocols still in production

Oracle’s own documentation is refreshingly plain about how the legacy layer works. The OPERA Cloud Hotel Property Interface application, IFC8, connects on-premise vendor systems to the property management system using “synchronous TCP/IP or serial connection exchanging messages”, speaking either the universal FIAS specification, XML-POS or a vendor’s own format. The messages it carries include “check-in / check-out notifications”, “charge postings received from vendor systems”, “make door key requests” and “credit card payment requests”.

Read that list again. A protocol family designed in the era of RS-232 is, in 2026, the thing that tells a lock to cut a key and a terminal to take a payment. It typically runs on a flat back-office network segment with no authentication worth the name, which is why interface traffic belongs on its own VLAN — the design our guide to VLAN segmentation for hotel guest WiFi sets out in detail.

Modern APIs move the problem rather than removing it

Cloud platforms replace the serial cable with REST and OAuth 2.0, which is a genuine improvement. It is not a solution. The API key or client credential still exists, it still grants programmatic access to guest data at machine speed, and it is typically issued once by an implementation consultant and never rotated. A stolen interface credential is quieter than a stolen staff password and usually lasts far longer.

Every interface has an account, and most have no owner

Ask who owns the channel manager’s hotel PMS login and you will normally get the name of somebody who left three years ago. Integration accounts are the least reviewed identities in the estate. They rarely have MFA, they frequently hold broad permissions because narrowing them broke something during go-live, and nothing alerts when one starts reading records at four in the morning.

Connected system	Direction	Typical transport	What abuse of it gives an attacker
Channel manager and OTAs	Both ways	REST or XML over TLS	Bulk reservation data and rate manipulation
Booking engine	Inbound	Web application	Direct guest data, often internet-exposed
Payment gateway	Both ways	TLS API, P2PE terminal	Card tokens and refund fraud
EPOS and food and beverage	Inbound postings	XML-POS, TCP/IP	Post charges, read the in-house list
Door lock encoder	Outbound key requests	FIAS over TCP/IP or serial	Cut a key to an occupied room
Guest WiFi and HSIA	Lookup	Vendor API	Name and room-number validation oracle
Revenue management	Outbound extract	Scheduled file or API	Historic booking dataset in bulk
CRM and marketing	Outbound sync	API or nightly export	Full contactable guest list
Back-office and BI	Outbound extract	Report scheduler, SFTP	Everything, in one file, unencrypted
Housekeeping and maintenance apps	Both ways	Mobile app to API	Room status and occupancy in real time

How hotel PMS reservation and guest data actually gets stolen

The value of studying real incidents is that they cut through the abstraction. Six patterns account for almost every published loss of hotel PMS and hospitality guest data, and only one of them involves anything you would call sophisticated.

Pattern one: the back-office platform nobody scoped

Otelier, a cloud back-office platform used by more than 10,000 hotels, disclosed a breach in January 2025. Attackers used credentials stolen by information-stealing malware from an employee to reach the company’s Atlassian server, harvested further credentials from tickets, and used those to reach Amazon S3 buckets. They claimed 7.8TB of data. The dataset contained 39 million reservation rows and 212 million user table entries, resolving to roughly 437,000 unique guest email addresses, with data from Marriott, Hilton, Hyatt and Wyndham properties. Passwords and billing details do not appear to have been taken.

The lesson is scoping. Almost no hotel’s risk register listed its back-office reporting vendor as a hotel PMS adjacent system holding a decade of reservation data. It did.

Pattern two: the reservation web app left open for six months

BWH Hotels, the group behind more than 4,000 properties worldwide, confirmed that an unauthorised third party had access to a reservation system from 14 October 2025 until 22 April 2026 — roughly six months. Exposed data included guest names, email addresses, telephone numbers, home addresses, reservation numbers, dates of stay and special requests. Payment information was not held in that system and was not taken.

Six months of undetected access to a reservation application is not an exotic failure. It is the absence of monitoring on an internet-facing component that everybody assumed the vendor was watching.

Pattern three: an unauthenticated flaw in the hotel PMS itself

Oracle Hospitality OPERA 5 Property Services has now produced three separately disclosed, remotely reachable defects in three years. CVE-2023-21932 allowed attackers to access, update or insert critical data. In January 2026 Oracle patched CVE-2026-21966, a reflected cross-site scripting bypass, and CVE-2026-21967, an unauthenticated server-side request forgery scoring 8.7 that lets an attacker “disclose database credentials, invoke POST requests on arbitrary URLs, and enumerate internal networks”.

In May 2026 CVE-2026-34311 was published: another unauthenticated SSRF, this one carrying a CVSS v3.1 base score of 9.8 critical, affecting OPERA 5 Property Services versions 5.6.19.24, 5.6.22, 5.6.25.19, 5.6.27.6 and 5.6.28. The researchers who found it noted that the vulnerable component was shipped with authorisation explicitly disabled.

No amount of staff training addresses this pattern. Only patching, exposure reduction and network segmentation do.

Pattern four: the help desk that reset the wrong password

MGM Resorts lost roughly $100 million of quarterly earnings to an attack that began with a ten-minute phone call. Attackers identified an employee on LinkedIn, called the IT help desk impersonating them, obtained a credential reset and escalated to administrative control of the identity platform. Room keys stopped working and reservation systems were taken offline.

The NCSC’s May 2025 guidance on retail incidents makes the countermeasure explicit, telling organisations to “review helpdesk password reset processes, including how the helpdesk authenticates staff members credentials before resetting passwords, especially those with escalated privileges”. A hotel group with a 24-hour service desk and a workforce it cannot recognise by voice is exactly the target that advice describes.

Pattern five: the platform account takeover that phishes your guests

Microsoft has tracked Storm-1865 since December 2024 running a campaign that impersonates Booking.com and targets hospitality staff directly. The lure is a negative review, a prospective booking or an account verification notice; the payload is a fake CAPTCHA that instructs the victim to press Win+R and paste a command, delivering XWorm, Lumma, VenomRAT, AsyncRAT, Danabot or NetSupport RAT.

The consequence is measurable in the UK. Action Fraud’s Booking.com alert recorded 532 reports and around £370,000 lost between June 2023 and September 2024, from guests contacted through a hotel’s own platform account after that account was taken over. The hotel’s credentials were the vulnerability; the guest paid for it.

Pattern six: automated exploitation at scale

In June 2026 researchers disclosed a set of intrusions against four accommodation-industry platforms, reportedly automated using a penetration-testing orchestration tool driven by a large language model whose guardrails were bypassed by framing each request as an authorised audit.

The published totals were 6.4 million booking records and 1.1 million unique email addresses from RoomScope in Thailand, around 2 million records from NebulaPMS in South Africa, 31,000 payment records and 49,000 product-purchase records from Staysee in Japan, and 1,400 records from IGMS in Canada including host emails, property addresses and WiFi passwords. NebulaPMS confirmed it had learned of a potential breach in March 2026.

The significance is not the tooling. It is that the cost of finding and exploiting a mid-market hotel PMS estate just fell, which shifts the risk calculation for every independent operator who assumed obscurity was a control.

Incident	When	Root cause	Control that would have mattered
Otelier	Jul–Oct 2024, disclosed Jan 2025	Infostealer credentials into SaaS admin tooling	MFA on supplier platforms, supplier scoping
BWH Hotels	14 Oct 2025 – 22 Apr 2026	Reservation web application access undetected	Monitoring and log review on guest-facing apps
Oracle OPERA CVE-2026-34311	Published 28 May 2026	Unauthenticated SSRF, CVSS 9.8	Patching cadence and internet exposure review
MGM Resorts	September 2023	Help desk social engineering	Identity-proofing on password reset
Storm-1865 / Booking.com	From December 2024	Staff phishing into platform account takeover	Phishing-resistant MFA, ClickFix awareness
Booking-platform set	Disclosed June 2026	Automated exploitation of small platforms	Vendor security assurance before selection

Cloud or on-premise: where hotel PMS responsibility splits

Ask most operators whether their hotel PMS is secure and the answer is “it’s cloud, so the vendor handles it”. That is half true, and the untrue half is where breaches live. The split is not a matter of opinion; it follows the same shared-responsibility logic that the Cyber Essentials scheme applies to hotels, where user access control remains the customer’s job across every cloud model.

What a cloud hotel PMS vendor genuinely does

Infrastructure patching, platform firewalling, database encryption at rest, physical security, backup of the underlying platform and, usually, TLS everywhere. A credible hotel PMS vendor will hold ISO 27001 or a SOC 2 Type II report covering the production service and will let you read it.

What stays yours in every model

Who has an account. What each role can see. Whether MFA is on. Which hotel PMS integrations exist and what they are permitted to do. What lands in free-text fields. How long records are kept. Who reviews the audit log. Not one of those is transferable to a vendor, and every one of them featured in the incidents above.

The on-premise hotel PMS server in the back office

Plenty of UK properties still run a hotel PMS on a server in a cupboard behind reception, often with a Windows version somebody stopped patching when the vendor said an upgrade would cost £14,000. That machine holds the full guest database, is usually on the same flat network as EPOS and the office printer, and frequently has a remote-access tool installed so the vendor can support it. It should be treated as the most sensitive asset in the building, and it rarely is.

Franchise and brand-managed estates

If the brand runs the hotel PMS centrally, your obligations do not disappear — they change shape. You still control local accounts, the local network the interfaces run on, the devices at reception, and the extracts your revenue and marketing teams pull. Get the brand’s statement of what it does and does not cover in writing, and treat everything outside it as yours.

Control	Cloud PMS	On-premise PMS	Brand-managed
Operating system and database patching	Vendor	You	Brand
Application patching and version currency	Vendor, on their schedule	You, with vendor packages	Brand
User accounts, roles and leavers	You	You	You
MFA enforcement	You, if the vendor supports it	You	Shared
Interface and API credentials	You	You	Shared
Network segmentation at the property	You	You	You
Audit log review	You	You	Shared
Retention and deletion decisions	You	You	You
Backup you can restore from	Verify, do not assume	You	Verify

Identity and access control for the hotel PMS

If you fix only one area, fix this one. Every pattern in the incident table except the OPERA vulnerabilities began with an identity failure, and identity is the part of hotel PMS security that costs least to repair.

Kill the shared front desk login on the hotel PMS

One account used by three shifts destroys the audit trail, survives every leaver, and cannot be tied to a person when something goes wrong. The usual objection is licensing, and it is usually wrong: most modern hotel PMS platforms price per property or per room, not per named user, so extra accounts are free. Where the platform genuinely charges per user, the answer is still named accounts — the cost of a licence is trivially less than the cost of not knowing who moved a folio.

Multi-factor authentication on the hotel PMS itself, not only on email

Hotels frequently enforce MFA in Microsoft 365 and stop there, leaving the system holding the guest database protected by a password that three people know. If your vendor supports single sign-on, use it, and inherit the conditional access policies you already pay for — the approach set out in our guide to Microsoft 365 for hotels. If the vendor supports only native MFA, turn it on anyway. If the vendor supports neither in 2026, that belongs on the risk register and in the next contract review.

Roles: what a receptionist genuinely needs

Default hotel PMS role sets are generous because vendors would rather ship permissive than field support calls. A receptionist needs to create and amend reservations, check guests in and out, and take payment. They do not need to run a full guest export, edit historic folios, view every stored document, or change interface configuration. Rebuilding roles around the actual job is a one-day exercise with a decade of benefit.

Night audit, override and comp permissions

The permissions that let someone zero a charge, reopen a closed folio or force a rate override are the ones fraud uses, and they are routinely granted to every duty manager because the night audit needs them. Separate them, log them, and review the hotel PMS exception report weekly. This is the control that catches internal loss long before it catches an intruder.

Leavers, agency staff and the 24-hour rule

With turnover at hospitality levels, the only workable rule is that hotel PMS access is removed within 24 hours of the last shift, not at the next monthly review. Agency and seasonal staff need accounts with an expiry date set at creation. A named owner should receive the account list monthly and be required to confirm it, in writing, against the current rota.

Where the accounts sit in a four-property estate — 144 PMS logins

Named staff users, 118 81.9%

Integration and service accounts, 11 7.6%

Shared front desk logins, 9 6.3%

Administrator accounts, 6 4.2%

Arithmetic on the worked example below: 118 + 11 + 9 + 6 = 144 accounts. The 26 that are shared, privileged or non-human are 18.1% of the total and carry almost all of the risk.

Permission	Receptionist	Duty manager	Revenue and finance	System admin
Create and amend reservations	Yes	Yes	No	Yes
View stored ID documents	At check-in only	Yes	No	Logged
Adjust or void a posted charge	No	Yes, logged	Yes, logged	Logged
Run a full guest export	No	No	Yes, alerted	Yes, alerted
Change interface configuration	No	No	No	Yes
Create or disable user accounts	No	No	No	Yes
Delete a guest profile	No	No	Request only	Yes, logged

Payment data: keeping the hotel PMS out of PCI DSS scope

Card data is the one dataset with a prescriptive external standard attached, and hospitality has an unusually awkward relationship with it because of card-on-file guarantees, no-show charges and deposits taken months ahead.

Tokenisation keeps card data out of the hotel PMS

The goal is that the hotel PMS never sees a primary account number at all. A point-to-point encryption solution encrypts the card at the terminal, and the gateway returns a token the property management system stores against the folio. Done properly, the reservation platform holds a reference that is worthless if stolen, and PCI DSS scope contracts to the terminals and the network path around them.

Card numbers in free-text fields undo all of it

The most common PCI failure in hospitality is not architectural, it is behavioural: a card number typed into a reservation comment because a guest read it out over the phone. Every one of those turns an out-of-scope hotel PMS back into a cardholder data environment. Search the notes fields for long digit strings, do it as a scheduled job, and give reception a compliant way to take a phone payment so the shortcut stops being necessary.

The requirements that actually bite a property management system

PCI DSS v4.0.1 was published in June 2024 and its 51 future-dated requirements became effective on 31 March 2025, so there is no grace period left to plan against. Several land squarely on the hotel PMS and its supporting estate.

Requirement	What it says	What it means at the front desk
3.3.1	Sensitive authentication data is not retained after authorisation	No CVV in a note, ever, even for a guarantee
3.5.1	PAN is rendered unreadable wherever it is stored	Tokens on the folio, not truncated numbers plus a note
6.3.3	Critical security patches installed within one month	A maintenance window that survives a full hotel
8.3.6	Minimum password length of 12 characters	The four-digit clerk code is finished
8.4.2	MFA for all access into the cardholder data environment	Not just admins, and not just from outside
10.5.1	Audit history retained 12 months, 3 immediately available	PMS logs exported, not left to roll over
11.3.1	Internal vulnerability scans at least every three months	Includes the back-office server behind reception
12.8.1–12.8.5	Third-party service providers managed and monitored	A written list of every integration and who owns it

Third-party service provider management is the clause hotels ignore

Requirement 12.8 asks for a maintained list of hotel PMS service providers, written agreements acknowledging their responsibility for cardholder data, due diligence before engagement, and a programme that monitors their compliance. In hotel PMS terms that means an actual register of the eleven integrations, with an owner and a review date against each. Almost nobody has one, and building it takes an afternoon.

Patching a hotel PMS you did not write

Hotel PMS patching is where hospitality diverges hardest from standard security advice, because the maintenance window a patch needs does not exist in a building that is full every night.

Hotel PMS patch cycles and the maintenance window problem

Oracle ships quarterly critical patch updates, and the OPERA defects above were fixed in those cycles. A patch is only protective once it is applied, and the gap between publication and application is when the risk is highest — CVE-2026-34311 was public knowledge with a CVSS of 9.8 from 28 May 2026, and every unpatched instance after that date was a known target. Agree the window in advance: a fixed quarterly slot at the lowest-occupancy hour, communicated to operations three months ahead, beats an argument every quarter.

“We are on a supported version” needs evidence

Ask the vendor for the exact hotel PMS version and build you are running, the current supported version, and the date support for yours ends. Get it in writing annually. Plenty of properties discover during an incident that the “supported” platform stopped receiving security fixes two releases ago.

Compensating controls when you genuinely cannot patch

Sometimes the upgrade is blocked by an interface that will not work on the new release. That is a legitimate operational constraint and a poor security answer on its own. The compensating set is restricting network reachability to the interface hosts only, putting the server on its own segment, removing internet exposure entirely, adding authenticated vulnerability scanning, and setting a dated plan to remove the blocker. Write it down and review it quarterly rather than letting it become permanent.

Nothing about the PMS should face the internet by accident

Reservation web applications, remote-support tools and interface listeners have a habit of ending up on a public IP because it was the fastest way to make something work in 2019. Run an external scan of your own address ranges, and check what a service such as the CISA known-exploited-vulnerabilities catalogue lists for the products you find. The Trustwave hospitality scan is a useful calibration point: 61.5% of initial access attempts it observed targeted publicly exposed services.

Hotel PMS retention: reservation and guest data under UK law

Retention is the hotel PMS control that reduces breach impact without touching a firewall, and it is the one hotel PMS owners most often defer, because the legal position genuinely does pull in two directions.

The Immigration (Hotel Records) Order 1972 sets a floor

Under the 1972 Order, keepers of premises providing lodging for reward must record the full name and nationality of every guest aged 16 or over. For guests who are not UK or Irish nationals the record must also capture the number and place of issue of their passport or identity document, and their next destination. The Order requires those records to be kept for a period of at least 12 months and made available to a constable or an authorised person on request.

UK GDPR sets a ceiling

The storage limitation principle says personal data is kept no longer than is necessary for the purpose. Marketing preferences, complaint histories and a decade of stay records are not covered by the 1972 Order, and keeping them because the hotel PMS never forced a choice is not a lawful basis. The Information Commissioner’s Office expects a documented retention schedule, and it expects deletion to actually happen.

A retention schedule that survives both

The workable answer is layered: identity-document data retained for the statutory minimum and then deleted; full reservation detail retained for a defined operational and tax window; guest profiles retained only where there is a live commercial relationship or consent; free-text notes purged aggressively because almost nothing in them has a defensible purpose after departure.

What deletion means when hotel PMS data sits in six systems

This is the part that catches people out. Deleting a guest profile in the hotel PMS itself does not remove them from the CRM, the marketing platform, the revenue management extract, last month’s BI file on a shared drive, or the vendor’s backups. A deletion process that only touches the primary system is not a deletion process. Map where each extract goes — the register you built for requirement 12.8 doubles as the map — and make deletion a defined step in each.

Consider the arithmetic for the four-property group used throughout this article. With 270 bedrooms and 365 nights, the estate has 98,550 available room nights a year; at 70% occupancy it sells 68,985 of them. At an average stay of 1.9 nights that is roughly 36,308 reservations a year. Held for seven years by default, the live dataset is about 254,156 reservation records. Cut full detail to 24 months and it falls to 72,616 — a 71% reduction in the volume of guest data any single credential can reach, achieved with a policy document rather than a product.

Monitoring and audit for the hotel PMS

BWH Hotels had an intruder in a reservation system for six months. Otelier’s attackers had access from July to October. The common factor is not a missing control at the perimeter; it is that nobody was reading anything.

The five hotel PMS events worth alerting on

You do not need a security operations centre to get value from hotel PMS logging. Alert on a bulk export or report run outside business hours; a new user or role created; MFA disabled or reset for any account; an integration credential used from a new address; and repeated failed logins against an administrative account. Five rules cover the overwhelming majority of published hospitality incidents.

Bulk export is the single most valuable signal

Every large hospitality data loss ends with a lot of records leaving at once. A receptionist does not run a 40,000-row guest extract. A revenue analyst does it monthly and can tell you when. That makes it a rare thing in security: a high-signal, low-noise alert that a small team can genuinely act on. Wire it up first.

Log retention has to outlive the discovery gap

If your hotel PMS retains only 30 days of audit history, a six-month intrusion is undetectable and, worse, uninvestigable. Export logs to somewhere you control, keep 12 months with three months immediately searchable — the PCI DSS position, and a sensible baseline whether or not you take cards. Our monitoring and threat intelligence services exist for operators who have no appetite to build this themselves.

Who reads them at 03:00

Nobody at the property, which is the honest answer and the reason to route alerts to a managed service rather than an inbox. Whoever receives them needs a defined path to somebody who can disable an account at three in the morning, and the duty manager needs to know how to reach them. That is an incident response question, not a tooling question.

Backups and the day the hotel PMS is not there

Availability is a hotel PMS security property too, and it is the one guests notice within minutes. Plan for the platform being unavailable, whether the cause is ransomware, a vendor outage or a fibre cut.

The vendor’s backup is not your backup until you have restored from it

Ask what the recovery point and recovery time objectives are contractually, not aspirationally. Ask when the vendor last performed a restore test and whether you may see the result. If you run the hotel PMS on-premise, hold an offline copy — the NCSC’s guidance on offline backups exists precisely because online-only copies get encrypted alongside everything else.

The offline arrivals pack

Every property should print or export from the hotel PMS, daily, the next 48 hours of arrivals with names, room allocations and rates, plus the current in-house list. It costs nothing, it lives in a drawer at reception, and it is the difference between checking guests in slowly and turning them away. MGM’s guests found their room keys had stopped working; the properties that coped were the ones with a manual fallback.

Manual check-in without touching card data

Write the procedure before you need it: how to allocate a room, how to cut a key when the encoder cannot reach the PMS, how to take a payment through the standalone terminal, and where the paper records go afterwards so they get keyed in and then securely destroyed. Rehearse it once a year with the night team.

Recovery time that reflects a hotel, not an office

A finance system can be down until Monday. A hotel PMS cannot. A property management system cannot be down through an evening arrivals peak. Set the recovery time objective against the 16:00 to 21:00 window and test whether your vendor’s contract actually supports it, because most standard service levels are written for offices.

Choosing and challenging a hotel PMS vendor

The most consequential hotel PMS security decision is which platform you buy, and it is usually made on commission handling and channel connectivity. Ask the security questions during procurement, when you still have leverage.

Twelve hotel PMS questions to send before you sign

Which certifications does the production service hold, and may we read the report? Do you support single sign-on and MFA, and at what cost?

How are interface credentials issued, scoped and rotated? What audit events do you log, and for how long? Can we export our own logs? What are the contractual RPO and RTO? How and when do you notify us of a security incident? What is your patching cadence and current supported version?

Where is our data hosted and processed? Which sub-processors touch guest data? How do we get a full data export on exit? What happens to our data after termination?

Certifications tell you something, but not everything

ISO 27001 and SOC 2 Type II tell you a hotel PMS vendor has a management system and that it was tested. Neither tells you whether the reservation web application has been penetration tested this year, or whether the version you are running is current. Ask for the scope statement — a certificate covering the corporate office and not the production platform is not unheard of.

Contract clauses worth insisting on

Incident notification within a defined number of hours. A right to audit or, more realistically, a right to receive the annual assessment. Sub-processor change notification. Data export in a documented format at any time. Deletion on termination with written confirmation. These are the same terms our guidance on vendor management applies to any supplier holding your data, and hospitality has no reason to be an exception.

Exit and portability decide your real leverage

If extracting your hotel PMS guest history requires a bespoke professional-services engagement, you cannot credibly threaten to leave, and a vendor that knows that has little incentive to improve. Test the export in year one, not in year seven.

What hotel PMS security costs: a worked example

Abstract advice is easy to nod at and hard to budget for, so here is a fully costed example for a plausible UK independent group. Every figure below is either a stated assumption or arithmetic on one.

The estate

Four properties of 92, 74, 58 and 46 bedrooms — 270 bedrooms in total. Reception is staffed 24 hours at the two larger properties and 06:00 to 23:00 at the smaller two. One cloud hotel PMS shared across the group, plus one payment gateway and one channel manager.

The hotel PMS account and interface inventory

118 named staff users, 9 shared front desk logins, 6 administrator accounts and 11 integration or service accounts: 144 accounts in total. The 26 that are shared, privileged or non-human are 18.1% of the estate and account for almost all of the meaningful risk. There are 11 live interfaces, of which 4 touch cardholder data or tokens and 3 can write to the guest record.

The bill

Line	Basis	One-off	Annual
Role and permission rebuild	2 consultancy days at £750	£1,500	—
SSO and MFA integration with the PMS	Vendor setup fee	£1,200	—
Vendor due diligence and contract review	Fixed fee	£1,800	—
P2PE terminals	12 terminals at £22 a month	—	£3,168
Annual penetration test, PMS scope	Fixed scope	—	£4,500
Managed log monitoring uplift	£480 a month	—	£5,760
Total	—	£4,500	£13,428

Year one is £4,500 plus £13,428, or £17,928 — £66.40 per bedroom. From year two the run rate is £13,428, or £49.73 per bedroom. For comparison, the same four-property group would spend a similar order of magnitude on tenant licensing and hardening, so a defensible hotel PMS security position is not a doubling of the IT budget; it is a line item.

Where the £17,928 goes in year one

Managed log monitoring, £5,760 32.1%

Penetration test, £4,500 25.1%

One-off project work, £4,500 25.1%

P2PE terminals, £3,168 17.7%

Arithmetic on the table above: £5,760 + £4,500 + £4,500 + £3,168 = £17,928. Two thirds of year one is recurring assurance rather than project spend.

A 90-day hotel PMS hardening plan

Twenty-one hotel PMS controls, sequenced so that the cheapest and most protective work happens first. Nothing here requires a new platform.

Days 1 to 30: know what you have and close the identity gaps

Export the full account list and identify every shared, dormant and administrative login. Remove leavers. Name an owner for each of the eleven interfaces. Turn on MFA for administrators. Search free-text fields for card numbers. Confirm the hotel PMS version and its support status in writing. Print the first offline arrivals pack. Agree who receives a security alert at 03:00. That is eight controls, and seven of them cost nothing but time.

Days 31 to 60: reduce what each credential can reach

Replace shared front desk logins with named accounts. Rebuild roles around actual jobs. Extend MFA to all users, ideally through single sign-on. Rotate every interface credential and scope it down. Enable the five alerts. Export audit logs to storage you control. Confirm the retention schedule and get it approved. That takes the running total to fifteen.

Days 61 to 90: prove it and make it repeatable

Run an external exposure scan and remove anything reachable that should not be. Book the PMS-scoped penetration test. Complete the vendor questionnaire and record the answers. Test a restore. Rehearse manual check-in with the night team. Set the quarterly patch window for the next twelve months. Twenty-one controls, complete.

Cumulative progress across the 90-day plan, 21 controls

Day 30 — 8 of 21 complete 38%

Day 60 — 15 of 21 complete 71%

Day 90 — 21 of 21 complete 100%

Arithmetic on the plan above: 8 ÷ 21 = 38%, 15 ÷ 21 = 71%. Fifteen of the twenty-one controls are configuration and process changes with no licence cost attached.

Hotel PMS cyber security: frequently asked questions

Is a cloud hotel PMS safer than an on-premise one?

Usually, but not automatically. A cloud hotel PMS removes operating-system patching and physical security from your list and gives you a vendor with a full-time security team. It does not remove account management, role design, interface credentials, retention or log review, and those are where the published breaches happened. The realistic answer is that cloud is safer for the layers you were not managing well and identical for the layers you still own.

Does a hotel need Cyber Essentials if the PMS is the vendor’s problem?

Certification looks at the devices and hotel PMS accounts you control, which includes every reception PC, kiosk and administrative login attached to the platform. Cloud services cannot be excluded from scope, so a hotel PMS in the cloud is assessed on how you configure and access it. Our Cyber Essentials guide for hotels walks through the scoping in detail.

How long should we keep reservation records?

Long enough for the statutory 12-month immigration record and your tax and contractual obligations, and no longer for everything else. Most groups land on 12 months for identity-document data, somewhere between two and seven years for financial records, and a much shorter window for marketing profiles and free-text notes. Write it down and automate it, because a retention policy that relies on somebody remembering is not a control.

What is the single highest-value change for a small independent hotel?

Removing the shared front desk login from the hotel PMS and turning on MFA. Together they take an hour of configuration, cost nothing on most platforms, and defeat the credential theft and reuse that starts the majority of hospitality incidents. Nothing else in this article has that return.

Should the guest WiFi be able to reach the PMS?

No. A guest device should never be able to reach the hotel PMS, and it is worth checking rather than assuming. Guest networks, the interface network and the back-office network belong in separate segments with only defined flows between them, which is also what keeps guest WiFi out of your cardholder scope. Our guides to hotel WiFi security and captive portal attacks cover the wireless side of the same estate.

Who should own hotel PMS security in a group with no IT team?

One named person at head office, supported by a provider. It does not have to be a security specialist, and in practice it is often the operations director. What matters is that a single person receives the monthly account list, owns the interface register and is accountable for the patch window. Where there is no internal candidate, managed IT services or a sector-specific IT support for hotels and hospitality arrangement is the usual answer, and it is how most independents fold the platform into a wider cybersecurity programme without hiring.