TimberSwitch carries your calls, voicemails and customer numbers. This page says plainly what we protect, how, and what we don't have yet. If something here stops being true, we change the page.
Encryption
- Our website and app use HTTPS (TLS 1.2 or newer).
- Browser and app calls use encrypted signaling (secure WebSockets) and encrypted audio (DTLS-SRTP) between your device and our carrier.
- Desk phones connect over SIP with TLS. Encrypted audio is offered, and we make it required model by model once we have verified that model works with it.
- Calls to and from ordinary phone numbers leave the internet and travel over carrier phone networks, which are not end-to-end encrypted. That is true of every phone provider.
- Stored data is encrypted with AES-256. Our database (call log, messages, transcripts, contacts) is encrypted with keys held in AWS Key Management Service. Voicemail audio and call recordings are encrypted in Amazon S3 with S3-managed keys, and the storage is never public.
Your data
- No selling, no ads. We don't sell or share your data with advertisers or list brokers.
- No third-party trackers. Our website and signed-in app use our own first-party page analytics, stored on our servers. No ad pixels, no session replay. The only outside scripts are Cloudflare's bot check on our pages and Stripe's card form when you pay.
- AI and your calls. We don't train AI models on your calls. The AI receptionist's language model runs on Amazon Bedrock, which doesn't use your data to train models, or through our carrier Telnyx, whose terms and the model maker's apply. Telnyx turns the caller's speech into text. If a number's calls must stay confidential, keep the AI receptionist off for it. Voicemail transcription runs on Amazon Transcribe.
- Every outside service is listed. See our subprocessors page.
- Automatic cleanup. Voicemail audio and transcripts are deleted after 90 days, call recordings after 90 days by default, and AI receptionist transcripts after 90 days.
- Deleting a voicemail removes it from your inbox, our database and our storage (audio and transcript) right away. Database backups roll off within 7 days.
- Leaving? Ask and we delete your workspace data within 30 days.
Who can access your data
- Your team. Only members of your workspace can see its calls, voicemails, messages and contacts. Owners and admins add and remove members and set their roles.
- Workspaces are kept apart. Every query is scoped to your workspace, and automated tests check that one business can't reach another's data.
- TimberSwitch staff. A small number of staff with the site administrator role can open a workspace to fix a problem. Before they can, they have to write down why. Your workspace's owners and admins get an email right away that says who opened it, when, why, and when the access ends. The start, the reason and the end are written to your workspace's audit log, and the audit log page lists every time our staff opened your workspace. The access switches off after 4 hours at most. Our servers check that limit on every request, and staff can end the access sooner.
- Support staff see the support tickets you send us, not your workspace.
- Staff sign-in. Administrator and support staff accounts can't sign in without two-factor authentication (an authenticator app or a backup code).
- Our cloud. Engineers reach production only through single sign-on, with sessions that end after a few hours. There are no standing passwords or stored access keys for individual users in our production cloud account, and every action anyone takes in our cloud is logged (see where it runs).
Your controls
- Two-factor sign-in with an authenticator app (TOTP) and backup codes. Workspace owners can require 2FA for every member.
- Sign in with Microsoft or Google if your team prefers.
- See and sign out your sessions from your account page, one at a time or everywhere at once.
- API keys are yours to create and revoke from your account page. We store only a hash of each key.
- Audit log. Sign-ins, password and 2FA changes, API keys, member changes, staff access and other security events are recorded. Owners and admins can see their workspace's log in the app. We keep audit records for 7 years.
- Delete your workspace. Owners can delete the workspace from its settings page, or ask us and we delete your workspace data within 30 days.
Calls and numbers
- Voicemail and recordings are private. Playback checks that you belong to the workspace, then uses a link that expires after 15 minutes.
- Carrier events are signature-checked. Every call event from our carrier must carry a valid Ed25519 signature or we reject it.
- Port-out PIN. Your account page gives you a PIN, set at our carrier, that must match before your numbers can move to another provider. Porting out is free; your numbers stay yours.
- Spam and abuse controls. Every inbound call is tagged from the carrier's caller-ID signal. Tagged calls still ring. A number you block does not. International and premium-rate calling are off by default, with spending caps, and public forms have bot checks and rate limits.
- 911. The browser phone refuses 911 until the carrier has confirmed this workspace's address, and it does not ask where you are. A desk phone dials 911 straight through to the carrier, so do not rely on it until the 911 page says active. Every 911 call emails the workspace's owners and admins. Outbound calling stays off until an owner accepts the 911 limits. The details are on our 911 / E911 notice.
How we build securely
- Threat modeling. We write down how an attacker would go after us (toll fraud, number hijacking, account takeover, data theft, AI prompt tricks and more) and fix the gaps. Last refreshed October 2026.
- Automated checks on every change. Each proposed change, and a weekly scan, checks for vulnerable dependencies, risky code patterns (Semgrep), leaked secrets (gitleaks) and cloud misconfiguration (Trivy).
- Locked by default. Every web address requires sign-in unless it is on a short public list, and a test fails if anything new becomes public without a reason.
- Careful releases. Changes go through pull requests with tests. Changes are tested on a preview environment before release. Deploys happen only from tagged releases, and production takes a separate, deliberate step.
- Least-privilege cloud access. Production, testing and security logging live in separate AWS accounts. People sign in through single sign-on, and deploys use short-lived credentials instead of stored keys.
Where it runs
- Amazon Web Services, US East (N. Virginia). Your data is stored there. AI requests go to Amazon Bedrock, which may process them in other US AWS regions, or to Telnyx, which processes in the US where it can but does not guarantee the region. Our carrier and other outside services are on the subprocessors page.
- Separate accounts. Production, testing and security logging are separate AWS accounts, so a mistake or break-in in one doesn't reach the others.
- Behind Cloudflare. All web traffic comes through Cloudflare. Our load balancer only accepts connections from Cloudflare's network, and only forwards requests that carry a secret header our own Cloudflare setup adds; anything else gets an error.
- Private database. The database is managed PostgreSQL (Amazon RDS) on a private network with no internet access. Only our app servers can reach it, it requires encrypted connections, our app verifies the database's certificate on every connection, and its storage is encrypted.
- Backups. The database is backed up automatically every day, backups are encrypted and kept for 7 days, and deletion protection is on.
- Threat detection. Amazon GuardDuty watches every one of our AWS accounts for suspicious activity and is managed from the separate security account.
- Every cloud action is recorded. AWS CloudTrail logs every action in every account and region, with integrity checks on the log files, into storage in the security account that our production and testing accounts can't change. We keep those logs for a year.
- Locked logs. New CloudTrail log files are write-once for a year (S3 Object Lock), so they can't be edited or deleted early.
- Guardrails nobody can switch off. Organization policies stop anyone in our production and testing accounts from turning off the audit trail, threat detection, configuration recording or Security Hub, or from removing an account from our organization.
- Continuous checks. AWS Security Hub (AWS best-practice and CIS benchmarks), AWS Config and IAM Access Analyzer check our production and testing accounts and report to the security account.
- Read-only means read-only. Our people's read-only cloud access cannot decrypt secrets such as keys and passwords.
What we don't have yet
- No SOC 2 report.
- No independent penetration test.
- No HIPAA business associate agreement as standard (ask us if you need one).
- No approval step before our staff open your workspace. We email you with the reason when they do, but you don't approve it first.
- No self-serve export of all your workspace data (ask us and we'll send it).
What's next on our list: access requests you approve before our staff open your workspace, customer-managed encryption keys for recordings, encrypted audio required on more desk-phone models, and a second reviewer on every production release as the team grows.
Legal requests
We require valid legal process, push back on overbroad requests, and tell you about a request when the law allows.
Found a vulnerability?
We welcome security research. Report it through our support form; the subject is filled in for you. Security tools can also find our contact in security.txt. We reply within 5 business days. Please give us a reasonable chance to fix an issue before you publish it, and don't access other customers' data.
Other questions
Privacy Policy · Terms of Service · Subprocessors · 911 / E911 notice