SOC 2 plan
Note
Pre-launch draft. There is no SOC 2 report today. This page says what is in place, what isn't, and when we plan to get a report. Dates are targets, not commitments.
Telltale detects AI agents, not several people sharing one login; the system in scope is the hosted Telltale service (server, database, sign-in) and the people and processes that run it.
Timeline
| When (target) | Step |
|---|---|
| Launch (Q4 2026) | Publish this trust kit; security questionnaire answers ready; controls below in place |
| Q1 2027 | Pick a compliance platform (Vanta, Drata or Secureframe) and an auditor; connect GitHub, AWS, Supabase and Google Workspace; write the policies listed below; gap assessment |
| Q2 2027 | Fix gaps; start the evidence period; run the first access review, restore rehearsal and incident tabletop |
| Q2–Q3 2027 | SOC 2 Type I (Security criteria; Availability and Confidentiality if customers ask) |
| Q3 2027 – Q1 2028 | 3–6 month observation window |
| Q1 2028 | SOC 2 Type II report |
Until a report exists, customers can review this page and our questionnaire answers, and ask jad@heypharos.com for the security overview and the DPA (available on request). Supabase, AWS, Vercel and Stripe each have their own SOC 2 reports, which we will rely on as carved-out subservice organisations.
Controls in place now (from the code and the deploy plan)
| Area (TSC) | Control | Evidence |
|---|---|---|
| Logical access (CC6.1–6.3) | Customer sign-in on Supabase Auth with email confirmation, 12-character minimum and leaked-password checks, TOTP two-step available to every account (optional in production today; the operator can require it for owners and admins); roles owner/admin/viewer | Sign-in configuration and its tests; Server API and recovery |
| Tenant isolation (CC6.1) | Postgres row-level security enabled and forced on every table; application role without BYPASSRLS; start-up refuses a misconfigured role or exposed schema | The database schema and the storage conformance tests |
| Encryption (CC6.1, CC6.7) | TLS to the browser and to the database, with the database certificate verified; AES-256-GCM for stored webhook secrets, integration credentials and sign-in tokens; keys and tokens hashed | Encryption code for webhooks, integrations and sign-in, and the start-up configuration checks |
| Secrets (CC6.1) | Secrets kept off the repository and the image, read from mode-600 files by the deploy script and never printed; held in AWS Secrets Manager in a Telltale-only AWS account and referenced by the ECS task definition; never logged; rotation with overlap, audited | The deployment runbook and the AWS infrastructure templates |
| Data minimisation (C1, P) | Script never collects typed content, credentials, cookies or values; IP not stored | How Telltale works, Browser SDK, Redaction controls |
| Retention and disposal (C1.2) | Per-kind retention with automatic pruning; erasure and export by user or account; Site and account deletion | The retention and erasure code and its tests |
| Change management (CC8.1) | All changes in git; npm run check and the full test suite on every pull request and push to main (GitHub Actions); exact-pinned dependencies with committed lockfiles | The continuous-integration workflow |
| Audit logging (CC7.2) | Security-relevant actions logged per workspace without secrets or IPs | The audit log and its tests |
| Availability (A1.2) | One ECS Fargate task at launch behind a health-checked load balancer, deployment circuit breaker with automatic rollback; leader lease for background work; daily database backups. A second node needs shared rate limits and demo state first | The AWS infrastructure templates and the leader-lease code |
| Vulnerability surface (CC7.1) | One runtime dependency; strict CSP; SSRF guard on webhooks; rate limits | The dependency list and the webhook sender |
Gaps to close before Type I
- Written policies: information security, access control, change management, incident response, business continuity and disaster recovery, vendor management, data classification and retention, acceptable use, risk assessment.
- People: background checks and security training for anyone with production access; signed confidentiality.
- Access reviews: quarterly review of AWS (IAM Identity Center), Supabase, GitHub, Resend and Stripe access; two-step enforced on each; offboarding checklist.
- Branch protection: require pull-request review and passing tests on
main. - Monitoring: uptime alerting, log retention or a log drain, alert routing and on-call.
- Dependency and secret scanning: Dependabot (or equivalent) and GitHub secret scanning.
- Backups: a documented, rehearsed restore with a recorded recovery time.
- Vendor reviews: collect and review each subprocessor's SOC 2 report yearly.
- Penetration test: an external test before Type II.
- Risk register and an annual risk assessment.