Trust & Security

• Transport and hosting safeguards. Website traffic is served over TLS, and our cloud services provide encryption capabilities. Encryption coverage for a particular datastore, backup, export, or integration must be confirmed against that service's configuration; this overview is not an attestation covering every data path.
• Role-scoped data access. Our platform uses database-level access policies alongside application permissions. Scope depends on the record, role, workflow, and privileged access involved. A service-specific access review is needed to establish the actual boundaries; we do not claim universal country isolation or identical controls across every integration.
• Workflow accountability. The platform includes case and agreement activity records and audit mechanisms. The events captured, retention, privileged access, and tamper-resistance depend on the workflow. Ask for the relevant evidence scope rather than assuming every action is recorded in one immutable log.
• Established infrastructure. We build on cloud services described in our draft Subprocessors inventory. The supplier, region, contract, and data scope must be confirmed for the service in use. Payment integrations have their own responsibilities and configuration; do not submit full card numbers or security codes through website chat or general contact messages.
• AI and human roles. Terra is a named AI assistant, not a clinician or emergency dispatcher. It may prepare information, flag issues, and support routing; its output is not a clinical sign-off, insurer approval, or payment guarantee. Where an agreed managed service includes human review, its workflow must identify the accountable human roles and escalation requirements. Clinical care remains the responsibility of appropriately licensed providers. This page does not promise that every website conversation is reviewed by a physician or a continuously staffed case team.
• Data minimization. Our design aims to limit information to what the task and authorized role need. Users should not submit unnecessary patient identifiers or records through a demo. AI prompts, logs, email, and shared documents require their own data-scope review; this principle is not a claim that identifiers never reach an integrated service.

We are pre-scale and building our formal compliance program deliberately. We would rather tell you exactly where we are than display a badge we haven't earned.

• SOC 2. We do not currently have a SOC 2 report. Any examination plans or status require confirmation.
• HIPAA. Business Associate duties depend on the actual relationship and processing. Applicable customer and vendor BAAs, safeguards, risk analysis, policies, and workforce arrangements must be confirmed for each PHI-handling service. Our formal program is in progress; a draft BAA is not evidence that these requirements have all been met. See the posture note below.
• GDPR / UK GDPR. Our draft Data Processing Addendum provides a basis for customer-specific terms and processing/security schedules. Applicable transfer mechanisms, including completed SCCs and any required UK instrument, must be selected and established for the actual data flow. Publication does not execute them.
• Independent testing. Third-party penetration testing and a coordinated vulnerability-disclosure process are planned.

Tourist SOS may handle health information in authorized coordination services. Where the facts make us a Business Associate under HIPAA, the applicable obligations arise from law, not merely from our choice of label or signature. Required BAAs and safeguards must be in place for the relevant service and subcontractors before PHI is entrusted to that workflow. We are not claiming a government-issued HIPAA certification or that every product is ready for PHI. Risk analysis, documentation, and vendor-contract completion remain part of our program. Do not use general website demonstrations or inquiry forms as an unrestricted patient-record intake channel. To discuss an appropriately scoped BAA and readiness evidence, contact security@tourist-sos.com.

Our ecosystem uses cloud services associated with US providers, but a supplier's headquarters does not establish every processing location. Confirm the actual hosting region, backups, support access, and onward transfers for the selected deployment. EU-only residency or another location restriction requires confirmed technical arrangements and a written agreement; it is not promised by this page.

What we collect and how we use it is described in our Privacy Policy. The third parties that process data on our behalf are listed on our Subprocessors page. Data-subject and privacy requests go to privacy@tourist-sos.com.

These are procurement discussion items, not a statement that every document is executed or every capability is generally available:

• Mutual NDA and a completed, approved customer DPA.
• A BAA and PHI-handling readiness evidence, where applicable.
• A confirmed service-specific subprocessor schedule and security responses.
• Deployment-specific identity and single-sign-on requirements and availability.
• Evidence of any applicable professional or cyber insurance, including scope and limits.

Request the document version, review date, coverage, exclusions, and responsible contact for material assurances. A supplier's report or certification applies to its stated scope and does not automatically cover Tourist SOS.

Security controls, operational support, clinical care, and financial authority are different responsibilities. Human review arrangements do not turn Terra into a medical professional, ensure a provider is available, establish insurance coverage, or authorize a financial commitment. The relevant service agreement, licensed professional, or authorized payer remains responsible for its own decision.

For procurement, ask us to identify which assertions are supported by current evidence, which are implementation goals, and which require a customer-specific arrangement. Relevant evidence may include access-control scope, retention and deletion procedures, incident handling, recovery testing, and supplier agreements. Availability and disclosure of that evidence must be confirmed; sensitive security details may require confidentiality protections.

We welcome good-faith vulnerability reports. Email security@tourist-sos.com with the affected service, a clear description, and the minimum evidence necessary to explain the issue. Do not send passwords or a bulk copy of personal data. If you encounter another person's records, stop accessing them and report the exposure.

Obtain written authorization before intrusive testing, automated scanning, or testing beyond your own account. Do not disrupt service, use social engineering, alter records, or test a third party's system without its permission. Give us a reasonable opportunity to investigate and remediate before disclosing details that could endanger users.

We aim to acknowledge reports promptly and will not pursue legal action against research conducted in good faith within these boundaries and any agreed authorization. This commitment cannot authorize access prohibited by law or bind another organization. Reporting a vulnerability is not a promise of a bounty or a guaranteed response or remediation time.

Security questions: security@tourist-sos.com. Procurement, questionnaires, and agreements: trust@tourist-sos.com.