Chapter 12.5 — Data Protection & Privacy
1. Purpose
travoBooks processes personal data of travellers, corporate customers, supplier contacts, and partner employees. This chapter defines the data-protection model: legal bases, data minimisation, encryption, retention, data-subject rights, breach response, and cross-border transfer controls. It is the document a Data Protection Officer (DPO) reads to evaluate the platform.
2. Why it matters
Travel data is among the most sensitive of routine commercial data — passports, dates of birth, payment instruments, travel patterns. Regulators (GDPR, UK GDPR, India DPDPA, Singapore PDPA, California CCPA, and many more) impose escalating obligations and steep fines. Beyond regulation, customer trust is the long-game asset.
3. Regulations in scope
| Regulation | Region | Relevance |
|---|---|---|
| GDPR (EU 2016/679) | EU | When processing EU residents' data |
| UK GDPR + DPA 2018 | UK | UK residents |
| DPDPA 2023 | India | India residents |
| PDPA 2012 | Singapore | Singapore residents |
| CCPA / CPRA | California | California residents |
| LGPD | Brazil | Brazil residents |
| BD ICT Act + emerging Data Protection Act | Bangladesh | travoBooks' home base |
| PCI DSS | Global | Payment card data |
| Sector-specific | Aviation, hospitality | IATA / GDS-imposed |
The platform implements the strictest applicable requirements globally to simplify operations; partner-specific tightening is supported.
4. Personal-data taxonomy
travoBooks classifies personal data into tiers:
| Tier | Examples | Treatment |
|---|---|---|
| Identifier | Name, email, phone, customer ID | Encrypted at rest; standard access controls |
| Travel document | Passport number, NID, visa info | Encrypted at rest with separate KMS key; restricted access; PII access logged |
| Date of birth | DOB | Same as identifier |
| Payment data | Card PAN, CVV, expiry | Never stored on travoBooks infrastructure; tokenised by PCI-compliant gateway |
| Geolocation history | Travel patterns | Aggregated; raw retained only as long as needed for operational reporting |
| Behavioural | Search history, preferences | Retained per consent |
| Special category (GDPR Art. 9) | Health (special meal as proxy), religion (meal preference as proxy) | Avoided where possible; if collected (e.g., wheelchair assistance), explicit consent; minimal retention |
| Children's data | Under-16 travellers | Parental consent flag; restricted processing |
5. Legal bases for processing
GDPR Art. 6 bases, mapped to platform flows:
| Basis | Used for |
|---|---|
| Contract (Art. 6(1)(b)) | Booking processing — fulfilment of the customer's request |
| Legal obligation (Art. 6(1)(c)) | Tax records, BSP records, AML/sanctions screening |
| Legitimate interest (Art. 6(1)(f)) | Fraud detection, security logs |
| Consent (Art. 6(1)(a)) | Marketing communications, optional preferences |
| Vital interests | Emergency contact during travel disruption |
The basis used per dataset is documented in data_processing_register table — the platform-level Record of Processing Activities (Art. 30).
6. Data minimisation
Platform principles: - Capture only fields needed for the operation. - Optional fields clearly flagged. - Free-text "notes" fields warned at input ("avoid personal data here"). - Test data masking — production data anonymised before non-prod use. - Reports default to aggregates; per-individual exports require explicit permission.
Schema enforces minimisation: e.g., customer_passengers.passport_number is NULL for domestic bookings (not needed); UI doesn't prompt for it.
7. Encryption
| Data type | Encryption at rest | Encryption in transit |
|---|---|---|
| Operational DB | AES-256 column-level for tiered PII; full-disk for the rest | TLS 1.3 |
| Backups | KMS-encrypted | TLS 1.3 to S3 |
| Document store (S3) | SSE-KMS per partner key | TLS 1.3 |
| Logs (operational) | KMS-encrypted | TLS 1.3 |
| Replication streams | Encrypted | TLS-tunneled |
Each partner has a dedicated KMS key for their PII column-level encryption (envelope encryption — partner key wraps per-row data keys). Revocation of partner key effectively bricks access — used in extreme offboarding scenarios.
8. Access control
- Least privilege — permissions per Chapter 2.1 RBAC.
- PII access permission required to view tiered PII (passport number, DOB).
- PII access logging — every read of restricted PII columns logged to
pii_access_log. - Just-in-time access — operational support users get time-bound access via an approval workflow, not standing access.
- No direct DB access in production for application engineers; debugging via scoped APIs.
9. Retention
| Data | Retention | Trigger |
|---|---|---|
| Active customer profile | While active + 7 years | Last activity > 7 years → archive candidate |
| Closed-account customer profile | 7 years | From closure |
| Booking record | 10 years | From booking date |
| Financial JE | 10+ years (jurisdictional) | From posting |
| Audit logs | 7-10 years | From event |
| Payment card token | 7 years from last use | (tokens; not card data) |
| Marketing consents | Until withdrawn + 2 years | For dispute defence |
| Web logs | 90 days | For security investigation |
| PII access logs | 7 years | |
| Anonymised analytics | Indefinite |
After retention period: anonymisation, not deletion (preserves referential integrity of financial records). For specific PII, replace values with hash placeholders; the JE row referencing a customer survives, but the customer master is anonymised.
10. Data subject rights
The platform supports DSR (Data Subject Request) workflows:
| Right | Implementation |
|---|---|
| Access (Art. 15) | API + UI to export all PII held about a subject as a structured archive |
| Rectification (Art. 16) | Standard update flow with audit |
| Erasure (Art. 17) | Anonymisation flow with regulatory-exemption preservation (financial records survive anonymised) |
| Restriction (Art. 18) | Flag on customer record; reads return placeholder; writes blocked |
| Portability (Art. 20) | Structured JSON export of customer-provided data |
| Object (Art. 21) | Marketing opt-out; legitimate-interest review |
| Automated decision-making (Art. 22) | None in Phase 1 |
DSR process flow: 1. Subject submits request via DPO portal (or partner DPO contact). 2. Identity verification. 3. Routed to data-protection role. 4. Platform generates DSR report or executes the action. 5. Response within statutory window (e.g., 30 days GDPR). 6. Logged for compliance reporting.
11. Cross-border transfers
Travel data inherently flows cross-border (DAC-DXB booking touches BD, AE, supplier servers).
Mechanisms: - Standard Contractual Clauses (SCCs) — for transfers from EEA to non-adequate-decision countries. - Adequacy decisions — relied upon where available. - Supplementary measures — encryption + access controls minimise transfer risk. - Data residency — partner-configurable; primary DB region selectable; backup region selectable.
Per-partner data_residency_region field drives infrastructure placement.
12. Breach response
The platform's breach-detection signals: - Anomalous bulk PII access (PII access log analytics). - Unusual data export volumes. - Authentication anomalies (Chapter 2.2). - WAF / IDS alerts.
Response runbook: 1. Detect — alert fires. 2. Triage — security team confirms within 1 hour. 3. Contain — disable affected accounts / API tokens; rotate compromised credentials. 4. Investigate — audit log + access log forensics. 5. Assess — what PII, whose, how many. 6. Notify: - Regulator within 72 hours (GDPR Art. 33). - Affected data subjects "without undue delay" if high risk (Art. 34). - Partner (for partner-impacting breach) within 24 hours. 7. Remediate — patch root cause; verify. 8. Document — breach register entry; lessons-learned review.
13. Vendor / sub-processor management
travoBooks' sub-processors (AWS, payment gateways, email providers, SMS providers, etc.) are listed in a public sub-processor registry. Partners are notified of changes with opt-out rights per their DPA.
Each sub-processor is contractually bound by GDPR Art. 28 data-processing agreements.
14. DPO / data-protection roles
Inside travoBooks: - DPO (Anthropic-of-travoBooks role) — accountable for the platform's overall data-protection posture. - Security team — operational security. - Engineering data-handling reviewer — every PR touching PII is reviewed.
Within partner organisation: - Partner-side DPO contact captured per partner. - DSR routing to partner DPO for partner-side decisions where relevant (e.g., for legitimate-interest balancing within partner's data).
15. Audit / certification
The platform pursues / maintains: - SOC 2 Type II — annual. - ISO 27001 — annual surveillance. - PCI DSS — annual (as a merchant processor's referrer, not a card-data store). - Cloud Security Alliance STAR Level 2 — Phase 2. - HIPAA — not applicable.
Compliance evidence stored in compliance_evidence document repository.
16. Common pitfalls
- ⚠️ Free-text notes containing PII. "Notes: customer's wife Sarah is allergic to peanuts" — capture allergy structurally, not in notes.
- ⚠️ Test data with real PII. Use anonymised test data only.
- ⚠️ Export endpoints without PII permission. Easy data-leakage surface.
- ⚠️ Email attachments with PII. Use secure-link delivery, not direct attachment.
- ⚠️ Long-tail retention. Old PII you forgot you had is a breach waiting to happen.
- 🔒 Backup retention vs production retention mismatch. If production data is anonymised but backups retain the original — gap.
- 🔒 PII in logs. Strip before logging.
- ⚠️ Sub-processor change without notice. Partner DPA obligations.