Skip to content
← Back to home

Privacy policy

Last updated: 2026-10-19

1. Data controller

Luis Fernández Couñago, tax ID 39489174Z, registered at Praza Fonte do Mouro, 2, 2ºD, 36800 Redondela, Pontevedra. Contact us at [email protected] for any data protection matter.

2. Two different roles

There are two situations worth telling apart:

  • Our customers' data (the property subscribing to PEMESE and its staff): we act as controller.
  • Guest data entered by the customer: we act as processor. The property is the controller and decides what data is processed and why. We process it only on their instructions, under Article 28 GDPR, on the terms of the Data Processing Agreement.

3. What we process and why

  • User account (name, email, hashed password): to create and maintain your account, authenticate you and provide support. Legal basis: performance of the contract.
  • Business data (properties, rooms, rates, reservations): to provide the contracted service. Legal basis: performance of the contract.
  • Guest data (name, contact details, ID document, nationality and other check-in data): processed on the customer's behalf so they can manage bookings and meet their legal duties.
  • Payment data (amount, date, currency, status and an identifier for the operation): to charge for the stay, issue the invoice and handle refunds. Legal basis: performance of the contract and compliance with tax obligations. The full card number never reaches our servers: it is entered into Stripe, which holds it. Of the card we keep the brand, the last four digits and the expiry date, so we can tell you which card was charged and warn you if it is about to expire.
  • Email delivery logs: to evidence that confirmations and reminders were sent. Legal basis: legitimate interest in service traceability.
  • Audit log (what was done inside the application, by whom and when): so a change can be reconstructed and accounted for. Legal basis: legitimate interest in security and traceability.
  • Email suppression list: if an address bounces permanently, or someone marks as spam an email that was not an offer, we stop writing to it; if what they mark is an offer from a property, or they ask to stop receiving them, we stop sending offers from that property and from every other property of the same business, while still sending the emails about their bookings. To honour that we keep a pseudonymous fingerprint (an HMAC with a secret key) of the address, not the address: with the key one can check whether a given address is on the list, but not read the addresses out of it. Legal basis: legitimate interest in respecting that signal and in not harming deliverability for the other properties that use the service.
  • Minimal technical data (access and error logs): to keep the service secure and working. Legal basis: legitimate interest.
  • Bug reports (what the person reporting a bug from the application writes, who they are and their role, the screen they were on, with its address stripped of the parameters except those that say which view it was, the language, the screen size, the version and the last error the application showed): to reproduce the bug, fix it and reply to you. They are read by the PEMESE team, not by the property. Legal basis: performance of the contract.
  • Information requests (name, email, phone, property, number of rooms, current system, timeframe, interests and whatever you write in the message): to answer your enquiry and, where appropriate, prepare a quote for you. Legal basis: pre-contractual steps taken at your request, where you are the one who writes to us through the site.
  • Contacts we note down ourselves: if you have spoken to us by phone, we met at a trade fair or someone passed on your name, we may record those same details without you having filled anything in. In that case the data did not come from you, so we will tell you where it came from and why we hold it at the latest the first time we contact you, in accordance with Article 14 GDPR. Legal basis: our legitimate interest in making the service known to properties that may need it, weighed against the fact that only professional contact details are recorded, never anything outside that activity, and that you can object and have them deleted with a single line. If you object, the row is deleted.

4. ID documents: we store no images

The check-in form collects the document details —type, number and support number— because Royal Decree 933/2021 requires the property to register them. No photograph or copy of the document is ever uploaded or stored, neither the guest's nor their companions'. This is a design decision, not a setting: there is no store of identity images that could leak, be lost or be forgotten.

5. Recipients and processors

We do not sell or share data with third parties. We rely on the following providers, all with appropriate safeguards and, for those that process data on our behalf, under a data processing agreement:

  • OVHcloud — server running the application and the database, in Gravelines (France, European Union).
  • Cloudflare — storage of the photographs uploaded by the property, of the database backups and of the archived audit log, all within European Union jurisdiction; and content delivery.
  • Resend — email delivery: transactional email (confirmations, reminders, invitations) and, on each property's behalf, commercial email to its former guests (the post-stay email and its offers).
  • Stripe — payments and subscriptions. The full card number is entered directly into Stripe and never reaches our servers: we keep the amount, the date, an identifier for the operation, and the card's brand, last four digits and expiry date so we can tell you which card was charged and warn you if it is about to expire. It may process this data in the United States: see below.
  • Aiosell — distribution channel, where the property contracts it and for as long as it stays linked to it. We do not send them guest data: we send availability, rates and restrictions. The reservation arrives from them, because the portal where it was booked gave it to them. Its registered office is in India, and its infrastructure in India and the United States: that international transfer exists only if the property contracts that module, and lasts for as long as the property stays linked.
  • Apple — the domain's contact and support mailboxes, under the iCloud+ terms. They process the messages you write to those addresses, including rights requests, and the internal notifications generated by the contact form and by each bug report; the one for a bug report, without what was written in it or the identifiers the screen's address may carry. They do not access the data properties enter in the application, and we do not send guest data to them. Being provided under consumer terms, this service has no data processing agreement; that is why what reaches those mailboxes is limited to correspondence.

Public authorities, where the law requires it: the traveller-report data is sent to the Spanish Ministry of the Interior through SES.Hospedajes, and the invoicing records to the Spanish tax agency, in both cases on the property's behalf and because a rule imposes it on them. And technical monitoring providers — healthchecks.io and Better Stack — which receive whether a task finished cleanly and whether the site responds: operational signals, with no guest or customer data inside.

The server, the database, the photograph storage and the email delivery are provided within the European Union. There are two transfers outside the European Economic Area. Stripe may process payment 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. And Aiosell, in India and the United States, which would happen only if the property contracted the distribution-channel module. That transfer requires the standard contractual clauses approved by the European Commission and an assessment of the safeguards in the destination country: as at this revision both are pending signature, so that module is not active for any property and today no guest data leaves the European Economic Area by that route. It will not be activated for anyone before they are in place, and once signed you can ask us for a copy of both by writing to [email protected].

6. Retention

The periods are enforced by the system itself: they do not depend on anyone remembering to delete anything. For guest data —where we act as processor— these are the periods the system applies by default and they form part of the data processing agreement with the property.

  • Account data: while the relationship is active and, after cancellation, as long as needed to address legal liabilities.
  • Guest records: three years from the end of their last stay —as the main guest, as a companion or in a booked service, such as a banquet—, the period Royal Decree 933/2021 sets for the traveller register; a record that never had one, three years from when it was created. Once it expires they are anonymised automatically: name, document, address and contact details are cleared, and only non-identifying data remain —country, nationality, language and dates— for the property's statistics. Along with the record, and at the same time, what was written about that person elsewhere is cleared: their companions' details in the online check-in, the notes and alerts on their bookings, the notes on their services and the alerts on their record, the copy of their traveller reports, what they said about the property —a complaint, a suggestion or a compliment— with what was done about it, and the tasks that mentioned them, with their comments.
  • Email delivery log (recipient, template and whether it went out; never the message body): 24 months.
  • Audit log: 3 months in the database and, after that, archived —24 months for anything touching permissions, security and money; 12 months for the rest—.
  • Application technical logs (the access and error logs of the four containers the service runs in: the two application ones, the web server's and the scheduled tasks'): they have no period in days but a size cap: about 50 MB for each container, and once it is full the oldest entries are discarded. How many days fit within that cap depends mostly on traffic, so we cannot give a figure: with little traffic it can be months. The record of each access, also when the request fails, leaves out cookies, the tokens in personal links and the referring page.
  • Suppression-list fingerprints: indefinitely. It is the only way not to write again to someone who bounced or complained, nor send offers to someone who turned them down; forgetting would mean bothering them again.
  • Objections to a property's offers (a pseudonymous fingerprint of the email —an HMAC with a secret key—, the property where they were offered to object or objected, whether they objected, when, through which channel and a fingerprint of the text they saw; their guest record is not stored): for as long as the business remains a customer, even if the guest record is anonymised or deleted, and until it is purged after it leaves. It is the evidence that they were offered to object and that their objection was respected, which stops the offers of every property of the same business; the objection itself also stays on the suppression list.
  • Maintenance and cleaning photographs: 30 days.
  • Bug reports: 12 months from when they are closed and, if they are never closed, 24 months from when they were sent. When a property leaves, they are erased earlier, in its purge.
  • Backups: 30 days. A backup holds the data as it stood that day, so an erasure can take that long to disappear everywhere.
  • Billing: billing books and records, and the payments and cash-drawer records that support them, are kept for the periods tax law requires, and are excluded from any automatic deletion.
  • Data of a property that leaves: on the day it leaves it is sent its data —reservations, guests, folios, payments, invoices, services and what the processing agreement lists— and, from 60 days on, everything that is not tax-related is deleted —guests, reservations, the team, objections to offers, the activity log and the rest—, except, of what we keep as controller, what has its own period: the contract acceptance, the suppression-list fingerprints, information requests and quotes issued; backups and the application technical logs, within the period or the cap stated above. Tax records are kept as the previous item says, and with them, emptied of anything that identifies anyone, what an invoice or a payment points to: its reservation and its service, without notes or card details, and the service under a neutral name; that reservation's guest, anonymised as at three years; and, of the client company, the name, tax ID and address the invoice already carries.
  • Contract acceptance (who accepted the terms, their email, when and which version): while the relationship is active and afterwards, for as long as claims under the contract can be brought. It is the evidence that the terms were accepted, so it survives that person leaving: if they close their account, the row keeps their email and loses the link to it.
  • Opportunity engine autopilot (who switched it on, changed it or switched it off for each room type, their email, when and under which version of the terms): while the relationship is active, even if the property or the room type is deleted. It is the evidence that the customer asked the program to apply measures on its own, so it survives that person leaving: the row keeps their email and loses the link to their account.
  • Quotes issued: four years from issue, the limitation period for personal actions. They hold the exact text that was sent, which is the evidence of what was offered.
  • Copy of the traveller report in the sending queue: 90 days from when it was filed or, if it never was, from when it entered the queue. The record the law requires to be kept is the property's, not the copy we make to push it through the API.
  • Information requests: 12 months from the last contact — the date it was handled, or the date it arrived if nobody handled it — and then they delete themselves. Becoming a customer does not extend this: from that point the relationship lives in the account data and the enquiry adds nothing.

7. Your rights

You may exercise your rights of access, rectification, erasure, objection, restriction and portability by writing to [email protected], stating the right you are exercising and proving your identity. If you are a guest of a property, address your request to that property as the controller; we will forward it if we receive it.

You may also lodge a complaint with the Spanish Data Protection Agency (www.aepd.es) if you believe the processing does not comply with the regulations.

8. Security

We apply technical and organisational measures to protect data: encryption in transit, isolation of each customer's data — every query is filtered by its company, and automated checks refuse to let through code that breaks that rule — role-based permissions and access logging. No system is infallible, but we review these measures regularly.

9. Changes

If we change this policy we will publish the new version on this page and, where the changes are significant, notify you by email.