International data transfers.

01Default hosting regions

Message.com hosts customer data in the United States and the European Union by default. Each workspace is pinned to a single region at signup, chosen by the customer, and stays there for the life of the account unless the customer explicitly migrates.

The current footprint is:

• United States: DigitalOcean SFO3 (San Francisco) and NYC3 (New York). Postgres primary and read replica, Spaces object storage, Redis.
• European Union: DigitalOcean FRA1 (Frankfurt). Postgres primary and read replica, Spaces object storage, Redis.
• AI inference runs on infrastructure we operate ourselves, so your conversations stay in your account and are never sent to a third-party model provider. EU customers can opt out of US-hosted inference (see section on region pinning below).

Backups stay in the same regional pool as the primary. We do not copy EU workspace data to US storage, and we do not copy US workspace data to EU storage.

02Transfer mechanisms

Where Personal Data leaves the EEA, the UK, or Switzerland and lands in a country without an adequacy decision, Message relies on the following transfer mechanisms, in this order:

• Adequacy decisions where applicable (for example, the EU-US Data Privacy Framework where the recipient is certified, and the UK extension to the DPF).
• Standard Contractual Clauses (SCCs) as approved by the European Commission in Decision (EU) 2021/914. Module 2 applies to controller-to-processor transfers; Module 3 applies to processor-to-sub-processor transfers; Module 4 applies in the rare case where the customer is a processor and Message acts in a controller capacity for the same data (this is unusual and only happens during specific support cases).
• UK International Data Transfer Addendum (IDTA) issued by the ICO for transfers covered by the UK GDPR, used in conjunction with the EU SCCs.
• Swiss FDPIC-recognized SCCs for transfers from Switzerland, with the modifications required by the Federal Data Protection and Information Commissioner.

The SCCs are incorporated by reference into the DPA. A counter-signed copy of the DPA, including the SCCs, is available on request from [email protected].

03Adequacy decisions

The European Commission has issued adequacy decisions for a number of jurisdictions (the UK, Switzerland, Andorra, Argentina, Canada (commercial organizations), Faroe Islands, Guernsey, Israel, Isle of Man, Japan (private-sector), Jersey, New Zealand, the Republic of Korea, the United Kingdom, Uruguay, and the United States under the DPF). Where the recipient country is covered by an adequacy decision, transfers happen on that basis and the SCCs are not required.

The Data Privacy Framework status of US-based sub-processors is tracked individually. Where a sub-processor is DPF-certified, transfers ride that framework. Where it is not, the SCCs apply. The current status per sub-processor is available from [email protected].

04Region pinning

Every workspace picks a region at signup. The default is US for customers signing up from US billing addresses, EU for customers signing up from EEA/UK/CH billing addresses. The choice is persisted and used to:

• Route the primary database, replicas, and object storage to that region.
• Pin backups to the same region.
• Pin logs and traces to the same region (Grafana Cloud regional endpoints).

Enterprise customers can additionally lock down:

• AI inference to infrastructure we run ourselves, so prompts and conversations stay private by default and are never sent to an outside model provider.
• Email delivery to a region-specific Resend endpoint.
• Voice processing to a specific region on our own carrier-grade SIP infrastructure (US only at present; EU coming in 2026).

Region migration after signup is supported but is a planned operation. Talk to [email protected] to schedule one. We do not charge for migrations.

05Transfer Impact Assessments

For every transfer of Personal Data to a third country outside the EEA without an adequacy decision, Message performs a Transfer Impact Assessment (TIA) to verify that the SCCs (and any supplementary measures) provide a level of protection essentially equivalent to that guaranteed within the EEA.

Each TIA considers:

• The nature of the data being transferred and the categories of Data Subjects.
• The purpose of the transfer and the entities involved.
• The legal regime of the destination country, including government-access laws (FISA 702, Executive Order 14086, the CLOUD Act, and equivalents in other jurisdictions).
• The technical and organizational safeguards in place (encryption in transit and at rest, encryption key control, audit logging, access governance).
• Any past disclosure requests received and how they were handled.

Completed TIAs are available to customers under NDA. The first request per calendar year is free; further requests are processed at our standard time-and-materials rate.

06Supplementary measures

In line with the European Data Protection Board's Recommendations 01/2020, the following supplementary measures apply to every cross-border transfer:

• AES-256 encryption at rest on every store containing Personal Data (Postgres, Spaces, backups).
• TLS 1.2+ in transit, with HSTS preload on all customer-facing domains.
• Envelope encryption using AWS KMS keys controlled by Message; data-encryption keys rotate quarterly.
• Role-based access controls, mandatory MFA, immutable audit logging of every production query (12-month retention minimum).
• Strict policy on responding to government access requests, set out in the Data Disclosure Policy.

07Enterprise data sovereignty options

Enterprise customers with stricter sovereignty requirements (regulated industries, public-sector contracts, multi-national groups with national-data laws) can choose from these additional options:

• Single-region lock. All data, backups, telemetry, AI inference, and support access stay inside a chosen region. No replication outside that region for any purpose.
• Dedicated database cluster. The workspace runs on a database cluster that is not shared with other customers, inside the chosen region.
• Bring-your-own KMS. Encryption keys are held in a KMS instance controlled by the customer, with revocation breaking access at any time.
• Customer-controlled AI. All AI inference runs on infrastructure we operate ourselves, so customer data is never sent to an outside model provider; the customer can additionally disable AI features entirely.

These options are priced into the Enterprise tier. Talk to [email protected] to scope a deployment.

08Support and engineering access

Message support and engineering staff occasionally need to access customer data to investigate incidents or to deliver advanced support. All such access is:

• Logged in an immutable audit trail retained for at least 12 months.
• Authenticated by SSO with MFA and bound to a specific support case.
• Limited to read-only unless write access is required to perform an action the customer has requested.
• Restricted to staff in jurisdictions that satisfy the customer's region requirements; EU-pinned workspaces can require EU-based staff only.

The full procedure, including approval levels and exception handling, is documented in the Data Disclosure Policy.

09Customer obligations

Customers are responsible for:

• Choosing a workspace region that matches their legal requirements at signup.
• Including the appropriate disclosures in their own privacy notices to inform their end users that data is processed by Message in the chosen region.
• Not configuring integrations that pull data out of the chosen region (for example, a CRM hosted in a different jurisdiction) without doing their own transfer impact analysis.
• Keeping the security contact on file current so that any cross-border incident notifications reach a human who can act.

Message is happy to share template language for the customer's own privacy notice. Ask [email protected].

10Changes

We update this page whenever the underlying mechanisms change (new adequacy decision, new region launched, new SCCs published by the Commission). Material changes are communicated to security contacts on file at least 30 days before they take effect, unless the change is mandated by law on a shorter timeline.

The current effective and last-updated dates are at the top of this page. Older versions are archived and available from [email protected].