Security

The security of this service has two features worth saying up front. First: there are no payments, no card data and no banking data in our systems. Second: the service works without an account, so there is less attack surface than in a product that stores profiles and cards.

Even so, a travel planner stores information that is sometimes sensitive: travel dates, who you are travelling with, which destinations interest you and, if you use the chat, everything you have written. What follows describes how we treat it.

The service database is copied periodically and the copies are stored encrypted with a limited retention window. A backup that has never been restored is not a backup: the restore procedure is tested periodically, not just the copy.

Trip data is separated from account data inside the same database through foreign keys, so that a deleted account cascades to everything it owns and no orphaned content is left behind.

We do not handle payment data. There is no payment gateway, no card fields, no payment tokens and no banking data. When you book, you do it on the provider's site, with your data and your payment methods.

This is not an accident: it is one of the product's design decisions. A travel planner does not need to see your card to plan your trip, and it does not ask for one.

We work with a short list of providers: the AI one, the inventory ones, email, hosting and maps. The list, with each role and its policy, is in the subprocessors document.

Each provider receives only the data it needs to do its job. The AI provider receives the trip context; the inventory providers receive the parameters of a search; none of them receives your email or your name in order to give you prices back.

If an incident compromises personal data, the plan is this: isolate and fix the access, assess what data and how many accounts are affected, notify the affected users and the competent authority when the law requires it, and document what happened so it does not happen again.

We publish the response time we commit to: we commit to answering affected users within seventy-two hours of confirming the impact. If the incident affects a subprocessor, we require the same level of notification from it.

We have no SOC 2 or ISO 27001 certifications, and we are not going to write that we do while we do not have them. Nor are we going to say that we comply with the GDPR one hundred per cent: what we do is describe concrete measures, which is something you can verify, and accept that an external auditor comes later.

A small, transparent product that tells the truth about its security posture is more useful than one that promises certifications it has not earned. When we have them, this page will say which standard, who audited it and when.

If you find a security flaw, write to us at the support address listed in the legal notice, with the relevant subject. Please do not publish it before telling us: give us time to fix it and we will be grateful for the wait.

We commit to acknowledging receipt within two working days and to keeping you informed until it is resolved. There is no reward for bug hunting: this is not a security programme, it is a favour we do well if you tell us first.