The Guest Data Liability Time Bomb — and How Portable Guest Profiles Defuse It
Every hotel accumulates guest data. Preference profiles. Stay histories. Dietary requirements. Room temperature preferences. Contact information. Payment methods. Special requests.
This data is valuable — it enables personalization, drives loyalty, and informs marketing. But it’s also a liability. Every record in the CRM is a record that can be breached, sold, subpoenaed, or mishandled. And the liability compounds: a hotel that’s been collecting preference data for 10 years has 10 years of records to protect.
The average cost of a data breach is $4.45 million (IBM, 2023). Hospitality is among the top 5 most-breached industries. The liability isn’t theoretical.
The accumulation model
The traditional guest data model is accumulate-and-store. The guest provides preferences (or staff infer them from behavior). The hotel stores them in the CRM, PMS, or loyalty database. The data persists indefinitely — “in case the guest returns.”
This model made sense when the alternative was paper files. It made less sense when GDPR gave guests the right to erasure, CCPA gave them the right to know what’s collected, and every new state privacy law added another compliance obligation.
The problem isn’t collecting the data. It’s storing it forever. A guest who stayed once in 2019 has a preference profile that’s been sitting in a database for years — unaccessed, possibly outdated, definitely a liability if the system is breached.
The Portable Guest Profile inversion
The Portable Guest Profile (PGP) inverts the data model. Instead of the hotel accumulating preferences, the guest carries their own preferences in their phone’s wallet as a W3C Verifiable Credential.
At check-in, the guest taps their phone on the Puck and selectively shares their preferences — room type, temperature, dietary restrictions, accessibility needs. The hotel uses the preferences for personalization during the stay. At checkout, the authorization expires. The hotel shreds the preference data within 24 hours.
The hotel retains a compliance audit record (confirming that preferences were shared and when they were deleted) but not the preference values themselves.
What this changes for the CISO
Breach exposure for preference data drops to near-zero. If there’s no historical preference database, there’s nothing to exfiltrate. A breach that occurs Tuesday can’t expose preference data from a guest who checked out Monday — because that data was shredded Monday night.
GDPR right-to-erasure is automatic. The data self-destructs at checkout + 24 hours. No manual deletion process. No data subject access request backlog. No risk of incomplete erasure.
CCPA “do not sell” is structurally satisfied. The hotel never accumulates the data — so there’s nothing to sell and no opt-out process to manage.
Data protection impact assessments (DPIAs) are simpler. The data lifecycle is short and defined: received at check-in, used during stay, shredded at checkout. There’s no “indefinite retention” scenario to assess.
What this changes for marketing
The VP of Marketing asks: “If we don’t keep preference data, how do we personalize?”
The answer: you still personalize. You personalize with data the guest just gave you — current, accurate, consent-captured preferences — instead of with stale data from a CRM profile that hasn’t been updated since the guest’s last visit.
PGP preferences are guest-maintained. When a guest changes their temperature preference, they update their PGP credential on their phone. The next hotel they visit receives the current preference, not the one from 2019. Personalization quality actually improves because the data is always fresh.
Loyalty data (tiers, points, membership status) still lives in the hotel’s loyalty system — PGP doesn’t replace loyalty programs. PGP handles preferences. Loyalty handles the relationship. They work together at check-in.
Beyond preference data, hotels can also reduce their exposure on the physical credential side — plastic keycards carry their own hidden costs.
