Most property operators can tell you exactly which platforms they use. They know their PMS, their channel manager, their dynamic pricing tool, their guest messaging app. What they often cannot tell you is what those platforms are built on top of, who processes data on their behalf, or how many invisible hands touch a guest’s personal information between the moment of booking and checkout.
That gap between what operators know and what’s actually happening inside their tech stack is not a minor oversight. It is, increasingly, the primary attack surface in hospitality.
The Stack Beneath the Stack
When a guest books a stay, their data moves. It flows through booking engines, into property management systems, across channel managers, through payment processors, into ID verification tools, and often into a dozen other micro-services that operators never directly chose or evaluated. Each of those connections represents a dependency. Each dependency is a potential point of failure.
This is what security professionals call the software supply chain, and it has become the defining vulnerability of the modern SaaS era. The Verizon 2025 Data Breach Investigations Report found that third-party involvement in breaches doubled in a single year, jumping from 15% to 30% of all incidents. That is not a trend line, that is an acceleration, and hospitality is not just caught in that trend, it is leading it.
SecurityScorecard’s 2025 Global Third-Party Breach Report found that 52.4% of all breaches in retail and hospitality originated from third-party compromises, the only industry where the majority of breaches came through vendors rather than direct attacks. The industry ranked second in absolute number of third-party breaches, despite ranking fifth in overall breach volume. That disparity tells you something important: hospitality is not being attacked more than other industries, it is being attacked more effectively through its vendors.
Why Hospitality Is a Target Worth Mapping
The data hospitality businesses hold is not incidental. It is extraordinarily rich. Guest profiles contain full names, passport numbers, home addresses, payment card data, travel itineraries, and behavioral patterns. As NexusTek notes, hospitality operations generate “a rich data set attackers covet,” one that combines financial, identity, and behavioral intelligence in a single record.
That richness makes every vendor in the hospitality tech stack a high-value target by association. An attacker who cannot breach a major hotel brand directly can instead compromise a smaller SaaS vendor that processes data for hundreds of properties. The blast radius of a single vendor breach has grown dramatically: Black Kite’s analysis of 2025 breach data found that every vendor breach now compromises an average of 5.28 downstream companies, the highest multiplier ever recorded, with an estimated 26,000 “shadow victims” impacted but never publicly disclosed.
The attack surface is no longer your platform. It is every platform your platform depends on.
This is the core problem with how most operators think about security. They evaluate the front door. They rarely inspect the loading dock.
The Otelier Breach: A Case Study in Invisible Risk
In mid-2024, a cloud-based hotel management platform called Otelier suffered a breach that exposed 39 million reservation records from major hotel brands including Marriott, Hilton, and Hyatt. The exposed data included guest names, physical addresses, phone numbers, booking details, and partial payment card information.
The entry point was not a sophisticated zero-day exploit. It was stolen employee credentials, specifically, infostealer malware that compromised an Atlassian account, which then provided access to Amazon S3 cloud storage containing years of guest data. The breach persisted from July through October 2024 before it was detected.
The hotel brands whose guests were exposed did not choose to be vulnerable. They chose a vendor. That vendor had its own infrastructure dependencies, its own credential management practices, its own security posture. None of that was visible to the operators whose guests were ultimately harmed.
This is not an isolated incident. In early 2025, Resort Data Processing (RDP), a property management software provider, suffered a supply chain attack in which a malicious script was injected into a customer-facing booking page, scraping guest names, payment card numbers, CVV codes, and expiration dates in real time. The properties using RDP’s booking widget had no visibility into the compromise until after the damage was done.
The Evaluation Gap
Here is the most troubling part of this picture: most organizations are not evaluating vendor security before sharing sensitive data with them.
Only 36% of companies assess vendor security posture before granting access to sensitive information. That means nearly two-thirds of businesses are extending trust to vendors they have never formally evaluated. In an industry where a single vendor can hold reservation data for thousands of properties, that is an extraordinary exposure.
The financial consequences are not abstract. IBM’s 2025 Cost of a Data Breach report found that breaches involving third-party vendors cost an average of $4.91 million, significantly higher than the overall average breach cost. And according to Resilience’s 2025 cyber insurance analysis, 23% of cyber insurance claims with material financial losses involved third-party breaches, a category that had never previously generated significant insured losses.
The cost of a third-party breach is not just financial. It is the trust of every guest whose data you were responsible for protecting.
A Practical Framework for Mapping Vendor Dependencies
The goal is not to eliminate third-party integrations. They are essential to how modern hospitality tech operates. The goal is to make the invisible layer visible, and to apply proportionate scrutiny based on data sensitivity.
Here is a working framework for operators and platform teams:
- Build a complete vendor inventory. List every platform, tool, SDK, and sub-processor that touches guest data. Include indirect dependencies where possible. Ask each primary vendor for their sub-processor list, reputable vendors will have this documented. If they do not, that is itself a signal.
- Classify by data sensitivity. Not all vendors carry equal risk. Segment your vendor inventory by the type of data they access: identity data (passport, government ID), payment data, behavioral/booking data, or operational data only. Vendors with access to identity and payment data warrant the highest scrutiny.
- Evaluate security posture before onboarding. Request SOC 2 Type II reports, ISO 27001 certifications, or equivalent third-party attestations. Ask about penetration testing cadence, incident response procedures, and breach notification timelines. A vendor that cannot answer these questions clearly is not ready to hold your guests’ data.
- Review data processing agreements and contractual obligations. Understand what your vendors are contractually obligated to do in the event of a breach. GDPR and many U.S. state privacy laws require sub-processors to notify data controllers within specific timeframes. Verify those obligations are reflected in your agreements.
- Establish ongoing monitoring, not just point-in-time review. Security posture changes. A vendor that passed evaluation 18 months ago may have since changed infrastructure providers, acquired new software, or experienced undisclosed incidents. Build a cadence for periodic re-evaluation of high-risk vendors, and monitor for breach disclosures in your vendor ecosystem.
The Responsibility Doesn’t Stop at Your Platform
There is a dimension of this problem that the hospitality tech industry has been slow to confront: platform providers, PMS vendors, channel managers, booking engines, bear a responsibility to educate their customers about the security implications of their integration ecosystems.
When a PMS marketplace lists 200 available integrations, operators reasonably assume that some level of vetting has occurred. Often, it has not. The integration partner may have passed a basic API review, but that is not the same as a security evaluation. The operator who enables that integration is extending trust they did not know they were extending.
Platforms that build integration ecosystems without clear security standards for their partners are, in effect, outsourcing risk to operators who have no way to assess it.
This is not an argument against open ecosystems. It is an argument for transparency within them.
Making the Invisible Visible
The hospitality industry has spent years building increasingly sophisticated guest experiences on top of increasingly complex technology stacks. The security conversation has not kept pace with the integration conversation.
The data is clear: third-party vendors are now the primary attack vector in hospitality. The financial exposure is measured in millions. The reputational exposure is measured in the trust of guests who handed over their identity and payment information in good faith.
Operators who want to close this gap do not need to become security experts. They need to ask better questions of the vendors they rely on, demand transparency about sub-processors and data flows, and apply the same due diligence to their tech stack that they apply to any other operational risk.
Platforms like Autohost are built with this visibility in mind, designed to give operators clarity not just about their guests, but about how guest data is handled, processed, and protected throughout the screening workflow. In a landscape where the hidden layer is the most dangerous layer, that kind of transparency is not a feature, it is a foundation. The stack beneath the stack is not going away, you should make sure you know what’s in it.
