Everything you need
to know.

Thrive uses enterprise-grade security at every layer. All data is encrypted in transit using TLS 1.3 (HTTPS) and encrypted at rest within our database. We enforce strict Content Security Policies, HTTP Strict Transport Security (HSTS), and prevent clickjacking with X-Frame-Options headers. Our infrastructure is hosted on Supabase, which runs on AWS with SOC 2 Type II compliance, ensuring your data is stored in secure, audited data centres.

All data is stored in a secure PostgreSQL database hosted by Supabase on AWS infrastructure. Data is stored within EU/UK-compliant regions. We do not store data on third-party servers, personal devices, or unencrypted locations. Uploaded files (such as evidence photos or organisation logos) are stored in secure, access-controlled storage buckets with strict file type and size restrictions.

Only authenticated members of your organisation can access your data. We enforce Row Level Security (RLS) on every single database table, meaning the database itself rejects any query from a user who does not belong to your organisation. Even if someone were to bypass the application layer, the database would still block unauthorised access. Within your organisation, access is further restricted by your custom Organisation Ladder — each role has granular permissions across 70+ actions, so every person only sees and does what their specific role allows.

Yes. Thrive is designed with data protection principles at its core. We collect only the minimum data necessary for clinical care delivery. All personal data is stored securely with encryption, access is restricted on a need-to-know basis through role-based permissions, and we maintain full audit trails of who accessed or modified any record. You retain full ownership of your data and can request export or deletion at any time.

Absolutely not. Your clinical data is yours. We never sell, share, rent, or provide access to your data to any third party. We do not use your data for advertising, analytics, or any purpose other than delivering the Thrive service to your organisation. There are no hidden data-sharing agreements.

If you choose to leave Thrive, you can export all your data in standard formats (CSV, Excel) before your account is closed. After account closure, we retain data for a limited period (as required by healthcare record-keeping regulations) and then permanently delete it from all systems including backups. We will never hold your data hostage.

We use multiple layers of protection: strong password requirements (minimum 12 characters with uppercase, lowercase, numbers, and symbols), rate limiting on login attempts (5 attempts per 5 minutes with automatic lockout), automatic session timeout after 30 minutes of inactivity (health data compliance), and secure cookie-based authentication with PKCE token exchange. We also use generic error messages to prevent attackers from discovering which email addresses are registered.

Yes. Every action taken within Thrive is logged in a comprehensive audit trail. This includes who made the change, what was changed (with old and new values), when it was changed, and from which role. Audit logs are filterable by user, patient, date, and action type. This supports CQC governance requirements and provides full accountability.

We implement a comprehensive set of security headers: Strict-Transport-Security (HSTS) with a 1-year max-age to force HTTPS, Content-Security-Policy to prevent XSS and injection attacks, X-Frame-Options set to DENY to prevent clickjacking, X-Content-Type-Options to prevent MIME sniffing, a strict Referrer-Policy, and a Permissions-Policy that disables camera, microphone, and geolocation access by default.

We follow responsible security practices including regular dependency updates, code reviews, and security-focused development patterns such as parameterised queries (preventing SQL injection), input validation with Zod schemas, and proper error handling that never exposes internal system details to end users. Our application is built with Next.js which provides built-in protections against common web vulnerabilities.