Skip to documentation content

Security & Privacy

Protect booking data and define retention

Map booking snapshots, guest data, payment records and external blocks to a documented retention and access policy.

Hotel Booking stores a booking snapshot so a historical confirmation remains stable when prices, taxes, services or room content change. Treat guest names, email addresses, notes, customer linkage, booking access tokens and payment references as sensitive data. The snapshot is an operational record, not a license to retain personal data forever. The site owner must document purpose, retention period, access roles and deletion or anonymization criteria for the jurisdiction in which the hotel operates.

Document the legal basis for each retention purpose and tell staff how the policy is reviewed.

Safe retention workflow

  1. Inventory the booking, booking-item, nightly-price, service, coupon, tax, payment/refund and customer-linkage records before choosing a retention rule.
  2. Keep immutable financial and tax evidence for the required accounting period; remove or anonymize unnecessary guest fields only through an approved, reversible maintenance procedure and a recorded change window.
  3. Keep external iCal blocks as occupancy records while their source is active; they contain no guest identity and must not be converted into a normal customer booking.
  4. Protect backups with encryption, limited operators and a tested restore path. A backup copy inherits the sensitivity of the production database.
  5. Verify that exports, CSV files, email previews and screenshots do not expose personal data. Never paste production rows into a public issue or document.

Do not delete booking rows to repair a pricing or license problem. Escalate a retention request that conflicts with legal, tax or payment obligations to the site’s privacy owner before touching canonical data.

Was this article helpful?

Your feedback helps us improve the documentation.