Tenant isolation, GDPR erasure, and audit logging aren’t a checkbox added before a sales call - they’re how the data layer is built.
| Qmatrix | Typical QA tool | |
|---|---|---|
| Tenant isolation enforced at the data layer | ✓ | Often UI-only |
| GDPR export, anonymize, and true hard-delete | ✓ | Soft-delete only, commonly |
| Tamper-evident audit trail - hash-chained with sequence numbers | ✓ | Plain event log, commonly |
| Customer-runnable audit-chain verification endpoint | ✓ | Rare |
| Audit writes survive load spikes - queued durably, never dropped | ✓ | Best-effort logging |
| Per-tenant single sign-on (OIDC - Azure AD, Okta, Google, Auth0) | ✓ | Enterprise-tier only, commonly |
| HMAC-signed outbound webhooks (X-Qmatrix-Signature) | ✓ | Varies |
| Server-side enforcement of plan/billing state | ✓ | Frontend-only in some tools |
| A lapsed subscription goes read-only, never deletes data | ✓ | Varies |
Every tenant-scoped query is filtered at the data-access layer itself, not left to individual endpoints to remember. Audited across every entity in the schema; the one gap the audit found was closed and shipped with a regression test.
Account removal runs export → anonymize → hard-delete: personal data is actually gone from the database, with associated content preserved under a placeholder account rather than orphaned or silently retained.
A failed payment gives a 5-day grace period, then the workspace goes read-only. Nothing is ever auto-deleted for a billing reason - reactivating restores full access with the data exactly as it was left.
Every entry is hash-chained to its predecessor and carries a monotonic sequence number, so both tampering and silent gaps are independently detectable. Destructive changes commit their data mutation and audit row in one transaction, and under load audit writes queue durably rather than drop. You can run the verification yourself, any time, from your own workspace.
Multi-tenant SaaS (Singapore region today); a dedicated instance in a region you choose from our host's regions; or customer-managed on your own infrastructure via Docker Compose - including an air-gap mode in which the product makes zero external calls and AI points at a model server inside your network. Customer-managed deployment on infrastructure you choose - including inside the Kingdom - is offered as proven on request: our clean-environment rehearsal is scheduled, not yet run, and we say so. Customer-managed deployments use no subprocessors at all.
The data-access layer itself, not individual endpoints. Every tenant-scoped query is filtered there directly, so a missed check in one endpoint can't leak another tenant's data - audited across every entity in the schema.
Yes. Account removal runs export → anonymize → hard-delete: personal data is genuinely removed from the database, not soft-deleted or flagged hidden. Associated content is preserved under a placeholder account rather than orphaned.
A failed payment gives a 5-day grace period, then the workspace goes read-only - nothing is ever auto-deleted for a billing reason, and reactivating restores full access with the data exactly as it was left.
Every outbound delivery carries an HMAC-SHA256 signature of the body in the X-Qmatrix-Signature header, computed with the secret you set per webhook, so a receiver can reject forged payloads. The payload does not yet carry a timestamp or nonce, so replay protection is on the receiving side today: de-duplicate on the event id in the body. Timestamped signatures are on the roadmap and this answer will change when they ship.
You can run it yourself. A verification endpoint walks the hash chain and sequence numbers of your own workspace's audit log and reports any break or gap. It's the same check we run against production - a clean result means the trail is intact end to end, not that nobody has looked.
Yes - per-tenant OIDC, so your workspace points at your own identity provider: Azure AD, Okta, Google Workspace, Auth0, or any OIDC-compliant IdP. SAML is available on Enterprise terms where a provider can't do OIDC.
On SaaS: Fly.io (hosting and database, Singapore region today), Tigris (attachment storage and off-box backup copies), Stripe (billing - card data never touches Qmatrix), Sentry (error reports, unless air-gapped) and, only if you enable AI features, Anthropic - or your own AI endpoint instead. Customer-managed deployments use no subprocessors at all.
Not yet - a formal SOC 2 Type II audit is on the roadmap. The underlying controls (tenant isolation, tamper-evident audit logging, encrypted credentials, role-based access, nightly self-validating backups with a drilled restore procedure - the production-scale restore rehearsal is scheduled, not yet run) are already in place, and we'll complete a standard security questionnaire for any evaluation on request.
We’d rather walk you through the actual architecture than hand you a compliance PDF written by someone who’s never seen the code.