Home / The Long Read / Research
Long Read

Third-Party Risk for Hotels and Short-Term Rentals: The OTA, PMS and Payment Stack

A hotel's largest cyber exposure now lives in a handful of platforms it does not run. How the OTA, PMS, channel manager, payment and lock stack is built, where it breaks, who is liable when it does, and what a property with no security team can do about it.

Third-Party Risk for Hotels and Short-Term Rentals: The OTA, PMS and Payment Stack
TL;DR

A hotel's largest cyber exposure now lives in a handful of platforms it does not run. How the OTA, PMS, channel manager, payment and lock stack is built, where it breaks, who is liable when it does, and what a property with no security team can do about it.

A hotel's largest cyber exposure now lives in a handful of platforms it does not run. Here is how the stack is built, where it breaks, who is liable when it does, and what a property with no security team can actually do about it.

A hotel's biggest cyber risk is concentrated in vendors it does not control, so the incidents that cause the most damage arrive through a third or fourth party rather than through the hotel's own systems. The typical independent property signs contracts with roughly a dozen vendors and then depends on the security of about forty, because each of those vendors runs vendors of its own. The distribution layer alone has become so concentrated that a single set of stolen extranet credentials can reach most of a property's online revenue, and the worst incidents of the last decade, from the Sabre SynXis breach to the Booking.com extranet fraud wave to the CrowdStrike outage, never touched the hotel's own network at all. A third-party risk programme that stops at each vendor's front door therefore misses almost all of the real exposure.

The numbers that define the risk

  • Booking Holdings holds 68.8% of European OTA bookings and Expedia Group 16.6%, for 85.4% combined (HOTREC European Hotel Distribution Study 2026).
  • OTAs generate 29.9% of European hotel overnights, up from 19.7% in 2013, with direct channels at 51.3% (HOTREC 2026).
  • In Switzerland, Booking.com alone accounts for more than 70% of online bookings for surveyed properties (hotelleriesuisse / HES-SO, May 2026).
  • The European OTA market scores roughly 5,000 on the Herfindahl-Hirschman Index, about twice the level regulators call highly concentrated (our own calculation from HOTREC shares).
  • 66% of European hotels use a channel manager, and SiteMinder alone connects more than 50,000 properties (HOTREC 2026; SiteMinder FY25 investor presentation).
  • The Sabre SynXis breach exposed data on about 1.3 million credit cards across roughly 36,000 properties on the system (Connecticut Attorney General; Sabre 10-K).
  • The July 2024 CrowdStrike update crashed 8.5 million Windows devices, which Microsoft put at less than 1% of all Windows machines.
  • The Unsaflok lock flaws affected more than 3 million locks across about 13,000 properties in 131 countries, and only about 36% were fixed a year after remediation began (unsaflok.com).

How concentrated is the hotel distribution market?

The European OTA market is effectively a two-firm market, and a property's cyber exposure is concentrated in exactly the same way its revenue is. HOTREC's 2026 study of 2,713 hotels puts Booking Holdings at 68.8% of OTA bookings and Expedia Group at 16.6%, and among chain hotels those two reach almost 94%. On our own calculation from those shares, the market scores around 5,000 on the Herfindahl-Hirschman Index, roughly double the level US regulators call highly concentrated. Switzerland sharpens the pattern further, since hotelleriesuisse and HES-SO reported in May 2026 that Booking.com alone accounts for more than 70% of online bookings for the properties they surveyed. The practical meaning is direct: when one platform holds most of your online bookings, one compromised extranet account, one API outage or one unilateral term change lands on most of your business at once, and you have no leverage to negotiate the security terms of a supplier that large.

What is in a hotel's third-party stack?

A hotel's stack is a chain of platforms that jointly decide whether a guest can book, pay and physically get into a room, and each layer fails in its own way through a third party. The table maps the layers, what each holds, and its main third-party failure mode. The vendors are examples of the market, not a ranking.

[@portabletext/react] Unknown block type "htmlBlock", specify a component for it in the `components.types` prop

An independent property, and HOTREC's sample runs to a median of 39 rooms with 74% independent, typically operates ten to twenty of these with no security staff. A short-term-rental manager swaps in a Guesty or Hostaway, adds dynamic pricing and smart locks, and ends up with a stack where the OTA listing, the PMS and the lock vendor together control whether a paying guest gets through the door.

Where do the worst losses come from?

The most damaging hotel breaches come from a vendor's vendor, the fourth party guests and hotels never see. The Sabre SynXis breach is the archetype. According to Sabre's 10-K, an attacker obtained account credentials for the SynXis central reservation system, and although Sabre encrypted card data, the stolen credential had the right to read it unencrypted. The attacker had access from August 2016 to March 2017, and the Connecticut Attorney General states the breach exposed the data of about 1.3 million credit cards across brands including Four Seasons, Kimpton and Loews. A multistate settlement cost Sabre 2.4 million dollars and forced its contracts to specify each party's breach responsibilities. The lesson is the whole point of this article, since guests who booked through OTAs, at luxury brands, lost card data through a reservation system they had never heard of, and the consumer notifications fell on the hotels.

The current version of the same pattern is the Booking.com extranet fraud wave, and it is now industrialised. Microsoft has tracked the group it calls Storm-1865 impersonating Booking.com to hotel staff since late 2024, using fake-review and verification lures that push staff to run malicious commands, which then drop credential-stealing malware. Sekoia's 2025 "I Paid Twice" reporting documents the follow-through, where stolen extranet credentials let criminals contact guests through email or WhatsApp with genuine reservation details and push them to fake payment pages, so a guest ends up paying once at the hotel and once to the attacker. In April 2026 Booking.com notified guests that unauthorised third parties may have been able to access certain booking information, reset reservation PINs, and stated that its own financial systems were not accessed. Booking.com has not confirmed the root cause, and attributing it to compromised hotel partners is an analyst inference rather than a company statement, but the chain is instructive either way, since a front-desk click becomes an extranet compromise, becomes a guest's financial loss, becomes the platform's breach notice, and lands on the property's reputation, with none of the failed controls sitting inside the hotel's contract with that guest.

What happens when a vendor simply stops?

Availability is a third-party risk exactly as much as confidentiality, and a single vendor failure can halt check-in, payments and room access across thousands of properties at once. On 19 July 2024 a faulty CrowdStrike sensor update crashed 8.5 million Windows devices, which Microsoft characterised as less than one percent of all Windows machines, and it stopped operations at major chains. Marriott said it was working with vendors to resolve the impact, a Hilton resort unlocked rooms manually, and some properties photocopied cards to take payment. The hotels had done nothing wrong, a vendor their IT provider had chosen simply failed. The Unsaflok disclosure of March 2024 shows the same coordination problem in physical form, since vulnerabilities in dormakaba Saflok systems let an attacker forge a keycard that opens any door in a property, affecting more than three million locks across roughly 13,000 properties in 131 countries, and only about 36% were fixed a year after the work began because remediation needs lock updates, reissued cards and upgraded encoder software rather than a single patch.

Do the rules now put third-party risk on the hotel?

Yes, and payments are the clearest lever, because PCI DSS Requirement 12.8 already binds every card-accepting hotel to a formal third-party risk process. PCI DSS v4.0.1 is the only active version, and its future-dated requirements became mandatory on 31 March 2025. Requirement 12.8 demands an inventory of service providers, written acknowledgements of responsibility, due diligence, at least annual monitoring and a documented split of responsibilities, which is a ready-made third-party risk mandate. The payment-page controls in 6.4.3 and 11.6.1 exist because of booking-engine script injection, and the requirement for strong cryptography over public networks rules out the common habit of receiving OTA virtual-card details by plain email.

In Switzerland the revised data protection law adds a personal dimension for managers, since the controller must satisfy itself that a processor can guarantee data security under Article 9, processors must notify controllers of breaches as quickly as possible under Article 24, and Article 61 allows fines of up to 250,000 Swiss francs on individuals for wilful breaches, including handing processing to a provider without meeting the Article 9 duty. For short-term-rental managers, EU Regulation 2024/1028 applies from 20 May 2026 and turns listing-data accuracy across the PMS, channel manager and OTA chain into a compliance dependency, since platforms must verify registration numbers and report activity data to national systems. Hotels are not a named NIS2 sector, but the directive still reaches them through supply-chain clauses that flow down from in-scope OTAs, cloud providers and managed service providers, so the obligation arrives through the contract rather than the sector list.

The newest vendor in the stack: AI booking assistants

AI booking assistants are the newest third party in the hotel stack, and they are the only one no property has signed a contract with, risk-assessed or entered in a vendor register. Guests increasingly open ChatGPT, Gemini or Google's AI answers to ask where to stay, and those systems now sit between the property and the guest in the same structural position an OTA occupies, except without data-processing terms, a breach-notification clause, a responsibility matrix or any reliable way to correct what they say about you, which is the working definition of an unvetted third party. For a third-party risk team the first job is simply to name it as a party, because a stack that already contains the OTA, the channel manager and the lock vendor now contains a discovery intermediary that none of the standard due-diligence questions were written for.

The exposure runs in two directions. On the risk side, these same assistants are already being impersonated in the phishing waves described earlier, and any AI concierge or chat tool a property bolts on becomes one more integration holding guest conversations and, usually, one more subprocessor to map. On the commercial side, the assistant increasingly decides whether the property is surfaced at all, which turns AI visibility into an operational dependency rather than a marketing nicety. A property that is invisible to the channel its guests now use has a distribution problem that no OTA contract will fix.

A third-party risk framework for properties with no security team

The programme does not need to be heavy, it needs to be about concentration. Inventory every vendor that touches guest data, payments, pricing or physical access, then tier them, putting the OTAs, PMS, channel manager, booking engine, payment processor and locks in Tier 1. For each Tier 1 vendor, record what it holds, how it integrates, which credentials it uses, its subprocessors and its hosting region, because the fourth party you cannot see is usually the one that takes you down.

Then map the concentration rather than just the list. For each critical function note the share of revenue that depends on it and the fourth parties it relies on, and flag any cloud, payment or endpoint provider that several of your Tier 1 vendors quietly share, since a property whose OTA revenue sits at 70% Booking.com and whose PMS, channel manager and booking engine share one cloud region is highly concentrated even if every vendor holds ISO 27001. Push the due-diligence questions that actually matter, meaning enforced MFA and per-user roles on every extranet, ISO 27001 scope and SOC 2 reports from the PMS and channel manager, a PCI attestation and a 12.8.5 responsibility matrix from payments, and a move away from legacy card technology on the locks. Where terms cannot be negotiated, as with the OTAs, document the gap and compensate with your own controls. Finally, rehearse the failures that will actually happen, meaning an extranet account takeover, a PMS or channel-manager outage that forces nightly printed arrival lists and a manual key procedure, and an endpoint outage that is survivable only if at least one front-desk device runs a different agent or OS. Anchor all of it to ISO/IEC 27001:2022's supplier-relationship controls and PCI DSS 12.8, and test it at least once a year.

The lesson every incident here repeats is the same one third-party risk teams meet in every other sector: the hotel stays accountable for data and continuity it does not physically control, so the unit to manage is not the vendor list but the concentration inside it. Map the stack, tier it, find the fourth parties your critical vendors share, and treat every new intermediary, the AI ones included, as a party to assess before it becomes the way in.

FAQ

What is third-party risk for hotels?

Third-party risk for hotels is the exposure created by the outside platforms a property depends on to operate, including OTAs, the property management system, the channel manager, payment processors and smart-lock vendors. The hotel remains legally accountable for guest data and continuity even though these vendors, and the vendors those vendors use, physically control most of it. The dominant loss pattern is a breach or outage that starts at one of these suppliers and flows downstream to the property and its guests.

Is Booking.com a security risk for hotels?

Booking.com is a concentration point rather than an insecure platform, because it holds 68.8% of European OTA bookings, so a single compromised hotel extranet account can expose a large share of a property's guest data. Since late 2024 the group Microsoft tracks as Storm-1865 has run phishing campaigns that impersonate Booking.com to hotel staff and harvest extranet credentials, which criminals then use to defraud guests directly. The platform itself is not usually the breached party, the hotel's own extranet login is the entry point.

What happens to a hotel if its PMS or channel manager goes down?

A property management system or channel-manager outage can stop check-in, key encoding, rate updates and reservation sync at the same time, because those functions all route through one vendor. The July 2024 CrowdStrike incident showed the scale of it, halting operations at major chains and forcing manual room unlocking and photocopied card payments. The mitigation is operational rather than technical, meaning nightly printed arrival and departure lists, a manual key procedure and an offline payment fallback.

Who is liable when a hotel's vendor is breached?

The hotel usually stays liable, because data-protection law makes the controller accountable for its processors. Under Switzerland's revised FADP, Article 9 requires the controller to satisfy itself that a processor can guarantee data security, and Article 61 allows fines of up to 250,000 Swiss francs on individuals for outsourcing without meeting that duty. Under GDPR, Article 28 governs processor contracts and the controller carries the 72-hour breach-notification obligation, so a vendor's breach becomes the hotel's disclosure.

Does PCI DSS apply to small independent hotels?

Yes, PCI DSS applies to any hotel that accepts card payments, regardless of size, and Requirement 12.8 specifically mandates a third-party risk process. That means an inventory of payment-related service providers, written responsibility acknowledgements, due diligence, at least annual monitoring and a documented responsibility matrix. PCI DSS v4.0.1 has been the only active version since v4.0 retired at the end of 2024, with its future-dated requirements mandatory from 31 March 2025.

What was the Sabre SynXis breach and why does it matter?

The Sabre SynXis breach exposed data on about 1.3 million credit cards between August 2016 and March 2017, after an attacker obtained credentials for the central reservation system that could read card data unencrypted. It affected roughly 36,000 properties and luxury brands including Four Seasons and Kimpton, and it cost Sabre a 2.4 million dollar multistate settlement. It matters as the archetypal fourth-party case, since guests lost data through a reservation system they had never heard of and the notifications fell on the hotels.

Are smart hotel locks secure?

Smart locks are a third-party risk like any other vendor, as the Unsaflok disclosure showed in March 2024 when researchers found flaws in dormakaba Saflok systems that let an attacker forge a keycard opening any door in a property. The flaws affected more than three million locks across about 13,000 properties in 131 countries, and only about 36% had been fixed a year after remediation began. The slow fix is because remediation requires lock updates, reissued keycards and upgraded encoder software, making it a multi-vendor project rather than a patch.

Are AI booking assistants a third-party risk for hotels?

AI booking assistants such as ChatGPT and Gemini are an emerging third party that most hotels have never risk-assessed, even though they increasingly sit between the property and the guest. They introduce both a security dimension, since they are impersonated in phishing campaigns and any AI concierge tool adds a subprocessor holding guest conversations, and a commercial dimension, since they influence whether a property is recommended at all. A third-party risk team should name the AI layer as a party in the vendor inventory rather than leaving it uncontracted and unmapped.

How do AI assistants decide which hotels to recommend?

AI assistants decompose a traveller's question into many sub-queries, retrieve a passage per sub-query from the sources they trust, and recommend the properties that are described clearly and consistently across the web rather than the ones that simply rank first in traditional search. This means a hotel can be highly visible on Google and still be absent from an AI recommendation if its information is thin, inconsistent or missing from the sources these systems draw on. The mechanics of how AI assistants choose which hotels to recommend are becoming an operational dependency for properties, because a hotel invisible to the channel its guests now use has a distribution problem no OTA contract will fix.

Is ChatGPT a third party a hotel must consider under GDPR?

When a hotel deliberately integrates an AI tool that processes guest data, such as an AI concierge or chat assistant, that provider is a processor or subprocessor and belongs in the GDPR Article 28 chain like any other vendor. When guests use a public assistant on their own to research a property, the hotel has no contractual relationship with it, which is precisely the gap, since the assistant shapes bookings and represents the property while sitting outside every control the hotel has. Either way, the AI layer needs to be identified and assessed rather than ignored.

How concentrated is the hotel OTA market?

The European hotel OTA market is highly concentrated, with Booking Holdings at 68.8% and Expedia Group at 16.6% of OTA bookings, for 85.4% combined, according to HOTREC's 2026 study. On a Herfindahl-Hirschman Index calculation from those shares, the market scores around 5,000, roughly twice the 2,500 threshold regulators treat as highly concentrated. In Switzerland the concentration is greater still, with Booking.com alone above 70% of online bookings for surveyed properties.

How can a small hotel with no security team manage vendor risk?

A small hotel manages vendor risk by focusing on concentration rather than trying to audit every supplier, since it has no leverage over a platform that holds most of its bookings. The practical steps are to inventory and tier every vendor that touches guest data, payments, pricing or physical access, map which cloud, payment or endpoint providers several critical vendors quietly share, enforce MFA and per-user roles on every extranet, and rehearse the outages and account takeovers that will actually happen. Anchoring the programme to ISO/IEC 27001:2022 supplier-relationship controls and PCI DSS Requirement 12.8 keeps it defensible without needing a security team.

What to do next

Want this applied to your supplier ecosystem? See the platform in action and map your top vendor risks live in one walkthrough.

Read next

AI-native GRC in 2026: who was born with AI, who added it, and what the assistant does with your compliance data

AI-native GRC in 2026: who was born with AI, who added it, and what the assistant does with your compliance data

An origin-based definition of AI-native GRC, applied to everyone. Four platforms scored on eight architecture criteria and six disclosure facts, plus the nine vendors in the wider market that pass the origin test.

Read article →
GRC software in Switzerland 2026: a due diligence brief for regulated buyers

GRC software in Switzerland 2026: a due diligence brief for regulated buyers

A buyer's brief on the Swiss GRC market rather than a feature list. What the Swiss regulatory frame actually demands, which of the three domestic generalists automates the programme instead of administering it, and the eight facts twelve vendors are willing to publish before an NDA.

Read article →
ChainDrop npm worm hits 400-plus packages: one stolen login becomes a self-spreading supply-chain attack

ChainDrop npm worm hits 400-plus packages: one stolen login becomes a self-spreading supply-chain attack

A self-propagating worm named ChainDrop infected more than 400 npm packages, including keyv, flat-cache and cache-manager, Microsoft reported on 4 August 2026. The malware steals developer and cloud credentials, then uses stolen publishing tokens to poison further packages on its own. For third-party risk teams, it is a fourth-party exposure most vendor registers never capture.

Read article →
Hotel Third-Party Risk: The OTA, PMS and Payment Stack | Supplier Shield