Security overview

Last updated 15 October 2026.

This page describes what is actually deployed, not what we intend to build. Where a control is missing, it is listed as missing — an institution's security review will find out either way, and finding out from us is better.

Access and authentication

  • Passwords hashed with bcrypt; login timing equalised for unknown emails
  • Sessions in httpOnly, Secure, SameSite=Lax cookies
  • Server-side session revocation
  • Role-based access at platform and study level
  • Optional Google sign-in

Protecting data

  • TLS 1.2/1.3, HSTS, HTTP redirected to HTTPS
  • Encryption at rest for database and object storage (AWS)
  • Private object storage with short-lived signed URLs
  • IP addresses never persisted — used only in memory for rate limiting

Isolating untrusted code

  • Experiments run in a sandboxed iframe on a separate origin
  • Analysis Python runs in the browser under a script-only sandbox
  • Uploaded libraries are validated by extension and content type
  • CSV exports neutralised against formula injection

Abuse and integrity

  • Redis-backed rate limiting that fails closed
  • CSRF protection via SameSite cookies and origin allowlist
  • Append-only audit log with impersonation attribution
  • Production refuses default or weak secrets

Research-specific safeguards

  • Version pinning for participant sessions
  • Immutable consent snapshots per session; typed signatures on a dedicated audited view only
  • Researchers see session IDs only — platform account identity is withheld from dashboards and exports
  • Optional per-study retention purge
  • Generated exports deleted after 7 days

Where your data can be hosted

Institutions differ on what their policy allows, so there are three options. The second and third are set up per agreement rather than running by default — ask us and we will scope it.

Standard managed service

Hosted in India. Transfers from the EEA or UK are covered by Standard Contractual Clauses and a transfer impact assessment.

Dedicated EEA deployment

For institutions whose policy requires participant data to remain in the EEA, we can scope a dedicated regional deployment. Scope, subprocessors, and timelines are agreed during onboarding.

Dedicated US deployment

For institutions that require US data residency, we can scope a dedicated regional deployment under an institutional agreement.

Institutional self-hosting

Under licence, the platform can run on your infrastructure with your object storage, mail relay, and AI provider credentials.

Not yet in place

  • Multi-factor authentication for researcher accounts
  • Independent penetration test with summary available to institutions
  • SOC 2 Type II and ISO 27001 — not currently held
  • Documented backup and disaster-recovery runbooks

Reporting a vulnerability

Email [email protected] with enough detail to reproduce the issue. We will acknowledge within three working days. Please give us a reasonable window to fix it before publishing, and do not access, modify or delete data belonging to anyone else while investigating — testing against your own account is always fine.

If something goes wrong

If a breach affects personal data we hold for a researcher, we will notify them without undue delay so they can meet their own 72-hour notification duty as controller, and we will give them the detail their regulator expects. Where we are the controller — account, wallet and billing data — we notify affected people and the relevant authority ourselves.

For institutional reviews

We complete HECVATs and institutional security questionnaires on request, and our data processing agreement with Standard Contractual Clauses is ready to countersign. A transfer impact assessment (draft, for counsel review) is available on request. An accessibility conformance report and a penetration test summary are arranged per institution, so tell us early if your review needs them. Email [email protected].