Data processing terms

1. Which role these terms are about

These terms set out how DEMCYN LTD, operating the RezRoute connectivity service, handles personal data on behalf of another party, as a processor within the meaning of Article 4(8) of the General Data Protection Regulation (EU) 2016/679. They are written to the content Article 28(3) requires of a contract between a controller and a processor.

RezRoute has two data protection roles at the same time, and they are kept apart here because the obligations differ.

• Processor. For traveller personal data that passes through the router in the course of a booking. The controller is the marketplace that holds the product. These terms govern that processing.
• Controller. For operator contact details, correspondence, billing records and the technical records of the service itself. That processing is described in the privacy notice and is not governed by these terms.

The distinction that matters most to an operator is the first row. Traveller booking data is not ours. We do not decide what is collected, what it is used for, or how long the marketplace keeps it. We carry it, and the party that decides those things is the marketplace named in that row.

2. Applicable law and supervisory authority

The General Data Protection Regulation applies to the processing described here. The company operating RezRoute, DEMCYN LTD, is established in the Republic of Cyprus, so the Regulation is supplemented there by Law 125(I)/2018, and the supervisory authority is the following.

Under Article 77(1) a data subject may lodge a complaint with the supervisory authority of the country where they live, where they work, or where the alleged infringement took place, whichever they prefer.

3. Subject matter and duration

Subject matter. The routing of availability, reservation, booking and cancellation calls between a sales channel and the marketplace that holds the product, and the technical records created while doing so.

Duration. Processing begins when a connection is configured for a product that the operator has opted in, and continues for as long as that connection is in place. It ends when the connection is terminated and the obligations in clause 11 are complete. Technical records may persist for their retention period after a connection ends.

What these terms do not cover. What a sales channel does with the personal data it holds for its own purposes. What the marketplace does with a booking after it lands. What an operator does with traveller details once it receives them. Each of those parties answers for its own processing under its own terms.

4. Nature and purpose of the processing

The processing is transmission, routing, and the technical logging that transmission requires. It is not analysis, enrichment, profiling, marketing, or the training of any model.

• Receiving a call from a connected sales channel and authenticating it. Authentication is HTTP Basic in both directions, because that is what the channels require.
• Identifying which marketplace holds the product the call refers to, and passing the call to that marketplace.
• Returning the marketplace response to the channel, within the response time targets the channel sets.
• Recording that a call happened and whether it succeeded, so that a failure can be explained to the operator it affected and the error ceilings the channels impose can be met.

The seat check and the write happen inside the marketplace's own database transaction. RezRoute keeps no copy of availability, creates no separate booking store, takes no payment and holds no money. There is no operator dashboard and no account to sign up for, so there is no second copy of a traveller record here to lose.

Distribution is opt in, per operator and per tour. A product that has not been opted in is not carried, and a channel asking about it is answered as though it does not exist, so no personal data about a booking for that product can reach the service at all.

5. Categories of personal data and data subjects

No payment data enters the service. A traveller pays the sales channel, and no card number, card token or bank detail is received, carried or stored at any point in this path.

No special category of personal data within the meaning of Article 9 is asked for. Free text supplied by a channel can nonetheless contain health, mobility or dietary information, and it is treated as sensitive wherever it appears.

6. Documented instructions

RezRoute processes personal data only on documented instructions from the controller, including as regards transfers, as Article 28(3)(a) requires. The standing instruction is narrow: carry the calls for the products that have been opted in, and do nothing else with the data that passes through.

• A call arriving from a connected sales channel is itself an instruction to route it.
• Configuration set by the controller, such as which products are connected to which channel, is an instruction.
• Written instructions sent to connectivity@rezroute.com are instructions.

We do not use traveller data for any purpose of our own, and we do not use it to inform commercial decisions on The Greek Local or Cyprus Bucket List. That commitment is published on the data use page as well as here, because it is the promise most worth being able to point at.

An instruction that appears to infringe the law

Under the second subparagraph of Article 28(3), a processor must immediately inform the controller if, in its opinion, an instruction infringes the Regulation or other Union or Member State data protection provisions. We will do so in writing, we will say why, and we will not act on the instruction while the question is open.

This is not a right to second guess a controller about its own business. It applies to the lawfulness of the processing we are asked to carry out, and nothing else.

Processing required by law

Where Union or Member State law requires us to process personal data beyond the controller's instructions, we will inform the controller of that legal requirement before processing, unless that law prohibits the notification on important grounds of public interest.

7. Confidentiality

Article 28(3)(b) requires that persons authorised to process the personal data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality.

Access to personal data processed under these terms is limited to people who need it in order to run or repair a connection. Everyone with such access is bound by a duty of confidence that survives the end of their engagement, and that duty covers operator data as well as traveller data.

8. Security of processing (Article 32)

Article 32 requires measures appropriate to the risk, taking account of the state of the art, the cost of implementation, and the nature, scope, context and purposes of the processing. The risk profile of this service is unusual and worth stating plainly, because it explains why the measures are what they are.

The service holds almost nothing. There is no availability copy, no booking store and no payment data, so the classic risk of a large standing database does not arise. The concentrated risk is instead the credential: authentication is HTTP Basic in both directions, which carries a reusable secret on every request, so the controls around that secret do the work a short lived token would otherwise do.

Measures that follow from the design

• No second copy of availability exists. Availability is answered from the marketplace database, so there is no cache, mirror or export to secure.
• No separate booking store exists. A booking is written into the marketplace, so a traveller record is held in one place rather than two.
• No payment data enters the service, and no money passes through it.
• Traveller personal data is not written to technical records, and credentials are redacted before an entry is written.
• A separate credential is used for each channel and for each direction, so that revoking one does not disturb the others.
• Traffic is served over HTTPS only. HTTP Basic is acceptable only over an encrypted transport, so plain HTTP is not served at all.

Certifications

RezRoute holds no SOC 2 report, no ISO/IEC 27001 certification and no PCI DSS attestation. None is in progress and none is scheduled, and nothing in this document should be read as implying otherwise. Neither GetYourGuide nor Viator requires a security certification of a connectivity partner. If that changes, or if a certification is obtained, it will be named here with its scope and its date rather than described in the abstract.

9. Sub-processing

The controller gives RezRoute general written authorisation to engage sub-processors, within the meaning of Article 28(2), subject to the conditions in this clause.

• The current sub-processors are published, with what each one does and the country it does it in, on the sub-processors page. That page carries its own date, and the date is the record.
• Each sub-processor is engaged under a written contract imposing data protection obligations no less protective than these terms, as Article 28(4) requires.
• RezRoute remains fully liable to the controller for the performance of its sub-processors' obligations.
• Notice of an intended new or replacement sub-processor is given before that sub-processor starts processing, in the manner described on the sub-processors page.
• The controller may object to an intended change.

Two parties that are not sub-processors

The marketplace. The Greek Local and Cyprus Bucket List are not sub-processors engaged by RezRoute. For traveller booking data the marketplace is the controller: it is the party whose instructions we act on, and the system that owns the booking record. A call reaching it is the destination of the instruction, not an onward disclosure by us. Each marketplace answers for its own processors under its own privacy notice.

The sales channel. GetYourGuide and Viator are separate controllers. Each takes the sale, sets its own purposes, holds traveller data under its own privacy notice, and sends a booking payload to us. Data reaches a channel because the traveller bought from it, not because we passed it on.

10. Assistance to the controller

Requests from data subjects

Article 28(3)(e) requires the processor to assist the controller, by appropriate technical and organisational measures and insofar as this is possible, in fulfilling its obligation to respond to requests under Chapter III of the Regulation.

Where a request reaches RezRoute about data it processes on behalf of a controller, we do not answer it ourselves. We pass it to the controller without undue delay and help the controller answer it, so far as the request concerns data we hold or carry.

In practice most traveller requests are answered by the party that holds the record, which is the sales channel, or the marketplace and the operator. RezRoute creates no separate booking store, so there is normally nothing here to search.

Personal data breaches

Under Article 33(2) a processor must notify the controller without undue delay after becoming aware of a personal data breach. The 72 hour deadline in Article 33(1) belongs to the controller and runs from the moment the controller becomes aware, which is why our notification has to be fast rather than merely prompt: every hour we take is an hour the controller does not have.

A notification from us will describe 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 we cannot provide all of that at once, we will provide it in phases rather than delay the first notification.

Assessments and prior consultation

Article 28(3)(f) requires assistance with the obligations in Articles 32 to 36, taking into account the nature of the processing and the information available to the processor. We will assist with a data protection impact assessment under Article 35, and with prior consultation of a supervisory authority under Article 36, by providing the information we hold about how the routing works and what it carries.

11. Deletion or return at the end of the service

Article 28(3)(g) requires that, at the end of the provision of services, the processor deletes or returns the personal data at the choice of the controller, and deletes existing copies, unless Union or Member State law requires storage.

The practical scope of this obligation is narrow by design. Booking records are held in the marketplace, not by RezRoute, so there is normally no traveller record here to return. What can exist is configuration, correspondence and technical records.

• Configuration and connection records: deleted on request after termination.
• Technical records: deleted at the end of their retention period.

12. Audit and information rights

Article 28(3)(h) requires the processor to make available to the controller all information necessary to demonstrate compliance with Article 28, and to allow for and contribute to audits, including inspections, conducted by the controller or another auditor it mandates.

There is no third party audit report to offer in place of an audit. No SOC 2 report and no ISO/IEC 27001 certificate exists, and neither channel requires one, so a request for assurance is answered with information and access rather than with a certificate. That is a weaker answer than a certificate and it is stated as such.

13. International transfers

A transfer governed by Chapter V of the Regulation happens when personal data processed in the European Economic Area is made available to somebody outside it. In this service that can arise in one way: a sub-processor storing or accessing data from outside the EEA. It does not arise merely because a sales channel outside the EEA sends a booking to us, since that is the channel's own disclosure under its own arrangements, made in the direction of the EEA rather than out of it.

Remote access from outside the EEA is itself a transfer even when the data sits inside it, so the question is answered per provider on the sub-processors page rather than waved through here. The company operating the service is established in Cyprus.

No transfer is made outside the EEA except where a mechanism provided by Chapter V of the Regulation is in place, and a controller may ask us for a copy of the safeguards relied on.

14. Precedence, liability, changes and contact

When these terms change, the date at the top of this page changes with them. Where a change also affects how a connection works, the notice period in the terms of service applies as well, because a connectivity change reaches an operator's live selling rather than only their paperwork.

Contact for matters under these terms: connectivity@rezroute.com, at DEMCYN LTD, Vavyla 3, Block A, Flat/Office 204, Pera Chorio Nisou, 2572 Nicosia, Cyprus.

This version is dated 24 October 2026.