Booth security
Security
Booth takes phone calls from the public on behalf of organisations that are accountable for those callers. This page states what we do to protect the data those calls produce, what we do not do, and who answers for it.
It is written to be checked. If anything here does not match what you observe, tell us.
Accountability
Named security contact. Henki Papp, founder and director of DIAL BOOTH LTD, is responsible for security at Booth. Reach them at [email protected]. There is no ticket queue in front of that address.
Who runs the systems. Booth is a small company. The person who built the system operates it, holds privileged access, and is the incident lead. We say this plainly because it is both a strength (no hand-offs, no gaps between teams) and a limit (no separation of duties). We treat that limit with controls, not with silence: every privileged action is logged, and privileged access requires hardware security keys.
What we will tell you. If we become aware of a personal data breach affecting your organisation’s data, we notify you without undue delay. We share what is known at that point and update you as the investigation progresses, so you can meet your own reporting obligations. If your contracts or regulators require faster or more specific notification, we work to that.
Contracting entity. DIAL BOOTH LTD, registered in England and Wales, company number 17117879. Booth is the trading name.
How we protect customer data
We keep transcripts, not calls. Booth does not record or store call audio. Audio is processed in the moment to understand and answer the caller, then discarded. What remains is a text transcript of the conversation and the structured outcome of the call (the question asked, the answer given, whether a handoff was needed).
The caller’s number stays in the telephony layer. The telephony layer needs the caller’s number to route the call. We do not pass it to the speech or language services, and we do not attach it to stored transcripts or outcomes. Information a caller says aloud, including a phone number, may appear in the transcript.
One organisation, one database. Each customer’s data lives in its own database. There is no shared table, no cross-customer index, and no pooled dataset. Deleting a customer means dropping that database. We do not benchmark one organisation against another and we will not offer a product that does.
Encryption. Traffic to dialbooth.com, the organiser dashboard, and our APIs is TLS 1.2 or higher. Signalling between our telephony carrier and our call-handling servers uses TLS, and call media between them uses SRTP. Stored data is encrypted at rest by the hosting provider. The public telephone network itself is not encrypted, and no phone product can change that.
Retention. Transcripts and call outcomes belong to the organisation. The organisation controls how long they stay in Booth’s active database and can delete them from the dashboard at any time. Deletion is not instant everywhere: backup copies expire within 30 days of deletion, and data already processed by a subprocessor follows that subprocessor’s retention period in the table below. Closing an account drops the organisation’s database; account records and support correspondence are deleted within 90 days of closure unless accounting or legal duties require us to keep them.
What we do not do. No outbound calling to the public. No voice analytics beyond what is needed to answer the call: no emotion detection, no voiceprints, no caller profiling. We do not sell customer data or use it for advertising, cross-customer benchmarking, or model training. We disclose it only to the subprocessors listed below, as needed to deliver the service and under a data processing agreement. Booth itself trains no models on customer data; each subprocessor’s own terms govern its use, and we only use providers whose API terms exclude training on customer content. Booth is not an emergency line and must not be presented to callers as one.
If you called a Booth number. The organisation you called is responsible for your data. To find out what was kept or to have it deleted, contact that organisation first. If you cannot reach them or get no answer, write to [email protected] and we will take it up with them on your behalf.
Subprocessors
These are the third parties that process data on our behalf, and what each one sees. We update this table when the list changes and notify customers under contract before adding a processor that handles transcript content.
Provider
Role
What it processes
Where
Jurisdiction
Telnyx
Phone numbers, inbound call delivery (SIP)
Caller number, call audio in transit
EU points of presence
US company
DigitalOcean
Hosts the call-handling servers (LiveKit, SIP)
Call audio in transit, caller number
Amsterdam
US company
Deepgram
Speech to text
Call audio (transient), produces transcript text
EU
US company
Anthropic
Language model that composes answers from approved knowledge
Transcript text, approved knowledge. Standard API inputs and outputs are normally deleted within 30 days, subject to Anthropic’s documented exceptions
US
US company
Cartesia
Text to speech
Answer text
US
US company
Cloudflare
Application backend, per-organisation databases, dashboard hosting
Transcripts, outcomes, approved knowledge, account data
EU data localisation
US company
Auth0 (Okta)
Login for the organiser dashboard
Staff email addresses, login events
EU
US company
PostHog
Dashboard feature flags and usage analytics
Account-level usage events only; no transcript content
EU
US company
Google Workspace
Email and documents for support and contracting
Correspondence with your staff
EU
US company
Plain reading of that table: our application backend and stored data are pinned to the EU. The speech and language providers in the live call path are US companies, each under a data processing agreement and each seeing only the slice of the call its job needs. If a deployment needs the whole chain in the UK or EU, that is a scoped change we can price.
Security controls
Our controls
We describe the controls we run, in plain terms. Where a control is not in place, it is not on this list.
Identity. All company accounts sit behind single sign-on on Google Workspace Enterprise. Multi-factor authentication is enforced and limited to hardware security keys; no SMS codes, no authenticator fallbacks. There are no shared accounts and no long-lived static credentials for production systems. Access to each provider is reviewed when the provider list changes and at least quarterly.
Endpoints. Every device that touches production is company-managed, has full-disk encryption on, applies operating system updates automatically, and locks after inactivity. Lost or stolen devices can be wiped remotely.
Engineering. Every change to the product goes through a pull request with review before it reaches production. Dependabot scans dependencies for known vulnerabilities on every change and opens the patch; patches run through GitHub Actions CI before release. Secrets live in a secrets manager and are injected at deploy time; they are never committed to the repository, and GitHub secret scanning enforces that. Service tokens are short-lived and rotated.
Voice behaviour. The agent is configured to answer using knowledge the organisation has approved, in languages configured and tested for that deployment, to say when it does not know, and to hand off questions outside its configured scope. Any change to how the agent speaks or behaves is test-dialled by an operator before it goes live. Two boundaries are enforced by application code outside the model and cannot be loosened by it: the AI disclosure at the start of every call, and the risk class that decides which topics must be handed to a person.
Telephony. Our call-handling servers accept calls only from our carrier’s addresses. Inbound webhooks are verified by signature before they are acted on. The product never places outbound calls to the public, which removes the most common class of telephony fraud by design. Call concurrency is capped per deployment and spend alerts are set at the carrier.
Detection and response. Logs from the call-handling servers, the application backend, and our providers are collected centrally, and alerts page the security contact. We run a written incident response process: contain, assess impact per organisation, notify affected customers without undue delay, as stated above, fix, and write up. Transcript content is not written to logs.
Backups and recovery. Per-organisation databases are backed up daily and retained for 30 days. Restore is tested. A restore recovers one organisation’s data without touching any other.
Framework alignment
We use NIST Cybersecurity Framework 2.0 as the reference for how our controls are organised and reviewed. We are not certified against it, and NIST does not certify. We hold no ISO 27001 certificate or SOC 2 report yet. If a customer needs a formal attestation, we will say what we have, what it would take to get there, and whether the deployment justifies it.
On request under NDA we share the control mapping behind this page, our data processing agreement, and our subprocessor agreements.
Vulnerability disclosure policy
If you find a security problem in Booth, we want to hear about it, and we will not take action against you for telling us in good faith.
In scope
dialbooth.com and its subdomains, including the organiser dashboard and admin console
Booth APIs and webhooks
The voice agent’s behaviour on our published demo number, including attempts to make it answer outside approved knowledge or disclose data it should not
Out of scope
Third-party services we use (report those to the provider; we are glad to be copied)
Social engineering of Booth staff, customers, or callers
Denial of service, load testing, or automated high-volume calling. Each call to our demo number costs money and ties up a real line; please test by hand
Physical attacks, and findings on customer-owned systems
Reports that only cite a scanner’s output without a demonstrated impact
What to send
Email [email protected]. Include the steps to reproduce, the affected address or number, and what you observed. The same contact details are published in machine-readable form at https://dialbooth.com/.well-known/security.txt.
What you can expect from us
Acknowledgement within 3 working days
An initial assessment and expected fix timeline within 10 working days
Updates at least every 14 days until the issue is closed
Credit on this page if you want it, once a fix is live
We do not run a paid bounty programme at this time.
Safe harbour
We consider security research conducted under this policy to be authorised. We will not pursue civil or criminal action against you, and will not refer you to law enforcement, for research that follows these rules: stay within scope, do not access, change, or delete more data than needed to demonstrate the issue, stop and report as soon as you encounter personal data, do not disclose the issue publicly before we have had a reasonable chance to fix it (we ask for 90 days from your report), and do not demand payment in exchange for the report. If a third party takes legal action against you for research that complied with this policy, we will make it known that your actions were authorised.