# Security: SOC 2 and PCI DSS Travel Platform | OnArrival > How OnArrival secures travel data: SOC 2 Type II, PCI DSS Level 1, AES-256 encryption, vault-isolated PII and a 24-hour disclosure window. Read the controls. Source: https://www.onarrival.com/security --- ## 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](https://www.onarrival.com/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. 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](mailto:hello@onarrival.travel) with the details and steps to reproduce.