← Back to home · Privacy policy · Sub-processors · DPA
Record of Processing Activities (ROPA)
Version 1.1 — 17 June 2026
This document is TravelCS's Record of Processing Activities maintained under Article 30 GDPR. It lists every distinct processing activity we perform — both as a controller (for our own marketing, operator account management and accountability records) and as a processor (for personal data we handle strictly on operators' documented instructions).
1. Controller identity
- Name: TravelCS
- Contact: dpo@travelcs.ai
- EU representative (Art. 27): appointed where required; named in the operator DPA at /dpa.
- Data Protection Officer: see contact above.
2. Processing activities
| Ref | Activity | Role | Purpose | Lawful basis | Subjects | Data | Recipients | Transfers | Retention | Security |
|---|---|---|---|---|---|---|---|---|---|---|
| A1a | Platform admin account management (TravelCS staff) | controller | Create, authenticate and govern TravelCS internal admin accounts (user_roles.role='admin') that operate the platform, run audits and fulfil DSAR / breach obligations. | Art. 6(1)(b) employment/contract with TravelCS; Art. 6(1)(c) legal obligation (Art. 5(2), 30, 32-34); Art. 6(1)(f) legitimate interest (platform security) | TravelCS employees and contractors with an admin role | Name, work email, hashed credentials, MFA factor, role assignment, last sign-in, auth-event IP/user-agent | Supabase (hosting), Lovable (platform), Resend (transactional email) | EEA by default; non-EEA fallbacks covered by EU SCCs 2021/914 (Module 2) | Until off-boarding + 30-day backup tail; auth logs 2 years (A8) | MFA enforced, admin-only RLS via has_role(_,'admin'), encryption in transit (TLS 1.2+) and at rest (AES-256) |
| A1b | Operator user account management (tenant employees) | controller | Create, authenticate and support operator-tenant user accounts (operator_members, operator_employees); manage per-operator roles, invites and team membership so the operator can use TravelCS as a processor on its behalf. | Art. 6(1)(b) contract (TravelCS terms with the operator covers the operator's staff using the service); Art. 6(1)(f) legitimate interest (account security, abuse prevention) | Operator admins and employees (tenant users) | Name, work email, phone, hashed credentials, operator membership, role, last sign-in, auth-event IP/user-agent | Supabase (hosting), Lovable (platform), Resend (transactional email) | EEA by default; non-EEA fallbacks covered by EU SCCs 2021/914 (Module 2) | Until account deletion or operator off-boarding + 30-day backup tail; auth logs 2 years (A8) | MFA available, strict_operator_members_* RLS scoping every tenant table, encryption in transit (TLS 1.2+) and at rest (AES-256) |
| A2 | Inbound customer messages (channels) | processor | Receive, classify, route and reply to customer messages on behalf of the operator. | Operator's lawful basis under Art. 6(1)(b) / 6(1)(f) — TravelCS processes only on documented instructions | End customers (travellers) of the operator | Customer name, email, phone, message body and metadata, channel identifiers | Google Workspace / Microsoft 365 (when connected by operator), Lovable AI gateway | EEA hosting; Google/Microsoft transfers covered by EU SCCs + EU-US DPF | Until operator deletes or 24 months idle, whichever is sooner | Strict per-operator RLS (strict_operator_members_* policies), OAuth tokens server-side only |
| A3 | Booking leads register | processor | Persist booking enquiries, dedupe by email/phone, surface them to operator employees. | Operator's Art. 6(1)(b) (contract) and Art. 6(1)(f) (legitimate interest) | End customers (travellers) of the operator | Customer email/phone/name, booking metadata, status | Supabase (storage), Lovable AI (classification only) | EEA | Operator-controlled; default 24 months after last activity | Per-operator RLS, audit log (auto_rls_applications), encryption at rest |
| A4 | AI-assisted drafting and classification | processor | Use LLMs to classify intent, draft replies and rank priorities for operator staff. | Operator's Art. 6(1)(f) legitimate interest in operational efficiency | End customers (content of their messages) | Message bodies and minimal context required for the prompt | Lovable AI gateway (no training on customer data; no third-party fine-tune) | EEA preferred; non-EEA model providers covered by SCCs Module 3 | Prompts/completions retained 30 days for abuse detection then purged | Prompt isolation, no PII in system prompts, no model-side persistence |
| A5 | Landing page / marketing leads | controller | Capture demo requests from travelcs.ai and follow up with prospects. | Art. 6(1)(a) consent (form submission) and 6(1)(f) for follow-up | Prospective customers visiting our marketing site | Email, company, source. Online Identifiers (IP address, User-Agent string, Referrer URL — Recital 30) are captured at submission for fraud-prevention and analytics. | Supabase, Resend (outbound email) | EEA | Online identifiers (IP, User-Agent, Referrer) masked / nullified after 48 hours (rule R2-minimisation, hourly job). Lead row deleted after 30 days from capture (rule R2/R3, daily job). | RLS, admin-only access via has_role(), encryption at rest, automated hourly minimisation + daily purge with monthly cadence audit |
| A6 | DSAR workflow | controller (joint with operator when scoped) | Receive, verify and fulfil Art. 15-22 data subject requests within 30 days (Art. 12(3)). | Art. 6(1)(c) legal obligation | Any data subject whose data is processed by the platform | Subject email/phone, request type, verification token, fulfilment artefacts | Admin team; affected operator when request is operator-scoped | EEA | Request record retained 3 years for accountability (Art. 5(2)) | Admin-only RLS plus strict_operator_members_* set, append-only event log |
| A7 | Security incident register | controller (joint with operator when scoped) | Triage, contain and report personal data breaches per Art. 33/34. | Art. 6(1)(c) legal obligation | Affected data subjects (identified per incident) | Incident metadata, affected categories, mitigation steps, notification timestamps | Admin team; supervisory authority (DPA); affected subjects when Art. 34 applies | EEA | 5 years from closure | Admin-only RLS plus strict_operator_members_* set, 72h DPA notification SLA tracked in DB |
| A8 | Platform telemetry and audit logs | controller | Detect abuse, debug errors, prove Art. 5(2) accountability, run RLS coverage probe. | Art. 6(1)(f) legitimate interest (security and accountability) | All authenticated users | User id, action, timestamp, IP, user-agent, RLS coverage snapshots | Admin team | EEA | 90 days for request logs; 2 years for security / RLS audit rows | Admin-only RLS, append-only tables, restricted service_role access |
| A9 | Deleted-operator JSON backups (admin restore window) | controller | When an admin permanently deletes an operator account, persist a JSON snapshot of the operator and its child rows so a mistaken deletion can be reversed within a short window and so the erasure is fully auditable (Art. 5(2)). | Art. 6(1)(c) accountability for admin-initiated erasures (Art. 5(2), Art. 30); Art. 32(1)(c) availability/resilience | The deleted operator's tenant data (operator profile + any child rows: employees, channels, leads, bookings, experiences, messages) | operator_id, company_name, deleted_by, reason, full JSONB snapshot of operator + child tables at deletion time | TravelCS admin team only (admin-only RLS, no operator or end-customer access) | EEA | 30 days from deleted_at (R11) — matches the R1 / R10 backup tail. DSAR Art. 17 erasure is honoured immediately on request, ahead of the 30-day window. | Admin-only RLS via has_role(_,'admin'), insert-only from the privileged delete-operator server function, encryption at rest (AES-256) |
3. Technical and organisational measures (Art. 32) — global
- Access control: SSO + MFA for admins; per-operator row-level security (RLS) on every tenant table; security-definer authorisation functions; quarterly access review.
- Encryption: TLS 1.2+ in transit, AES-256 at rest, OAuth tokens stored server-side and never returned to the browser.
- Security-by-default: Postgres event trigger applies the canonical RLS template to every new public table (see
public.auto_rls_applications); live coverage probe (public.audit_rls_coverage) gates audits. - Logging & monitoring: Append-only audit logs for DSARs, breach incidents, RLS application and admin actions.
- Resilience: Daily managed backups with point-in-time recovery and tested restore procedure.
- Vendor management: Every sub-processor is bound by its own DPA / SCCs — see /sub-processors.
4. International transfers (Chapter V)
Personal data is hosted in the EEA by default. Where any sub-processor unavoidably processes data outside the EEA, transfers rely on the EU Standard Contractual Clauses (Commission Implementing Decision 2021/914, Module 2 for controller-to-processor and Module 3 for processor-to-sub-processor), supplemented by the EU-US Data Privacy Framework where the sub-processor is self-certified. Per-sub-processor detail is published at /sub-processors.
5. Maintenance
This ROPA is reviewed at least every 12 months and whenever a new processing activity, sub-processor or transfer mechanism is introduced. Material changes are logged in the platform's internal change history and notified to operator admins by email.
6. Contact
Questions, audit requests or supervisory authority correspondence: dpo@travelcs.ai.