Data Processing Agreement

This Data Processing Agreement (“DPA”) is made under Article 28 of the General Data Protection Regulation (EU) 2016/679 (“GDPR”). It forms part of the Host Terms of Service.

Version 1.0. Effective from 26 October 2026.

1. Parties and roles

1.1 The Controller is the Host: the accommodation business that uses CheckinGuest under the Host Terms.

1.2 The Processor is Prague Retreat Management s.r.o., Revoluční 1082/8, Nové Město, 110 00 Praha 1, Czech Republic, IČO 22473874, which provides CheckinGuest.

1.3 The Controller decides why and how guest personal data is processed. The Processor processes it only to provide CheckinGuest to the Controller.

1.4 Where Prague Retreat Management s.r.o. uses CheckinGuest for its own accommodation, it is the controller itself and this DPA does not apply to that use.

2. Details of the processing

Subject matter. Providing the CheckinGuest online check-in service described in the Host Terms.

Duration. For as long as the Host Terms are in force, and after that until the data is deleted or returned under section 11.

Nature and purpose. Collecting, storing, organising, reading, sending and deleting guest data so that the Controller can:

• register foreign guests with the Czech Foreign Police (Act No. 326/1999 Coll.);
• keep the guest register and the accommodation tax evidence book (Act No. 326/1999 Coll. and Act No. 565/1990 Coll.);
• manage reservations, check-in, door access and payments;
• keep proof of check-in, signature and acceptance of house rules and terms;
• communicate with guests and answer support requests;
• keep the service secure and prevent fraud.

Types of personal data.

• Identity and registration data: name, date of birth, nationality, travel document type and number, visa or residence permit number, home address, purpose of stay, arrival and departure dates.
• Reservation data: name on the booking, booking reference, room, stay dates.
• Photos of travel documents, read in memory only and not stored by the Processor.
• Signature, consent records (text shown, time, IP address, browser).
• Door access codes and their validity dates.
• Payment data: email address, amounts and payment status. Card details go straight to Stripe and do not reach the Processor.
• Messages and support chat content.
• Police submission confirmations (doručenka).

Special categories. None are intended. Nationality is collected because the law requires it. Guests are asked not to put sensitive data in messages.

Categories of data subjects. The Controller's guests, including people travelling with the main guest. Also the Controller's staff who use CheckinGuest, for their login and activity data.

3. Instructions

3.1 The Processor processes personal data only on the Controller's documented instructions. These are the Host Terms, this DPA, and the settings the Controller chooses in CheckinGuest.

3.2 This also applies to transfers to a country outside the EU. The Processor may process data without instructions only where EU or Czech law requires it. In that case it will tell the Controller first, unless the law forbids that.

3.3 The Processor will tell the Controller straight away if it thinks an instruction breaks the GDPR or other data protection law.

4. Confidentiality

The Processor makes sure that everyone it authorises to process the personal data has committed to confidentiality, or is under a legal duty of confidentiality. Access is limited to people who need it for their work.

5. Security

5.1 The Processor takes the technical and organisational measures required by Article 32 GDPR. The current measures are listed in Annex 1.

5.2 The Processor may update these measures, as long as the overall level of security does not go down.

6. Subprocessors

6.1 The Controller gives the Processor general authorisation to use subprocessors. The current list is at checkinguest.com/subprocessors.

6.2 The Processor will tell the Controller at least 30 days before adding or replacing a subprocessor.

6.3 The Controller may object on reasonable data protection grounds within those 30 days. If we cannot resolve the objection, the Controller may end the Host Terms with effect before the change, without a penalty.

6.4 The Processor puts the same data protection duties on each subprocessor by written contract. It remains responsible to the Controller for its subprocessors.

6.5 Not a subprocessor: the Czech Foreign Police receive registrations through UbyPort because the law requires it. They are an independent recipient acting under their own legal powers, not a subprocessor.

7. International transfers

Where a subprocessor processes personal data outside the European Economic Area, the transfer is covered by an adequacy decision (including the EU-US Data Privacy Framework) or by the EU Standard Contractual Clauses. The basis for each subprocessor is shown on the subprocessors page.

8. Help with data subject requests

8.1 Taking into account the nature of the processing, the Processor helps the Controller answer guests who use their GDPR rights (access, correction, deletion, restriction, portability, objection).

8.2 If a guest sends a request to the Processor about the Controller's data, the Processor passes it to the Controller without undue delay and does not answer it itself, unless the Controller asks it to.

8.3 CheckinGuest gives the Controller tools to export a stay's data and to erase it once the legal storage period has ended.

9. Help with the Controller's other duties

Taking into account the nature of the processing and the information it has, the Processor helps the Controller meet its duties under Articles 32 to 36 GDPR: security, breach notification, telling affected guests, data protection impact assessments, and prior consultation with the supervisory authority.

10. Personal data breaches

10.1 The Processor will tell the Controller about a personal data breach without undue delay, and aim to do so within 48 hours of becoming aware of it.

10.2 The notice will describe, as far as is known: what happened, the types and rough number of guests and records affected, the likely effects, and what has been done or is planned to deal with it. Information that is not yet known will follow as soon as it is.

10.3 The Controller decides whether to notify the supervisory authority and the guests. The Processor will help.

11. End of processing

11.1 When the Host Terms end, the Controller may export its data during the period set out in the Host Terms.

11.2 After that, the Processor deletes the personal data, or returns it if the Controller asks, and deletes the remaining copies. This happens within 60 days, unless EU or Czech law requires the Processor to keep it.

11.3 The Controller is responsible for keeping the guest register and the accommodation tax evidence book for the period the law requires, after export.

12. Audits and information

12.1 The Processor gives the Controller all information needed to show that it meets Article 28 GDPR.

12.2 The Processor allows and helps with audits, including inspections, by the Controller or an auditor it appoints. The Controller gives at least 30 days' notice, except after a breach. Audits happen during business hours, avoid disrupting the service, and the auditor is bound by confidentiality. Each party bears its own costs, unless the audit shows a material breach by the Processor.

13. Liability and conflicts

13.1 Liability under this DPA is governed by the Host Terms, except where the GDPR does not allow it to be limited.

13.2 If this DPA conflicts with the Host Terms on any matter about personal data, this DPA applies.

13.3 This DPA is governed by Czech law.

Annex 1: Security measures

The measures in place on the effective date:

• EU hosting. The database and file storage are hosted in the EU (Ireland). The application runs in Frankfurt, Germany.
• Encryption in transit. All traffic to and from CheckinGuest uses HTTPS. Registrations to the police are sent through an encrypted tunnel.
• No direct database access from browsers. Guests and staff never connect to the database. All access goes through the application server, which checks every request.
• Access control. Staff sign in and can only reach data for the properties they are assigned to. Guests use a signed session cookie that only reaches their own stay, and guest links expire after the stay.
• No storage of document images. Photos of travel documents are read in memory and are never written to the database or file storage.
• No card data. Card details are entered directly into Stripe and never reach CheckinGuest.
• Private file storage. Police confirmations and incident evidence are kept in private storage with no public links, and are served only through checked application routes.
• Pseudonymised matching. In incident records, travel document numbers are stored only as a keyed hash, not as the number itself.
• Restricted incident access. Only managers can read incident record details and open their files.
• Rate limiting on the public check-in endpoints, to slow down guessing and abuse.
• Audit logs for changes to guest data, for searches of incident records by document number, and for erasures.
• Retention and erasure tools. A nightly job deletes guest chat and support messages 90 days after check-out, event RSVPs 30 days after the event, and incident records with their files when they expire. Registration data, signatures and consent records are kept for the six year legal period and then removed with an erasure tool. They are not deleted automatically.
• Subprocessor contracts. Every subprocessor is bound by a written data processing agreement.