Security Overview

Version: v1.0 — 2026-07-23 Effective date: 2026-07-23

Forward-looking statements. Some controls below describe our intended program rather than a completed one — in particular SOC 2 attestation and external penetration testing, which are called out inline as "planned" or "in progress". Where a control is gated to a specific tier or feature flag, that is stated inline.

This document is the public-facing description of how Vestibo ("Vestibo") protects customer data. It is the companion document to the technical and organisational measures referenced in Schedule 2 of the Data Processing Addendum.

Our public Trust portal at https://vestibo.com/trust exposes the live controls inventory, sub-processor list, and SOC 2 status.

1. Architecture and tenancy

• Service model. SaaS, multi-tenant by default; single-tenant and self-hosted options are available for customers with regulatory or sovereignty requirements (single-tenant deployment mode).
• Tenant isolation. Logical tenant isolation is enforced at three layers of the stack: the ORM (every model carries a tenant_id column with a foreign-key constraint), the repository layer (every query is scoped through a Tenant-aware base), and the HTTP route layer (every endpoint resolves the caller's tenant_id from the auth token and refuses cross-tenant access). A continuous test suite verifies this end-to-end on every CI run.
• Hosting region. Primary infrastructure runs on AWS in us-east-1. Single-tenant customers can pin to a specific AWS region. Sub-processors run in the regions documented in SUBPROCESSORS.md.

2. Compliance posture

3. Access control

• Customer authentication. Magic-link email login (default) plus TOTP-based MFA available on every account.
• Customer authorisation. Role-based access at the dashboard layer (Owner, Admin, Manager, Staff). API keys can be issued with scoped permissions and revoked at any time.
• Internal access. Vestibo employees use SSO with hardware tokens. Production access is just-in-time, requires written justification, and is logged. Quarterly access reviews use an access-review classifier.
• Privileged access. Database superuser, KMS administrator, and cloud-account root are limited to a documented short list and used only via break-glass procedures with audit logging.
• Session lifetime. The session token (a JWT) is valid for seven (7) days; its httpOnly cookie is cleared after thirty (30) days at the latest, and the token is revoked server-side on logout.

4. Encryption

• In transit. TLS 1.2+ for every external connection; TLS 1.3 preferred. HSTS enabled on every public host. Strong cipher suites only; we run our endpoints through Mozilla's intermediate cipher profile.
• At rest (storage layer). The application database and its backups are encrypted at the AWS storage layer (RDS) with AES-256, using AWS KMS-managed keys. (No application object storage is in use today; any future object storage will be KMS-encrypted the same way.)
• Customer-supplied secrets (application layer). API keys, OAuth tokens, and other credentials the customer connects are encrypted with an application-layer Fernet envelope (AES-128-CBC + HMAC-SHA-256) before being persisted, so a database leak alone does not yield usable secrets.
• Key management. Master keys live in AWS KMS, where automatic key rotation is available. The application-layer key can be rotated on demand via an operational runbook.

5. Audit logging

Security- and compliance-relevant actions emit a structured audit event recording the actor (user or system), tenant, action/route, status, and request ID, with before/after values included in the event description where material. The append-only ledger is hash-chained with a keyed HMAC (HMAC-SHA-256) so that tampering is detectable. Audit records are intended to be retained for one (1) year in primary storage and three (3) more years in cold storage. (Coverage is being extended toward every state-changing endpoint.)

Customers on eligible tiers can export their audit log; streaming to an external SIEM (for example via webhook) is on our roadmap.

6. Vulnerability management

• Static analysis. Ruff, Bandit, ESLint, TypeScript strict mode, and a custom Walker that asserts zero dead buttons on every public route — all run on every CI build.
• Dependency scanning. pip-audit, npm audit, Trivy (container image), Gitleaks (secret scanning) on every CI build. Critical findings block merge; high-severity findings are surfaced for triage.
• Schema fuzzing. Schemathesis runs property tests against every new HTTP endpoint, asserting contract conformance.
• Manual review. Every PR is reviewed by at least one engineer other than the author.
• Penetration testing (planned). We intend to commission an external, independent penetration test before general availability, and at least annually and on material architectural change thereafter. No external penetration test has been completed yet.
• Vulnerability disclosure. Public researcher programme at VULNERABILITY_DISCLOSURE.md.

7. Backups, recovery, and resilience

• Backups. Encrypted automated backups with point-in-time recovery for the primary database, retained seven (7) days. A cross-region disaster-recovery replica and weekly restore-integrity checks are on our roadmap.
• Restore drill. We intend to rehearse a full restore from a backup snapshot at least every six (6) months and log the result in the Trust portal.
• RPO / RTO targets. Target RPO ≤ 1 hour; target RTO ≤ 4 hours.
• Availability. See SLA.md for the contractual uptime commitment and credits.

8. Personnel security

• Background checks where permitted by law for employees with access to Customer Data.
• Confidentiality agreements for every employee and contractor.
• Annual security and privacy training for every employee, with role-based extensions for engineering, support, and sales.
• Off-boarding revokes every access within twenty-four (24) hours of separation.

9. Vendor management

We maintain a vendor risk programme:

• every sub-processor is reviewed before engagement (SOC 2 review, HIPAA BAA where needed, DPA, security questionnaire);
• every sub-processor's risk is re-scored annually (vendor risk scoring and review queue);
• the live sub-processor list lives at SUBPROCESSORS.md and is mirrored at /legal/subprocessors on the marketing site.

10. Browser Agent sandbox (planned)

The Browser Agent is an experimental capability, off by default and not yet available in production. As designed, it will run in an isolated sandbox with an allowlist of hosts the customer has explicitly approved — refusing and logging any off-allowlist navigation, isolating credentials per customer, and destroying the sandbox after each session. These egress controls describe the intended design; the production sandbox backend has not shipped yet.

11. Voice runtime security

On the default telephony path, live calls are handled through Twilio, including Twilio's speech recognition on the call fallback; Twilio is the voice sub-processor on that path. Deployments that enable the self-hosted voice runtime process speech-to-text and text-to-speech on our own infrastructure (self-hosted STT with Nemotron and TTS with Kokoro / Chatterbox), with no third-party voice sub-processor. Third-party STT/TTS providers (e.g. Deepgram, OpenAI Realtime, ElevenLabs) are optional and used only where a deployment explicitly configures them and the relevant BAA is in place. Full live-call audio is not recorded by default. Where the voicemail / message-capture path is enabled, the recorded message is Twilio-hosted, encrypted at rest, and deleted after ninety (90) days; text transcripts of conversations are stored. Recording behaviour is configured at the deployment level.

12. Incident response

• 24×7 on-call rotation; documented runbooks per service.
• Defined incident severities (SEV1–SEV5) and response targets.
• Customer-affecting incidents posted to https://vestibo.com/status.
• Personal data breaches notified to affected customers within forty-eight (48) hours of awareness per the DPA.
• Post-incident review within ten (10) business days of resolution.

13. Customer responsibilities

Some security controls are shared between Vestibo and the customer. You are responsible for:

• protecting your dashboard credentials and enabling MFA;
• configuring guardrails appropriate to your use case;
• collecting any consents and providing any AI / recording disclosures required by law in your jurisdiction;
• reviewing the suggested-improvements and escalation queues;
• not uploading PHI without a BAA in place;
• securing the third-party integrations you connect (Google, Acuity, HubSpot, Salesforce, etc.);
• reviewing your audit log and revoking access promptly when personnel change.

14. Reporting a security issue

See VULNERABILITY_DISCLOSURE.md. Urgent: security@vestibo.com.

Changelog

• v1.0 (2026-07-23) — first published version; rebranded to Vestibo and reconciled to the current product.
• v0.1 (2026-05-16) — initial internal draft.