help wanted: GDPR erasure must scrub PII across stay artifacts (not only guest row)

[telivity-otaip]

Why hotels care

EU (and many brand) hotels get DSAR / right-to-erasure requests. If the guest profile is anonymized but reservation notes still say "Alice Müller, passport C8…, allergic, company Amex on file", the hotel is still holding personal data — and the GM is the one facing the DPA.

HAIP already tombstones the guests row (Bug 4). Operators need a complete erasure map for everything that can hold guest PII.

Current state (code anchors)

• apps/api/src/modules/guest/guest.service.ts delete() — anonymizes guest columns, sets isDeleted, writes gdpr_erasure audit without previous PII
• Stay history kept intentionally (FK + operational retention)
• Likely residual PII surfaces (verify, don’t assume completeness):
  • reservations.specialRequests, bookings.notes
  • reservation_notes table
  • reservation_guests names / ID fields for accompanying guests
  • Folio / payment display names, house-account notes
  • Staff notifications / webhook payloads already delivered (out of band)
  • Search indexes / Connect content caches if any

What we need

1. Erasure inventory — markdown table in the PR: column/table → keep / scrub / already-safe, with legal retention rationale (no invented law — cite hotel retention practice or mark NEEDS_DOMAIN)
2. Property-scoped erasure job that scrubs confirmed PII fields while preserving non-PII operational history needed for audit/tax
3. Idempotent re-run; audit event summarizing what was scrubbed (counts, not values)
4. Tests proving a post-erasure GET / search / folio print cannot resurrect PII
5. Dashboard: clear "Erase guest (GDPR)" confirmation copy listing what is kept vs removed

Open questions (hoteliers / counsel — comment)

• After erasure, should confirmation numbers remain searchable by staff?
• Must accompanying-guest PII on the same stay be erased when the primary guest is erased, or only when that person is the data subject?
• Fiscal / invoice legal name retention vs GDPR — which wins in your jurisdiction?

Do not invent the legal answer. If ambiguous, keep the field and flag NEEDS_DOMAIN in the inventory.

Acceptance criteria

• Published erasure inventory reviewed in PR
• Automated scrub covers every "scrub" row in that inventory
• Guest find/search 404 after erasure; stay history remains without PII
• No PII written into the erasure audit log
• Vitest coverage for multi-table scrub + cross-property deny

How to contribute

Ideal for privacy engineers, GDPR-savvy hoteliers, or contributors who have shipped DSAR tooling.

Search keywords: GDPR, right to erasure, DSAR, anonymize guest, PII, hotel PMS privacy, data retention