Travel PII and Passenger Data Boundaries

Travel systems can often search anonymously, but booking and servicing may require passenger identity, contact and document data. The key principle is to open PII only at the boundary that needs it instead of carrying raw passenger data through the whole domain.

Data boundary

Passenger data boundary

Mermaid source (.mmd)

Data classes

Classify passenger name, email/phone, date of birth, nationality, identity documents, loyalty numbers, special-service requests, payment identifiers and booking references separately. They do not necessarily share the same access or retention policy.

Token/reference pattern

Use an internal reference instead of propagating raw passenger records into search, analytics and observability:

passengerProfileRef -> secure vault lookup -> scoped provider payload

Least privilege

A provider adapter should only access fields required for the active booking operation. Search and ranking services should not see passport or phone data.

Logging

Never log full provider request bodies, passport numbers, raw email/phone, payment details or authentication tokens. Prefer operational identifiers such as canonical booking ID and provider reference.

Encryption and secrets

Protect sensitive data at rest and in transit, rotate keys, and keep provider credentials separate from passenger-data surfaces.

Retention

Retention should be tied to booking lifecycle, servicing/refund windows, legal/accounting requirements, fraud/dispute needs and explicit deletion/anonymization policy.

Analytics boundary

Use business fields such as market, route/destination class, booking state, provider, amount bucket and latency instead of raw PII in analytics events.

Support and operations access

Show masked data by default. Revealing sensitive fields should require explicit permission and produce an audit trail.

Failure modes

PII in traces/logs, real passenger data in fixtures, email in analytics pipelines, passport/email used as cache keys, uncontrolled provider error-body persistence and backup retention longer than primary-data policy.

Observability

Track redaction failures, unauthorized reveal attempts, sensitive-field access, retention deletion failures and raw-payload persistence detection.

Production checklist

Use data classification, a PII-free search domain, secure passenger references, scoped adapter access, redaction, retention policies, masked operations UI, audited reveal, sanitized fixtures and backup/deletion parity.