Skip to main content
OnArrival

Data Processing Addendum summary.

The binding DPA is signed alongside the master agreement. This page summarises its scope for engineering, security and procurement teams.

Illustration: a person handing a sealed envelope to a courier who receives it with both hands and tucks it carefully into a leather satchel.

Roles

Roles split cleanly along a single line, and that line is the most-misread part of any DPA. For the traveller data your customers hand you (names, contact details, documents, itineraries, payment instruments), you are the data controller: you decide why and how it is used, and we act only on your documented instructions as your data processor. We never become the controller of that traveller data. Separately, for the operational data we generate to run the platform (engineering, application and dashboard logs), we are the controller, and that data is governed by our own Privacy notice.

YOUControllerTraveller PIIyou decide why & howon instructionONARRIVALProcessorTraveller PIIwe only executeour logs · we control these
You own the traveller data · we only act on it under your instructions
The line, stated once
Traveller PII is yours to control, ours to process. Our own engineering and dashboard logs are ours to control. We do not blur the two: traveller data is never repurposed into our controller-side analytics, and our operational logs are pseudonymised away from raw passenger identifiers.

Scope

We process traveller PII strictly for the purposes you direct: searching, booking, ticketing, settling, servicing and reporting on travel. Everything outside that envelope is contractually off-limits: we do not use traveller data for our own marketing, we do not pool it to train models that benefit other customers, and we do not resell or enrich it. The boundary below is written into the DPA, not left to good intentions.

In scope vs. out of scope
In scope
Search — fares, availability and itineraries you query
Book — orders placed with airlines, GDSs and aggregators
Ticket — issuance, exchange and refund of travel documents
Settle — charging, settlement and reconciliation of payments
Service — changes, cancellations and traveller support you direct
Report — usage and booking reporting back to you
Out of scope
No marketing use — we never market to your travellers off your data
No cross-customer training — your data does not train models that serve anyone else
No resale or enrichment — we do not sell, broker or augment traveller data
The in-scope column tracks the purposes in your order form; the out-of-scope column is committed in the DPA regardless of tier. If a new purpose is ever needed, it is added by your written instruction, never assumed.

Sub-processors

Every sub-processor is listed with its name, location, purpose and tier, so you always know who touches your data and why. Material changes are notified 30 days in advance, and you may object with reasonable cause.

  • Infrastructure — cloud hosting, databases and storage that run the platform.
  • Travel supply — the airlines, GDSs and aggregators we book and ticket through on your behalf.
  • Payments & settlement — processors and ledgers used to charge, settle and reconcile.
  • Operations — observability, support and communications tooling, with PII access scoped to what each tool needs.
Where to find the details
The four classes above are the current sub-processor categories; the live registry with each vendor’s name, location and purpose is shared under your agreement. Security controls and certifications live on our Security page, and controller-side data handling is described in our Privacy notice.

Cross-border

Where traveller data crosses a border, a recognised transfer mechanism governs it. The regime depends on where your travellers are:

  • EU & UK — Standard Contractual Clauses, plus the UK Addendum where applicable.
  • India — processed in-region under the DPDP framework.
  • Enterprise tier — customer-specific data localisation available on request.

Data-subject rights

When a traveller exercises a right (access, correction, deletion, portability or objection), the request lands with us as processor, but the decision is yours as controller. So we do not answer travellers directly: we route the request to you, attach the booking context needed to act on it, and then support fulfilment with the tooling and reasonable assistance the DPA already commits us to.

The SLA, in one line
Every data-subject request is routed to you within one business day, with the relevant booking context attached, so you can meet your own statutory response windows with time to spare, rather than starting the clock when we get around to it.

Audit

You may audit our controls once per year, with reasonable notice, scoped strictly to OnArrival's processing of your data. In practice, most customers never need to send auditors on-site: our SOC 2 Type II report (refreshed annually by an independent assessor and available under NDA) satisfies the great majority of customer audit obligations, alongside our PCI DSS Level 1 Attestation of Compliance and a current penetration-test summary.

  • What you can request — the SOC 2 Type II report, PCI AoC, sub-processor registry, and the security measures annexed below, on a recurring basis without invoking a formal audit.
  • Formal audit — once per twelve-month period with 30 days’ written notice, during business hours, under confidentiality, and without access to other customers’ data or our wider production environment.
  • Cause-based audit — additional audits are available, at your cost, following a confirmed material incident affecting your data or a regulator’s direct instruction.

Security measures (Annex)

This annex summarises the technical and organisational measures (TOMs) we maintain as your processor. It is the list procurement and security teams most often ask to attach to the signed DPA. The authoritative, versioned description (including certifications and architecture detail) lives on our Security page; the two are kept aligned.

AES-256 · VAULTApplicationRBAC · tokenAnalyticspseudonymousSub-processorsflow-down DPA
Raw PII never leaves the vault; only access-controlled tokens do
  • Encryption — AES-256 at rest and TLS 1.2+ in transit, across every store that holds traveller PII or payment data.
  • PII isolation & pseudonymisation — passenger identifiers and payment instruments are held in a segregated vault and referenced by token, so application and analytics layers operate on pseudonymous keys rather than raw PII.
  • Access control — least-privilege, role-based access with mandatory SSO and MFA for staff; production PII access is scoped, time-bound and logged, with no standing access to raw customer data.
  • Logging & monitoring — immutable, centralised audit logs of access and administrative actions, retained for investigation and reviewed against alerting on anomalous behaviour.
  • Resilience & recovery — encrypted, regularly tested backups with defined recovery objectives, so a failure degrades gracefully rather than losing your data.
  • Sub-processor flow-down — every sub-processor is bound by contract to data-protection obligations no less protective than this DPA, before any traveller data reaches them.
  • Assurance — SOC 2 Type II and PCI DSS Level 1, with measures reviewed at least annually and after material change.
Breach notification
If we confirm a personal-data breach affecting your traveller data, we notify you without undue delay and within 24 hours of confirmation, the same disclosure clock published on our Security page. The notice describes the nature of the breach, the categories and approximate volume of records and data subjects affected, the likely consequences, and the measures taken or proposed to contain it, which is enough for you, as controller, to meet your own regulatory deadlines.
Get started
Have a question we didn’t answer? Talk to us.