Guest Records Under GDPR-Style Rules: What You May Keep

Keeping records is a duty in some places and a liability in others. The safe position is to know which field you need, and why.

Last updated: September 30, 2026

Guest records sit between two duties that pull in opposite directions. Some rules require you to collect and keep certain details. Others require you to hold as little as possible, for as short a time as possible. The way through isn't to memorise the rules. It's to know, field by field, why you have it — and to be able to say who else can see it.

Key Takeaways

• The rules reach small hosts. The trigger is handling personal data, not the size of your business.
• Every field needs a reason. If you can't say why you hold a detail, it shouldn't be in the record.
• Access is a decision, not a default. Each person gets the areas their job needs, not the whole record.
• Retention is something you choose. Keeping everything forever is a choice you'd have to defend.
• Answers differ by place. Check what applies where you host rather than copying another city's rules.

Why guest-data rules reach small hosts at all

It's tempting to assume data rules are for companies with legal departments. They aren't. The trigger is the activity, not the headcount. If you collect and keep information that identifies a person, you're handling personal data. The duties that follow apply to a host with one property much as they apply to a chain.

That matters for a business where guest details are everywhere. A booking brings a name, a phone number, an email, often a passport or ID image, and a payment record. Some of that arrives because the platform needs it, some because the local authority does, and some simply because it was easy to keep.

Reporting duties can pull against privacy ones. In Portugal, hosts registered as Alojamento Local must report foreign guests, including EU citizens, to a national system shortly after both arrival and departure. Trade media have reported that failing to report can carry a penalty on a per-filing basis (reported; the exact filing requirements and timing are set by the local authority and change). Treat that as one place's current practice, not a general rule.

Bigger rules are stacking on top. From 20 May 2026, European Union data-sharing rules require platforms to verify a listing's registration number before publishing it, but they sit on top of national and municipal limits rather than replacing them (confirmed). So a host can face a platform check, an authority check and a reporting duty at the same time — all involving the same guest, and all with their own idea of what to keep.

The practical point is that you can't resolve this by choosing one rule to follow. What you can do is make your own record answerable: for each field, a reason; for each person, a scope; for each record, a lifetime.

Step one: separate the fields you must keep

The first step is the simplest and the one most hosts skip. Before you ask how long to keep something, ask why you have it at all.

Sort every field into three groups. Must-keep fields are the ones a duty requires — a registration report, a tax record, a platform requirement. Useful fields are the ones that let you host well: a phone number you'll message about arrival, a note about an early check-out. Unnecessary fields are everything else, and this group is usually bigger than hosts expect.

Then apply a single test. Say the reason out loud. "I need the passport number because the authority requires it for this report" is a reason. "I might need it one day" isn't. If the sentence doesn't finish cleanly, the field shouldn't be there.

The uncomfortable part is the second group. Useful isn't the same as necessary, and a detail that makes hosting smoother can also be one more thing you're responsible for. Keep the phone number if you'll actually use it. Skip the copy of the ID if nothing requires it, because a scan you never needed is pure exposure with no upside.

Sorting the fields first also makes the next two steps possible. You can't decide who should see a record you haven't defined, and you can't set a lifetime for a field you haven't justified.

Step two: set who inside your team may see them

Most hosts don't work alone. A co-host handles messages, a cleaner needs the arrival time, an accountant sees the payments. Each of those people needs a slice of the guest record — and almost none of them needs all of it.

The mistake is treating access as one key. When everyone shares the same login, the cleaner who needs tonight's door code can also open last month's passport scans. That's not a staffing problem; it's a records problem, and it's the sort of thing that looks careless only after something goes wrong.

The fix is to grant access by area rather than by person. One teammate works the bookings, another handles payments, a third looks after availability and rates. Each sees the part that matches their work, and personal details that have nothing to do with them stay out of view. When you mask the details that don't need to be visible, the record still works for the job without carrying the whole file into every pair of hands.

This is also the step where records software can do what a shared password can't. On the records side, localsbnb.com keeps guest names, phone numbers and ID numbers masked by default, and grants access by area: orders, finance, availability and rates. A person running your calendar sees the stay, not the passport image behind it.

Set the scopes once, when you add a person, and revisit them when a role changes. Access that nobody re-reads drifts out of date, and an old teammate's key that still works is the same problem as a shared password.

Step three: fix the retention you can defend

Retention sounds like an administrative detail. It's actually the decision that determines whether your record is a duty met or a liability kept too long.

Start from the reason you gave each field in step one. A registration report probably needs to survive for as long as the authority could ask about it. A door code sent to a guest can go as soon as the stay ends. Payment records follow your accounting needs, not your curiosity. Matching the lifetime to the reason is the whole exercise — the exact period is set by the rules where you operate and by your own obligations, so check those rather than copying a figure from somewhere else.

Write the periods down and put a review date on them. What you can defend is a decision you made and can explain: this field, for this reason, for this long. What you can't defend is the default almost everyone starts with, which is keeping everything indefinitely because deleting felt like work.

Deleting has a trap of its own. Clearing a record too early can breach a duty just as holding it too long can, so the point isn't to keep less in general. It's to keep each field for exactly as long as its reason lasts, and no longer. That also means you need a way to act when a guest asks what you hold or asks you to remove it — a question you can only answer if you know where things are.

FAQ

Do GDPR-style rules apply to a host with one property?

In many places they can, because the trigger is handling personal data rather than the size of the business. If you keep guest names, contact details or ID copies, the duties attached to that data apply to you, whatever the platform does on its own side.

Which fields am I actually required to keep?

That depends on where the property is. Some places require a registration report after arrival and departure; tax rules require payment records; platforms require what they require. Sort your fields by the reason you have them, then confirm the periods against your local authority rather than assuming a general rule.

Can I just keep everything in case I need it one day?

That's the default to avoid. A field you can't justify is one you're responsible for without a reason, and a record kept forever is hard to defend. Keep what a duty or a real hosting task requires, and let the rest go when its reason ends.

The three steps are the same whether you have one unit or ten: give every field a reason, give every person a scope, give every record a lifetime. None of it needs a legal department, and all of it is worth doing before a guest asks a question you can't answer. When you want those choices to be enforced rather than remembered, localsbnb.com keeps login credentials stored locally, so the account that holds your guest records is one you can account for.

---

This article is general guidance for hosts and isn't legal or data-protection advice. Record-keeping duties, retention expectations and reporting rules differ by country and region and change over time; check the current requirements of your local authority and the current terms of the platforms you use.