Guest data requests under KVKK: a front office procedure

Under KVKK, Türkiye's personal data protection law, a guest can ask a hotel whether it processes their data, and to correct or delete it. One named owner logs the request, confirms identity from records already held, searches every system, and replies in plain language within the statutory window.

A guest at checkout says she wants to see everything the hotel holds about her, and then wants it deleted. The receptionist has no script, the guest card is in the PMS, the messages are in a booking site's inbox, and last season's paper registration cards are in a cabinet in the back office. This article gives you the script and the route: how to receive a KVKK data request at a hotel, log it, confirm identity, search every system, decide what to correct, delete and keep, and reply in writing. The legal detail stays with counsel and the accountant; the procedure is yours to write this week.

Where do guest data requests arrive, and who owns them?#

They arrive wherever a guest can reach you: at the desk, in the hotel's email, on the phone, in a booking site's message thread, in the guest app or by post. One named person owns every request from the moment it lands, with a deputy for days off.

Define the term once for staff. The data controller (veri sorumlusu) is the party that sets the purposes and means of processing personal data, and in a hotel that is the hotel itself, not the receptionist and not the software vendor (Law No. 6698, Article 3, mevzuat.gov.tr, consolidated text, 1 November 2026). The request is addressed to the hotel, and the hotel answers for it.

The Authority's communiqué on applications to the data controller (opens in a new tab) (Official Gazette, 10 March 2018, No. 30356) lists the formal channels: in writing, by registered electronic mail (KEP), with a secure electronic or mobile signature, from an email address the person gave the controller earlier and that is registered in its system, or through software built for applications. A request that arrives by another route is still a request. Answer it, and tell the guest which channels formally count; confirm with counsel how a message sent through a booking site or a social account should be treated.

The desk's job is to capture, not to answer. A one-line script is enough: "I will record this today and our data protection contact will reply in writing." Never say at the desk that the hotel keeps nothing. Anything that arrives as a lawyer's letter, an authority's letter or a court notice goes to the owner and to counsel the same day, without a draft reply from the front office.

A complaint about service is not a data request. The moment the guest asks what the hotel holds, who it was shared with, or that it be corrected or deleted, it becomes one.

What should the request log record?#

One line per request, opened the day it arrives: who asked, through which channel, what exactly they asked for, and every action until the reply is sent.

Record the date and time received, the channel, the guest's name and contact, the request in the guest's own words, and the category: learn, copy, correct, delete, object to a result from automated analysis, or ask about third parties. Add the reservation code and stay dates where they exist, so the search does not start from a name alone.

Record the search itself: which systems were checked, by whom, on what date, and what came back. An empty result written down is a result; an empty result remembered is not. Keep the log append-only: corrections go on a new line, never over the old one, the same discipline as a night audit. The log is your evidence of the date the clock started.

One file per request holds the log line, the original message, the identity check, the search results and the sent reply. The log is an index, not a second copy of the guest's data, so keep it to what is needed to find the file. Review the log once a month: how many requests, from which channels, which system took longest to search. That review is how the procedure improves without a consultant.

How do you confirm identity without collecting more data?#

Match the request to records you already hold, and ask for nothing you would not already have. A data request is not a reason to collect a new ID copy.

The application must itself carry the name and surname (and a signature if written), the T.C. identity number for Turkish citizens or the nationality and passport or identity number for foreigners, an address for notification, and the subject of the request (Official Gazette, 10 March 2018, No. 30356, Article 5). That is the applicant's own content, not new collection by the hotel.

Verify against the reservation: reservation code, stay dates, the email or phone already on the guest card, the name on the folio. A request from an address the hotel already holds is the strongest single signal. If the request comes from an unknown address, call the number on the reservation, confirm, and ask the guest to resend from the address on file.

Third parties need authority: a lawyer, a family member, an agency. Ask for written authority and confirm with counsel what is sufficient before anything is released. If identity cannot be confirmed, reply in writing that you cannot proceed yet, say what would let you, and log the attempt. Silence is the one response that always looks wrong later. Staff must not read a guest's data to an unverified caller, even one who knows the room number and the departure date.

Where does guest data actually sit in a hotel?#

In more places than the PMS: the guest card and folio, the booking site's inbox, the hotel's email, staff phones, the restaurant till, the spa book, the door-lock log, the KBS notifications (the guest identity notification required of every lodging facility) and sometimes a paper registration card in a cabinet.

Set a search order and keep it: PMS guest card and folio, reservation and channel messages, hotel email, guest app, outlet systems (restaurant, bar, spa), access and door-lock logs, KBS notifications, paper and spreadsheets, then the accountant and the e-invoice integrator. Write down, for each system, who holds it and how to search it. That list is the procedure; without it the search depends on who is on shift. The same inventory matters when you change systems, as covered in what to move, check and leave behind in a PMS data migration.

Paper registration cards are the classic gap. Decide where they are stored, who holds the key, how a card is retrieved for a request without the file leaving the office, and how long they stay; the retention period is a question for counsel. Guest messages on a receptionist's personal phone are hotel data on a personal device. The fix is to move guest messaging to a hotel-owned channel; until that is done, the search must include staff devices and the owner must ask staff directly.

The PMS should be able to export one guest's record without exporting the database. If it cannot, that is a question for the vendor and a line in the risk list. Booking sites and e-invoice integrators hold their own copies under their own terms; your reply covers what the hotel holds, and counsel confirms how the rest is handled. Record the search result per system even when it is empty, and date it. The file should show a complete sweep, not a lucky find. For the wider frame of what a stay obliges, see the four steps of every stay, including the guest identity notification.

What must you keep, and what can you correct or delete?#

Split the request into three answers: what you will correct, what you will delete or stop using, and what another duty requires you to keep. The guest is entitled to a clear answer on all three.

The rights are specific: learn whether data is processed and for what purpose, know the third parties in Türkiye or abroad it was transferred to, ask for correction, ask for deletion or destruction, and object to a result against the person that comes solely from automated analysis (Law No. 6698, Article 11 (opens in a new tab), mevzuat.gov.tr, consolidated text, 1 November 2026). Deletion is conditional, not automatic. When the reasons for processing end, the controller deletes, destroys or anonymizes the data on its own initiative or at the person's request (Law No. 6698, Article 7). Where a record must stay, anonymizing it can meet the same aim as deleting it.

Fiscal records are the clearest example of a duty that outlasts a request. An invoice must show the customer's name and address, and those who keep books retain books and documents for five years from the calendar year after the year they relate to (Tax Procedure Law No. 213, Articles 229, 230 and 253 (opens in a new tab), mevzuat.gov.tr, consolidated text, 1 November 2026). Confirm the hotel's own position with the accountant before you write it into a reply. How long a hotel must keep its own KBS records is not settled in the sources we could verify; ask the authority and counsel rather than guessing in a letter.

Correction means correcting the live record and noting it in the file. Where data was transferred to a third party, the deletion regulation requires notifying that third party (Official Gazette, 28 October 2017, Articles 11 and 12); confirm the scope with counsel. Controllers required to register with the Data Controllers' Registry prepare a retention and destruction policy with periodic destruction intervals that may not exceed six months; controllers without such a policy destroy at three-month intervals (Official Gazette, 28 October 2017, Articles 5 and 11). Whether a given hotel must register is a question for counsel. Do not delete a record that is part of an open dispute or an unpaid bill; say so plainly in the reply, with the reason and the period. For the wider context of notices, consent and retention, see KVKK for hotels.

How do you write the reply?#

One letter in plain language that mirrors what the guest asked, with a readable copy of their data, sent by a route you can prove.

Follow the guest's own order. If she asked three things, answer three things, each under its own short heading. Give a readable copy, not a database export: stay dates, contact details on file, folio lines, messages, and the purpose each set serves. A screenshot of the PMS screen is not a readable copy. No internal codes, no record-type numbers, no legal citations unless the guest asked for them. Write in the guest's language where the hotel can.

The letter comes from the hotel as data controller and is signed with a role, such as data protection contact, not with the name of the receptionist who happened to be on shift. The statutory frame: conclude the request as soon as possible and within thirty days at the latest, free of charge unless the action involves an extra cost under the Board's tariff (Law No. 6698, Articles 11 and 13, mevzuat.gov.tr, consolidated text, 1 November 2026). Set an internal target well inside that window and confirm your calendar with counsel. Where a deletion request is carried out, the person must be informed within thirty days at the latest (Official Gazette, 28 October 2017, Article 12).

If part of the request is refused, say which part, why, and how the guest can challenge it. The exact grounds and wording go past counsel before they go to the guest. Send by the channel the guest used and by email to the address on file, and keep the sent copy in the file with its date.

What should you confirm with your lawyer and your accountant?#

The procedure is yours to write; the deadlines, refusal grounds, retention periods and registry duties are theirs to confirm. Put the questions in writing once and keep the answers with the procedure.

Ask about the response calendar and what counts as receipt of a request, including a message that arrives through a booking site or a social account. Ask about the grounds for refusing all or part of a request, the wording of that refusal, and the route open to the guest afterward. Ask about retention periods beyond the fiscal five years, including commercial-code periods and how long the hotel keeps its own KBS records, neither of which we could verify here.

Ask whether the hotel must register with the Data Controllers' Registry, and the retention and destruction policy and intervals that follow from the answer. Ask about cross-border transfers, if any system stores guest data outside Türkiye; ask the question rather than assuming the answer, and do not promise a guest where data is held. Breach notification: the law says as soon as possible, and the specific period is a question for counsel, not a line for a blog post. Finally, staff training and an annual review: the procedure should carry the date of its last review on the first page, so anyone picking it up knows how old it is. If AI assistants touch guest data, the questions in AI assistants and guest data belong in the same email.

What to do next#

Write the one-page procedure this week: name the owner and the deputy, open the log, list every system that holds guest data with the person who can search it, and send the five questions to counsel and the accountant in a single email. The parts fit in that order: intake, identity, search, decision, reply, and the questions only your advisers can answer.