Compliance posture, written honestly.
We do not present certifications we have not earned. We do not use a security page to sell features. This is an operational disclosure — what is built today, what is in progress, and what is explicitly out of scope.
Tenant isolation by design.
Every customer lives in its own PostgreSQL schema with search_path isolation at the connection level. A bug in application code cannot accidentally cross tenant boundaries because the database layer enforces the separation, not just the query.
- Schema-per-tenant on Cloud SQL Postgres, region northamerica-northeast2
- Never a shared table with a tenant_id filter — the isolation is structural, not conventional
- Encrypted at rest (GCP managed), TLS 1.3 in transit
- Daily automated backups with 35-day retention
Twilio as the carrier. Signed webhooks only.
Every inbound voice webhook is verified against Twilio's X-Twilio-Signature header before any processing happens. SMS webhooks are validated the same way. Twilio is PCI-DSS Level 1 certified and operates SOC 2 Type II.
- X-Twilio-Signature validated against the external HTTPS URL on every request
- PII redacted in logs — phone numbers last 4 digits only, never logged in full at INFO/WARN
- Call-recording disclosure is per-tenant and jurisdiction-aware: off by default in Canada under Criminal Code s.184 one-party consent (operator is the consenting party); pre-call disclosure plays for US two-party-consent states (CA, FL, MD, and peers)
- Voicemail fallback isolated on a separate Twilio Function — primary outage does not block callers
Gemini Live, native audio, ephemeral.
Indi runs on Google's Gemini Live native-audio model. Sessions are ephemeral: no audio is retained by the model provider for training. Transcripts are captured by us, stored in our database, and retained under our retention policy — not Google's.
- Native-audio model only — no text-to-speech stitching of pre-generated clips
- Per-session isolated context — no cross-tenant model state
- Transcripts and structured data written to customer-scoped schema only
- No customer audio used for model training at our provider or downstream
Canadian Anti-Spam Law, enforced structurally.
CASL is not a checkbox. Every outbound SMS requires an immutable sms_consent_log entry referencing how consent was captured. No consent → the code path refuses to send. There is no override, no admin toggle, no "just this once."
- In-call verbal consent, logged with call SID and timestamp
- Opt-out keywords (STOP, UNSUBSCRIBE, CANCEL) processed automatically and logged
- Consent log append-only — never deleted, only flagged revoked
- Retained for the full CASL statutory period from the last outbound message
Scoped per-tenant CRM keys, no leaked secrets.
Each tenant's CRM API credentials are stored in Google Secret Manager, accessed only by the post-call pipeline, never by frontend code. Secrets never traverse the wire unencrypted and never appear in logs, stack traces, or error responses.
- Per-tenant Secret Manager entries, scoped IAM
- No secret material in frontend bundles, ever
- Webhook signatures validated on every inbound CRM callback
- Graceful degradation: a CRM outage does not block the call; the note is queued and retried
Sentry for errors. Structured JSON for everything else.
We log what we need to operate — call SIDs, intent classifications, outcomes, durations. We do not log caller content, full phone numbers, email addresses, or any PII that is not necessary to run the system.
- Sentry error capture with caller PII redaction
- Structured JSON logs via Cloud Logging, centralized and searchable
- Uptime checks from multiple regions, paging the operator on failure
- Daily digest of anomalies reviewed manually during the pilot phase
Where we are, where we're going, where we're not.
We publish this table so you can plan your compliance conversation before procurement, not during it. If something here is a blocker, write to us directly.
Related public documents: Privacy Policy, Data Processing Addendum, and Sub-processor List.
| Framework | Status | Note |
|---|---|---|
| SOC 2 Type II | Planned | On the roadmap for late 2026. We run SOC 2-aligned controls today but are not yet audited; we will not state certification until the audit is complete. |
| CASL | Pursuing | Structural compliance enforced in code today. Operational compliance reviewed quarterly. No claim of certification; CASL does not issue one. |
| PIPEDA | Pursuing | Canadian privacy law compliance reviewed against our data-handling practices. Privacy policy (pending legal review) documents the details. |
| HIPAA | Not pursued | MeetIndi does not handle PHI. We do not position against healthcare use cases and will decline pilots that require HIPAA BAAs. |
| GDPR | Pursuing | Data-handling review for EU users in progress. Not a primary market at launch; EU customers handled case-by-case with DPAs until formal compliance lands. |
Have a specific compliance requirement?
Mortgage and legal operators especially — write first, we'll answer with specifics, and we'll tell you honestly if MeetIndi is not a fit today.