Data Processing Agreement

1. Purpose and scope

This agreement governs the processing of personal data that Luis Fernández Couñago, tax ID 39489174Z, registered at Praza Fonte do Mouro, 2, 2ºD, 36800 Redondela, Pontevedra —hereinafter the processor— carries out on behalf of the property subscribing to PEMESE —hereinafter the controller—, under Article 28 of Regulation (EU) 2016/679 (GDPR) and Spanish Organic Law 3/2018.

It forms an inseparable part of the Service Terms and is accepted with them. Its content follows what Article 28.3 GDPR requires.

2. Role of each party

• The property is the controller of its guests' and staff's data: it decides what data it collects, why and for how long, and it must inform data subjects and have a lawful basis.
• The provider is the processor: it processes that data solely to deliver the contracted service and on the controller's documented instructions.
• For the customer's own account data —name, email and billing details of whoever subscribes— the provider acts as controller, and that is governed by the privacy policy, not by this agreement.

3. Duration

This agreement is in force for as long as the service contract is, and its confidentiality and return-or-deletion obligations survive its termination.

4. Nature and purpose of the processing

The processing consists of hosting, storing, consulting, structuring, modifying, communicating and deleting the data the controller enters into the application or that is generated by using it.

Its purpose is solely to deliver the contracted service: managing bookings and stays, the guest folio and its invoicing, check-in and the traveller register, housekeeping and maintenance, guest communication, the reports the controller configures and, if it contracts the opportunity engine, the analysis of the occupancy of its own dates and the price and restriction recommendations the controller decides to apply, itself or through the autopilot. To know which holidays outside its area move its demand, that analysis counts in aggregate where its guests come from, using the billing postcode and country, the company that pays and the phone prefix, never the nationality, identity document or residence collected for the traveller register, and it neither shows nor uses a place fewer than five guests come from. That analysis is done with each controller's data separately: no data is cross-referenced between properties of different controllers.

Guest communication includes offering them to object to the controller's offers when their data is collected —when booking on its website or at check-in— and in every message, and the record of that objection: at which property, when and where it was offered, which text they saw and whether they objected, stored with a pseudonymous fingerprint of their email —an HMAC with a secret key— rather than the email itself, and not linked to their guest record. It also includes, when the controller so decides, sending offers of stays from each of its properties to guests who have stayed at that same property and have not objected. An objection recorded at any of the controller's properties stops the offers of all of them, and it is not passed on to any other controller. The controller decides to send them and is responsible for their legal basis.

If someone reporting a bug from the application writes a guest's data in it, the processor processes that data only to resolve that bug, and it is erased with the report: twelve months after it is closed or twenty-four after it was sent, and earlier if the controller leaves. The report collects nothing from the screen beyond its address —without the parameters except those that say which view it was— and the text of the last error the application showed; that address may carry the internal identifier of a row —a guest record, a booking, an invoice or a service—, which the email notification of the report leaves out.

The processor does not use this data for any purpose of its own: it does not analyse it in identifiable form to improve its product, does not use it to train systems, does not transfer or commercialise it, and does not cross-reference it with other controllers' data.

5. Types of personal data

• Identifying: full name, type and number of identity document and its support number, date of birth, sex, nationality and kinship, as required by the annex to Royal Decree 933/2021.
• Contact: postal address, country and town of residence, telephone and email.
• Stay-related: check-in and check-out dates, room, board, companions, charges and any notes the controller records; and complaints, suggestions and compliments —those the guest writes through the link they are sent and those the staff record—, with the booking, the person in the booking and the room they refer to where there are any, who handles them and what was done.
• Financial: amounts, dates, payment method, operation identifier and billing details. The full card number never reaches the processor's servers: it is entered directly into the payment gateway. Of the payment method, the brand, the last four digits, the expiry date and the gateway's own reference are kept, so the guest can be told which card was charged, warned about one about to expire, and charged again where they authorised it.
• Usage: a record of which user did what and when inside the application.
• Commercial communication: whether they were offered to object to the controller's offers and whether they objected, at which property, when, through which channel and a fingerprint of the text they saw, stored with a pseudonymous fingerprint of their email —an HMAC with a secret key— rather than the email itself.
• The controller's representation certificate, where it is deposited so the processor can file on its behalf with the Spanish tax agency and SES.Hospedajes: the file and its password are stored encrypted, contain the identifying details of the individual who holds it, and are used only to sign those filings. The controller may withdraw it at any time, and it is destroyed when they do.
• The service is not designed to process special categories of data under Article 9 GDPR: there is no field intended to collect them. There are, however, free-text fields — the notes on a reservation and on services, and the text of a complaint or a suggestion — filled in by the controller's staff or by the guest, in which information of that kind may end up being written, such as an allergy when booking a meal or an illness described in a complaint. The controller decides what is collected in them and is the one who must have an Article 9.2 legal basis where that happens; the processor handles them like everything else, with the same security measures, without using them for any purpose of its own and without extracting any category from them.

6. Categories of data subjects

• Guests and their companions, including minors travelling with a responsible adult.
• Contact persons at companies and agencies booking with the property.
• Property staff with access to the application.

7. Processor obligations

Under Article 28.3 GDPR, the processor undertakes to:

• a) Documented instructions. Process the data only on the controller's documented instructions, including as regards international transfers, unless required to do otherwise by Union or Member State law, in which case it will inform the controller beforehand unless prohibited. Subscribing to the service and the configuration the controller chooses in the application constitute its documented instructions.
• b) Confidentiality. Ensure that persons authorised to process the data have committed to confidentiality, a duty that survives the end of the relationship.
• c) Security. Apply the technical and organisational measures of Article 32, described in section 10.
• d) Sub-processors. Not engage another processor without authorisation, on the terms of section 8.
• e) Data subject rights. Assist the controller, through the application's own features, in handling requests for access, rectification, erasure, objection, restriction and portability. If a data subject addresses a request to the processor, it will not act on it and will pass it to the controller without delay.
• f) Security assistance. Help the controller comply with Articles 32 to 36: security measures, breach notification, communication to data subjects and impact assessments, taking into account the nature of the processing and the information available.
• g) Return or deletion. At the controller's choice, return or delete the data when the service ends, on the terms of section 13.
• h) Information and audits. Make available to the controller the information needed to demonstrate compliance with these obligations and allow audits, on the terms of section 14.

8. Sub-processors

The controller gives general authorisation for the processor to engage the following services. With those that process data on the processor's behalf, an Article 28 GDPR processing agreement has been signed or accepted, carrying the same obligations the processor assumes; where a provider supplies a purely instrumental service with no ordinary access to the data, this is stated expressly:

• OVHcloud — hosting of the server and the database, in Gravelines (France, European Union).
• Cloudflare — storage of photographs, backups and the archived audit log, within European Union jurisdiction; and content delivery and attack protection.
• Resend — delivery of email to guests and property staff: transactional email and, where the controller sends it, commercial email to its former guests —the post-stay email and the offers in section 4—.
• Stripe — payment gateway. For guest payments the property holds its own account and its own relationship with Stripe; the processor only transmits the operation's data.
• Aiosell — distribution channel, only where the controller contracts that module, and for as long as its property stays linked to it: if the module is cancelled or goes unpaid, the channel is not cut off at once —that would leave the portals selling with stale prices and availability—, but when the property is unlinked. It receives and sends the booking data needed to operate with the portals. Aiosell Technologies Pvt. Ltd. has its registered office in India and its infrastructure in India and the United States: see section 9.
• Apple — the mailboxes for the domain's contact and support addresses, provided under the iCloud+ terms. They process what is written to those addresses and the internal notifications from the contact form and from each bug report —the latter without what was written in it or the identifiers in the screen's address—, and do not access the data the controller enters in the application; for that reason the service is provided without an Article 28 processor agreement, and guest data must not be sent to those addresses, as it is always handled inside the application.

The processor will inform the controller of any addition or replacement of the sub-processors it engages directly — those in the list above — at least 30 days in advance.

Where the provider being changed is one of those sub-processors' own, the processor will pass the notice on to the controller without delay from the moment it receives it. The period there is not set by the processor: it is set by the contract it holds with that sub-processor, and it may be shorter than 30 days. It is put this way rather than promising a single period because a promise that depends on a third party cannot be kept in writing: what is guaranteed is that the controller finds out as soon as we do, with the same right to object.

In either case the controller may object on reasonable data protection grounds; if the objection makes the service impossible to deliver, they may terminate the contract at no cost and with no penalty.

9. International transfers

The server, the database, file storage and email delivery are provided within the European Union: OVHcloud in Gravelines (France), Cloudflare under European Union jurisdiction and Resend delivering from the eu-west-1 region. Outside the European Economic Area, Stripe may process payment-operation data in the United States, under the safeguards of its own data processing agreement: the EU–US Data Privacy Framework, under which it is certified, and the standard contractual clauses.

The other international transfer exists only if the controller contracts the distribution-channel module: Aiosell Technologies Pvt. Ltd. has its registered office in India and its infrastructure in India and the United States. India has no adequacy decision from the European Commission, and the EU–US adequacy framework does not cover this transfer either: it covers US organisations that self-certify, and the recipient here is an Indian company. Both routes therefore rely on standard contractual clauses. No personal data travels out to Aiosell: what the processor sends them is availability, rates, restrictions and the no-show flag, which carries the property code, the booking identifier and the channel. The direction is the opposite one: the reservation arrives from them, because the portal where the guest booked gave it to them, and with it the name, the dates, the room type and the amount. That does not stop Chapter V GDPR from applying — they process that data on the controller's behalf — but it does pin down what is transferred, and which way.

The processor will not activate that module for a controller without first having in place the standard contractual clauses approved by Implementing Decision (EU) 2021/914 — module 3, processor to processor, which is the one that applies: the controller is the property and the exporter is its processor — and the assessment of the safeguards in the destination country. As at this revision both are pending signature. Accordingly the module is not active for any controller and no international transfer is taking place, and the software itself refuses to grant it while that remains the case. Once signed, a copy of both is available to the controller on simple request, in accordance with Article 46.1 GDPR.

10. Security measures

Having regard to the state of the art and the risks of the processing, the processor applies at least the following measures:

• Isolation per controller. Every row carries the identifier of the company it belongs to and no query runs without that filter. It is the application's data access layer that enforces this, watched by automated checks that run on every change and refuse to let code through if it breaks the rule. The database also declares row-level policies that protect against direct access with stolen credentials, but they are not the barrier that separates one controller from another: the code is.
• Encryption in transit on all communications, with strict transport security.
• Role-based access control, with differentiated permissions and access limited per property.
• Session timeout on inactivity, configurable by the controller.
• Audit log of the operations carried out, identifying the user and the moment.
• Daily backups, stored off the production server, with thirty days of retention and a verified restore procedure.
• Minimisation: no images or copies of identity documents are stored, only the details the rules require to be registered.
• Automatic deletion once retention periods expire, without depending on manual action.

11. Personal data breaches

The processor will notify the controller of any personal data breach without undue delay once it becomes aware of it, and in any event early enough for the controller to meet its own seventy-two-hour deadline under Article 33 GDPR.

The notification will include, as far as known: the nature of the breach, the categories and approximate number of data subjects and records affected, the likely consequences, and the measures taken or proposed. Where it is not possible to provide everything at once, it will be provided in phases without undue delay.

12. Controller obligations

• Have a lawful basis for the processing and inform data subjects properly.
• Enter into the application only the data that is necessary, and not include special categories in free-text fields.
• Configure its staff's permissions and revoke access for anyone who no longer needs it.
• Give the processor any instructions it needs, in writing and through the contract's contact addresses.
• Carry out, where applicable, the impact assessment and prior consultation.

13. Return or deletion on termination

Throughout the contract —including during a limitation for non-payment— the controller may export its reports as CSV from within the application, at no cost and with no formalities, and request the rest of its information — reservations, guest records, folios and invoices — in a structured, commonly used format, delivered within fifteen days and at no cost. Those two routes are the ordinary means of return.

Once the contract ends, the processor sends the controller its data —reservations and companions, guest records, folios, payments, invoices, services, client companies, complaints and objections to offers, in that same format— and tells it when it will be deleted. From 60 days after termination, and never before that notice has gone out, it is all deleted, backups included, except what Union or Spanish law requires to be retained —the accounting and invoicing records, and the payments and cash-drawer records that support them—, which is kept for that period and then deleted. Of the reservation and the service one of them points to, and of that reservation's guest, only the row is kept, emptied of anything that identifies a person —of the guest, only the country, nationality, language and dates remain, as when a record is anonymised at three years—, and of the client company, the name, tax ID and address the invoice already shows. Until the deletion, the controller can still look at and download its data, but no longer change it.

Backups hold the data as it stood each day, so an erasure can take up to thirty days to disappear from all of them. During that period the data is not accessed except to restore the service.

14. Information and audits

On a reasoned request, the processor will make available to the controller the information needed to demonstrate compliance with this agreement: a description of the security measures, the list of sub-processors and the location of the processing.

The controller may carry out or commission an audit, on at least thirty days' notice, during business hours, without interrupting the service and with the auditor bound by confidentiality. Unless the audit reveals a breach by the processor, its costs are borne by the controller, and it may not take place more than once a year save at the request of a supervisory authority or following a significant security incident.

15. Liability

Each party is liable for the damage it causes by breaching the obligations the GDPR specifically imposes on it, or by acting outside the other party's lawful instructions, under Article 82 GDPR. A processor that determines the purposes and means of processing outside this agreement is considered a controller in respect of that processing, under Article 28.10.