Privacy, retention & deletion

Guests have enforceable rights over their data, and DineGlobe runs those rights as explicit, audited cases rather than quiet favors: a request is recorded, identity is verified as its own stamped act, and only then is anything executed. Deletion erases down to the lawful minimum and leaves an append-only tombstone for every removal, so the record of what was erased survives even a backup restore. This page explains how to file and work a case, how verification, legal holds and retention schedules interact, and what guests are actually told.

What a guest can ask for

Three request types exist, and every case names exactly one:

Request type	What it asks	What the pilot does today
ACCESS	A picture of the data held about the guest	Recorded and verified as a case; the response itself is staff work
CORRECTION	A fix to something wrong	Recorded and verified as a case; the fix itself is staff work
DELETION	Erasure of the guest’s data	Recorded, verified, then executed by the deletion command described below

There is no self-service privacy form in the pilot: a guest asks the venue — in person, by phone or in writing — and a staff member records the case on their behalf. That intake is itself deliberate: an act with this much consequence starts with a human who can be asked follow-up questions.

The case flow

State	Meaning
RECEIVED	The case is recorded but identity is not yet verified. A due date is stamped 30 days out at intake — a documented response window, stated as a working commitment, never as a statutory claim
VERIFIED	The verification act is done, stamped with its method, the instant and the verifier
COMPLETED	The executed outcome: the response records which data classes were removed, which were retained and why
RESTRICTED	A reserved decided-state in the state vocabulary for a legally restricted outcome — no pilot command writes it today

Verification is proportionate to the data’s risk, from a bounded method list: account_session, management_token, government_id_reviewed or payment_reference. A matching email address is deliberately not on that list — it verifies nothing. Verification is never implied by intake: leaving the method blank records the case as RECEIVED only.

Executing a verified deletion

Only one act erases data: executing a verified DELETION case for a venue’s own guest. Anything else — verifying twice, executing an unverified case, executing an ACCESS case, repeating a completed execution — is refused with PRIVACY_CASE_INVALID_TRANSITION. The guarded state transition is the single arbiter, so a replay can never erase twice.

Execution removes the unnecessary: service notes, tag assignments and the profile’s contact PII (the display name is replaced with “Deleted guest”, and email, phone and preferred language are cleared). The lawful minimum survives by name in the outcome record: consent evidence, the audit trail, any future bookings that still have to happen, and financial references — plus the guest’s identity itself when a legal hold pins it. Active holds are never silently worked around; they are listed in the outcome with their reason and review date.

Every removal writes a tombstone to the deletion ledger: the removed record’s id plus a keyed digest of the subject — never the contents. The ledger is append-only, and it exists for the restore case: after a backup is restored, the ledger is reapplied from the checkpoint instant (the backup’s moment), re-asserting every tombstone executed after it before the restored data serves anyone. The reapply is idempotent — run it twice and nothing further changes.

Legal holds

A legal hold pauses deletion for one specific resource. Holds are typed to a fixed allowlist — GUEST_PROFILE, GUEST_NOTE, RESERVATION, REFUND_INTENT, PAYMENT_ATTEMPT, CONSENT_RECORD — and two things are mandatory: a reason (1–500 characters) and a review date in the future. A hold is bounded by its review date, never a blanket never-delete switch.

Releasing a hold is an explicit, stamped event; the hold row itself is retained evidence and is never deleted or rewritten. Releasing twice answers PRIVACY_HOLD_ALREADY_RELEASED. While a hold is active, deletion and retention sweeps hold the covered items back and count them, so the numbers show what was skipped and why.

Retention schedules

Retention is an approved schedule, not a silent default. A schedule is recorded per country, venue and data class, for the three classes with executable sweeps today: guest_service_notes, guest_profile_contact and waitlist_contact. The schedule names its retention days (0–36500) and a purpose (1–500 characters); approvals are versioned, and a sweep runs against the latest approved version only. The schema documents suggested operating defaults — 30 days for service notes, 24 months for profile contact, 7 days for waitlist contact — but until an approver records a schedule for your venue, nothing is swept.

A sweep reports its own arithmetic: candidates considered, items removed, tombstones written, and items held back. Held back means obligations and law: profiles with future bookings, profiles with open refunds, and anything under an active legal hold. Financial and audit data classes deliberately have no schedule at all — their country-specific retention is never guessed.

Who may file and work cases

Act	Who may do it
Open, verify, execute, hold and sweep for a venue’s guest	Roles holding privacy.case.process: the venue’s manager, org admin or owner
Any act on a platform-consumer case (a registered user, not a venue guest)	The ownership tier only — an org-wide owner or org admin
Read case metadata and diagnostics on the platform axis	The PRIVACY_OFFICER platform role (platform role plus MFA; execution stays with the venue roles)

Cross-tenant probing reads as a plain NOT_FOUND here as everywhere else. Every act is audited with field names only, and case receipts carry ids, states and dates — the subject’s identity never echoes back through the workflow.

What guests are told

A venue keeps, about a guest: the booking’s frozen contact snapshot (name, email, optional phone, and the guest’s own requests to the venue), the confirmation code, party size, booked times, the accepted policy snapshot and the guest’s own cancellation reason. That is the working set the profiles page describes in Guest profiles & notes.

Guests are also entitled to a few plain statements, and the product is built to make them true: staff notes and tags never appear on the guest’s private booking page; reading a restricted note category is an audited act; audit events record field names, never values or note bodies; and nothing a guest submits is stored on a device — the offline screen says exactly that. The platform-operator side of privacy governance is covered in Platform operator guide, and refusal codes you may meet while working cases are listed in Error codes & fixes.