Security
Your customer conversations are the most sensitive data you have. Here’s how we treat them.
Resonant IQ is a customer evidence layer — it ingests your customer conversations and account activity to show you why accounts are healthy or slipping, with receipts. We built the security architecture before we onboarded our first customer, because a product whose entire value is trustworthy evidence has to start by being trustworthy with the evidence.
This page describes what is actually built and running today. No aspirational language; where something is planned rather than shipped, we say so.
Tenant isolation
Every customer’s data lives in a logically isolated tenant, enforced in depth:
- Every query is tenant-scoped at the application boundary. Tenant-scoped database access goes through an enforced wrapper that requires a tenant context — a missing tenant filter fails loudly rather than silently returning data. A static lint rule blocks unscoped queries from entering the codebase.
- Row-level security as a second, independent layer. Postgres RLS policies back the application-layer enforcement, running under a restricted database role with guaranteed connection affinity — so even a hypothetical application-layer defect is caught at the database.
- Isolation is continuously tested, not assumed. A dedicated cross-tenant isolation test suite exercises query paths and server actions as tenant A using tenant B’s identifiers and asserts zero rows returned. It runs in CI on changes to the isolation surface and on a scheduled cadence.
Access control
- Role-based access within each tenant; sensitive commercial attributes are visible only to admin roles.
- Support access is read-only and audited. When we assist with a support issue, impersonation is write-protected at the platform level — our team can see what you see to help you, and cannot modify your data.
- Platform administration is hardened: admin access requires phishing-resistant passkey (WebAuthn) authentication with no password fallback, runs in a structurally isolated route group with its own auth configuration, and sessions expire after 30 minutes.
- Code-level controls: protected branches, required review via CODEOWNERS on security-relevant files, and CI checks required before any change reaches production.
Audit logging
- Every platform-admin action is logged — logins, impersonation start/end, tenant suspensions, settings changes, data exports — with actor, target tenant, and timestamp.
- The audit log is immutable: append-only, enforced by a database trigger. Not even we can rewrite it.
- Human score corrections are audited within each tenant with before/after values, so your QA trail is complete.
Data handling
- What we ingest: customer conversations and account activity events from the integrations you connect — nothing else.
- PII discipline in operations: personally identifiable information is stripped from server logs by design.
- Encryption: TLS for all data in transit; AES-256 encryption at rest. Integration credentials are additionally encrypted at the application layer (AES-256-GCM) before storage.
- Deletion: tenant data is deleted on request; archived accounts free their slot while preserving identity if re-added.
- Backups: automated daily backups with 7-day retention. We document our actual recovery posture (RPO ≤ 24 hours) rather than overstating it; point-in-time recovery is on our roadmap with a defined upgrade trigger.
AI and your data
Resonant IQ uses large language models to score and detect signals in conversations.
- Your data is never used to train models — ours or our providers’. This is a contractual commitment in our customer agreements, not just a policy.
- Model providers: conversation scoring uses Anthropic’s API; semantic search uses Voyage AI embeddings. Both process data per their enterprise data-handling terms; neither retains your data for training.
- Evidence over inference, structurally: every AI-generated signal is tied to the specific conversations and timestamps it came from. Nothing in the product asserts something about your customers that it cannot show you the source for.
Infrastructure & subprocessors
We run on a small, deliberate set of providers:
| Provider | Role |
|---|---|
| Vercel | Application hosting |
| Supabase | Database (Postgres), at-rest encryption, backups |
| Anthropic | AI conversation scoring |
| Voyage AI | Embeddings (semantic search) |
| Stripe | Billing (we never store payment credentials) |
| Inngest | Background job processing |
| Sentry | Error monitoring (PII scrubbed before transmission) |
| Resend | Transactional email |
| Help Scout | Customer support |
| Google Workspace | Internal email & docs |
Compliance posture — where we actually stand
We are pre-launch and do not yet hold a SOC 2 report. What we have instead, and have had since early 2026, is a running internal controls program: security-relevant work is mapped to SOC 2 Trust Services Criteria (CC6, CC7, C1) in a living controls inventory maintained in our codebase, with code references and implementation status updated in the same pull request that ships each control. Tenant isolation, access control, audit logging, and backup/recovery controls described on this page are implemented and verifiable — not planned.
We also support GDPR data-subject obligations: full tenant data export on request, and deletion as described above.
A formal SOC 2 audit is planned once we have production customers; the controls program above exists so that audit is a verification exercise, not a remediation project. Our full security documentation is available under NDA, and we’re glad to complete your security questionnaire.
Contact
Security questions or vulnerability reports: security@resonantiq.app