Guest Data Requests: Access and Deletion Across Systems

“Please send me all the personal data you hold about me, then delete it.” A hotel receives the message after a four-night stay. The front desk can export the guest profile immediately. But arrival arrangements were discussed by phone, a luggage question was handled through a messaging app, and a room photograph was sent to the cleaning company.

This starts a process that an export from the property management system (PMS) cannot complete on its own. The following case is a fictional editorial example. It shows how an accommodation business can coordinate access and erasure across systems without exposing someone else’s information or prematurely destroying records it needs to retain.

Which rules apply to this business?

For a private Swiss accommodation business, the Federal Act on Data Protection (FADP) is the starting point. Whether the EU General Data Protection Regulation (GDPR) also applies to a particular processing activity requires a separate assessment. A guest’s German passport does not establish this by itself.

Article 3 GDPR covers, among other things, processing in the context of an EU establishment’s activities and certain processing related to services targeted at people who are in the EU. Monitoring their behavior within the EU may also be relevant. The European Data Protection Board’s territorial scope guidelines explain these distinctions. A website being accessible worldwide does not settle the question. When the position is unclear, assess the actual activity before relying on a deadline or exemption from the wrong legal framework.

Record the request before starting the search

In our example, one designated person coordinates the response. She records the receipt date, scope, contact channel, and response deadline, then acknowledges the request. Access and subsequent erasure are treated as related but distinct tasks. Relevant data should not disappear before the requested access has been prepared. Equally, handling the request does not justify creating an indefinite additional archive.

Under Article 18 of the Swiss Data Protection Ordinance, access must be provided within 30 days of receiving the request. If this is not possible, the controller must inform the person and state when the information will be provided. Refusal, restriction, or deferral must also be communicated within that period. This rule concerns access. It is not a general statutory 30-day deadline for every erasure request.

Where the GDPR applies, Article 12(3) requires information about the action taken without undue delay and within one month at the latest. An extension of up to two further months is possible where justified by the complexity or number of requests. The person must be told about the extension and its reasons within the first month. A busy support department is not a substitute for that justification.

Verify identity without creating unnecessary records

Before releasing information, establish that the requester is entitled to receive it. A message from an unknown email address carrying a former guest’s name is not necessarily sufficient. Nor should every request automatically trigger a demand for a complete passport copy.

Choose verification proportionate to the risk, such as an already verified account or an additional confirmation through an existing contact channel. Further information may be needed if doubts remain. Unnecessary identity document details do not belong in the case file. The Swiss Federal Data Protection and Information Commissioner (FDPIC) specifically addresses identification and protection against unauthorized disclosure. Under the GDPR, Article 12(6) permits additional identifying information where reasonable doubts exist.

A request on behalf of a spouse or travel group also requires verification of the person’s authority to act. Paying the invoice does not automatically entitle someone to all the other travelers’ information.

Follow the stay and the paths its data took

The coordinator locates the guest profile and reservation in the PMS. She then checks email, the business messaging app, relevant service cases, and the telephone system in use. Booking references, stay dates, and known contact details help connect the records. The search follows the scope of the request and the data actually being processed. It does not require collecting new information about the guest.

In this fictional case, a cleaning photograph includes a readable luggage label. The image is outside the guest profile but can still be linked to the stay. An internal complaint note can contain personal data too. Labeling something “internal” does not automatically exempt it from access.

For each relevant location, record who checked it, what was found, and whose response is still outstanding. Local exports and devices used for business belong in the search where they hold relevant information. The goal is a traceable search, not an indiscriminate copy of every company folder.

The software provider does not automatically take responsibility

Where the hotel determines the purposes and means of processing, it is the controller for that activity. When a provider processes data on its behalf, assistance must be organized. Under Article 25(4) FADP, the controller remains responsible for providing access even where a processor holds the data. Article 17 of the Data Protection Ordinance addresses the processor’s assistance.

The FDPIC’s outsourcing guidance emphasizes that outsourced data must remain accessible and people must still be able to exercise their rights. In practice, a provider request needs a clear connection to the guest, the required scope, and a return date before the hotel’s own response deadline.

However, not every recipient is a processor. A booking platform or payment provider may be an independent controller for particular activities. Its role follows what it actually does, rather than the contractual label alone. The hotel answers for its own activities and explains the boundary. It does not promise erasure in another controller’s systems when it cannot decide or verify that outcome.

With AI phone systems, deleting a conversation may not be enough

A telephone service may store audio, a transcript, and a summary separately. If the conversation generated a task or an email, further copies exist. The coordinator therefore checks both the conversation and the personal information transferred from it.

ElevenLabs, for example, documents separate retention settings for transcripts and audio and an API operation for deleting individual conversations. Neither establishes that deleting a conversation will also remove a copy in the PMS or a forwarded message. Those connections need to be traced and tested in the business’s actual setup.

It is also too broad to claim that AI automatically learns from every guest’s data. Training use depends on the service, contractual arrangement, and settings. The ElevenLabs privacy policy, for example, describes a separate training preference. Retention, erasure, and training use therefore need separate checks. Our existing guide to AI in hotels and phone automation covers implementation. This article addresses the records those applications leave behind.

Provide access while protecting other people

The guest needs understandable information about their personal data actually being processed. A generic privacy policy or a list of software products is not enough. Depending on the applicable rules, the response also needs purposes, retention periods or their criteria, sources, and recipients. Include the required information about international transfers where relevant.

Review the material before release. A messaging thread may contain a companion’s details, while a photograph may show someone else. That calls for a specific assessment of the competing interests. Where needed, redact relevant passages or provide extracts without making the information to which the guest is entitled unintelligible. The European Data Protection Board’s access guidelines explain why the rights of others do not justify refusing the entire request by default.

The coordinator assembles understandable files and checks the recipient again. The transfer method should reflect the content and its risk. A publicly accessible sharing link would be unsuitable for a complete guest dossier.

Erase, retain specific records, or restrict processing first?

Each dataset requires its own decision. Under Article 6(4) FADP, data must be destroyed or anonymized once it is no longer needed for its processing purpose. This does not mean that every document becomes unnecessary at checkout. It also does not permit a business to retain everything just in case.

Article 958f of the Swiss Code of Obligations requires accounting records and accounting vouchers to be retained for ten years from the end of the financial year. That does not create a blanket ten-year period for guest messages, call recordings, or every photograph. Guest registration requirements must likewise be checked against the specific location and the records concerned.

A substantiated legal dispute may require separate assessment of relevant evidence. Record the specific reason, necessary scope, permitted access, and a review date. Under the GDPR, Article 17(3) includes certain obligations under EU or Member State law and the establishment, exercise, or defense of legal claims among the exceptions. They apply to the extent necessary, rather than providing unlimited justification for keeping the entire profile.

Following that review in our example, the invoice may be retained while a resolved luggage message and an unnecessary call recording are deleted. If a particular photograph is still needed for an outstanding claim, document the reason for retaining that specific record. Restricting processing and erasing data are different outcomes and should not be described as interchangeable.

Backups and evidence of completion need decisions too

An entry removed from the production system may remain in backups or logs. The people responsible for IT need to establish which copies are affected, how access is limited, and how a later restore handles data already approved for erasure. A backup is not an automatic exception to the right to erasure.

As an operational minimum, use a documented procedure with deletion or overwrite periods and a way to reapply erasure decisions after a restore. Whether that procedure meets the legal requirements in the particular case needs separate assessment. Do not tell the guest that everything is complete while relevant actions remain outstanding.

Evidence of handling the request must also remain proportionate. The date, systems checked, decision, and completion confirmation may be useful. That does not automatically justify a permanent copy of every document supplied. The request file needs its own purpose, access controls, and retention decision.

Send a response that matches the actual outcome

The final message distinguishes what was provided, what was erased, and what remains stored for which reason and period or retention criteria. It also identifies outstanding actions. Explain any restriction or refusal. Where the GDPR applies, Article 12(4) requires a response when no action is taken that also explains the possibility of complaining to a supervisory authority and seeking a judicial remedy.

Recipients must be considered after rectification, erasure, or restriction. Article 19 GDPR requires communication to recipients unless this proves impossible or involves disproportionate effort. Outsourced processing is included in implementation in any event. An unanswered provider request stays open for follow-up rather than being recorded as completed.

Before the next request arrives, run the workflow using a synthetic guest record. Can staff find connected entries, make appropriate decisions, and verify implementation? This is the operational connection to Oprivia: organizing responsibilities, follow-up tasks, and evidence across existing systems. The appropriate support depends on the systems and processes already in place. The relevant specialists remain responsible for the legal decisions.

For the guest, the result should be an answer they can rely on. For the operator, that answer must agree with its own records and the confirmations received from its service providers.