Trust & Security
This page lists the security controls the IMSQ platform actually ships with today — no certifications implied, no roadmap promises. The same sub-processor list backs our Privacy Policy and Data Processing Addendum.
Security controls
Tenant isolation (row-level security)
Every account’s data is isolated with PostgreSQL row-level security — access rules are enforced in the database itself, per row and per role, not only in application code.
Multi-factor authentication
Privileged roles sign in with multi-factor authentication, with support for trusted devices under an operator-controlled kill switch.
Rate limiting
Abuse-prone surfaces — public forms, email sends, payment-adjacent endpoints — are rate-limited at the database layer, with per-recipient caps on outbound email.
CI security gates
Database schema changes run a row-level-security isolation test suite and the Supabase security linter in continuous integration before they ship.
Privileged-function hardening
Database functions that run with elevated privileges pin their search path and follow default-deny grants: execute rights are revoked from public and anonymous roles and re-granted only where a surface needs them.
Leaked-password protection
Passwords are checked against known-breach corpora at sign-in and password-change via our authentication provider’s leaked-password protection.
Sub-processors
The vendors that process data to operate the service. This list is maintained in one place and is identical to the one in the Privacy Policy and the DPA.
Session transcripts
The transcript is stored in IMSQ’s secured Microsoft 365 environment but is not ingested into the IMSQ SaaS application.
Reporting a vulnerability
We publish a machine-readable security contact per RFC 9116 at /.well-known/security.txt. To report a security issue, email security@imsq.org.