This page summarizes verified LeadLatch security practices. It is informational, is not a service level agreement, and does not replace the binding security obligations in the DPA.
1. Data and architecture
LeadLatch processes business account information and Caller Data that may include phone numbers, service addresses, job details, audio, transcripts, prices, drive times, and bookings. Calls pass through telephony and real-time media providers to the voice worker. Deterministic tools supply service-area, price, availability, and booking results. The application stores operational records in its hosted database and sends Customer notifications by email.
2. Authentication and tenant isolation
The dashboard uses server-side Supabase authentication and necessary session cookies. It does not ship a browser database client. Database row-level security enforces Customer isolation through the dashboard.
3. Voice-worker access
The voice worker connects through the scoped leadlatch_worker Postgres role rather than an
administrative service credential. Its database operations are concentrated in the worker database
layer and booking repository.
4. Deterministic truth controls
The voice model does not independently determine authorized prices, service-area eligibility, availability, or booking success. Backend tools produce those values, and output controls are used to reduce unauthorized price or timing statements.
5. Personnel access
Authorized personnel may access Customer and Caller Data for support, operations, debugging, security, legal needs, and targeted quality assurance. Access is limited to legitimate need and is subject to confidentiality obligations. LeadLatch does not claim that call content is accessible only to machines.
6. Secrets and transmission
Service credentials are kept outside source control and supplied through deployment configuration. Application and provider connections are configured to use encrypted transport where supported.
7. Error monitoring
LeadLatch uses Sentry with default personal-information collection disabled and additional redaction controls. Redaction reduces risk but does not guarantee that personal information can never appear in a diagnostic event.
8. Retention and deletion
A scheduled process targets matched call recordings for deletion after approximately 30 days. A known unmatched-recording coverage gap and monitoring requirement must be fixed before LeadLatch promises a firm 30-day maximum. Transcripts currently have no defined deletion schedule.
9. Providers and location
LeadLatch uses the providers listed in the Subprocessor Register. Vercel hosts more than the public website, OpenAI receives call audio and conversation content, Resend emails may contain Caller and booking details, and GitHub Actions currently handles call audio during recording ingestion.
LeadLatch does not claim that all data is processed or stored in the United States. Processing location depends on vendor, plan, region, endpoint, and subprocessors.
10. Incident handling and disclosure
LeadLatch maintains incident handling sufficient to perform its DPA obligations. Security reports
may be sent to security@leadlatch.org. No acknowledgement, resolution, or notification time is
promised on this page.
11. Current assurance status
LeadLatch is not SOC 2 certified, has not completed an external penetration test, and does not offer an uptime SLA. These statements describe current status and are not a representation that a particular certification is required for the Service.
12. Contact
Security reports: security@leadlatch.org
Privacy questions: privacy@leadlatch.org