Echo Core Services and Sub-Processors

Last updated: 10 December 2025

To provide Echo’s call-based safety and wellbeing check-ins, we rely on a small number of third-party service providers (“processors” and “sub-processors”) who process personal information on our behalf.

This page explains who they are, what they do, and where they process data.

Echo:

applies multi-factor authentication (2FA) to all admin accounts
limits access to these systems to a small number of authorised Echo team members.
reviews each provider regularly for security, privacy and necessity.

For information about what data Echo collects and why, see the Echo Pilot Participant Information & Privacy Notice.

1. Definitions

Core services – Echo group entities and infrastructure providers that are essential to running the Echo application (for example hosting, storage, internal email/calendar).
Sub-processors – Third-party providers that process personal information to deliver specific Echo features (for example telephony, AI models, workflow orchestration, support tools).
Customer – The organisation (employer / pilot partner) that has a contract with Echo.

Our contracts with Customers govern our use of sub-processors and the Customer’s right to be notified of changes or to object.

2. Core infrastructure and platform services

These providers underpin the Echo platform itself.

Provider	Role	Data types processed	Primary processing / storage location(s)	Notes
Amazon Web Services (AWS)	Cloud hosting, storage (S3), and database services (DynamoDB via ElectroDB)	Core Echo application data, including worker identifiers, call metadata, transcripts, risk scores and configuration	ap-southeast-2 (Sydney, Australia)	Primary infrastructure for the Echo app and API. All data encrypted in transit and at rest using AWS services.
Managed Redis (syd1)	Short-term, high-speed storage for demo and transient data	Temporary worker identifiers and demo call data	syd1 (Sydney, Australia Southeast)	Used as a short-lived cache only. Demo-related data is automatically deleted within 24 hours via enforced TTL.
Inngest	Event-driven workflow orchestration for background jobs and scheduled tasks	Workflow events, job metadata, IDs linking events to workers/teams (pseudonymous where possible)	Cloud infrastructure operated by Inngest (multi-region)	Orchestrates retries, scheduling and durable execution for Echo workflows.
Google Workspace	Internal email and calendar used by the Echo team	Customer admin contact details, meeting invites, internal support emails (no routine worker call content)	Google global infrastructure, with no specific data region preference configured	Used mainly for admin and support communications.
Vercel	Hosting and CI/CD for Echo’s marketing site (and optionally web app frontends)	Web logs (IP addresses, user agents), basic analytics; any data submitted via embedded forms is handled by the underlying form provider (e.g. Tally)	Global edge network, regions as configured per project	Primarily serves static content and frontend assets. Any sensitive data is handled by back-end APIs hosted on AWS.

3. Sub-processors used for worker interactions

3.1 Telephony, voice AI and messaging

These providers enable Echo’s calls and reminders.

Provider	Role	Data types processed	Primary processing / storage location(s)	Notes
Twilio	Telephony platform for outbound Echo calls; creates WebSocket connections to Hume/Bland to deliver AI calls	Worker phone numbers, call metadata (time, duration, call status), and voice audio passed through Twilio’s infrastructure	AU1 (Sydney, Australia) for production Voice traffic	Twilio is pinned to the AU1 region for Australian calls. Used to originate and route Echo calls to workers.
Hume.ai	Empathic voice interface used to orchestrate live AI phone conversations	Call audio, real-time voice streams via WebSocket, conversation transcripts and interaction metadata	Cloud infrastructure operated by Hume (multi-region)	Used to run live conversations. Configured so that Hume does not use Echo data to train its foundation models.
Bland.ai	Alternative AI call orchestrator for inbound/outbound calls when used instead of Hume	Call audio, phone numbers, call metadata, conversation content	Cloud infrastructure operated by Bland (multi-region)	Used only for consented demo conversations where explicitly enabled. Transcript data for these demos is stored by Bland but limited to that use case.
ClickSend	SMS provider for sending Echo reminders (e.g. “your call is coming up”)	Worker phone numbers and SMS reminder content	Infrastructure operated by ClickSend with routing via local carriers (Australia and other regions as applicable)	Used only for reminder messages, not core check-in content.
Calendly	Scheduling tool used to book/reschedule calls (for example, when a worker misses regular calls)	Names, email addresses, phone numbers (where used), meeting times and titles	Cloud infrastructure operated by Calendly (multi-region)	Optional channel for scheduling. Echo configures events to contain only scheduling information, not full call content.

3.2 AI model providers (analysis and reporting)

These services analyse transcripts and structured data to generate insights, reports and call configurations.

Provider	Role	Data types processed	Primary processing / storage location(s)	Notes
OpenAI	Large language models used to summarise transcripts, generate reports, and design call configurations	Call transcripts and structured call data (pseudonymised where possible), prompts and model outputs	Multi-region infrastructure operated by OpenAI	Used via the API only. Echo’s configuration excludes API data from OpenAI model training. Multiple regions may be used depending on the specific API endpoint or service.
Anthropic	Claude models used alongside or instead of OpenAI to analyse transcripts, construct reports and power live call logic	Call transcripts and structured data (pseudonymised where possible)	Multi-region infrastructure operated by Anthropic (hosted on cloud providers)	Used via the API only. Echo’s configuration excludes API data from Anthropic model training. Multiple regions may be used depending on the specific API endpoint or service.

Echo’s design aims to pseudonymise worker data before sending it to AI model providers wherever possible (for example, using worker IDs and role/site codes instead of names). Where full transcripts or names must be sent, this is limited to the minimum required for the feature to work.

3.3 Forms, orchestration and alerts

These services help collect consent, orchestrate workflows and generate internal alerts.

Provider	Role	Data types processed	Primary processing / storage location(s)	Notes
Tally	Online forms for collecting worker details and consent for Echo pilots	Names, contact details, consent choices, employer name, site/team, and other form fields as configured	Cloud infrastructure operated by Tally (EU-based)	Used to capture sign-ups and consent. Form responses are then synchronised into Echo via workflow tools.
Zapier	Workflow automation to move data between Tally, Echo, ClickSend, and other systems	Worker contact details, consent status, scheduling information, and pre-/post-call processing data; may include portions of transcripts where necessary	Cloud infrastructure operated by Zapier (multi-region)	Used for pre- and post-call processing steps where no direct integration exists. Zap design is minimised to what is necessary for the workflow.
Slack	Internal communications and alerting (e.g. notifications to Echo staff when certain events or errors occur)	Limited worker-related data in alert messages (for example pseudonymous IDs, high-level issue descriptions), plus staff communications	Slack infrastructure with default US data residency	Used only for internal alerts and collaboration. Echo avoids including full transcripts or sensitive content in Slack alerts.

4. Access controls for third-party systems

Across these providers, Echo applies the following general controls:

Multi-factor authentication (2FA) is required for all admin accounts.
Access is limited to a small number of authorised Echo team members (currently Fletch and Leo), each with unique credentials.
Access is granted on the principle of least privilege – roles, API keys and tokens are scoped to the minimum permissions needed (for example, separate production vs sandbox keys).
Secrets and keys are managed via environment variables and secure secret stores rather than hard-coded into code or configuration files.

Where providers offer additional controls (for example, data-retention flags, training opt-out, or data-residency options), Echo configures these to favour privacy and minimisation.

5. Changes to this list

We may add, replace or remove processors and sub-processors over time as we scale and improve Echo. When we do so, we will:

update this page; and
where required by our agreement with Customers, notify Customers in advance and give them an opportunity to object before the change takes effect.

Customers who want to receive change notifications can contact us at privacy@echo-control.com or refer to their Data Processing Addendum (DPA) for full details.