# Building a data retention schedule for guest records that actually gets enforced
A guest checks out of a property in Lisbon, and their booking record, payment tokentokenA token is the basic unit of text that language models process, often a word fragment, whole word, or punctuation mark rather than a single character.Voir la définition complète →, dietary preferences, and loyalty points sit in six different systems, each with a different idea of when that data should die. This is not a hypothetical. It is the daily reality for any multi-brand hotel group running a central reservation system, a property management system (PMS) at each hotel, a CRMCRMCustomer Relationship Management: software and strategy to manage and analyse customer interactions throughout their lifecycle.Voir la définition complète → for loyalty, and a data lakedata lakeA data lake is a centralized repository that stores large volumes of raw data in its native format, from structured tables to unstructured files, until needed.Voir la définition complète → feeding analytics. The retention clock starts at a different time in each one, and almost nobody enforces it.
Picture a global hotel group, call it "Meridian Hotels," with luxury, midscale, and budget brands under one loyalty program.
The loyalty team wants five years of stay history per guest. Their argument: predicting who deserves a suite upgrade or a birthday bottle of wine requires multi-year behavioral data. This is a legitimate business case, not vanity.
The privacy regulator, meanwhile, points to purpose limitation. Under the EU's General Data Protection Regulation (GDPR), personal data must be kept "no longer than is necessary for the purposes for which it is processed" (Article 5(1)(e)). A guest who stayed once in 2022 and never engaged with the loyalty program again has a reasonable expectation that their data will not linger indefinitely. Several EU data protection authorities, including France's CNIL (Commission Nationale de l'Informatique et des Libertés), have issued guidance suggesting inactive customer data should be deleted or archived after around two to three years of inactivity, absent a specific legal basis to keep it longer (CNIL retention guidance).
Both sides are right. The resolution is not a single number. It is a tiered retention schedule tied to purpose, not to convenience.
The mistake most hotel groups make is setting retention at the system level ("keep everything in the CRMCRMCustomer Relationship Management: software and strategy to manage and analyse customer interactions throughout their lifecycle.Voir la définition complète → for five years"). Regulators do not think in systems. They think in purposes.
A workable schedule for Meridian Hotels looks like this:
| Data category | Purpose | Retention trigger | Retention period (estimate, illustrative) |
|---|---|---|---|
| Active loyalty profile | Personalization, tier benefits | Last qualifying activity | 3 years of inactivity, then archive/delete |
| Stay history (folio, room type, spend) | Loyalty analytics, forecasting | Check-out date | 5 years, but pseudonymized after year 2 |
| Payment card data | Transaction processing | Transaction date | Per PCI DSS, typically 12 to 18 months unless needed for chargebacks |
| Guest ID/passport scans | Legal requirement (hotel registration laws) | Check-in date | As mandated locally, often 1 to 3 years |
| Marketing consent record | Proof of opt-in for email/SMS | Consent given/withdrawn | Kept until withdrawal, plus a short evidentiary window |
| CCTV/lobby footage | Security | Recording date | Typically 30 to 90 days unless flagged for incident |
The key move: stay history is retained for five years, but pseudonymized (stripped of direct identifiers like name and email) after year two. This satisfies the loyalty team's analytics need (aggregate and trend data survives) while satisfying the regulator's minimization principle (the data is no longer "personal data" tied to an identifiable guest in the same way after pseudonymization). GDPR treats pseudonymized data as still personal data if re-identification is possible, so this only works if the re-identification key is genuinely separated and access-controlled, not just cosmetically hashed.
For a hotel group operating across the US and Europe, the relevant frameworks include:
The schedule has to reconcile a *ceiling* (regulator: don't keep too long) with a *floor* (local law: must keep at least this long for registration or tax records). Retention policy is the negotiation between these two lines, category by category, not one blanket number.
A retention schedule that lives in a PDF on a compliance SharePoint is not a retention schedule. It is a liability document that proves you knew the rule and didn't follow it.
Enforcement requires:
1. A system of record for retention metadata. Every guest record needs a "retention clock" field: category, trigger date, calculated expiry date. This cannot live only in someone's memory.
2. Automated deletion or archiving jobs, not manual review. A simple nightly batch job illustrates the logic:
-- Illustrative: flag loyalty profiles for pseudonymization
-- after 2 years of inactivity
SELECT guest_id
FROM loyalty_profiles
WHERE last_qualifying_activity < CURRENT_DATE - INTERVAL '2 years'
AND pseudonymized_flag = FALSE;
-- Then run pseudonymization routine, replacing name/email/phone
-- with a reversible token stored in a separate, access-restricted vault3. Cross-system reconciliation. A guest who exercises their right to erasure in the CRMCRMCustomer Relationship Management: software and strategy to manage and analyse customer interactions throughout their lifecycle.Voir la définition complète → must also be purged from the marketing platform, the data lakedata lakeA data lake is a centralized repository that stores large volumes of raw data in its native format, from structured tables to unstructured files, until needed.Voir la définition complète →, and any third-party processor (a common gap: hotel groups forget about vendors like email service providers or review-management tools holding copies).
4. A quarterly retention audit. Sample records across each category and verify the calculated expiry date matches what actually happened in the system. This is where governance turns into a checkable control rather than a policy statement.
Vérification des acquis
1. A hotel group's loyalty team wants five years of stay history while privacy guidance suggests deleting inactive customer data after two to three years. What is the correct way to resolve this tension?
2. Why does GDPR's purpose limitation principle (Article 5(1)(e)) create pressure to delete a guest's data after a period of inactivity?
3. A multi-brand hotel group has a guest's data spread across a central reservation system, a property management system, a CRM, and a data lake, each with its own retention timing. What core problem does this illustrate?
4. Select ALL correct answers about why a tiered retention schedule (rather than one uniform period) is appropriate for guest data.
Sélectionnez toutes les réponses correctes.
5. Select ALL correct answers about the CNIL guidance on customer data retention referenced in the lesson.
Sélectionnez toutes les réponses correctes.
A practical, recurring audit for a hotel group's guest data should check:
🎬 [VIDEO: "GDPR Explained: The Right to Erasure" - youtube.com/results?search_query=gdpr+right+to+erasure+explained - a short explainer on how erasure requests work in practice, useful background for the audit step above]
Back to Meridian Hotels: the final policy isn't "five years" or "two years." It's:
This gives the loyalty team its five-year analytical horizon while giving the regulator a genuine, auditable reduction in personal data risk after year two. Both numbers survive. Neither side "wins" the whole argument, which is usually the sign of a workable governance compromise.