Skip to main content
OnArrival

Built to hold sensitive data.

How we protect traveller data, payment tokens and supplier credentials. Start with the 30-second summary, then read as much detail as you need.

Illustration: an attendant at a bright left-luggage counter hands a traveller a small claim tag, a wall of closed lockers holding one case safely behind them.
Type II, audited annually
SOC 2
Level 1 service provider
PCI DSS
Encryption at rest
AES-256
Breach-disclosure window
24h
Security in 30 seconds

Where your data goes, and how it stays safe.

Follow one booking from your app to the airline or hotel. Each lock marks a point where the data is protected.

  1. Traveller
    Books a trip in your app.
  2. The traveller’s connection to your app is on your side.
  3. Your app
    Sends the booking to OnArrival.
  4. Encrypted in transit with TLS 1.2 or newer.
  5. OnArrival
    Processes the booking with suppliers.
    • Stored data encrypted with AES-256
    • Passport and contact details in a separate vault
    • Card data tokenised by our payment provider
    • No routine staff access, and all access logged
  6. Encrypted in transit with TLS 1.2 or newer; sensitive supplier links use mutual TLS.
  7. Suppliers
    Airlines, hotels and other suppliers confirm the trip.
Locked: encrypted while it moves. TLS is the standard behind the padlock in your browser.Dashed: the link between the traveller and your app, which sits on your side.
Six things to know
Encrypted in storage and on the moveStored data uses AES-256 encryption. Data moving between systems uses TLS 1.2 or newer.Personal details kept in a vaultNames, passports and contact details sit in a dedicated vault. Only the booking service can unlock them, and every request is logged.Card numbers become tokensOur payment provider swaps card data for a stand-in token inside its PCI environment.No routine staff accessEngineers do not have routine access to production data. Every access is logged.Independently auditedSOC 2 Type II, audited every year by an independent firm. PCI DSS Level 1, attested every year.Told within 24 hoursIf a material incident affects you, we disclose it within 24 hours of confirming it.

Audits

In short

Independent firms check our security every year. You can read the SOC 2 report and the penetration-test summary under NDA.

SOC 2
Type II
Audited annually
An independent audit of our security controls.
Audited annually by an independent firm. The report is available under NDA.
PCI DSS
Level 1 service provider
Attested annually
The card industry’s security standard.
Card data is tokenised by our payment provider (PSP) in its PCI environment: the card number is swapped for a stand-in token. Tokenisation can reduce PCI scope; confirm the scope of your integration with your QSA, your PCI assessor.
ISO 27001
Stage 2
Scheduled · Q4 2026
An international standard for managing information security.
Stage 2 audit scheduled; certification expected Q4 2026.
GDPR + CCPA
DPA per customer
Attested
EU and California privacy law.
We sign a DPA (data processing agreement) with each customer, publish a sub-processor registry and give 30 days’ notice of changes.
Pen-test
External, full-scope
At least annually
Outside experts try to break in, to find weak spots.
A full-scope external test by an independent firm, at least annually and after any material architecture change. Critical and high findings are fixed within 30 days. The executive summary is shared under NDA.

Architecture

In short

Your data lives in the region you contract in, unless an export is explicitly approved. It is kept apart from other customers’ data, and it is encrypted.

We run in multiple regions, each across multiple availability zones (separate data centres). Each customer’s data is logically isolated from every other customer’s. On Enterprise tier, each customer gets its own encryption keys.

REGION · eu-westaz-aaz-baz-ctenant_atenant_btenant_cper-customer keysLogicalisolationlanes nevercross
Per-tenant isolation across AZs: separate lanes, separate keys
Encrypted at restStored data is encrypted with AES-256 (S3, RDS and the vault), so it is unreadable without the key.
Encrypted in transitTLS 1.2+ everywhere. Sensitive supplier links use mTLS, where both sides prove who they are.
Secrets and keysHeld in AWS KMS and HashiCorp Vault, and rotated quarterly.
Personal data in a vaultOnly the booking service can read it, and each request carries an audited signature.

Access

In short

People get only the access their job needs, and every access is logged.

Least privilege from day one. Engineers do not have routine access to production data. Emergency access is granted just in time, signed, and reviewed within one business day.

Your team, your directorySSO and SCIM on the customer dashboard. Access follows your directory, so an offboarded user loses access in minutes, not on a ticket queue.
Our staff, by roleRole-based access. Sensitive roles need MFA with hardware keys, and standing production-data access is denied by default.
Every access loggedLogs stream to a tamper-resistant, append-only audit store, so every read can be traced to who made it.

PII handling

In short

Traveller details are locked in a separate vault. Other services get a reference token, not the details themselves.

Traveller PII (name, date of birth, passport and contact details) is tagged as it is saved and routed to a dedicated vault. Application services receive a reference token. Only the booking service decrypts the real data, on demand, and every call is logged.

Incoming PIIname · DOB · passporttag @ writeAES-256 · PII VAULTtok_••• (reference only)App servicestoken onlysigned decrypt · on demandBooking servicedecrypts on callaudit-log stamped
Tagged at write · only the booking service decrypts · every call is stamped

Each authorised decrypt request is signed and logged, so it can be investigated.

Sub-processors & vendor management

In short

We review every sub-processor before it touches your data, bind it to terms at least as protective as your DPA, and give you 30 days’ notice of changes.

  1. Step 1
    Review
    Before onboarding, every prospective sub-processor is assessed against the same control framework we hold ourselves to: certifications, data handling, incident history and operating regions. High-risk gaps must be fixed before any production data flows.
  2. Step 2
    Bind
    Each one is contractually bound to terms no less protective than your DPA. Confidentiality, security measures, breach notification and audit rights flow all the way down the chain. Access is scoped to the data needed for its contracted purpose.
  3. Step 3
    Publish
    The live registry lists every sub-processor by name, location, purpose and class, so your vendor file shows exactly who handles your data and why.
  4. Step 4
    Notify
    Material additions or changes are announced at least 30 days in advance. You can review them, and object with reasonable cause, before they take effect.
Sub-processor details
The current sub-processor list, with each vendor’s name, location and purpose, is maintained under your agreement and referenced from our DPA.

Incidents

In short

A documented plan sets who is on call, how issues escalate and how we tell customers. Material incidents are disclosed to affected customers within 24 hours of confirmation.

Illustration: late at night in a quiet home study, an on-call engineer calmly takes a phone call at a small desk, one hand on an open laptop, under the single warm pool of a desk lamp while the city outside sleeps.
Detectt = 0Page on-callminutesCustomer comms< 1 hourBreach disclosure< 24 hoursPostmortemshared
Comms in the first hour · disclosure inside 24, not after the postmortem
  1. Detectt = 0
  2. Page on-callminutes
  3. Customer comms< 1 hour
  4. Breach disclosure< 24 hours
  5. Postmortemshared

Resilience

In short

If a zone or a region fails, booking-critical services move to a standby automatically. We rehearse a full region failover every quarter.

RPO: the most recent data that could be lost
≤ 5 min
RTO: time to restore service
≤ 30 min
Encrypted snapshot, kept for 35 days
Every 6 h
Backups restored and integrity-checked
Monthly
Full region-failover game day
Quarterly

RPO and RTO are recovery targets for booking-critical services, contractually committed on Enterprise tier.

Booking-critical services run across availability zones. Stateless services scale across zones and stateful stores use automated failover.

async replicationRPO ≤ 5m · RTO ≤ 30mREGION APrimaryread/writereplicareplicasynchronous · in-regionREGION BWarm standbyready to take overPROMOTEDautomated · drilled quarterly
Fail over without a human in the loop: promotion is automated and drilled
  • Multi-region, multi-AZ by default. Databases keep synchronous replicas in-region and replicate asynchronously to a warm standby region. Promotion is automated and drilled.
  • Backups: continuous point-in-time recovery on primary stores, plus encrypted snapshots every 6 hours retained for 35 days. Backups are AES-256 encrypted and stored in a separate account to contain blast radius.
  • Restore testing: every month, backups are restored to an isolated environment and integrity-checked. Every quarter, a full region-failover game day is timed against our RTO.
  • DDoS protection (against floods of junk traffic): edge anycast with always-on L3/L4 absorption, L7 rate-limiting and WAF rules, and traffic shaping that sheds abusive load before it reaches origin.

Reporting

In short

Found a security issue? Email us. We acknowledge every report within one business day.

Coordinated disclosure is preferred, and we will never pursue good-faith researchers.

Report a vulnerability
Email hello@onarrival.travel with the details and steps to reproduce.
Illustration: late in the evening, a hotel concierge places a traveller's passport into one of a wall of small safe-deposit boxes behind the front desk while the traveller waits, relaxed, holding a room key.
Get started
Have a question we didn’t answer? Talk to us.

Related reading

All field notes →
AI and agents · 12 min

AI travel agents need booking permissions and spending limits

An AI agent can find a trip without having permission to buy it. Booking needs separate checks for the approved price, traveller, budget and any repeated request.

Pawan ShettyOperations · 10 min

Post-booking service: who handles changes and refunds?

A confirmed booking still needs support when a flight changes, a traveller cancels or a refund is delayed. Customers need a clear status, a next step and someone responsible for the outcome.

Ankit Sawant