Cross-Border Guest Data: What a Host Must Not Export

The obligation follows the property, not the company address. That single sentence explains most of what goes wrong.

Last updated: September 24, 2026

A host can be registered in one country, letting a unit in a second, and keeping guest records on a laptop in a third. The rule that applies is the one where the guest slept. That sentence explains most of what goes wrong here, and everything after it is about not moving data you never needed to collect in the first place.

Key Takeaways

• The property's location sets the rule. Where your company is registered settles very little.
• Three categories, sorted by risk. Booking and stay data, contact data, and identity data.
• Identity data is the one that shouldn't travel. It's collected for a local purpose and usually satisfies that purpose locally.
• Order the requirements. Purpose, minimisation, basis, destination, transparency, record, deletion — in that order.
• Collect less. The cheapest compliance work is a smaller pile of data.

Why the applicable rule is the one where the guest slept, not where your business is registered

Picture the common case. A company registered in one country. One apartment in another. Guests who live in a third. Records sitting in a cloud folder whose servers are in a fourth. Four jurisdictions, and the temptation to assume the first one governs everything.

It doesn't. The two obligations that bite a host are attached to the property. The guest register — where a locality requires one — is required by the authority that has jurisdiction over the unit, and it's that authority that will ask to see it. Data protection runs the same way: the general position in most regimes is that processing is governed by the rules of the place where the establishment carrying it out is located, not by where the company's registered office happens to be.

Europe is the clearest example, and worth naming because so many portfolios touch it. Regulation (EU) 2016/679 — the GDPR — has applied since 25 May 2018, and it attaches to processing carried out in the context of an establishment's activities in the EU regardless of where the data ends up. Verified. Alongside it, industry summaries dated September 2026 describe EU Regulation 2024/1028 as adding registration and data-exchange duties for short-term rental hosting, with activity data shared with authorities. One-party claim, industry blog. Both are references to read and then confirm with your own authority — not a summary you can run a portfolio on.

The practical consequence is unglamorous. If you let in three countries, you're running three guest-register regimes and three retention clocks, and "we're one company with one spreadsheet" is the sentence that turns that into a problem. Keep the register for each unit under the rule for that unit.

The three data categories, and the one that should almost never leave the country

Sort what you hold into three piles, because they behave differently once they cross a border.

Booking and stay data. Dates, nights, amount, channel reference, whether the guest arrived. This is commercial rather than personal in most of what it contains, and it's the category you legitimately move — to an accountant, to a management report, to a tax filing.

Contact data. Name, phone number, email, sometimes a home address. You need it to run the stay, and it's the category that travels most easily: it identifies a person, it fits in a spreadsheet, and it's the thing least likely to be missed when it goes.

Identity data. Passport or national ID number, and in some places a scan or photograph of the document. You hold it because a local registration regime asked for it, and for essentially no other reason.

That third pile is the one that should almost never leave the country. Three reasons, and they compound. It carries the highest consequence if it leaks — a passport copy is worth more to a thief than a booking reference. It was collected for one specific legal purpose, which is the guest register. And that purpose is usually satisfied by submitting the data to the local authority through the channel the authority provides, which means copying it into your own cloud storage adds risk without adding purpose.

A scan is worse than a number. A number is data; a scan of a passport page is a document with a photograph, a signature and a machine-readable zone, and it should live where the guest slept or nowhere at all. Some localities require you to keep a register on the premises and produce it on request — which is a strong hint about where they expect the underlying data to sit.

What a lawful transfer actually requires, in the order the requirements apply

The order matters as much as the list, because a missing step early on can't be repaired by doing a later one well.

Purpose. One you can state, and it has to be the actual one. "It's easier to keep everything together" isn't a purpose; "my accountant needs the nights figure for the filing" is.

Minimisation. Send what that purpose needs. A nights figure, not a guest list. Anonymised where the purpose allows it.

Lawful basis for the transfer. Separate from the basis for collecting it in the first place, and the most commonly skipped step.

Destination. Where is it actually going, and what protection applies there? This is where a cloud folder with servers you've never checked becomes a problem you didn't know you had, and where transfers between countries with very different regimes need real attention.

Transparency. The guest has to be told, and told accurately. If your privacy notice says data stays in the country and your tooling syncs it elsewhere, the notice is the thing that's wrong.

Record. What moved, when, to whom, and on what basis. A log, not a memory.

Retention and deletion. Delete on the schedule the local rule sets, not on the one that suits your filing system. Where a locality requires deletion after a statutory window, keeping the data past it is its own breach rather than a harmless habit.

One practical test for the whole list: can you answer a question about a booking without exporting a spreadsheet at all? With the AI layer, the answer comes back in the chat you already use, access is granted per domain, and guest identifiers are masked rather than handed over — see localsbnb.com.

Building the habit: minimising collection so there is less to export at all

Every rule above gets cheaper if you hold less. That's the habit worth building, and it's mostly about timing.

Collect identity data at the point the law requires it, not earlier. Plenty of hosts ask for a document at booking because it's convenient, which means holding it for weeks before any duty to hold it exists, and for guests who then cancel. Take it at check-in, from the person standing in front of you, and only where the local rule actually asks.

Use the authority's own channel for the register where one exists. Submitting through the portal they provide means your copy is a record of what was submitted rather than a second store of identity documents. Keep the timestamp; that's the part you'll want later.

Don't photograph documents into a shared drive. If a copy has to exist, it goes where the guest slept, under the same access discipline as the register.

Keep one written list: what you hold, where it lives, who can see it, and how long it's kept. Update it when anything changes. It takes an hour the first time and fifteen minutes after that, and it's the document that turns a question from an authority into a five-minute answer rather than a weekend.

Then apply the same test to your tools. Where do credentials sit? Who can see guest identifiers, and are they masked by default? If a tool needs a copy of your guest list on someone else's server to be useful, that's a cost, not a feature.

FAQ

I'm registered in one country and let in another. Which rules apply?

For the guest record and the local registration duties, the ones where the property is. Your company's registration governs your corporate and tax filings; it doesn't decide whether your guest register in another country is being kept properly.

Can I keep a spreadsheet of guest documents on my laptop?

You can, and it's the habit behind most of the trouble. Ask two questions first: does the local rule require me to hold this at all, and does submitting it to the authority already satisfy the purpose? Usually the answer removes the spreadsheet.

Do I have to tell guests that their data moves?

Transparency is a requirement in the regimes we've looked at, and it has to be accurate. If data leaves the country, the notice has to say so — and saying so is often the prompt to ask why it's leaving.

Keep the register in the country that asked for it, keep your own copy of it small, and write down what you hold before somebody asks. Most of this is collection discipline rather than paperwork. For the tooling half — credentials that stay on your own machine, access granted per domain — that's localsbnb.com.

---

Data protection rules, guest register duties and retention periods are set by the authority where the property is and change over time; the EU instruments named above are dated external references, not advice about your own case. Confirm with the local authority and with the current terms of any platform you use. This is general guidance for hosts and isn't legal advice.