Security & data handling

All traffic is served over HTTPS/TLS. HTTP Strict Transport Security is enabled with a one-year max-age covering subdomains, so browsers refuse to downgrade the connection. The application connects to its database over TLS in production.

Database storage and backups are encrypted at rest by our hosting provider (Railway) using platform-managed keys. We do not operate a customer-managed key (BYOK/CMEK) option.

Passwords are hashed with bcrypt and never stored or logged in plain text, and are never recoverable — a reset issues a new single-use, time-limited link rather than revealing the old password. Minimum length is 8 characters.

Application and database infrastructure is hosted in the United States. If your organisation requires EU data residency, we cannot offer it today.

Every record carries the identifier of the company that owns it, and every query that reads customer data is scoped to the signed-in user’s company. Isolation is enforced in the application layer rather than by database row-level security.

Four roles with distinct permissions: Super Admin (platform operator), Client Administrator (full access within one company), Campaign Administrator (their own campaigns and subjects), and Survey Subject (no platform login at all). Survey recipients answer through a unique emailed link and never hold an account.

Authentication uses signed JSON Web Tokens with a 24-hour lifetime (2 hours for the public demo). Changing a password invalidates the ability to sign in with the old one immediately.

Security-relevant actions — sign-ins, user and role changes, campaign and contact changes, company setting changes — are written to a per-company audit log that Client Administrators can review in the product.

A small number of operators can access production infrastructure for support and maintenance. We do not access customer survey content except where necessary to resolve a fault you have reported. See how anonymity works for a precise account of what that access could technically reveal.

A Content Security Policy restricts which origins may load scripts, styles and frames. Clickjacking, MIME-sniffing and referrer-leak protections are set through standard security headers, and camera, microphone, geolocation, payment and USB access are denied at the permissions-policy level.

All database access uses parameterised queries — user input is never concatenated into SQL.

Sign-in, password reset, signup and the public survey endpoints are individually rate limited, with a general per-IP limit across the API. Signup additionally requires email verification before the account can send any mail, which prevents a new account being used as a relay.

Card details are handled entirely by Stripe and never reach Timbre’s servers or database. We store a Stripe customer reference and subscription status only.

No audited report today, and no penetration test report we can share.

In development for the Enterprise tier. Today all users sign in with an email address and password.

A standard DPA is being prepared. If you need one to proceed, contact us — we will work through your paper rather than pretend it exists.

Infrastructure is US-hosted; there is no EU-region option.

People are added by CSV or Excel import, or individually. There is no automated HRIS sync or public API today.

Email [email protected] with details and reproduction steps. We aim to acknowledge within two business days. We will not pursue legal action against researchers who report in good faith, avoid privacy violations and data destruction, and give us reasonable time to fix the issue before disclosing it.