What Data Should a Hotel Receive Before Signing a Sauna-App Contract?

What Data Should a Hotel Receive Before Signing a Sauna-App Contract?

A hotel should receive a plain data schedule before signing. It should name each data category, its meaning, collection frequency, location, retention period, access route, export format, account roles, support access and exit treatment. Where data are personal data, GDPR duties and rights apply within their exact scope. If the arrangement qualifies as a connected product or related service under the EU Data Act, its pre-contract information and access rules may also apply. Neither law means the hotel owns every datum.

Key Takeaways

• Ask for a data inventory before discussing dashboards or attractive app screens.

• Separate product events, account records, support data and supplier-created analytics.

• Define who administers accounts, who can see data and who answers data-subject requests.

• Test a real export for fields, timestamps, units, identifiers and readable metadata.

• Record retention and deletion by data category, including the contract exit state.

• Apply GDPR and Data Act language only after checking their separate scopes.

Why should the data schedule come before the demo?

A demo proves that a screen can display something. It does not prove what the underlying record means, whether the hotel can retrieve it, how long it remains available or what happens after a supplier change. A procurement team should therefore compare the data contract, not only the interface.

I am Giedrius Patlaba, CEO of Wood Architects. From a manufacturer's side, the useful question is whether the digital handover is as specific as the physical one. Our public panoramic cube page identifies full-height glazing and a 128 mm wall build-up. Those are concrete product facts. They do not tell a hotel who can export a control event, recover an administrator account or interpret a timestamp. The digital package needs its own schedule and owner.

The EU Data Act gives a useful pre-contract structure only where the supplied arrangement falls within its definitions of a connected product or related service. Article 3 asks for information such as the type, format and estimated volume of product data, whether generation is continuous or real-time, storage location and retention, and how the user can access, retrieve or where relevant erase data. Article 4 addresses access to readily available data and relevant metadata. Scope, technical feasibility, security restrictions, trade secrets and other law still matter.

Separate the layers before asking what the hotel can view, export, retain or delete.

Which data categories should the supplier name?

Start with the smallest useful inventory. A device event might show that a command was sent or a state changed. An account record may identify an administrator or operator. Operational history may group events into sessions or alerts. Support data can include diagnostic material made available during a case. Derived analytics may be created by the supplier from several inputs. These categories should not be treated as interchangeable.

For every category, request the field name, definition, source, unit where relevant, timestamp convention, collection frequency, storage location, normal retention and user-facing purpose. Ask whether a field is raw, transformed, inferred or aggregated. If the system does not collect a category, record that answer too. A deliberate absence is better than a blank column that later becomes an assumption.

The physical interface also needs a boundary. A photographed door, handle and glass surface can help a team discuss what an event label might describe. It does not prove that any sensor exists or that a digital event corresponds to the visible hardware.

This real door and glass interface illustrates the object an event name might describe. It is not evidence of a sensor, app, data field or product identity.

What should an export test prove?

Do not accept the word export without a sample. Ask the supplier to produce one representative file or a clearly documented mock export before contract award. Check whether field names match the inventory, timestamps include a time zone, units are stated, identifiers remain stable and metadata explains codes. Check whether the hotel can open the file with ordinary tools and whether the export covers the period and sites selected by an authorised account.

Article 20 of the GDPR is narrower than a general business-data export. It concerns personal data relating to the data subject, provided by that person, where processing is based on consent or contract and carried out by automated means. Its conditions and effects should not be presented as a right for the hotel to port all device, operational or supplier-derived data. The contract can promise useful business exports beyond that legal minimum, but it should say so expressly.

If the Data Act applies, the relevant question is also not ownership. The Regulation establishes access and use rules for covered product data and related-service data. It includes relevant metadata and distinguishes data that are readily available from information that a product was never designed to store or transmit. Put the precise deliverable into the contract rather than using a broad ownership slogan.

How should accounts and privacy roles be split?

Ask who creates the first administrator, how a second administrator is approved, who can add and remove operators, whether supplier support can enter the account, and how access is recorded. The hotel should know the recovery route before the original administrator leaves. It should also know whether one account spans several properties and whether each property can be separated at export and exit.

Where personal data are processed, identify the controller and processor roles for each processing purpose rather than assigning one label to the whole commercial relationship. GDPR Article 13 requires specified information when personal data are collected from a data subject. Article 28 requires processing by a processor to be governed by a contract or other legal act with required content. A supplier may be a processor for one operation and act differently for another. The project privacy adviser should validate the actual arrangement.

Subprocessors, support access, hosting location, retention and deletion should be recorded in the same schedule, but this article does not design cyber controls or an outage plan. Those are separate decisions. For a broader procurement sequence, use our public guide on comparing two outdoor sauna quotes after all bidders have returned equivalent information.

Use this copyable sauna-app data schedule

SAUNA-APP DATA SCHEDULE
System and version:
Contracting parties:
Property or site scope:

For each data category record:
- category and field name
- plain-English definition
- raw, transformed, inferred or aggregated
- source and collection frequency
- timestamp convention and unit
- storage location and retention
- hotel view and access route
- export format, metadata and limits
- account roles with access
- support and subprocessor access
- deletion or retention at contract exit
- supplier evidence or sample

Account handover:
- first and second administrator
- recovery route
- operator removal process
- property separation

Legal scope check:
- personal-data purposes and roles
- privacy notice owner
- processor terms where applicable
- Data Act scope decision and reason
- unresolved local advice

Make each promise testable with an owner and an acceptance artefact before contract award.

What should happen at contract exit?

Write the exit as a sequence. Name who requests the final export, which categories and period it covers, how completeness is checked, when operator access ends, what remains under a justified retention rule and when deletion is confirmed. Include the treatment of backups only to the level the supplier can accurately promise. Do not use “all data deleted immediately” if the service cannot evidence that statement.

The schedule should also distinguish account closure from device transfer. A hotel may end one service while physical equipment remains on site. Record what functionality changes, which records remain accessible and what a replacement operator needs. This is a contractual handover question. It is not an outage-continuity design and it is not a digital product passport.

Frequently Asked Questions

Does GDPR give the hotel ownership of all sauna-app data?

No. GDPR governs personal data and gives rights to data subjects within defined conditions. It does not create a blanket hotel ownership right over every device event, operational record or supplier-created analysis. Contract language should separate legal rights from any additional business access the supplier promises.

Does the EU Data Act always apply to a sauna app?

No. The supplied arrangement must first meet the Regulation's relevant definitions and territorial scope. A buyer should document whether the sauna control is a connected product and whether the app is a related service, then apply the correct duties without extending them to excluded data.

Is a dashboard the same as data access?

No. A dashboard may offer a useful view without providing the underlying fields, metadata, history or an export. Ask separately what can be viewed, retrieved and machine-read, which account can do it, and whether selection by property and period works in a representative test.

Who should own the main administrator account?

The contract should name an accountable hotel role and a second authorised recovery route. The exact arrangement depends on the supplier's account model and the hotel group structure. Avoid an undocumented personal account that becomes inaccessible when one employee or external installer leaves the project.

What is the minimum useful evidence before contract?

Require a completed data schedule, a role demonstration, one readable export sample, the privacy role map where personal data are involved, and a written exit sequence. Any unknown field, retention rule or recovery path should remain an explicit open item rather than an assumed capability.

Sources: GDPR, Regulation (EU) 2016/679, EU Data Act, Regulation (EU) 2023/2854, and Wood Architects cube saunas. Legal scope and contract wording require project-specific review.