# Data Processing Addendum (DPA) | OnArrival > The OnArrival Data Processing Addendum: roles, scope, sub-processors, cross-border transfers, data-subject rights and audit rights. Read it in plain English. Source: https://www.onarrival.com/dpa --- At a glance Binding version Signed alongside the master agreement Written for Engineering, security and procurement teams Updated 14 May 2026 Related pages [Security page](https://www.onarrival.com/security) and [Privacy notice](https://www.onarrival.com/privacy) ## Roles 01 / 07Who is controller and who is processor, for which data 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 02 / 07What traveller data is processed for, and what is out of 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 03 / 07Sub-processor categories and how changes are notified 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](https://www.onarrival.com/security) , and controller-side data handling is described in our [Privacy notice](https://www.onarrival.com/privacy) . ## Cross-border 04 / 07Transfer mechanisms by region 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 05 / 07How traveller rights requests are routed to you 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, with a clear handoff between our teams. ## Audit 06 / 07What you can request, and how audits work 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) 07 / 07Technical and organisational measures, and breach notification 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 Traveller data is decrypted only for authorised processing - **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](https://www.onarrival.com/security) . 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. End of summary · Updated 14 May 2026Back to top