- Every request is checked against your organisation before any data is read. One organisation cannot see another's rows.
- Every change is written to an audit log that is never edited. Deleting governance records needs a second approver.
- KlaritiQ staff cannot open your workspace unless you switch on time-boxed support access, which is itself logged.
- Sessions expire after 2 hours idle and 7 days at most; sensitive actions need a sign-in from the last 15 minutes.
- Not yet: two-factor authentication, India hosting for the database, an external security audit.
The shape of the system
The application and database run on Render in the United States; uploaded files sit in a Cloudflare R2 bucket in the Asia-Pacific region. The case engine that runs assessments is a second service on the same database; it refuses any request that does not carry a server-to-server key, and that key is never sent to a browser. Two administrative operations, erasing a transcript and reading the authoring queue, need a second, separate key that the public-facing server deliberately does not hold, so they cannot be triggered from the web at all.
Keeping organisations apart
| Control | What it means for you |
|---|---|
| Tenant scoping on every request | Before a route touches data it confirms you are an active member of the organisation in the URL and loads only that organisation's rows. There is no "all organisations" query in the product. |
| Roles | Owner, admin, member and light. Owners can delete or transfer the organisation; admins manage members and settings; members work; light members see less. |
| Department scoping | An organisation can restrict a member to their own department's records. |
| Benchmarks without leakage | Peer comparisons use only aggregate functions (count, average, percentiles) across a group of at least several organisations, so no single organisation's numbers can be recovered. |
Accountability
| Control | What it means for you |
|---|---|
| Immutable audit log | Every state change, every sign-in, every deletion request is appended with who, what and when. Nothing in the product edits or deletes an entry while the organisation exists. Owners can export it. |
| Second-approver deletion | Deleting evidence, initiatives, risks or decisions creates a request that another admin must approve. An owner or admin can self-approve, and the log says so. |
| Support access, opt-in | KlaritiQ staff have no standing access to workspaces. An owner or admin can grant support access for a set number of hours, with a reason; the grant, its expiry and anything done under it are logged. |
| Platform admin, minimal | Our own admin console is limited to site content, subscribers, leads and the regulatory review queue. It does not browse organisation workspaces. |
Accounts and sessions
| Control | Detail |
|---|---|
| Passwords | Stored as salted hashes; we never see or store the password itself. Password-less sign-in links expire in 5 minutes and work once. |
| Sessions | 2 hours of inactivity ends a session; 7 days ends it regardless. Deleting an organisation, transferring ownership, removing a member or deleting your account requires a sign-in from the last 15 minutes. |
| Google sign-in | Optional. We store the identity Google gives us; we hold no Google credentials. |
| Single sign-on | Per-organisation SAML/OIDC registration exists in the data model and is being wired up for enterprise customers; it is not self-serve yet. |
| API keys | Shown once at creation; only a SHA-256 hash is stored. Keys are organisation-scoped. |
| Rate limits | Public forms and account endpoints are rate-limited per IP. |
Documents you upload
Files are checked against their declared type before they are accepted (a PDF must actually be a PDF), limited in size, and stored under an opaque key. Their text is sent to Claude to propose facts; the proposal sits on the document until a person confirms or rejects it. Raw files are not retained by default: an organisation switches file retention on, sets an expiry (365 days unless changed) and a storage cap, and files past expiry are deleted by a daily job while the confirmed facts remain.
Encryption, backups, logs
| Where | What is in place |
|---|---|
| In transit | HTTPS everywhere between your browser and us, and between our services and Render, Cloudflare, Anthropic, Resend, Google and HubSpot. |
| At rest | Render's managed Postgres and Cloudflare R2 both encrypt stored data at rest. We do not add a second layer of application-level encryption today. |
| Backups | Render takes automated database backups. An erased record can survive in those backups for the provider's retention window before it ages out; we do not restore backups except to recover from an outage. |
| Logs | Application logs hold request paths, user ids and error details, not document contents or assessment answers. IP addresses appear in the assessment turn log, the consent record and the admin action log for evidentiary reasons, and are removed when the account is erased. |
| Secrets | API keys for Anthropic, Resend, Google and HubSpot live in the hosting environment, never in the code repository. |
What we do not have yet
We would rather you read this here than discover it later.
| Missing | Status |
|---|---|
| Two-factor authentication | Not built. Google sign-in with 2FA on the Google side is the workaround today. |
| Hosting in India | Not offered by default. Available as a scoped arrangement agreed in writing before regulated data is uploaded. |
| Independent security audit or certification (SOC 2, ISO 27001) | None yet. We are a founder-run company pre-incorporation; we will pursue these when customers require them. |
| Security headers beyond the defaults | A hardening pass (strict transport security, content security policy) is on the list. |
| Automatic erasure of case-engine transcripts | Account and organisation purges run automatically for everything on the main database; the transcript held by the case engine is erased by an operator with the separate admin key, inside the same 30-day window. |
If something goes wrong
If we discover a breach affecting personal data we will contain it, tell affected account holders what happened and what to do, and notify the Data Protection Board of India within the timelines the DPDP Rules set. If you find a vulnerability, please write to klaritiq@gmail.com with "Security" in the subject; we will not take action against good-faith research that respects other users' data.
Related
Privacy Notice · Retention & deletion · How AI is used · Data processing terms
Questions about anything on this page: klaritiq@gmail.com. We write these pages ourselves, in plain language, to match what the product actually does; they are not a substitute for legal advice to you.