Why Hotels Are Accidental Data Hoarders
Walk into the back office of almost any independent hotel and ask one question: what personal data do you hold about guests, and when does each piece of it get deleted? The first half usually gets a confident answer. The second half gets a blank look. Hotels are extraordinarily good at collecting guest data and almost universally bad at getting rid of it. There are passport scans from 2019 sitting in a shared drive, a spreadsheet of card details someone built for a coach group three summers ago, a marketing list with ten thousand addresses nobody can prove consented to anything, and a reservation system holding the full stay history of every guest who ever walked through the door. None of it was kept maliciously. It accumulated because deleting data takes a deliberate decision and keeping it takes none.
Under the General Data Protection Regulation, that accumulation is not neutral. It is a growing liability. The GDPR storage limitation principle says you may keep personal data only for as long as you actually need it, and the right to erasure gives every guest the ability to ask you to delete what you hold. The data living in your property management system, your CRM, your email tool, and those forgotten spreadsheets is not an asset that quietly appreciates; it is risk that compounds. Every extra record and every extra year is more to lose in a breach, more to surface in an access request, and more for a regulator to ask about. This article is for the operator, not the lawyer: what GDPR actually requires on retention, how to build a schedule that names each kind of data and its deletion clock, when you can refuse an erasure request, and a 30-day plan to clean up the hoard.
A short honesty note before the detail. I write for Prostay, and our team builds property management and payment software for hotels, so one short section near the end is a disclosure rather than advice. Everything else here is vendor-neutral and applies whatever systems you run. And one disclaimer that matters: this is operational guidance, not legal advice. GDPR is interpreted by national regulators with their own guidance, retention periods are set by your country's tax and commercial law, and a genuinely complex case deserves a data protection lawyer. The aim here is to get you from "we keep everything forever" to a defensible, written, enforced position that covers the vast majority of what a hotel actually holds.
What GDPR Actually Requires on Retention
The frustrating thing for operators who want a single rule is that GDPR deliberately refuses to give one. It does not say "keep guest data for X years." Instead it sets principles and lets the specifics fall out of them. Two principles do almost all the work on retention, and once you understand them the apparent vagueness turns into something you can actually operationalise.
The Storage Limitation Principle
Storage limitation is the GDPR principle that personal data must be kept in a form which permits identification of people for no longer than is necessary for the purposes it is processed for. In plain terms: you can hold data only as long as you genuinely need it for the reason you collected it. Once that reason is gone and no other lawful basis applies, you must delete it or anonymise it so it can no longer be tied to a person. The principle is the direct answer to "just in case" retention. Keeping a guest's data indefinitely because it might be useful one day is precisely what storage limitation prohibits, because "might be useful" is not a defined purpose with an end date.
This is why the right unit of thinking is not the hotel as a whole but each purpose. The data you collected to fulfil a booking has a purpose that ends some defined time after the stay. The data you keep for tax has a purpose that ends when the legal retention period expires. The data you hold for marketing has a purpose that lasts only while consent stands. Each purpose has its own clock, and storage limitation says you stop when the clock runs out.
Lawful Basis Decides How Long You Keep It
The companion idea is lawful basis: the legal reason you are allowed to process a given piece of data in the first place. The basis you rely on largely determines how long you can keep the data, because retention is tied to the purpose the basis supports. Three bases cover most hotel data. Contract covers what you need to deliver the stay the guest booked. Legal obligation covers what a separate law forces you to keep, tax and accounting records being the obvious case. Consent covers things the guest actively opted into, marketing being the main one, and it lasts only until they withdraw it.
The practical consequence is that "how long do we keep guest data" has different answers for different data, and the basis tells you which. Booking and billing records sit largely under legal obligation, so their clock is set by your national tax law, often six to ten years. Marketing data sits under consent, so its clock ends when the guest unsubscribes or your inactivity policy kicks in. An operational note a manager wrote about a difficult guest sits under legitimate interest at best, so it should be short-lived. Get the basis right for each category and the retention period almost writes itself.
Building a Guest Data Retention Schedule
The single most useful thing a hotel can do for GDPR compliance is also the least glamorous: write a retention schedule. A retention schedule is a simple table that lists every category of personal data you hold, the lawful basis for holding it, the purpose, the period after which you delete it, and where it lives. It is not a legal treatise; a good one fits on two pages. Its value is that it converts a vague obligation into a set of concrete, enforceable rules, and it is the first document a regulator will ask for if they ever come knocking.
The discipline of writing it is what flushes out the problems. You cannot fill in "where it lives" without discovering the spreadsheet on the shared drive and the export someone emailed themselves. You cannot fill in "retention period" without deciding, finally, how long you actually keep a marketing contact who has not opened an email in three years. The schedule forces the decisions that "we will deal with it later" has been deferring, and once written it becomes the rule the whole team and your systems follow.
Retention by Data Category
Here is how the main categories typically break down for a hotel. Treat these as a sensible starting frame, not gospel, because your national law and your specific circumstances move the numbers.
- Booking and reservation data (name, contact, stay dates, preferences): needed during and shortly after the stay under contract. A common approach is to keep the active booking data for a defined window after checkout, to handle disputes, refunds, and follow-up, then delete or archive it, with anything that became part of an invoice moving to the financial-records clock below.
- Financial and invoice records (invoices, payment confirmations, folio): governed by legal obligation, so the period is set by tax and commercial law, commonly six to ten years (ten in Germany and France, around six to seven elsewhere). You generally cannot delete these early, even on request.
- Payment card data: the goal is to hold as little as possible for as short as possible, ideally none, because tokenization through your payment provider removes the card number from your systems entirely. More on this below.
- Marketing data (email addresses, preferences, consent records): kept under consent, so retained only while consent stands. Set an inactivity rule, for example removing or re-permissioning contacts who have not engaged in 24 to 36 months, and honour unsubscribes immediately.
- Identity documents (passport or ID scans, where law requires registration): a sensitive problem covered below; keep only as long as the specific guest-registration law requires, then delete, rather than hoarding scans indefinitely.
- CCTV and access logs: short by default, often days to a few weeks unless a specific incident triggers a hold.
- Operational notes and free-text comments: the riskiest and least disciplined category; keep brief, factual, and short-lived, and never record anything you would not want the guest to read.
The Right to Erasure, and Its Limits
The right to erasure, often called the right to be forgotten, lets a person ask you to delete the personal data you hold about them. For hotels it most commonly arrives as an email: a former guest, or someone who once joined your mailing list, asking you to remove their data. The instinct is to treat this as binary, either delete everything or refuse, and both instincts are wrong. The correct response is more surgical, and getting it right protects you in both directions.
The right applies most clearly when you no longer have a lawful basis to hold the data. If someone withdraws marketing consent, the basis for keeping their marketing profile evaporates and you must delete it. If the purpose you collected data for has ended and nothing else justifies keeping it, the same applies. But the right is not a universal delete button. Where another lawful basis still applies, in particular a legal obligation to retain certain records, you can and sometimes must keep that specific data, and the right to erasure does not override it. The art is separating the data you must now delete from the narrow set you are legally required to keep.
What you cannot do is ignore the request or sit on it. GDPR gives you one month to respond, and the response must tell the person what you have done: what you erased, what you retained, and the legal reason for any retention. "We have deleted your data" when you have in fact kept the invoices for tax is both untrue and unhelpful; "we have removed you from all marketing and deleted your guest profile, and we are required to retain your booking invoices for several years under tax law, after which they will also be deleted" is the honest, compliant answer. Document the request and your response either way.
When You Can Refuse: Legal Holds and Exceptions
Because the right to erasure is not absolute, you need to know the situations where keeping data is legitimate, so you neither over-delete nor over-retain. Several exceptions matter to hotels.
The biggest is legal obligation. Tax and accounting law in every EU country requires you to keep financial records, including the invoices tied to a guest's stay, for a defined number of years. That obligation overrides an erasure request for that specific data. A guest can ask you to forget them, and you should forget everything you are free to forget, but the invoice stays until its legal clock expires. The same logic applies to any record a specific law requires you to keep, such as guest registration data where local law mandates it for a set period.
A second exception is the establishment, exercise, or defence of legal claims. If you are in, or reasonably anticipate, a dispute with a guest, a chargeback, a personal-injury claim, an unpaid bill, you may retain the data relevant to that claim until it is resolved, because you need it to defend yourself. This is not a licence to keep everything forever by imagining hypothetical disputes; it is a narrow, genuine-dispute exception. The discipline is to apply a specific legal hold to the relevant records and release it, deleting them, once the matter is closed.
The thread connecting these is specificity. An exception lets you keep the particular data the exception covers, for as long as the exception lasts, and no more. It is not a reason to keep the whole guest profile indefinitely. When you invoke an exception in response to an erasure request, keep only the data it justifies, delete the rest, and note why.
Passports, IDs, and Special-Category Data
Identity documents deserve their own section because hotels handle them constantly and often mishandle them. In many countries, law requires hotels to register guests and sometimes to verify identity, which is a legitimate reason to see a passport or ID at check-in. It is not, by itself, a reason to scan it and keep the image forever. The two are routinely confused: a property that is required to record certain registration details starts photographing every passport and storing the images indefinitely to be safe, which creates a large, sensitive, attractive-to-attackers data store that the law never asked for.
The disciplined approach is to separate what the law requires you to record from what you choose to retain. Record the specific fields the guest-registration law in your jurisdiction requires, keep them only for the period that law specifies, and then delete them. If you do scan or photograph an ID, treat that image as high-risk data: restrict who can see it, store it encrypted, and delete it as soon as the registration purpose is met, rather than letting scans pile up in a folder. For the mechanics of guest registration and police-reporting obligations specifically, we cover that in detail in our guest registration and police reporting guide; the retention point here is narrower: collect the minimum the law names, keep it for the minimum the law allows, and delete on schedule.
Be careful, too, about data that strays into special categories, the sensitive types GDPR protects more strictly, such as health information. A guest mentioning a serious allergy or an accessibility need can put health-adjacent data into your notes. You may need it to serve the guest well, but it warrants extra care: keep it only as long as it serves that guest's stays, restrict access, and do not let it linger in free-text fields long after it is relevant.
Payment Data: The Easiest Retention Problem to Solve
Of all the retention headaches, payment card data is the one with the cleanest solution, and many hotels have not taken it. The instinct from the old days was to store card numbers: capture them on a booking form, keep them on file for the no-show charge or the incidentals, write them on a slip. Every card number you store is a retention liability, a PCI obligation, and a breach waiting to happen. The modern answer is to not store them at all.
Tokenization, provided by any competent payment platform, replaces the card number with a meaningless token that is useless to a thief and lives with the payment provider, not in your systems. You can still charge the no-show, capture the incidentals, and process the deposit, because the token authorises the charge through the provider, but the actual card data never sits in your PMS, your spreadsheet, or your filing cabinet. That single architectural choice removes an entire category of retention risk: there is nothing sensitive to keep, so there is nothing to delete, nothing to breach, and far less to prove to an auditor. Using an integrated payment layer such as Prostay Pay that tokenizes by default means card data is minimised by design rather than managed by policy, which is always the stronger position.
If you still hold card numbers anywhere, on paper, in a spreadsheet, in email, in an old booking system, that is the highest-priority item in any retention cleanup, ahead of almost everything else. It is the data most attractive to attackers, most heavily regulated, and most clearly unnecessary to keep once tokenization is available. The fastest GDPR and security win most hotels can make is to find every stored card number and eliminate the practice that created it.
Marketing Lists, Consent, and the Quiet Liability
Marketing data is where good intentions create slow-burning risk. A hotel builds an email list over years, from booking forms, wifi sign-ins, a competition, a newsletter box, and rarely goes back to ask whether each contact actually consented, whether that consent was specific and informed, and whether it still stands. The result is a large list with murky provenance, exactly the thing that turns a routine complaint into a regulatory problem.
The retention discipline for marketing is built on consent. You may keep and use marketing data only while you have valid consent, which means the contact actively opted in, knew what they were agreeing to, and can withdraw as easily as they gave it. Two rules follow. First, honour unsubscribes immediately and completely: when someone opts out, stop emailing them and remove them from the active list, keeping at most a minimal suppression record so you do not accidentally re-add them. Second, deal with inactivity. A contact who has not opened or clicked in two or three years is a contact whose consent is stale and whose data you have little reason to keep; a sensible policy re-permissions them once and deletes them if they do not respond.
This feels counterintuitive to operators who equate a bigger list with more reach, but a large list of unconsented, unengaged, possibly improperly held contacts is not an asset; it is a liability that delivers poor results and high risk. A smaller list of people who genuinely want to hear from you performs better and carries almost no GDPR exposure. Pruning the list is both a compliance act and a marketing improvement, which is a rare alignment worth taking.
OTAs, Channel Managers, and Who Deletes What
Guest data does not arrive through one door, and that complicates retention. A booking might come from your direct website, from Booking.com or Expedia, through a channel manager, from a travel agent, or by phone. A common and dangerous assumption is that if the booking came through an OTA, the OTA owns the data and its deletion handles yours. It does not.
In most OTA relationships, both the platform and the hotel act as controllers for their own copies of the guest's data. The OTA is responsible for the data in its systems and for handling erasure there; you are responsible for the copy that lands in yours. When a Booking.com reservation flows through your channel manager into your PMS, the durable record that needs a retention policy and an erasure process is the one now sitting in your environment. The channel manager is usually a conduit, a processor moving the data, but the PMS copy is yours to govern.
The practical takeaways are concrete. You cannot point at an OTA and consider an erasure request handled; you must process it in your own systems regardless of how the booking arrived. You should know, for each platform you use, who is controller and who is processor for which data, which is set out in the data processing terms you agreed to and rarely read. And your retention schedule must cover every copy of guest data in your environment, not just the ones from your direct channel, because a regulator and a complaining guest will not care that the data originally came from somewhere else.
The Mechanics: Deleting Across PMS, CRM, Email, and Backups
Knowing what to delete is half the battle; actually deleting it across a real hotel's tangle of systems is the other half, and it is where good intentions die. Guest data is rarely in one place. It is in the PMS, the CRM or guest-profile tool, the email marketing platform, the spreadsheets, the inbox where someone forwarded a booking, and the backups behind all of it. A retention policy that only deletes from the PMS leaves copies everywhere else.
Start by mapping where data actually lives, the same exercise the retention schedule forces. For each system, find out how deletion works: does the PMS have a way to delete or anonymise a guest profile, does the email tool truly remove a contact or just suppress them, can you purge the spreadsheets and stop creating new ones. The aim is a defined deletion path for every place guest data sits, so that when a retention period expires or an erasure request arrives, you can act everywhere, not just in the obvious system.
Backups are the question everyone gets stuck on, and the regulators' position is pragmatic. You are expected to delete from live, active systems promptly. For backups, the expectation is that the data ages out on a normal, documented rotation and that you do not restore erased data back into live use. You are not generally expected to crack open every historical backup to surgically excise one guest the moment they ask. Two things make this defensible: backups on a sensible rotation that overwrites old data rather than keeping it forever, and a restore process that re-applies erasures so a recovery does not quietly resurrect deleted records. A backup you never overwrite is itself a storage-limitation failure, so the fix is partly just having a real backup retention policy.
Where you cannot easily delete, anonymisation is the accepted alternative. If you want to keep aggregate statistics, occupancy trends, length-of-stay averages, you can strip the data of anything that identifies a person and keep the anonymised figures, which fall outside GDPR because they are no longer personal data. Done properly, that lets you retain the business insight without retaining the liability.
Handling an Access or Erasure Request
When a guest exercises their rights, the request itself has rules, and handling it smoothly is mostly about having a process ready before the first one arrives. The two you will see most are the access request, where the guest wants a copy of the data you hold about them, and the erasure request, where they want it deleted. Both run on the same one-month clock and the same basic steps.
First, recognise the request. It does not have to be on a form or use legal language; an email saying "please send me everything you have on me" or "delete my data" counts, and the clock starts when you receive it. Make sure front-desk and reservations staff know to route these to whoever owns data protection rather than ignoring or mishandling them. Second, verify identity, proportionately. You must be sure you are dealing with the actual person before you hand over or delete data, but you should not demand excessive proof; confirming they control the email or booking reference on file is usually enough. Over-asking for ID is itself a data-collection problem.
Third, act across all systems, using the map and deletion paths above, and apply the legal-hold logic: for an erasure, delete everything you have no remaining lawful basis to keep, retain only what a law compels, and for an access request, gather a complete copy including the easily forgotten places. Fourth, respond within one month, in writing, explaining what you did, and for any retained data, why. Keep a simple log of requests and responses. None of this is hard once the process exists; the failures come from having no process, so the first request triggers panic, missed deadlines, and either over-deletion or a flat refusal, any of which can escalate a minor request into a complaint.
A 30-Day Data-Retention Cleanup Plan
You do not need a year or a consultant to get from "we keep everything" to a defensible position. A focused month, run by someone with authority to make decisions, gets a typical independent hotel most of the way there.
Days 1 to 7: find the data. Map every place guest personal data lives: PMS, CRM or guest profiles, email marketing tool, spreadsheets, shared drives, inboxes, the old system nobody decommissioned, paper files. Be ruthless about the forgotten corners, because those are where the worst risk hides. Flag immediately any stored card numbers and any standalone passport or ID scans; those are your highest-priority targets.
Days 8 to 14: write the schedule. Build the retention schedule: for each category of data, record the lawful basis, the purpose, the retention period anchored to your national tax and registration law for the legally mandated ones, and where it lives. Decide your marketing inactivity rule and your CCTV and notes periods. This document is the backbone of everything else.
Days 15 to 21: fix the worst exposures. Eliminate stored card data by moving to tokenized payments and destroying any card numbers on paper or in spreadsheets. Delete or properly secure standalone ID scans. Prune the marketing list: honour every outstanding unsubscribe and remove or re-permission long-inactive contacts. These three actions remove most of the real-world risk.
Days 22 to 28: build the processes. Define the deletion path for each system so retention periods can actually be enforced, ideally automating what you can. Write a one-page procedure for handling access and erasure requests, including who owns them, how identity is verified, and the one-month deadline. Brief front-desk and reservations staff so requests get routed, not lost. Check your backup rotation is finite and documented.
Days 29 to 30: document and schedule the review. Save the retention schedule and the request procedure where the team can find them, record what you cleaned up, which is useful evidence of good faith if a regulator ever asks, and put a recurring date in the calendar, quarterly or twice a year, to enforce the schedule and prune again. Retention is not a one-off project; it is a habit, and the calendar reminder is what keeps the hoard from rebuilding.
Where Prostay Fits, Briefly and Honestly
The disclosure: I write for Prostay, which builds a property management system and an integrated payment layer for hotels, so this section is interest, not neutral advice. The honest, useful point is narrow. A large part of the retention problem is architectural, and the right systems make the compliant path the default one. A PMS that lets you delete or anonymise a guest profile cleanly, rather than leaving data scattered and undeletable, makes both scheduled retention and erasure requests far easier to honour. And payments that tokenize by default, as Prostay Pay does, remove card data from your environment entirely, which deletes an entire category of retention and breach risk before you write a single policy.
None of that is unique to us, and it is not the point of the article. Plenty of modern PMS and payment vendors handle this well, and the right choice depends on your stack and your country. The genuinely useful test is the one in this article: can your systems delete what your schedule says to delete, do they minimise the sensitive data you hold in the first place, and can you act on an erasure request across all of them within a month. If yours can, the vendor barely matters. If they cannot, that is the gap to close, with us or anyone else. Buy and configure for the compliant default, not for a checkbox on a feature list.
Frequently Asked Questions
Five questions hotel operators ask most about GDPR retention and the right to erasure, answered from how this plays out in a real property rather than from the text of the regulation.
