Security
Security Overview
Last updated: May 2026
Thrive is a clinical care platform that processes sensitive health data regulated under UK GDPR and the Data Protection Act 2018. Security is fundamental to our architecture, not an afterthought. This page provides a transparent overview of our security posture for organisations considering Thrive.
Infrastructure
| Hosting Provider | Supabase (managed PostgreSQL on AWS) |
| Data Region | AWS eu-west-2 (London, United Kingdom) |
| Web Hosting | Vercel (Edge Network, EU-routed) |
| Compliance Certifications | SOC 2 Type II, ISO 27001 (via Supabase/AWS infrastructure) |
| Database Engine | PostgreSQL 17 |
| Backups | Daily automated backups with point-in-time recovery (7 days) |
Encryption
- In transit: All connections use TLS 1.3 (HTTPS). HSTS is enforced with a 1-year max-age and includeSubDomains.
- At rest: All database storage and backups are encrypted using AES-256 via AWS managed encryption keys.
- Passwords: Stored as bcrypt hashes. Plaintext passwords are never stored or logged. Leaked password protection enabled — passwords are checked against known breach databases (HaveIBeenPwned) to prevent compromised credentials from being used.
Access Control
- Row Level Security (RLS): Enforced on every database table. Users can only access data belonging to their organisation, regardless of application-layer controls.
- Granular Permissions: 70+ individually permissioned actions across all clinical tools. Each staff role has explicit allow/deny per action.
- Patient Assignment: Non-admin staff can only view service users explicitly assigned to them — enforced at database level.
- Session Management: Cookie-based sessions with PKCE authentication flow. Automatic timeout after 30 minutes of inactivity.
- Rate Limiting: Login attempts capped at 5 per 5 minutes with automatic account lockout.
Application Security
- Security Headers: Content-Security-Policy, X-Frame-Options (DENY), X-Content-Type-Options, Referrer-Policy (strict-origin-when-cross-origin), Permissions-Policy
- Input Validation: All user input validated with Zod schemas before processing
- SQL Injection Prevention: Parameterised queries throughout — no raw string concatenation in database calls
- XSS Protection: React auto-escaping, strict CSP, no dangerouslySetInnerHTML
- CSRF Protection: SameSite cookie policy with PKCE token verification
- Error Handling: Generic error messages to prevent information leakage. Internal errors are logged server-side only.
Audit & Monitoring
- Unified Audit Trail: Every clinical action is logged with user, timestamp, old value, new value, role, and tool context.
- Field-Level Change Tracking: Audit logs capture individual field changes, not just record-level events.
- Immutable Logs: Audit entries cannot be edited or deleted by any user, including administrators.
- Filterable by: Staff member, service user, date range, action type, and tool.
AI Security
The Thrive AI assistant (Aayu) processes text entirely within the user's web browser. The AI model (Qwen2.5-1.5B-Instruct) is an open-source model cached locally on the user's device. No clinical text is transmitted to any external server during AI processing. We do not use OpenAI, Google, Anthropic, or any third-party AI APIs for clinical data.
Data Isolation
Thrive is a multi-tenant platform where each organisation's data is fully isolated at the database level. Every table includes an organization_idcolumn with Row Level Security policies that prevent cross-organisation data access. This isolation is enforced by PostgreSQL itself — not by application code — meaning even a compromised application layer cannot expose another organisation's data.
Incident Response
- Affected organisations notified within 72 hours of confirmed breach (as per UK GDPR Article 33)
- Full incident disclosure including scope, affected data categories, and remediation steps
- ICO notification where required under the Data Protection Act 2018
- Post-incident review and published learnings
What We Do Not Do
- We do not sell, share, or provide third-party access to your data
- We do not use your clinical data for AI training, analytics, or any secondary purpose
- We do not use advertising trackers, analytics cookies, or fingerprinting
- We do not store data outside the UK/EU
- We do not retain data beyond regulatory retention periods after account closure
Sub-Processors
| Provider | Purpose | Data Location |
|---|---|---|
| Supabase (AWS) | Database, authentication, file storage, edge functions | eu-west-2 (London) |
| Vercel | Web application hosting, CDN, serverless functions | EU-routed edge network |
Both sub-processors operate under GDPR-compliant Data Processing Agreements with appropriate safeguards.
Questions
For security-related enquiries or to request a copy of our Data Processing Agreement, contact us at: [email protected]
See also: Privacy Policy · Data Processing Agreement · Security FAQs