What we actually do, and what we do not have
This page describes practice rather than posture. It ends with a list of things we do not have, because that list is more useful to you than another paragraph about how seriously we take security.
What this page is
Most security pages are written to survive a procurement questionnaire. This one is written for an owner deciding whether to put their booking data somewhere. It describes what we do, names the failure each measure prevents, and ends with what we do not have.
We hold no ISO, SOC 2 or PCI-DSS certification, and we publish no numeric uptime guarantee.
Where client data lives and who can reach it
Wherever possible, systems run in accounts that belong to you: your hosting, your domain, your gateway merchant account. We are given access in order to work, so if the relationship ends you change the passwords and everything keeps running.
Production access inside our team is limited to named people who need it for that system — not everyone in the company, and not partner developers, who work in development environments with test data. Credentials are individual rather than a shared login, because a shared login makes the question who changed this unanswerable. When someone leaves a project their access is removed and that system's shared secrets are rotated.
Write to disk before calling anything outside
This is the one operational rule we would keep if we had to throw the rest away, and it applies to every form we build, including the one below.
When a visitor submits a form, the server writes the submission to a file on disk first. Only then does it call the outside services: a Lark webhook that puts the enquiry into the sales pipeline, and Mailgun to send the notification email.
The order matters because outside services fail in ways nobody controls. A webhook returns a 500. A route between Hanoi and Europe drops for ninety seconds. Call first and write second, and that enquiry is gone with nobody aware it existed. Written first, it is on disk and can be replayed.
Before a site goes live we deliberately break the webhook URL and submit the form. The enquiry must still appear in the log file.
Three layers against form spam, and what each one misses
An enquiry form on a public travel site is hit constantly. Three cheap layers remove almost all of it without putting a puzzle in front of a real customer.
| Layer | What it catches | What it does not catch |
|---|---|---|
| Hidden honeypot field | Automated scripts that fill every input they find | Bots written for your site, and humans paid to submit forms |
| Minimum time before submit | Scripts that post in under a second, faster than a person can read the form | A slow, patient bot that waits |
| Per-IP hourly limit | Bursts from one address, and accidental resubmissions | Distributed spam from a rotating proxy pool |
We do not add a third-party captcha by default: it loads external scripts on every page and costs bookings on weak mobile connections. The per-IP limit has a side effect worth stating — an office behind one address can hit it if several staff submit in the same hour — so the threshold is adjustable per site.
Keys, secrets and where they are not
API keys, webhook URLs, database and mail credentials live outside the public web directory or in the server environment. They are never inside the folder the web server publishes, so no misconfiguration turns a config file into a downloadable page. They are not in the code repository either: a repository gets cloned, handed over and eventually shared with a developer you no longer work with, and a key inside it lives forever.
Backups, and the part everyone skips
Backups run on a schedule matching how often the data changes, and copies are held away from the running system, because a backup on the same server is a copy of the same accident.
The part that matters is the restore. A backup nobody has restored is a belief rather than a safeguard, so a restore is performed as part of the acceptance checklist before a system goes live and the time it takes is written down — a measured number from your own system rather than an industry average.
When something breaks
Incidents are not rare in travel systems. What separates suppliers is the first hour.
- Stop the bleeding — take the broken path out of service rather than leaving customers to hit it, even if a booking form temporarily becomes an email form.
- Tell you in the same hour: what is affected, what is not, and what we know so far. A holding message with three honest facts beats silence.
- Preserve the evidence — logs and the on-disk record of enquiries, which is exactly why the write-first rule exists.
- Fix, then confirm the fix from outside the system rather than from our own dashboard.
- Write up what happened and what changes, in language your operations team can read. We do not do silent fixes.
If personal data is involved you are told, and we help you meet your own notification obligations, which are yours in law rather than ours.
Personal data, retention and what a person can ask for
An enquiry form collects what an operator needs to answer it: a name, a way to reply, and the question. A booking collects more, because the supplier and the payment require it. We build forms that ask for the minimum the operation actually uses.
Retention is agreed per project and written into the site privacy policy rather than left implicit. Enquiry records and log files are kept for a defined period and then removed; booking records are kept longer for accounting and supplier reasons, and that period comes from your accountant.
A person can ask what you hold about them, ask for it to be corrected, or ask for it to be deleted where you are not required to keep it. On systems we run there is a defined way to find everything tied to an email address and remove it. The specifics for this site are in our privacy policy.
What we do not have, and what that means for you
- No ISO 27001, SOC 2 or PCI-DSS certification. Nobody independent has audited these practices; you are trusting our description of them.
- No published uptime figure. We will not print a number we have not committed to contractually.
- No 24-hour staffed operations centre. The team works from Hanoi in GMT+7 and responds outside those hours when something is broken, which is not a rota.
- No penetration test certificate. Where a client requires one, they commission it and we fix what it finds.
Practically: if your procurement requires certificates we will not pass it, and it is better to know now than in week six.
For card payments we build hosted checkout arrangements, so card numbers are entered on the gateway's own page and never pass through servers we operate. That reduces your exposure by design; it is not a certification and we do not present it as one.
Send us your security questions before you send a contract
We answer specific questions in writing, including the ones where the answer is that we do not do that.
What travel operators ask us most
Do you have ISO or SOC 2 certification?
No. We hold no independent security certification and we do not claim one. What we can give you is a written description of how a specific system is built, hosted and accessed, and access to the people who run it.
If a certificate is a hard requirement in your procurement, we are not the right supplier and we would rather say it in the first email.
What uptime do you guarantee?
We publish no percentage, because a number without a contract behind it is marketing. What we agree per project is where the system is hosted, how it is monitored, who is contacted when it stops, and how quickly we respond during working hours.
Static sites we build have very little that can fall over, which is a large part of why we build them that way.
Who can see our bookings and customer data?
Named people on our side who work on that system, using individual credentials. Outside development partners work with test data in development environments and do not hold production access.
Where the system runs in your own hosting and gateway accounts, you can see and revoke that access yourself at any time.
What happens to our data when we stop working with you?
You get an export in a standard format, and the arrangement for it is written into the contract rather than left to goodwill. Accounts held in your name simply stay yours.
Copies on our side are removed once the handover is confirmed, apart from records we are required to keep for accounting.
Do you store credit card numbers?
No. The integrations we build use hosted checkout pages provided by the payment gateway, so card details are entered on the gateway's system and never reach a server we operate.
That reduces your exposure by design. It is not a certification, and we do not describe it as one.
Read next
Tell us what you are trying to run
What you sell, what you use today, and what is breaking. You get a written answer with an approach and a price range - not a brochure.