When a Guest Asks You to Delete Their Data: A Host's Obligations

You can't delete what a tax authority still expects you to keep. That conflict is the whole answer.

Last updated: September 23, 2026

An erasure request lands, and the instinct is to comply completely. Refusing feels like the risky option. In practice the request reaches less than most hosts think. And the part it doesn't reach is the part that carries the penalty.

A short-stay host holds two kinds of guest data at once. There's the data you keep because you chose to keep it, and the data you keep because somebody with enforcement powers expects to read it. A deletion request clears the first. It stops at the second.

This guide separates the two. It explains which law applies when your company and the property sit in different places. It sets a storage discipline that keeps the retained set as small as it can be. And it gives a four-step reply you can send without promising something you can't deliver.

Key Takeaways

• Two piles, not one. What you keep by choice is erasable; what a register requires isn't.
• Location decides the rule. The obligation generally follows where the stay happens, not where your company is registered.
• Retention is a window, not forever. Statutory registers run to a defined period and then fall away.
• Minimisation is the real control. The safest record is the one you never collected.
• Answer in four steps. Acknowledge, split, state the period, then delete what's left.

What a deletion request actually covers

The request reaches everything you hold for your own purposes. That's a shorter list than it feels like when the message lands:

• Marketing and rebooking lists. Anything you'd use to bring the guest back.
• Personal notes. Preferences, observations, the remark you wrote so the next stay would go better.
• Messages past their purpose. Threads that no longer support a booking, a dispute or a tax record.
• Anything collected by habit. The fields your form asks for because the form always asked for them.

What it doesn't reach is the record a law requires you to hold. In most of Europe that means the guest register: the entry showing who stayed, which nights, and what identity document was presented. A stay that has already happened has generated a public interest in that record — policing, tax, and in some countries the reporting of foreign nationals to an authority.

Latvia is one documented example. Accommodation providers there submit foreign guest declarations through the national Latvija.lv portal, and industry reporting in 2026 describes the retained data as governed by EU Regulation 2016/679, with deletion at the end of the statutory audit window. Treat that as one country's arrangement rather than a European default. Then confirm the period that applies where your property sits.

Here's the useful reframing. The guest isn't asking you to break the law, and you aren't refusing them. You're being asked to delete one pile. You're telling them, with the reason, why the other pile has to stay until its window closes.

The statutory registers that override a deletion request

Two questions decide most of this. Hosts usually answer both with the wrong jurisdiction.

Which law applies. Industry guidance for holiday lets makes the point directly: the applicable rule is the one tied to where the accommodation is, not where your company happens to be registered. A host incorporated in one country and letting in another follows the property's regime for the register, and may follow a different regime for the marketing list. When the two disagree, the stricter retention applies to the register. And the stricter deletion applies to everything else.

How long it runs. Statutory retention is expressed as a window, not as a permanent obligation, and it's commonly measured in years. The same guidance notes that a paper register has a weakness a digital one doesn't: it's hard to prove when an entry was submitted. That matters more than it sounds, because the moment you need to evidence compliance is the moment the burden of proof is on you.

Three consequences follow. They're worth writing down once:

• Keep the register separate. If it lives inside the same file as your marketing notes, a deletion becomes a judgement call every time instead of a mechanical act.
• Record the clock. Note the stay date and the date the window closes, so a request two years later is answered from a record rather than from memory.
• Don't over-collect to be safe. Extra fields don't make you safer; they enlarge the set you're obliged to protect and later to justify.

Storage discipline: what to collect, where to keep it, and who may open it

The cheapest compliance decision available to a host is collecting less. Every field on your check-in form should answer a question: is this required by the register, required to operate the stay, or asked out of habit. The third category is the one to delete from the form rather than from the database.

Where the data sits matters as much as what it contains. Practical discipline looks like this:

• Credentials stay local. Login details for your own tools belong on your own machine, not in a shared note or a group chat that outlives the person who joined it.
• Masking happens by default. Guest names, phone numbers and identity document numbers should appear masked in day-to-day use, so a screen shared during a handover doesn't become a disclosure.
• Access is granted by area, not by person. Whoever cleans the unit doesn't need the money view, and whoever handles money doesn't need the identity documents. Grant the narrowest slice that lets the work happen.
• One owner per store. If nobody's named, the register keeps growing on a laptop somebody else owns.

This is also where the tool choice does work for you. The three questions above are answerable from a product's own documentation rather than from a promise. Are guest contact details masked in normal use? Is access granted by area rather than to everybody at once? Do the credentials for your channels stay on your own machine? Holding availability and rates for Airbnb, Booking.com, Agoda and Trip.com on one grid at localsbnb.com also means the register has one place to be exported from. That's the part that makes step four of the reply a mechanical act rather than an afternoon.

A four-step reply that answers the request

The failure mode in these exchanges isn't refusal. It's a vague promise made in the first reply and broken in the second. Four steps keep it clean.

1. Acknowledge with a date. Say you received the request and give the date you'll respond by. Don't say yes or no in this message.

2. Split the data in the reply. Name the two categories plainly: what you'll delete now, and what a legal obligation requires you to retain. Guests usually accept the second once the reason is stated. They rarely accept a silence that looks like an excuse.

3. State the period and the basis. Name the retention window and what sets it, in the terms your authority uses. If you don't know the period, say you'll confirm it rather than inventing a number — a wrong date is worse than a short delay.

4. Delete the rest, then confirm. Do the deletion, then send the confirmation. The confirmation should say what went, what stayed, and when the rest falls away.

One boundary worth holding: keep the reply about data and not about the stay. If the request arrived alongside a complaint or a dispute, the register is evidence. Deleting mid-dispute converts a manageable problem into a serious one.

FAQ

Can I refuse the request outright?

Not the whole of it. You can refuse the part that a statutory register requires you to keep, and you should say why. You can't refuse the part you hold for your own purposes.

Does the rule follow my company or my property?

Generally the property. Industry guidance for holiday lets treats the obligation as tied to where the accommodation sits rather than where the business is registered, and your marketing list may sit under a different regime than your register.

How long do I have to keep the register?

The period set by the authority for that address, commonly expressed in years — and it expires. Don't adopt a number from another country; confirm the one that applies to yours, and note the closing date with the stay.

Two piles, kept apart from the start: that's the whole answer. It turns a frightening message into a short piece of admin. Keep the register separate, collect less than your form currently asks for, and answer in four steps. If you want guest contact details handled the same way — masked in normal use, access granted by area, channel credentials staying on your own machine — that's the standard to hold any tool to at localsbnb.com.

---

This article is general information and not legal advice. Guest register, retention and erasure obligations differ by country and by municipality; the governing sources are the authority for the property's address and the current text of the applicable data protection law.