Trust model
Defence in depth, by design.
Employee wellbeing data sits at one of the most sensitive intersections of any HR stack. MindSafe is engineered so that privacy and security are properties of the architecture, not of a settings screen. This page describes the controls we rely on at every layer of the platform.
Identity and authorisation
Authorisation is enforced at the database itself, using row-level security policies evaluated by Postgres in the security context of the requesting user. Every read and write of employee or aggregate data is policy-checked at the data layer; the application code cannot bypass these policies.
Personal pulse responses are readable only by the data subject. Aggregate team metrics are readable only by users whose role grants explicit access, and only above a defensible privacy floor of five distinct respondents per cohort. Administrative actions are scoped to a single workspace and recorded in an append-only audit log.
Encryption in transit and at rest
All connections to MindSafe use TLS 1.3 with modern cipher suites; weaker fallbacks are disabled at the edge. Application data, including pulse responses, is encrypted at rest with AES-256 against the underlying managed Postgres storage. Backups are encrypted with the same standard. Encryption keys are managed by our infrastructure providers with provider-managed rotation.
Network and runtime isolation
MindSafe runs on isolated, ephemeral serverless functions distributed across a global anycast edge network. Each request executes in a sandboxed runtime with no shared filesystem state and no persistent in-memory secrets across invocations. The edge applies DDoS mitigation and rate-limiting before traffic reaches the application, reducing both attack surface and the cost of patching.
Personal-first access patterns
Employees access their personal dashboards through signed, expiring tokens delivered by the daily pulse email. Tokens are scoped to a single employee record, expire on a short window, and are invalidated by an erasure event. There are no long-lived browser sessions for personal pulse views.
Manager and HR sessions are protected by managed authentication with secure, HTTP-only session cookies, multi-factor enrolment available, and a strict middleware-enforced lockout that prevents authenticated users from ever rendering another employee's individual data.
Aggregation and the privacy floor
Manager and HR aggregate views are gated by a minimum cohort size of five distinct respondents in the rolling reporting window. The threshold is enforced in the database query itself; cohorts that fall below the floor are not returned, regardless of caller. This prevents inferential identification from small teams.
Erasure and the right to be forgotten
Employees may erase their identity from MindSafe directly from their personal dashboard. Erasure is a single, audited operation that severs the link between the employee record and historical responses, and disables future pulse delivery to that record. Anonymised response data may persist for legitimate aggregate analysis where re-identification is not possible.
See the privacy lifecycle for the full timeline, and the data retention schedule for category-by-category retention windows.
Operational security
Production access is restricted to a small set of named operators authenticated with hardware-backed credentials. All production changes are deployed from version control through reviewed pull requests, with no direct console mutation of production data. Dependency updates are continuously monitored, and security advisories trigger expedited review.
Backups are taken automatically by our managed database provider and are restorable point-in-time within the retention window. Restores are tested as part of routine operational drills.
Incident response
In the event of a confirmed personal data breach, MindSafe will notify affected workspace administrators without undue delay and within 72 hours of becoming aware, consistent with Article 33 of the UK GDPR and the EU GDPR. Notifications include the nature of the breach, the categories and approximate number of data subjects, the likely consequences, and the measures taken or proposed to address it.
Sub-processors
MindSafe uses a small number of vetted infrastructure sub-processors to deliver the service. The current list is published in the privacy policy. Each sub-processor is bound by a written data processing agreement and operates under recognised security frameworks (ISO 27001, SOC 2 Type II, or equivalent).
Reporting a vulnerability
We welcome co-ordinated disclosure of security issues. If you believe you have found a vulnerability in MindSafe, please contact us with the technical details. We will acknowledge receipt within two business days and keep you informed of remediation progress.