[ Security ]
Security Overview
- Effective
- August 6, 2026
- Version
- 2026-08-06
This document details the technical and organizational security measures protecting the Syntax Voice platform. We state our exact capabilities today; where a standard control does not yet exist, we disclose it plainly.
01 / Scope and Transparency
- Coverage. This overview covers the production voice and messaging service, dashboard, databases, and underlying infrastructure. It does not cover your own network security or the third-party endpoints you configure.
- Current certifications. We do not currently hold a SOC 2 Type II report, an ISO 27001 certificate, or a third-party penetration test report.
02 / Architecture and Tenant Isolation
- Infrastructure. We operate entirely on Amazon Web Services and Vercel, relying on them for all physical data center security.
- Strict two-layer isolation. Tenants share infrastructure, but logical isolation is enforced twice. First, the application strictly derives tenant identifiers from authenticated session claims. Second, the PostgreSQL database independently enforces row-level security bound per transaction. A query lacking a tenant constraint returns zero rows.
Network exposure
While the voice host tightly restricts inbound traffic to ports 443 and 80, the PostgreSQL database endpoint accepts connections from the public internet. We mitigate this by requiring encrypted transit (TLS), distinct credentials, and strict row-level security.
03 / Encryption
- In transit. All traffic is encrypted using TLS 1.2 or 1.3. Database and third-party API connections enforce TLS server-side.
- At rest (storage layer). AWS provides default storage-layer encryption for our RDS databases and S3 object storage, where call recordings and backups live.
- At rest (application layer). We apply AES-256-GCM application-layer encryption only to HIPAA-restricted Protected Health Information and third-party integration credentials. We do not apply application-layer encryption to standard transcripts, summaries, or metadata.
04 / Access Controls and People Security
- Internal access. Access is strictly need-to-know, provisioned dynamically, and bound by confidentiality. We do not currently run formal background checks, recurring awareness training, or centralized device management.
- Customer authentication. Passwords are bcrypt-hashed. We do not support multi-factor authentication today.
- Audit logging. Workspace administrative actions are logged and retained for 365 days, well beyond the 90-day retention for call records.
05 / Change and Vulnerability Management
- Automated guardrails. Our CI/CD pipeline enforces automated tests that fail any build containing blocking I/O on real-time paths, tenant-scoping violations, unminimized personal data in logs, or leaked secrets.
- Infrastructure as code. We manage all infrastructure and deployments via Terraform. Application secrets are stored securely in AWS Systems Manager Parameter Store.
- Vulnerability scanning. We do not currently run automated software composition analysis, container scanning, or scheduled external vulnerability scans.
06 / Incident Response
- 72-hour commitment. We commit to notifying you via email of any personal data breach affecting your data within 72 hours of awareness.
- Notification duty. You are the controller; you retain the responsibility to notify regulators and individuals. See the Data Processing Addendum.
07 / Resilience, Continuity, and Backups
- Single-instance architecture. The platform currently runs on a single compute instance and a single-availability-zone database. We do not have automatic failover or cross-region replicas. Outage recovery is a manual restore operation.
- Backups. We maintain AWS automated point-in-time backups and scheduled logical dumps to S3. Backups are retained for 30 days and automatically verified using a dead-man’s switch monitor.