Compliance & Privacy
Nexa operates as a data processor for its airline customers. This page documents the regulatory regimes the platform addresses, the data we process (and don't process), the rights of data subjects, and the certifications we hold.
Regimes in scope
| Regime | Applies when | Notes |
|---|---|---|
| LGPD (Brazil) | Tenant operates routes touching Brazilian-resident passengers | Lei Geral de Proteção de Dados |
| GDPR (EU) | Connecting passengers or loyalty members are EU residents | Standard data-processor obligations |
| ISO/IEC 27001:2022 | Always (platform-level) | Information security management system |
| SOC 2 Type II | Always (platform-level) | Trust Services Criteria — Security, Availability, Confidentiality, Processing Integrity, Privacy |
| PCI DSS v4.0 | Wallet integration in scope for PCI compliance via Pomelo (issuer) | Nexa is not a PCI environment — see PCI boundary below |
| EU 261 | EU departures / arrivals | Compensation rules enforced via per-regulation policy keys |
| ANAC RBAC 400 | Brazilian carriers | Same — regulation-keyed policy enforcement |
| DOT 14 CFR 259 | US carriers | Same |
A regime can be added or removed per tenant via configuration; the platform's control mapping covers their union.
What data Nexa processes
The platform's data-minimization rule is strict: the minimum necessary to allocate a hotel and pay for it.
Data we process
| Category | Data | Source |
|---|---|---|
| Passenger identity (reference) | Name, contact (email/phone), language preference | Airline manifest |
| Passenger journey | PNR, cabin class, loyalty tier, special-needs flags | Airline manifest |
| Operator identity | User URN, role, organization | Identity provider |
| Case state | Case URN, sub-case state, saga progress | Internal |
| Booking | Hotel URN, vendor confirmation URN, dates, price | Vendor adapters |
| Wallet | Card URN, balance history, transaction events (no PAN) | Pomelo webhooks |
| Audit | Actor, action, before/after snapshots, correlation URN | Internal |
Data we deliberately do NOT process
The platform's toxic-PII boundary is structural. The following data never enters Nexa:
- Passport numbers, national-ID numbers, document scans.
- Date of birth.
- Card PAN, CVV, expiration (PCI boundary at the Pomelo iframe).
- Frequent-flyer credentials.
- Government-issued credentials of any kind.
The airline's PSS and the wallet provider (Pomelo) hold this data in their respective compliance scopes. Nexa references it via URN only.
Tenant isolation
A token issued for one airline cannot read another airline's data. Isolation is enforced in three reinforcing places:
- JWT claim —
tenant_urnis stamped at issuance. - Application-level guard — every query is automatically filtered. CI asserts the guard at boot.
- Per-tenant data partitioning — operational stores are partitioned per-tenant; analytical reads use row-level security; workflow topics are per-tenant with topic-level access controls; coordination state is per-tenant by namespace.
A misconfiguration that gets through one layer is caught by the other two.
PCI boundary
Nexa is not a PCI environment. The wallet integration (Pomelo) keeps the entire PCI scope on Pomelo's side:
- The PAN, CVV, and expiration never cross the Nexa backend.
- The reveal flow uses Pomelo's hosted PCI iframe; Nexa mints a short-lived JWT scoped to the card URN, but the iframe content (card details) is fetched directly from Pomelo by the passenger's browser.
- Nexa stores card URNs, balance history, and merchant + amount data — none of which is in PCI scope.
Tenants get PCI compliance for the wallet leg via Pomelo's attestation, not Nexa's. Nexa's audit scope for SOC 2 / ISO 27001 explicitly excludes PCI scope.
Data subject rights (DSR)
For passengers and operators whose data is processed via the platform, the platform supports the full DSR catalog:
| Right | API path | Turnaround target |
|---|---|---|
| Access | DSR portal request | 30 days (GDPR) / 15 days (LGPD) |
| Rectification | DSR portal request | 30 days |
| Erasure / "right to be forgotten" | DSR portal request | 30 days |
| Restriction of processing | DSR portal request | 30 days |
| Portability | DSR portal request, JSON export | 30 days |
| Objection (e.g., to certain notification channels) | Real-time via passenger PWA | Immediate |
DSR requests received by the airline (the data controller) are propagated to Nexa via a dedicated API endpoint. Nexa acknowledges within 24 hours and completes within the regulation's window.
Erasure cascade
When the airline requests erasure for a data subject:
- Nexa locates every record carrying the passenger URN (cases, sub-cases, audit, snapshots, wallet).
- Records that are operationally active (the disruption is still in progress) are flagged for deferred erasure — they must be retained until the operational obligation completes (typically the disruption + 30 days for billing reconciliation).
- Records that are archival are erased immediately, leaving an audit row that records the erasure (the audit row is not itself erased — DSR rules permit retention of audit records of the erasure itself).
- Erasure cascades to vendor sub-processors (Pomelo, Twilio, etc.) per their respective DSR contracts.
- A completion certificate is delivered back to the airline with timestamps for every step.
Audit logging
Every action that touches a passenger's data is logged. The audit row carries:
- Actor URN (operator, system, partner).
- Tenant URN.
- Action (e.g.,
STATE_TRANSITION,BOOKING_ISSUED,WALLET_ISSUED). - Entity URN (case, sub-case, reservation, card).
- Before / after snapshots.
- W3C correlation URN.
- Timestamp.
Audit is append-only — never mutated, never deleted within retention. Cold-tier rows carry hash-chain signatures for tamper-evidence: any modification breaks the chain and is detected on retrieval.
Vendor sub-processors
Every vendor that processes personal data on behalf of a Nexa tenant is a data sub-processor. Each is bound by:
- DPA (Data Processing Agreement) covering the airline's tenant.
- SCCs (Standard Contractual Clauses) where data crosses borders.
- Region pinning where the airline's regulation requires it (e.g., LGPD-compatible storage for Brazilian-resident data).
Current customer-touching sub-processors include Amadeus, Hotelbeds, Pomelo, Twilio, SendGrid, Meta, Uber, Cabify, AeroAPI, and AviationStack. Infrastructure sub-processors (cloud hosting, identity, AI, managed datastores) are listed per-tenant in the published sub-processor record under NDA.
The full sub-processor list with regions, DPAs, and SCCs is published per-tenant via Customer Success.
Certifications
| Certification | Status | Renewal cadence |
|---|---|---|
| SOC 2 Type II | Annual | Annual report available to enterprise customers under NDA |
| ISO/IEC 27001:2022 | Annual | Surveillance audit yearly; full audit every 3 years |
| LGPD | Compliance attestation | Continuous via control monitoring |
| GDPR | Compliance attestation | Continuous via control monitoring |
Certifications and attestation reports are available to customers via Customer Success after the customer signs the appropriate confidentiality agreement.
Security review for new tenants
Before a new tenant goes live, Nexa Security Engineering completes a tenant security review:
- Tenant-specific threat model.
- Vendor sub-processor sign-off (each vendor the tenant uses).
- DSR workflow validation (with airline contact).
- Penetration-test scope (covering tenant's surface).
- Incident-response runbook walkthrough.
The review takes 2–4 weeks and runs in parallel with the integration work.
Reporting a security concern
security@nexa.ai — PGP key published at https://nexa.ai/.well-known/security.txt. We follow coordinated vulnerability disclosure with researchers; please give us 90 days to fix before public disclosure.
Where to next
- Operations & SLA — uptime, MTTR, throughput, recovery objectives.
- Authentication — identity model end-to-end.
- Architecture § Tenant isolation — how the platform structurally enforces isolation.