Security

Compliance

Data protection and encryption

• All traffic between patients, practice staff, and VoxHealth travels over TLS 1.2 or higher. We do not accept unencrypted connections.
• Patient data is encrypted at rest with AES-256 across our databases, disk volumes, object storage, and snapshots, using keys managed by AWS KMS. Encryption at rest is verified continuously by our compliance monitoring.
• Secrets and API credentials are held in managed secret storage and are never committed to source code.
• Protected health information is kept out of our logs. Request bodies on the voice path are never logged, and our loggers redact names, dates of birth, phone numbers, and email addresses before anything is written.
• Patient data never enters our engineering tickets, source repositories, or error reports.

Infrastructure security

• VoxHealth runs on Amazon Web Services in the United States, inside private networks with no public database access.
• Administrative access to production databases happens only through an authenticated AWS Systems Manager tunnel, so there is no open port for an attacker to find.
• Staging and production are fully separate environments with separate data and separate credentials.
• Databases are backed up on a regular schedule, and we keep a documented and tested restore procedure so we can recover from data loss.
• Infrastructure configuration is monitored continuously for drift from our security baseline.

Access control and tenant isolation

• Every practice is a separate tenant. Postgres row-level security is applied to every table, so one practice can never read another practice's data, even if an application bug tried to ask for it.
• Staff accounts carry a defined role — administrator, front desk, or provider — and each role only reaches the data and actions that role needs.
• Multi-factor authentication is available for staff accounts and is enforced by the database itself on sensitive data, not just by the user interface.
• Inactive sessions are logged out automatically.
• Patients calling in must verify their identity with a one-time code before the agent will touch anything on their chart. Verification attempts are recorded and rate-limited.
• Internal employee accounts are managed centrally through Google Workspace, and access is removed on the day someone leaves.

Secure development

• Code changes are peer-reviewed, and production deploys run only through our automated pipeline.
• Automated checks run on every change: linting, type checking, unit tests, database tests that assert our tenant-isolation rules still hold, and end-to-end tests against a real database.
• Dependencies and container images are scanned automatically for known vulnerabilities, and findings are triaged and prioritized for remediation by severity.
• Engineers do not hand-deploy to production. Shipping happens by merging to a protected branch, which triggers the deployment pipeline.
• Database changes ship as versioned, append-only migrations, so every schema change is reviewable and traceable.

Monitoring, logging, and incident response

• Application errors and availability are monitored continuously, with alerting to the engineering team.
• Authentication and security events are written to an audit log that practice administrators can review in the app, and every action the AI agent takes on a call is recorded in a per-call trail.
• Webhooks from our voice, messaging, and payment providers are cryptographically verified before we act on them.
• Security events are triaged by the engineering team on detection, and we are formalizing our written incident response plan and testing schedule as part of our SOC 2 program.
• If a security incident affects patient data, we notify affected customers without unreasonable delay and support the breach notification obligations HIPAA places on both of us.

Vendors and subprocessors

• We sign a Business Associate Agreement with every vendor that handles patient data on our behalf, and we assess vendors for security before adopting them.
• Vendor access is scoped to what the integration needs and is reviewed as part of our ongoing compliance program.
• A current list of subprocessors is available to customers and prospective customers on request.

Reporting a vulnerability

Security review and documentation

This page is owned by the VoxHealth security and compliance team and is reviewed at least quarterly. Last reviewed: August 2026. Questions or corrections: security@voxhealth.ai.