Mapping your next journey
Legal document
Lawyer review required. This specific revision is awaiting recorded review completion.
This Privacy Policy explains how LeBo Travel B.V. ("LeBo Travel", "we", "us", or "our") handles personal data when you use our websites, customer account, order portal, forms, payments, travel-support services, business-travel services, LeBot, push notifications, and related communications.
LeBo Travel B.V., established in the Netherlands, is the controller of the personal data described in this Policy unless a specific notice identifies another controller.
Privacy enquiries and rights requests may be sent to hello@lebotravel.com or through our contact page. Please write "Privacy request" in the subject line and include enough information for us to identify the relevant account, order, enquiry, or interaction.
We act as controller when we decide why and how information is used for our own website, accounts, sales, support, security, and service-delivery records. A separate provider may act as an independent controller for its own booking, payment, transport, connectivity, government, or professional service. In limited cases we may process information on a customer's documented instructions; the applicable order or business agreement will identify that arrangement rather than this general Policy.
When contacting us, please do not send identity documents or other high-risk information merely to prove who you are. We will first explain an appropriate verification method. If your request concerns several travellers, an employer-sponsored trip, or a person represented by an agent, we may ask for evidence of authority before disclosing or changing records. We record the request, the verification steps, the decision, and any action taken so that the process is accountable.
Controller responsibility is allocated by examining who determines the purpose and essential means of the relevant processing, rather than by relying only on the name used in an invoice or interface. LeBo Travel's controller functions include deciding what account, order, support, security, content, and service-delivery records are needed and how those records are governed.
A privacy enquiry is logged against the relevant person, account, journey, order, conversation, or system event where this can be done without collecting excessive identification. Requests involving a representative, group organiser, employer, or cardholder are separated so that authority for one record is not incorrectly treated as authority for every traveller or transaction.
This Policy applies when you:
This Policy does not govern an independent airline, hotel, payment provider, eSIM supplier, driver, interpreter, local assistant, booking platform, government authority, social network, or other third party that processes personal data under its own notice.
The Policy applies throughout the lifecycle of an interaction: initial browsing, saved or submitted intake, quote review, checkout, service delivery, account support, complaints, refunds, disputes, and legally required recordkeeping. It also applies when a page is reached through a campaign link, QR code, shared quote, order-recovery link, or another LeBo Travel-controlled entry point. A service-specific notice may provide more detail and will supplement this Policy for that feature.
It does not automatically apply to a third party merely because we link to it, introduce it, transmit a customer-authorised request, or display information obtained from it. Before moving into a third party's environment, check the destination, recipient, and applicable notice. If you interact with LeBo Travel on a social network or messaging service, both that service's rules and this Policy may apply to different parts of the interaction.
The scope analysis follows the data and the responsible service, including pre-submission drafts, abandoned checkout state, support received after completion, and records retained after an account is closed. A branded page, campaign, subdomain, or language version is covered when LeBo Travel controls the relevant processing and links or refers to this Policy.
Where an interaction moves between LeBo Travel and an independent provider, we identify the transition by the destination address, checkout environment, provider communication, or service confirmation. The customer should preserve that context because access, correction, deletion, cancellation, and complaint requests may need to be divided between separate controllers.
The categories depend on how you interact with us.
This may include your name, email address, phone or messaging contact, country or region, preferred language, company name, role, and contact preferences.
This may include account identifiers, verified email status, coarse device type, browser family, platform family, account membership, session and device records, security-event metadata, login and recovery timestamps, and hashed or short-lived verification credentials. We do not store your account password because customer and administrator authentication is handled through our authentication provider.
This may include destinations, cities, travel dates, trip length, number and type of travellers, itinerary context, transport and accommodation context, accessibility or language needs, booking status, service selections, urgency, budget range, preferences, business-visit goals, meeting or supplier context, and any other information you choose to provide.
This may include order and case numbers, selected service and tier, add-ons, eSIM plan, quote scope, currency, amount, discounts, payment status, refund or dispute status, invoices, payment-provider references, delivery status, fulfilment records, and communications about the transaction. Full payment-card numbers are collected and processed by the payment provider and are not stored by LeBo Travel.
This may include contact messages, intake answers, account conversations, LeBot messages, human-handoff summaries, support correspondence, call notes, feedback, ratings, files you intentionally provide, and records of our responses.
This may include IP address, request time, page or API path, referrer, browser and device signals, request identifiers, security and rate-limit signals, Content Security Policy reports, Turnstile verification results, push-subscription endpoint and public encryption keys, service-worker status, and information stored in cookies or browser storage as described in our Cookie Notice.
When needed to answer or fulfil your request, we may receive information from a payment processor, authentication provider, email provider, booking or connectivity provider, local service provider, a person travelling with you, a company representative, or publicly available official and supplier sources.
The exact fields collected are determined by the feature and the stage of the customer journey. For example, browsing ordinarily produces technical request data, while a reviewed quote or fulfilled order requires enough identity, scope, transaction, and delivery information to connect the work to the correct customer. We seek to avoid collecting data merely because it might be useful later, and internal access is organised around operational need.
Information may also be inferred from activity without creating a sensitive profile. Examples include whether a verification attempt succeeded, whether an account session appears inactive, whether two checkout attempts relate to the same journey, whether a message needs human follow-up, or whether a supplier response is still outstanding. These operational statuses help us prevent duplication and manage delivery. They are not used to infer protected characteristics for advertising.
Files and free-text fields can contain more information than the surrounding form requests. Before uploading or typing, remove unrelated names, document numbers, confidential attachments, hidden spreadsheet columns, image metadata, and message history that we do not need. If we identify excessive data, we may redact, restrict, return, or securely delete it where practical.
A category description includes data intentionally supplied, technical attributes generated by a request, operational status derived from activity, and references returned by providers. It does not mean that every item in the category is collected from every person. Collection is tied to the feature used, the service stage, security risk, and information reasonably necessary to complete the stated purpose.
When new fields or derived statuses are introduced, the product owner should document the source, purpose, access group, required or optional status, retention trigger, and recipient category. Free-text and file inputs receive heightened attention because they can contain unexpected third-party, sensitive, confidential, or embedded metadata that structured fields would not ordinarily request.
If you provide personal data about another traveller, colleague, family member, customer, supplier contact, or meeting participant, you must have authority to provide it and should share this Policy with them where appropriate. Do not submit more information about another person than is necessary for the request.
Where one person organises a group or business trip, we may treat that organiser as the practical contact while still recognising that each traveller's data belongs to that individual. The organiser should distinguish confirmed facts from assumptions, keep the group informed, and avoid forwarding account links, order credentials, or private correspondence to people who do not need them.
If another person contacts us about a traveller, we may communicate only at a general level until authority is established. Authority may arise from the traveller's instruction, parental responsibility, a documented business role, or another lawful basis. We may refuse a request where the authority is unclear, disclosure could prejudice another person, or the request conflicts with a legal duty. A traveller may contact us directly to correct their own information or preferences.
Authority to provide another person's information must cover both disclosure to LeBo Travel and the requested use, such as obtaining a quote or coordinating a traveller-specific service. Being related to, travelling with, employing, or paying for another person does not necessarily authorise access to all of that person's communications, account activity, preferences, or rights requests.
We may separate group records, redact information relating to other participants, communicate directly with the affected person, or require a written mandate. If competing instructions are received, processing may be paused while identity and authority are resolved. We record the basis on which an organiser or representative was permitted to act and any limitation communicated to that person.
Some travel requests can reveal health, accessibility, dietary, religious, nationality, immigration, or other sensitive information. Please do not send passport scans, passport numbers, national identification numbers, full visa files, payment-card data, medical records, criminal-history information, precise live location, trade secrets, or other highly sensitive material through a public form or LeBot.
If a service genuinely requires sensitive information, we will identify the information needed, the purpose, the appropriate channel, and any additional safeguards. Where applicable law requires explicit consent or another specific condition for processing sensitive data, we will rely on that condition.
We apply data minimisation to sensitive requests. Accessibility assistance may require a functional description of the help needed, but usually not a diagnosis or full medical history. Entry-support work may require nationality, document type, expiry timing, or travel history, but a public intake normally does not require a scan of the document. Business coordination may require a contact's role and company, but not unrelated personnel files or confidential commercial records.
If sensitive data is unexpectedly included, receipt does not mean that we have agreed to assess it or that it is suitable for the requested service. We may isolate access, ask for a safer replacement, redact unnecessary details, or stop processing the affected material. In an urgent health, safety, immigration, or legal situation, contact the competent authority or qualified professional rather than using a public LeBo Travel channel.
Sensitive data is evaluated according to substance, not the label selected by the customer. A request can reveal health, disability, religion, ethnicity, sexual orientation, biometric identity, political risk, or immigration circumstances indirectly through itinerary details or support needs. The fact that such information is useful to a trip does not make unlimited collection proportionate.
Before requesting sensitive material, we should identify the exact decision or coordination step it supports, whether a less intrusive description would work, who needs access, and when the material can be removed. Unexpected high-risk files can be quarantined from ordinary workflows. A request may be declined where the proposed channel, recipient, or purpose cannot support appropriate protection.
We collect personal data:
Direct collection includes information entered progressively and saved before final submission. Where draft-saving is enabled, a random browser credential can reconnect the same browser to the draft; submitting the form converts the information into an operational request. We may also record the version, source page, consent state, and timestamps needed to understand what was submitted and under which terms.
Automatic collection occurs when our systems must route a request, secure a session, deliver content, remember a requested setting, or diagnose failure. Third-party collection is limited to information relevant to the transaction or coordination, such as payment confirmation, delivery status, email events, provider availability, or an official policy update. We do not treat information found online as necessarily accurate and may retain the source and retrieval date so it can be evaluated.
Collection source is recorded where it affects reliability, notice obligations, correction rights, or the ability to verify the information. Data supplied by a traveller is distinguished from information supplied by an organiser, generated by a security system, returned by a payment or delivery provider, or extracted from an official or public source.
When information is obtained indirectly and applicable law requires notice, we provide the required information within the statutory period or at the first communication or disclosure, subject to lawful exceptions. Source records may include submission timestamps, provider event identifiers, retrieval dates, consent state, and the version of the form or policy relevant to the interaction.
Where the General Data Protection Regulation ("GDPR") applies, we use the following legal bases. More than one basis may apply to the same processing.
| Purpose | Typical data | GDPR legal basis |
|---|---|---|
| Responding to an enquiry and preparing a quote | Contact and request details | Steps at your request before a contract; legitimate interests |
| Accepting, delivering, and supporting a service | Identity, travel, order, communication, and delivery data | Contract performance; legitimate interests |
| Processing and reconciling payments | Order, amount, payment status, provider references | Contract performance; legal obligation; legitimate interests |
| Providing accounts, order access, and secure communications | Account, device, verification, order, and session data | Contract performance; legitimate interests in secure access |
| Operating LeBot and human handoff | Messages, page context, account or verified-order context, feedback | Contract or requested pre-contract steps; legitimate interests; consent where required |
| Preventing fraud, abuse, and security incidents | Technical, device, request, verification, and audit data | Legitimate interests; legal obligation |
| Keeping financial, tax, compliance, and dispute records | Transaction, invoice, contract, and case data | Legal obligation; legitimate interests; legal claims |
| Sending service and security communications | Contact, order, account, and notification data | Contract performance; legitimate interests |
| Sending optional marketing | Contact details and preferences | Consent, or legitimate interests where permitted with an opt-out |
| Using optional device technologies | Cookie or similar-technology data | Consent where required |
Our legitimate interests include operating a reliable travel-support business, securing users and systems, improving service quality, preventing misuse, maintaining evidence of transactions and instructions, and protecting legal rights. We consider the impact on individuals before relying on legitimate interests.
Before relying on legitimate interests, we consider the purpose, necessity, reasonable expectations, sensitivity of the data, possible consequences, and safeguards available. Safeguards can include limiting fields, shortening retention, restricting staff access, separating credentials from business records, and offering an objection route. Where an individual's interests override ours, we will not rely on legitimate interests for that processing.
Contract necessity is interpreted narrowly: processing must be objectively needed to take the step requested or provide the purchased service, not merely convenient for a broader business goal. Legal obligation applies where binding law requires records, reporting, cooperation, or preservation. Consent is specific and can be withdrawn for future processing, but withdrawal does not undo prior lawful use or require deletion of records retained under another valid basis.
If the purpose materially changes, we assess whether it is compatible with the original purpose and whether another notice, legal basis, or consent is required. We do not reuse travel details, communications, or order history for unrelated advertising profiles.
The legal basis assessment is purpose-specific. The presence of a contract does not make every use of customer data necessary for that contract, and a consent box is not used to legitimise processing that is compulsory or already required by law. A single record may be retained under one basis after an earlier purpose has ended, but the later purpose must be documented separately.
Legitimate-interest assessments should record the interest, necessity, reasonable expectations, likely impact, safeguards, and outcome. Consent records should show what was presented, the affirmative action, date, channel, and withdrawal state. Where a legal obligation or claim basis is used, access and retention are limited to the records reasonably connected with that obligation or claim.
Some data is required to enter into or perform a contract, verify an order, secure an account, process payment, or comply with law. If you do not provide required data, we may be unable to provide the relevant feature or service. Optional fields are identified by context and may be left blank.
A form may separate required fields from optional context, but operational follow-up can reveal that additional information is necessary. We will explain why it is needed and, where possible, offer a less intrusive alternative. For example, a general route review may proceed with approximate dates, while a time-sensitive entry assessment may require exact travel dates and nationality information.
Declining optional information should not reduce access to an unrelated feature. Declining necessary information may mean we can provide only general guidance, pause a quote, refuse to contact a provider, or close an incomplete request. We may also be legally unable to erase or alter information that forms part of an invoice, payment reconciliation, fraud record, complaint file, or evidence of instructions.
Whether information is required is determined at the point the feature or service needs it. A field can be optional for a general enquiry but necessary before a quote is accepted, a provider is contacted, an account is recovered, or a regulated payment record is completed. Required status must not be used to obtain unrelated information.
If a customer does not provide necessary data, we explain the affected step and, where feasible, offer a reduced-scope or non-identifying alternative. We distinguish inability to perform from a refusal based on risk or law. The record should show the information requested, why it was necessary, any alternative offered, and the operational consequence of non-provision.
LeBot is an AI-assisted customer interface operated by LeBo Travel. Messages and a limited amount of relevant page, service, language, account, or verified-order context may be sent to the configured AI infrastructure to generate a response. Depending on the active configuration, that infrastructure may include Vercel AI Gateway, Cloudflare AI Gateway, and a model provider such as Google Gemini. Providers may change as the service develops.
We store LeBot conversations, response-source and safety metadata, provider request identifiers, feedback, and handoff records so that we can provide conversation history, enforce security and quality controls, prevent duplicate processing, support a human handoff, and investigate problems. Do not put highly sensitive data into LeBot.
Automated entry checks, recommendation logic, fraud controls, and LeBot responses are advisory or protective tools. They do not make a solely automated decision that produces legal or similarly significant effects about visa eligibility, border admission, travel permission, credit, insurance, employment, or another protected matter. Final travel and entry decisions remain with the relevant authorities and providers.
LeBot is designed to separate conversational assistance from actions that require confirmation. It may explain services, collect preliminary context, retrieve allowed account or verified-order information, and prepare a summary for a human handoff. It should not expose another customer's information, and possession of a conversation alone does not prove authority over an account or order. Additional verification may therefore be required before order-specific support.
We use safeguards such as input validation, limited context, access controls, safety rules, source metadata, abuse prevention, and human escalation paths. Nevertheless, an AI response can contain an incorrect inference or omit an important qualification. Customers should correct inaccurate assumptions and use official or professional sources for high-impact decisions. Feedback may be linked to the relevant turn so we can investigate quality and safety.
We do not permit our AI providers to act as independent travel agents on the customer's behalf through the LeBot interface. A generated suggestion is not evidence that a booking, cancellation, payment, refund, provider contact, or government filing occurred.
AI processing is limited by the role assigned to the tool, the context authorised for the particular turn, and the action boundary enforced by the surrounding system. Conversational fluency does not enlarge the system's authority. Account, order, payment, provider, and government actions require the separate controls and confirmations applicable to those operations.
Relevant governance records can include model or gateway category, request identifier, safety outcome, source set, latency, failure mode, customer feedback, escalation, and whether protected account context was used. Testing should cover data leakage, prompt manipulation, unsupported claims, identity boundaries, language variation, and recovery when the model or provider is unavailable.
We disclose personal data only where reasonably necessary for the purposes described above. Recipient categories may include:
We do not sell personal data. We do not share personal data for cross-context behavioural advertising, and we do not use sensitive personal data to infer characteristics for advertising.
Each recipient receives only the information reasonably connected with its role. A payment processor needs transaction and fraud-prevention information but not the full travel narrative. A local provider may need date, city, group size, language, and service requirements but not account security records. An email provider transmits the message addressed through it; it does not need unrestricted access to the customer database.
We use contractual, technical, and organisational measures appropriate to the relationship, including confidentiality terms, access restrictions, security requirements, deletion or return obligations, and review of subprocessor information where relevant. Some recipients act only on our instructions, while others decide independently how to meet legal, payment, carrier, platform, or professional obligations.
We may disclose information without the customer's direction when reasonably necessary to comply with binding process, investigate fraud or security abuse, protect a person from serious harm, establish or defend legal claims, or complete a corporate transaction. We assess the request and disclose no more than the circumstances require.
Recipient selection follows functional necessity and role. A subprocessor handling infrastructure is not given independent permission to market to customers, while an independent carrier, payment institution, authority, or local provider may have its own statutory and contractual purposes. Recipient status may differ for separate data flows within the same commercial relationship.
Before a new recipient category is used, we assess requested fields, access method, location, retention, security commitments, subprocessing, breach cooperation, deletion, and rights support. Disclosures made for legal process or safety are reviewed for authority, scope, urgency, and whether the person can lawfully be notified. A disclosure log or equivalent evidence is retained where proportionate.
When you ask us to contact or coordinate with an independent provider, the provider may become its own controller for the data it receives. Its terms and privacy notice will apply to its services. Share only the data necessary for that coordination and review the provider's information before proceeding.
Before transmitting a request, we may confirm the intended recipient, the purpose, the fields to be shared, and whether the customer wishes to be copied. If availability can be checked without identifying the traveller, we may begin with non-identifying information. More detail can be provided after the customer approves the provider or the provider confirms that it can perform the requested service.
Once an independent provider receives the information, it may need to keep its own booking, safety, accounting, or compliance records. Requests to change or delete that copy may need to be directed to the provider. LeBo Travel can help identify the recipient and relay a request where practical, but cannot guarantee how an independent controller will respond.
Customer instruction to contact a provider authorises only the transmission reasonably required for that contact. It does not authorise unrelated marketing, open-ended sharing, or disclosure to additional providers merely because they offer a similar service. Provider selection and the stage of discussion determine whether identifying data is necessary.
Initial availability requests may use anonymous or aggregated details. Before identifying information or documents are sent, the recipient and purpose should be confirmed through the order, conversation, or another durable instruction. Responses and onward requests are reviewed so that a provider cannot expand the data sought without customer awareness and an appropriate lawful basis.
LeBo Travel is established in the Netherlands, while our users, providers, and service partners may be located worldwide. Personal data may therefore be processed outside your country, including outside the European Economic Area ("EEA") or the United Kingdom.
Where GDPR transfer rules apply, we use an available lawful mechanism such as an adequacy decision, the European Commission's Standard Contractual Clauses, the UK International Data Transfer Addendum or Agreement, or another permitted safeguard. We may also rely on a statutory derogation for a transfer that is necessary to perform a contract or take requested pre-contract steps, for example where a traveller asks us to contact a provider in the destination country. You may contact us for information about the applicable safeguard.
An international transfer can occur through infrastructure location, remote support access, email routing, an overseas model or security provider, or coordination with a provider in the destination country. We consider the type of information, destination, recipient, frequency, and supplementary safeguards rather than assuming that every transfer creates the same risk.
Where contractual clauses are used, they address data-protection obligations between the exporting and importing organisations. Depending on the risk, supplementary measures may include encryption in transit, access logging, data minimisation, pseudonymous identifiers, restricted support access, or separating high-risk material from ordinary coordination. No transfer mechanism changes the fact that a destination government or provider may be subject to local law.
For an occasional transfer requested by the traveller, we will limit the information to what is needed for that request. A request for safeguard information may be answered in summary form where full contracts contain confidential or security-sensitive provisions.
Transfer analysis covers storage location, support access, network routing, provider subprocessors, and destination-country coordination. It is performed for the actual data flow rather than assuming that a provider's headquarters determines every processing location. Repeated infrastructure transfers are distinguished from an occasional transfer necessary to fulfil a traveller's specific overseas request.
The transfer file may record the destination, recipient, data categories, frequency, mechanism, transfer-impact assessment, supplementary measures, and review date. If the mechanism changes or a legal decision affects its validity, new transfers are reassessed and existing arrangements are remediated, suspended, localised, or replaced as reasonably required.
We keep personal data only for as long as needed for the relevant purpose, taking account of contract, tax, accounting, consumer, security, limitation-period, dispute, and evidentiary requirements.
| Record category | General retention approach |
|---|---|
| Enquiries, contact forms, and unaccepted intakes | Usually up to 24 months after the last meaningful interaction, unless a shorter period is appropriate or the record becomes part of an order or dispute |
| Orders, accepted quotes, service delivery, support, and customer communications | For the service relationship and generally up to 24 months after completion, then longer where needed for warranty, complaint, chargeback, dispute, or legal-claim periods |
| Invoices, payments, refunds, tax, and accounting records | For the period required by applicable law, generally seven years for Dutch tax and accounting records |
| Customer accounts and device sessions | While active; inactivity notice begins after prolonged inactivity and access may be deactivated at about 24 months, while transaction and legally required records remain under their separate schedules |
| Order-recovery and security credentials | Short-lived according to their security purpose; verification codes generally expire within minutes and order-access sessions generally within 24 hours |
| Registration abuse signals | Hashed abuse records are routinely pruned after 90 days; expired email challenges are pruned sooner |
| LeBot and support conversations | For as long as reasonably necessary to provide history, complete a handoff, maintain quality and safety evidence, and handle complaints or disputes |
| Security and audit logs | For a period proportionate to investigation, fraud prevention, system integrity, compliance, and legal-claim needs |
| Push subscriptions | Until you disable notifications, the subscription expires, delivery failures require revocation, or the associated session or account is revoked |
Deletion may be delayed or limited where records must be preserved for legal obligations, fraud prevention, security, a dispute, or the rights of another person. When practical, we delete, anonymise, aggregate, or restrict data that is no longer needed.
Retention begins from the event relevant to the record, such as last interaction, completion, account inactivity, payment date, closure of a complaint, or expiry of a security credential. A later interaction, active dispute, legal hold, fraud investigation, or renewed customer relationship may reset or suspend the normal deletion point. Backup copies may remain for a limited rotation period and are not restored for ordinary business use after deletion.
We distinguish deletion from restriction and anonymisation. Restricted records remain available only for the reason that prevents deletion, such as a legal claim or statutory requirement. Anonymised or aggregated information is altered so it no longer identifies a person and may be retained for service reliability, financial analysis, or product planning. Merely removing a name is not treated as anonymisation if the record can still reasonably be linked back.
The table states general operating targets rather than promising destruction on a particular day. We periodically review data sets and deletion mechanisms, and we may use shorter periods where a feature, provider contract, or risk assessment supports them.
Retention applies at record and field level where systems allow, because an invoice, support conversation, security event, and optional preference can have different lawful lifetimes even when connected to one customer. A long limitation or tax period does not justify retaining every underlying message or sensitive attachment for the same duration.
Deletion schedules use identifiable triggers, owners, exceptions, and verification. Legal holds suspend ordinary deletion only for material reasonably related to the issue and are released when no longer required. Disposal should address primary systems, indexes, exports, working copies, and provider deletion workflows, while backup expiration follows controlled rotation rather than ad hoc restoration and manual deletion.
We use administrative, technical, and organisational safeguards appropriate to the nature of the data and the risks, including access controls, role-based administration, encrypted transport, secret separation, restricted service credentials, hashed one-time credentials, short-lived sessions, rate limits, anti-bot controls, audit logging, content sanitisation, payment-provider tokenisation, and no-store controls for sensitive pages.
No system can be guaranteed completely secure. You are responsible for maintaining access to your email account and device, checking that you are using an authentic LeBo Travel domain, and notifying us promptly if you suspect unauthorised account or order access.
Access to administrative and operational systems is limited by role and purpose. We separate public and privileged credentials, restrict direct database access, verify signed payment events, validate inputs, and maintain records of sensitive content changes and review actions. Security controls are adjusted as the product and threat environment change.
If we become aware of a personal-data breach, we investigate scope, containment, affected data, likely consequences, and remedial measures. Where required, we notify the competent supervisory authority and affected individuals within the applicable legal framework. A failed login, delayed email, or service outage is not automatically a personal-data breach, but each can be reviewed for security impact.
Customers should use unique email-account credentials, keep devices updated, sign out on shared devices, and avoid sending access links through insecure channels. We will never ask for a full payment-card number, password, or one-time authentication code through LeBot or an ordinary support message.
Security measures are selected according to confidentiality, integrity, availability, and resilience risks across public forms, authenticated areas, privileged administration, provider integrations, communications, and stored records. The existence of encryption or authentication does not eliminate the need for least privilege, monitoring, secure development, recovery, and staff procedures.
Security events are triaged to determine whether personal data was affected, whether access or alteration occurred, the likely population and consequences, containment, evidence preservation, notification duties, and corrective action. Access reviews, credential rotation, dependency updates, provider assurance, restoration tests, and incident exercises are performed at intervals proportionate to risk.
Subject to applicable law and exceptions, you may have the right to:
To exercise a right, contact us using Section 1. We may ask for information reasonably necessary to verify identity and protect another person's data. We normally respond within the period required by applicable law. Complex or numerous requests may take longer where the law permits, and we will explain any extension.
A request should identify the right being exercised and the relevant service, approximate date, email address, order reference, or other context. We may ask the requester to use an already authenticated account, confirm access to an email address, or provide limited additional evidence. Verification information is used for the request and protected from unnecessary reuse.
Rights are not absolute. Access may be limited to protect another person's privacy, legal privilege, security, confidential business information, or an active investigation. Erasure may not apply to transaction, tax, fraud, dispute, or legal-claim records. Portability generally concerns data provided by the individual and processed by automated means under consent or contract, not every internal note or derived status.
If we refuse or limit a request, we will explain the principal reason and available complaint or appeal route where law requires. Authorised agents must provide evidence of authority, and we may still verify the individual's identity directly. We do not charge a fee unless the law allows it for a manifestly unfounded, excessive, or repetitive request.
Rights are applied to personal data concerning the requester, not automatically to every business document or group record in which the requester appears. The response must balance transparency with the privacy of other people, legal privilege, security, intellectual property, confidentiality, and exceptions expressly recognised by applicable law.
The request workflow records receipt, scope, identity verification, systems searched, recipients consulted, exemptions applied, response package, corrections or restrictions implemented, and completion date. Where data has been disclosed, required notices of correction, erasure, or restriction are sent to recipients unless impossible or disproportionate, and the requester may ask to be informed of those recipients.
Service, security, transaction, and account messages are not marketing and may be necessary to provide the service. If we send optional marketing, you may use the unsubscribe method in the message or contact us. Withdrawing marketing consent does not stop essential service communications.
Marketing preferences are applied to the address or channel identified in the request and may take a short operational period to propagate. We may keep a minimal suppression record so that an opted-out address is not accidentally re-added. A customer can choose not to receive general promotions while still receiving a requested quote, order update, security notice, account lifecycle message, policy change, or direct response.
If a business contact asks about services in a professional capacity, we may send a proportionate follow-up where permitted. The message will identify LeBo Travel and provide a practical opt-out. We do not purchase opaque marketing lists, combine travel requests into third-party advertising audiences, or condition service delivery on agreement to unrelated promotional messages.
Marketing classification turns on content, purpose, recipient, and context rather than the name of the message. A transaction update can contain incidental service information without becoming marketing, while a message described as a customer update can still be promotional if its principal purpose is to encourage a new purchase.
Preference and suppression systems should identify channel, address, jurisdiction where relevant, source of permission, scope, withdrawal date, and exceptions for essential communications. Purchased, scraped, or unverifiable lists are not treated as valid permission. Campaign selection should exclude sensitive travel, support, dispute, or security information from audience-building and personalisation.
Some jurisdictions provide additional rights such as confirmation of processing, correction, deletion, access to specific categories, portability, appeal, or opting out of sale, targeted advertising, or certain profiling. If a law applies to our processing of your data, you may submit the request using Section 1.
Because we do not sell personal data or share it for cross-context behavioural advertising, there is currently no sale or targeted-advertising opt-out to apply. We will not discriminate against you for exercising an applicable privacy right.
Applicable rights depend on the person's location, our relationship with that person, statutory thresholds, and the type of processing. Terms such as “sale,” “sharing,” “targeted advertising,” and “sensitive data” have jurisdiction-specific meanings. Our statement that we do not engage in those practices describes the current service and does not waive any right that applies despite a different legal characterisation.
Where an appeal right exists, the response to the original request will explain how to appeal. We may need to preserve a request record to demonstrate compliance. Signals such as Global Privacy Control are relevant primarily to sale or targeted-advertising opt-outs; because those activities are not currently used on the public website, receiving such a signal does not ordinarily change strictly necessary processing.
Regional privacy obligations are assessed against statutory applicability, including establishment, targeting, thresholds, exemptions, and the person's relationship with LeBo Travel. Similar terminology does not guarantee identical rights or deadlines. A response is therefore mapped to the law that actually governs the request while preserving a consistent baseline of access, correction, and fair treatment.
Where required, we support appeal, authorised-agent, opt-out signal, and non-discrimination processes. Metrics or request logs can be maintained to demonstrate handling without publicly exposing requester identities. If future processing is legally characterised as sale, sharing, targeted advertising, or qualifying profiling, the required notices and opt-out controls must exist before or when that processing begins.
Our website and services are intended for adults who can enter into a contract. We do not knowingly offer accounts or direct services to children under 18. An adult arranging travel for a child may provide limited information necessary for the requested service and must have authority to do so. If you believe a child submitted data without appropriate authority, contact us.
We do not knowingly profile or market to children. Public destination information may be viewed by families, but an enquiry, account, purchase, or contract must be handled by an adult with the required authority. When an adult provides a child's details for travel support, only information reasonably necessary for the specific itinerary, booking context, accessibility need, or service coordination should be included.
If we learn that a child submitted an account or request directly, we may suspend the interaction, seek confirmation from an authorised adult, and delete information that has no lawful reason to remain. Safety, payment, fraud, dispute, and legal records may still need to be preserved. The age at which a person can consent to particular online processing varies, but our contractual service eligibility remains 18 unless we expressly agree otherwise.
Age controls are designed around the contractual audience and foreseeable use. The presence of family travel content does not make the service directed to children. An adult arranging a trip may provide limited child information, but the adult remains responsible for authority, accuracy, and communicating relevant notices where appropriate.
Potential underage submissions are assessed using the information available without requesting unnecessary identity documents. We may restrict the account or request, seek adult confirmation, preserve only records required for safety, payment, fraud, or law, and delete the remainder. Advertising, profiling, and optional communications must not be directed to a known child through the service.
We use strictly necessary cookies, browser storage, service workers, and similar technologies to provide security, authentication, order access, checkout continuity, preferences, offline public assets, and requested notifications. We do not currently load advertising cookies or third-party behavioural analytics on the public website. See the Cookie Notice for the current inventory and controls.
The Cookie Notice distinguishes browser cookies from local storage, session storage, service workers, push subscriptions, security challenges, and technologies used after redirecting to another provider. It identifies their purposes and typical duration because a browser may describe all site data under one general settings screen.
Strictly necessary technology is used to carry out a request, authenticate access, preserve transaction continuity, or protect the service. Disabling it may cause a feature to fail rather than create an alternative tracking-free version of the same feature. If we later introduce non-essential analytics, advertising, or personalisation that requires consent, it will not be activated merely because a person continues browsing.
The classification of a device technology considers whether it stores or accesses information, the party controlling it, its purpose, duration, and whether it is objectively necessary for the user-requested function. Calling a key local storage or a token rather than a cookie does not avoid applicable device-access or privacy rules.
The technical inventory should be reconciled against source code, provider configuration, browser observation, and product documentation. A new optional technology is reviewed before release for notice, consent, default state, withdrawal, retention, provider role, and geographic variation. Material discrepancies between implementation and the Cookie Notice are corrected promptly.
Links to other websites, social networks, maps, suppliers, or official sources are provided for convenience and context. Their operators control their own collection and use of personal data. Opening or interacting with a third-party service may allow that party to receive your IP address, device information, referrer, account identity, or information you submit to it.
We aim to use ordinary outbound links instead of silently loading third-party content where practical. An outbound link can still include information inherent in the destination URL, such as a campaign or service parameter, so customers should review the address before opening or sharing it. We do not control whether the destination combines the visit with an existing account or cookie.
Content posted publicly on a social platform can be visible to others and may be copied or indexed outside our control. Do not publish order numbers, access links, passport details, contact information, or travel dates in public comments. If support begins on a public channel, we may ask to continue through a private LeBo Travel-controlled channel.
Third-party interaction begins when content is requested from, transmitted to, or actively opened in another party's environment. A plain link, live embed, social plugin, map, video, and authenticated share can create different data flows. The design should minimise automatic disclosure where the third-party feature is not needed for the page to function.
Before embedding or promoting an external service, we review the information sent before interaction, referrer behaviour, account recognition, cookies, contractual purpose, and available privacy-preserving mode. Private access parameters must not be placed in publicly shareable or indexable links. Support initiated on a public network is moved to a controlled channel before account or order details are discussed.
Please contact us first so we can investigate. You also have the right to complain to the Dutch Data Protection Authority, Autoriteit Persoonsgegevens, or to the competent authority in your habitual residence, place of work, or place of the alleged infringement. Information about the Dutch authority is available at autoriteitpersoonsgegevens.nl.
A complaint should describe the processing in question, the outcome sought, and any earlier correspondence. We will route it to an appropriate person, preserve relevant evidence, and distinguish a privacy complaint from a service-quality, payment, or third-party-provider dispute. Several processes may run in parallel where the same event raises different issues.
Contacting us does not affect the right to approach a supervisory authority, and you do not need our permission to do so. The competent authority may depend on residence, workplace, establishment, or the location of the alleged infringement. We will cooperate with a lawful authority request while protecting information unrelated to the matter.
A privacy complaint can concern lawfulness, transparency, security, rights handling, provider disclosure, retention, marketing, or another aspect of processing. It is distinguished from, but may overlap with, a service complaint, refund request, employment matter, or allegation involving an independent provider.
The complaint record should include the allegation, affected data and period, immediate containment if needed, responsible investigator, evidence reviewed, findings, remedial action, communication, and escalation route. Retaliation or service discrimination for a good-faith privacy complaint is prohibited. Supervisory-authority cooperation is handled through verified official channels and limited to the lawful request.
We may update this Policy when our services, providers, technology, or legal obligations change. The "Last updated" date identifies the current version. Material changes will be communicated by a proportionate method, such as a website notice, account message, or email where required. Earlier versions remain evidenced through our controlled content revision history.
We may update wording to improve clarity without changing the underlying processing, or make a material change because a new feature, provider category, legal basis, recipient, transfer arrangement, or retention practice is introduced. The significance of the change determines the notice method and whether renewed consent is necessary.
The version in effect when an interaction occurs governs the notice for that interaction, subject to any later compatible processing and mandatory law. Publishing a new version does not retrospectively convert an unlawful practice into a lawful one. Our revision controls record publication time and support internal lawyer-review status for each immutable revision.
Version governance distinguishes editorial clarification, correction of an error, and a material change to actual processing. A material change can affect purpose, legal basis, category, recipient, transfer, retention, automated processing, rights, or the practical consequences for an individual. The effective version must be identifiable from the published record.
Change approval should document the business and legal reason, affected systems and notices, transition plan, consent or communication requirement, publication time, and reviewer status. Where a change cannot lawfully rely on the earlier notice or basis, processing is not started merely because revised wording has been drafted. Previous versions and associated review evidence remain immutable for audit purposes.
