Data Processing Agreement

1. Parties

• Controller: whoever operates the accommodation business and decides which guests are registered and for what purpose. As a rule that is the Client itself — the company or professional that owns the Kinapi account; where the Client manages accommodation on behalf of third parties, see below.
• Processor: Sereno Tech S.L., tax ID B44916658, Calle Tulipán 1, España. Data protection contact: gestion@kinapi.es.

This agreement is entered into when the Client accepts it at account sign-up. We keep a record of the version accepted, the date and the user who accepted it.

2. Subject matter, duration, nature and purpose

The Client instructs Kinapi to process its guests’ personal data for the sole purpose of providing the service: collecting traveller registration data, validating it, generating and holding the signed accommodation contract and its evidence, and transmitting the traveller report to the Ministry of the Interior’s SES.Hospedajes platform under Royal Decree 933/2021.

The processing lasts while the account is active and ends when it is closed, without prejudice to the retention obligations in clause 10.

3. Data and data subjects

Where the Client enters means-of-payment data because its reporting obligation requires it, Kinapi will transmit it to the Ministry and will not retain it beyond what is strictly necessary for that transmission.

4. Kinapi’s obligations as processor

1. Process the data only on documented instructions from the Client. This agreement, the terms of service, the configuration the Client sets in the panel and the API calls it makes all constitute documented instructions. If Kinapi is required by Union or Spanish law to process otherwise, it will inform the Client beforehand unless legally prohibited.
2. Not use the data for its own purposes, nor disclose it, nor use it to train models, nor for advertising or statistical purposes unrelated to the service. In particular, and given that persons connected to Kinapi operate a tourist accommodation management business, Kinapi expressly undertakes not to use the Client’s data, bookings, occupancy or any other information — whether identified, pseudonymised or aggregated — for any management, commercialisation or market-intelligence activity, its own or a third party’s.
3. Ensure that authorised persons have committed themselves to confidentiality on an indefinite basis.
4. Apply the security measures under Article 32 GDPR described in Annex II.
5. Assist the Client, as far as possible, in responding to data subject rights requests. If a guest contacts Kinapi directly, they will be referred to the Client and the Client will be informed without delay.
6. Assist the Client in complying with Articles 32 to 36 GDPR (security, breach notification, impact assessments and prior consultation), taking into account the nature of processing and the information available.
7. Make available to the Client the information needed to demonstrate compliance with these obligations and allow audits under clause 9.
8. Inform the Client immediately and in writing if it considers that an instruction infringes data protection law.

5. The Client’s obligations as controller

• Have a legal basis for the processing and have informed guests under Articles 13 and 14 GDPR.
• Enter only accurate, relevant data limited to what is necessary.
• Ensure compliance, before and throughout the processing, with the rules applicable to its activity, including its obligations towards the Ministry of the Interior.
• Safeguard its access and API credentials, and the SES.Hospedajes credentials it registers in the panel.
• Supervise the processing and report any incident it detects to Kinapi.

6. Sub-processors

The Client gives general authorisation for Kinapi to use the sub-processors listed below, with which Kinapi has entered into the contracts required by Article 28(4) GDPR. Kinapi remains fully liable for their performance.

Kinapi will notify the Client by email of any addition or replacement of a sub-processor 30 days in advance. The Client may object on reasonable and substantiated grounds within that period; failing a solution, it may terminate without penalty.

6.1. International transfers

Processing of personal data takes place entirely within the European Union, in Microsoft Azure’s Spain Central region. The only entity in a third country is the timestamping authority, which receives exclusively the cryptographic digest (SHA-256 hash) of the contract — a value from which no personal data can be extracted — and never the document. Beyond this, no international transfers take place; should any become necessary, they will rely on an adequacy decision or standard contractual clauses, and the Client will be informed in advance.

7. Personal data breaches

Kinapi will notify the Client of any personal data breach without undue delay after becoming aware of it, by email to the account contact address, and early enough for the Client to meet its own 72-hour deadline under Article 33(1) GDPR. The notification will include, with the information available at the time: the nature of the breach, the categories and approximate number of data subjects and records affected, a contact point for further information, the likely consequences and the measures taken or proposed.

It is for the Client, as controller, to decide on notification to the supervisory authority and, where applicable, to the data subjects. Kinapi will provide reasonable assistance.

8. Data subject rights

The Client can handle access, rectification and portability requests itself from the panel and the API. For those requiring Kinapi’s involvement, Kinapi will respond within a maximum of 10 working days of the Client’s request.

9. Audit

On the Client’s reasoned request, and at most once a year, Kinapi will make available the information needed to demonstrate compliance with this agreement. The Client may carry out audits — itself or through an independent auditor bound by confidentiality — on 30 days’ notice, during business hours, without disrupting the service and at its own cost, unless the audit reveals material breaches attributable to Kinapi.

10. End of processing

Return. The Client may export its data at any time from the panel or the API: an archive with the traveller reports, the proofs of filing, the signed contracts and the signature evidence of every stay, together with the data in a structured format. This is how Kinapi returns the data at the end of the processing (Art. 28(3)(g) GDPR).

Closing the account. The Client may request the closure from the panel. From then on the account is closed —no reports are filed, no emails are sent to guests and the API only allows exports— and during a 30-day grace period the Client may reactivate it or export its data. When that period ends, Kinapi will delete the personal data processed on the Client’s behalf, and existing copies, except:

• traveller report data of stays still within their legal retention period (three years from check-out), which is kept blocked: separated from the account and with no access by the Client or by Kinapi, except to comply with a request from a competent authority, and deleted when each period ends;
• signature evidence in the immutable container, until its retention policy expires;
• accounting and tax records of the commercial relationship, which contain no guest data.

Offboarding an owner. When the Client stops managing the accommodations of one of its owners, it may export that owner’s records and then delete their data from the panel. The same rule applies: whatever must be retained is kept blocked until its period ends, and the bookings remain in the account anonymised, with no data identifying the guests.

While the account is active, Kinapi does not delete traveller records on its own: their retention and deletion follow the Client’s instructions.

11. Liability

Liability towards data subjects and supervisory authorities is governed by Article 82 GDPR and is not limited by this agreement or by the terms of service: that liability cannot be disposed of between the parties.

As between the parties, and without prejudice to the above, the liability cap in clause 7 of the terms of service does apply to the obligations under this agreement, except where mandatory law does not permit limitation. Each party is liable for damage caused by its own breach of data protection law or of this agreement.

Annex II · Security measures

Technical and organisational measures applied under Article 32 GDPR. Kinapi may update them provided the level of security is not reduced.

• Encryption in transit: TLS enforced on all connections, minimum TLS 1.2. The public API accepts HTTPS only.
• Encryption at rest: platform encryption on database and storage. Third-party credentials the Client registers — SES.Hospedajes password, notification tokens, webhook signing secrets — are additionally encrypted at application level (AES-256-GCM), so they are not readable even with direct database access.
• Tenant isolation: all data is partitioned by client identifier, and that identifier is always taken from the verified session or the API key, never from a value the request can supply.
• Guest link: the check-in link is a bearer credential per booking: it allows registering guests and viewing the group list with the document number masked. The fields that identify a person — document and date of birth — are shown only to the browser that registered them, and only for a few hours; afterwards they can be corrected but not read. The link expires automatically 14 days after checkout. Even so, the Client should distribute it carefully: guests on the same booking are co-signers of the contract, which identifies all of them.
• Access control: federated authentication through an identity provider (Microsoft Entra External ID); there are no local passwords. Role-based access. API keys are stored only as SHA-256 hashes.
• Secret management: platform secrets live in Azure Key Vault accessed via managed identity, with no credentials in code or environment variables.
• Integrity and non-repudiation: signed contracts are stamped with an RFC 3161 timestamp and copied to immutable (WORM) storage, with an append-only record of IP, user-agent and signature hash per signer.
• Minimisation: no copy of the identity document is requested or stored. Guest check-in links expire automatically after the configured period from checkout.
• Traceability: activity logging of the API and of SES communications, with centralised telemetry and bounded retention.
• Resilience: managed infrastructure with provider redundancy, automatic backups and point-in-time restore.
• Abuse limits: per-client quotas and sign-up rate limiting by origin, to contain anomalous use before it affects the service or generates improper data.