Data processing agreement

1. Parties and scope

This data processing agreement ("DPA") is concluded between:

• the customer — the organization that has accepted it through its Vivestay account, acting as controller; and
• Cloudsource LTD, registration number HE 478194, registered office Strovolou 77, Strovolos Center, Office 401, 2018, Strovolos, Cyprus ("we", "us"), acting as processor.

It forms part of, and is governed by, the terms and conditions. It applies to all personal data we process on the customer's behalf in providing the Vivestay service, and it prevails over the terms and conditions to the extent of any conflict about data protection.

It does not apply to personal data for which we are ourselves the controller — the customer's account, billing, support and security data. That processing is described in the privacy policy, and a controller does not conclude an Article 28 agreement with itself.

2. Subject matter, nature and purpose

We process personal data solely to provide the Vivestay service: collecting guest registration data on the customer's behalf, validating it against the rules the customer has configured, retaining it as an auditable record, and preparing and recording submissions to an accommodation-reporting authority where the customer has enabled that; and operating and identifying the customer's reservations in the service.

The customer's reservation data is processed for that last purpose and, where an accommodation-reporting obligation requires it, to report the booking. It may be entered by the customer, supplied through the customer's integrations, or received from a property-management system the customer connects.

The duration of the processing is the term of the customer's agreement, extended only by the retention obligations in section 10.

3. Categories of data subject and of personal data

Data subjects. Guests and other travellers whose registration data the customer collects; the person a booking was made by or is held in the name of (the booking holder), who may not be one of the guests who stay; the customer's own users to the extent their identity appears in the audit trail of a guest record.

Categories of personal data. Identity data required by the applicable accommodation-reporting obligation — typically name, date of birth, nationality, identity document type and number, and the dates and address of the stay — together with contact details where the customer collects them, and the record of who entered or amended each field and when.

Reservation data consists of the details of each booking held in the service and, for its booking holder, the name under which the booking was made, which may be entered by the customer, supplied through the customer's integrations or received from a connected property-management system. Information we receive about the booking holder from a connected property-management system is limited to that name. Separately, where the customer enters them, or supplies them through its own integration, because the Spanish accommodation-reporting obligation requires the holder of the booking contract to be identified when the booking is communicated, we also process the holder's first name, surnames, telephone number and email address. Booking-holder information is kept separately from guest registration data: it does not register a guest and is not treated as a guest's registration details.

Identity document data is of a sensitivity that warrants particular care, and we treat it accordingly. We do not require, and the service does not ask for, special categories of data under Article 9, and the customer must not submit any through the service.

4. Our obligations

We will:

1. Process personal data only on the customer's documented instructions, including as to international transfers, unless required otherwise by EU or member-state law — in which case we will inform the customer before processing, unless that law prohibits it. This DPA, the customer's configuration of the service, and their use of its documented features together constitute those instructions.
2. Inform the customer if, in our opinion, an instruction infringes the GDPR or other applicable data-protection law.
3. Ensure that people authorised to process the data are bound by an appropriate obligation of confidentiality.
4. Implement the technical and organisational measures described in section 7.
5. Respect the conditions in section 5 for engaging a sub-processor.
6. Assist the customer, by appropriate technical and organisational measures and insofar as possible, in responding to requests to exercise data-subject rights.
7. Assist the customer with Articles 32 to 36 — security, breach notification, data protection impact assessment and prior consultation — taking into account the nature of the processing and the information available to us.
8. At the customer's choice, delete or return the personal data at the end of the provision of services, and delete existing copies, subject to section 10.
9. Make available the information necessary to demonstrate compliance with Article 28, and allow for and contribute to audits, as described in section 8.

5. Sub-processors

The customer gives general written authorisation for us to engage sub-processors. The roles we engage, what each of them does, and how to obtain the identity of the party currently performing each role are in Annex III.

Engagement. We engage a sub-processor only under a written contract imposing data-protection obligations equivalent to those in this DPA, and we take reasonable steps to ensure that the applicable Article 28 obligations flow down to it. We remain fully liable to the customer for a sub-processor's performance of those obligations.

Notice of change. We will give affected customers at least 30 days' advance electronic notice of an intended addition or replacement of a sub-processor. Notice may be sent to the administrative email address registered on the organization, or given through another established electronic notification mechanism in the service.

Objection. Within that notice period the customer may raise a reasonable, documented objection on data-protection grounds. We will make reasonable efforts to address a legitimate objection — for example by offering an alternative arrangement or an additional safeguard. Where no reasonable solution can be found, the customer may terminate the affected part of the service without penalty for the remainder of its term. An objection does not require us to abandon a provider for every other customer, and this clause is not a veto over how the service is operated generally.

No sub-processor is named in the operative clauses of this agreement, and Annex III states the roles rather than freezing identities into an immutable text. A change of provider is therefore handled by the notice and objection mechanism in this clause, not by renegotiating the agreement — and the customer obtains the current identities from us on request, as Annex III sets out.

6. International transfers

We do not promise that personal data will be processed only within the European Economic Area. Where processing constitutes a restricted international transfer under Chapter V GDPR, we will put an appropriate lawful transfer mechanism in place before that processing begins. That may be an adequacy decision, the applicable EU standard contractual clauses, or another legally valid Chapter V mechanism.

Where the standard contractual clauses are legally required for a particular transfer, the applicable clauses govern that transfer and prevail over any conflicting provision of this DPA in respect of it.

For each party performing a role in Annex III, we state where the processing takes place and the transfer mechanism relied on where it occurs outside the European Economic Area, as part of the information Annex III gives on request. We do not claim a safeguard we have not put in place.

7. Security

We implement technical and organisational measures appropriate to the risk, taking into account the state of the art, the costs of implementation, and the nature, scope, context and purposes of processing.

Measures in place include: encryption of all traffic in transit; passwords stored only as cryptographic hashes; separation between customer organizations enforced at the database level rather than only in application code; secrets held encrypted at rest under managed keys; access to production systems limited to named accounts; an immutable audit trail of significant actions; and structured logging that minimises personal data — guest registration identity and identity-document content are not written to ordinary application logs, while technical request metadata such as the network address a request came from is processed where necessary to operate and secure the service.

We do not describe our infrastructure, hosting arrangements or internal architecture here. Publishing an operational map of a system holding passport-grade identity data would reduce its security, not demonstrate it. We will describe our measures in the detail an audit reasonably requires, under section 8.

No system is perfectly secure and we will not pretend otherwise. What we commit to is proportionate measures, honest disclosure, and notification where the law requires it.

8. Audit

We will make available to the customer the information reasonably necessary to demonstrate compliance with Article 28, and will allow for and contribute to audits and inspections conducted by the customer or an independent qualified auditor it mandates.

Documentation first, where it answers the question. We will respond to an information request with documentation, certifications and compliance or security reports, or through a remote review, wherever those reasonably satisfy the request. That is not a substitute for the audit right below; it is the quickest way to answer most of what an audit is asked to establish.

Conducting an audit. The customer may conduct an audit where reasonably necessary to verify our compliance with this DPA. Reasonable advance notice is required, except where genuine urgency makes advance notice inappropriate. Audits take place during normal business hours and must be conducted so as to minimise disruption to the service and to our other customers. The customer and any auditor it mandates are bound by confidentiality and by our reasonable security requirements while on site or connected to our systems.

What an audit cannot reach. An audit must not expose another customer's data, the credentials of any person or system, security-sensitive information whose disclosure would weaken the protection of personal data, or information we are prohibited by law or by a binding obligation from disclosing.

Costs. The customer bears its own costs of an audit, and our reasonable extraordinary costs caused by an audit it requests. We will not charge those costs where the audit is reasonably required because of a material breach by us, or where applicable law or a supervisory authority requires otherwise.

No arbitrary frequency limit is imposed. We do not restrict the customer to one audit in a period where its Article 28 rights reasonably require another — for example after a personal data breach or a material change in the processing.

9. Personal data breach

We will notify the customer without undue delay after becoming aware of a personal data breach affecting personal data we process on their behalf.

With that notification, and afterwards as the position becomes clearer, we will provide the information reasonably available to us that the customer needs in order to meet its own obligations under Articles 33 and 34 — the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, and the measures taken or proposed. Where the full picture is not yet available we will provide information in phases rather than delay the first notification until everything is known.

We will cooperate reasonably with the customer's investigation, with mitigation, and with its obligations towards a supervisory authority or data subjects.

No fixed contractual hour limit applies to our notification, and this clause does not transfer the controller's own deadline to us: the 72-hour period in Article 33(1) runs against the controller, and our obligation is to notify without undue delay and to assist the controller in meeting it.

10. Retention, return and deletion

At the end of the provision of services, we will delete or return the guest registration data at the customer's choice, and delete existing copies, except where EU or member-state law requires storage. Reservation data is treated as described below.

That exception is not theoretical and the customer should read it carefully. Guest registration data is frequently subject to a statutory retention period set by the law creating the reporting obligation, and neither the customer nor we may shorten it. Where such a period applies, we retain the data for its duration and process it for no other purpose, then delete it under the platform's retention lifecycle.

Reservation data is not currently on that lifecycle. The retention periods described in this section, and the platform's retention lifecycle as it currently operates, apply to guest registration records. Reservation data, including the booking-holder information described in section 3, is not currently subject to an automatic retention or deletion schedule, and deletion of reservation data at the end of the provision of services has not yet been defined or implemented. The customer can export its reservation data as described in the terms and conditions. That describes the present state of the service, not an intended retention period: the retention of reservation data remains subject to applicable legal requirements and to the platform's retention policy once one is defined for that data.

Where the customer is subject to Royal Decree 933/2021, a guest registration record passes through two distinct periods, and they should not be confused with each other.

• Months 0 to 36 — the statutory period. Royal Decree 933/2021 requires an operator subject to it to keep the register for three years from the end of the accommodation service. That obligation is the customer's, it binds us as its processor, and neither of us may shorten it.
• Months 36 to 42 — restricted preservation. When the statutory period expires we do not delete the record immediately. We preserve it for a further six months for two purposes and no others: the establishment, exercise or defence of legal claims, and the resolution of a late dispute about compliance with the accommodation-registration obligation. Royal Decree 933/2021 does not require these six months and we do not claim that it does. During them the record is not used for ordinary operational purposes, for guest management or for anything else, and it is handled only for the two purposes above and by those authorised to deal with a claim or a compliance dispute.
• At month 42 — permanent deletion. The personal data is permanently deleted, unless a specific legal hold or another applicable legal obligation independently requires it to be kept for longer.

Where the customer is not subject to that statutory obligation, the three-year period is not imposed on it by Royal Decree 933/2021 and we do not represent that it is. Retaining identifiable guest data in that case needs a lawful basis and a defensible retention purpose of the customer's own, as controller; our retention engine is configured by policy rather than hard-coded, so a different period can be applied. Vivestay's initial commercial target is Spanish professional accommodation operators.

The customer remains the controller throughout, remains responsible for the lawful basis on which its data is kept, and may give us different documented instructions to the extent permitted by applicable law and this agreement. No instruction can require us to delete or alter a record that EU or member-state law requires either of us to keep, or otherwise to act unlawfully; where an instruction would have that effect we will tell the customer instead of acting on it.

Retention is never a reason not to let a customer leave. Where we are required to keep a record, we keep it for that reason only, and we will not use it to delay, complicate or refuse a customer's export, portability or switching request.

We will make the customer's data available for export as described in the terms and conditions, and a record we must retain is excluded from erasure but not from export.

11. Controller obligations

The customer warrants that it has a lawful basis for the processing it instructs, that it has provided any information notice its own data subjects are entitled to, and that its instructions comply with applicable law. The customer is responsible for configuring properties, jurisdictions, deadlines and reporting entities correctly; we act on the configuration given to us.

We never determine who the obligated party is under an accommodation-reporting obligation, and nothing in this agreement or in the service constitutes legal advice.

12. Liability

One liability framework governs this agreement and the terms and conditions together. The limitation of liability in the terms and conditions applies to claims under this DPA, and this DPA does not add a separate cap of its own: our aggregate liability for all claims arising under the terms and this agreement together is limited as stated there, and a claim under this agreement does not create an additional amount recoverable on top of it. There is no separate data-protection or confidentiality super-cap.

What no cap can limit. Nothing in this agreement or in the terms and conditions purports to limit or exclude:

• liability that applicable mandatory law does not permit to be limited or excluded;
• the powers of a data protection supervisory authority, including its power to impose an administrative fine;
• a liability under the GDPR that cannot lawfully be limited; or
• the independent rights and remedies of a data subject, including the right to compensation under Article 82 GDPR and the right to lodge a complaint.

13. Term, governing law and contact

This DPA takes effect when the customer accepts it and continues for as long as we process personal data on their behalf. It is governed by the laws of Cyprus, and the courts named in the terms and conditions have jurisdiction over it, subject in each case to mandatory rules that cannot validly be displaced and to the rights and remedies preserved by section 12.

Data-protection contact: hello@vivestay.com. Postal contact: Cloudsource LTD, Strovolou 77, Strovolos Center, Office 401, 2018, Strovolos, Cyprus.

Data protection officer. Cloudsource LTD has not appointed a data protection officer, having assessed that the current processing does not trigger a mandatory designation under Article 37 GDPR. Data-protection requests are handled at the contact address above, and the position is reassessed if the nature or scale of the processing materially changes.

14. Annexes

Annex I — subject matter, duration, nature, purpose, data and data subjects: sections 2 and 3 above.

Annex II — technical and organisational measures: section 7 above.

Annex III — sub-processors

Who belongs in this annex. A party is listed here if, and only if, it processes personal data that we hold on a customer's behalf — the guest registration data and reservation data described in section 3, for which the customer is controller and we are processor. That is what Article 28(2) and 28(4) govern, and this annex is scoped to it.

What is stated for each party. Name and country of establishment, so the customer can identify it and carry out its own due diligence; what it does for us; the categories of personal data it has access to; where the processing takes place; and the transfer mechanism relied on where processing occurs outside the European Economic Area. We do not state our commercial terms with a provider, the components it serves, or anything else that would amount to an architecture description: a customer's Article 28 assessment needs to know who processes its data, what they do with it and where, and publishing more would weaken the security of a service holding passport-grade identity data without telling the customer anything it needs.

The roles engaged. Exactly two roles qualify under the test above, and no others:

• the infrastructure provider on which the Vivestay application, its database and its backups run; and
• the transactional email provider through which guest invitations and service messages are delivered.

No other party processes personal data on a customer's behalf. Where a single party performs both roles, there is one sub-processor and we say so.

How to obtain the current identities. We give the customer, on request and without charge, the identity of the party performing each role together with each of the five facts stated above, and we do so before the customer's data is first processed if it asks then. Any addition or replacement is notified in advance under section 5, with the objection right that section gives.

We furnish the identities this way rather than freezing them into the text of this agreement for a reason that matters to the customer rather than to us: each published version of this agreement is immutable. A provider change would otherwise require a new version of the whole agreement to keep one line accurate, and until that happened the customer would be relying on a name that had quietly gone out of date — which is worse than no name at all, because it looks current. Section 5 already carries the mechanism that keeps the customer informed, and this annex uses it instead of duplicating it in a form that cannot be corrected.

Nothing in this paragraph narrows section 5: the general authorisation, the 30 days' advance electronic notice, the documented objection right, the flow-down of equivalent obligations and our full liability for a sub-processor's performance apply to every party performing either role.

Parties that are not sub-processors. Three kinds of party are involved in the service and none of them belongs in this annex. They are set out because a customer carrying out due diligence will ask about each, and an answer given once in the agreement is better than the same answer given differently three times.

• Our payment provider. Subscription and invoicing data is personal data for which we are the controller — it is our commercial relationship with the customer, not the customer's data about its guests — and no guest registration data reaches a payment provider. Card details are handled by the provider directly and never reach us. That processing is described in the privacy policy; it is not Article 28 processing carried out on a customer's behalf, so its provider is not a sub-processor of the customer's data.
• An accommodation-reporting authority. Where the customer has enabled reporting, we prepare and transmit a submission to the national authority the obligation runs to. That authority receives the data under a legal obligation and determines for itself what to do with it: it is a separate controller, not anyone's processor. The obligation is the customer's, and we transmit on the customer's instruction.
• A system the customer connects. Property-management systems, channel managers and calendar feeds are the customer's own suppliers, chosen and authorised by the customer. Data reaches us from them because the customer instructed it. We do not engage them and we hold no contract with them on the customer's behalf; their processing is governed by the customer's own agreement with them.

Changes to this annex are made under section 5, with the notice and objection rights described there.

Version 1.1 · effective 27 September 2026