Security & Technical Measures

• Every part of the application that holds personal data requires a signed-in account.
• Authentication is handled by Supabase Auth, including sign-in, email verification and password reset.
• Access to data is enforced in the database itself through row-level security policies keyed to the signed-in user, their practice membership and their permission level, rather than only in application code.
• Roles are separated: practice membership levels, clinical roles and a separate administrator role table govern what a person can see and do.
• Administrative functions re-check the caller’s administrator role server-side on every call. An administrator can generate a one-time sign-in link to access a member’s account for support.
• The iOS app offers an optional on-device biometric lock, which is enforced locally on the device.

Two-factor authentication (a time-based code from an authenticator app) is required for privileged administrative functions. The check is made on the server for every privileged action, using the assurance level recorded in the signed session, so it cannot be bypassed from the browser. An authenticator-app code is specifically required for privileged administrative functions; no other factor type unlocks them.

Any account may switch two-step verification on from its profile, and we recommend it. Once switched on it is enforced: that account must enter a six-digit code from its authenticator app at every subsequent sign-in, and the second factor can only be moved or replaced from a session that has already passed a code check — a password alone can never replace it. A member who loses access to their app is verified by support rather than self-serving a replacement. Ordinary member accounts are not compelled to switch it on, so we do not claim that every account is protected by two steps; privileged administrative functions are, without exception. The one-time secret and the codes are generated and checked by the authentication platform (Supabase Auth); Unpack never sees or stores either. A mobile number is optional contact detail and is not used for authentication, so no text-message provider is involved in signing in, and phone sign-in is switched off in the authentication platform. Privileged administrative checks fail closed: if the required code cannot be confirmed on the current session, the action is refused.

Before an administrator can sign in to a member’s account for support, they must give a written reason, and a record is written to a server-side audit log. If that record cannot be written, the access does not happen. Returning to the administrator’s own account is logged too, so each support session has a start and an end.

• All traffic between the app, our servers and our providers travels over TLS.
• Data at rest sits in managed infrastructure with the provider’s own storage and access controls.

To be explicit about a limitation: transcript text is not encrypted at application level and is not end-to-end encrypted under the current architecture. It is stored as readable text in the managed database, protected by access controls rather than by encryption we hold the key to.

We do not state an encryption-at-rest standard or algorithm here. Provider-managed at-rest protections apply, and we do not publish a contractual claim about their exact scope that we cannot evidence.

Separation is enforced by row-level security in the database. Policies scope rows to the owning user, to active practice membership, and to permission level, using security-definer helper functions so that a check on one table cannot be bypassed through another.

Shared visibility is deliberate and scoped: practice-level material is visible to members of that practice according to their role, and material shared with a coach is visible to that coach.

This is logical separation within a shared managed database, not physically separate infrastructure per practice. We do not claim absolute isolation.

• Service credentials — the privileged database key, AI gateway key, push credentials, scheduled-task secrets and integration secrets — are held as server-side environment secrets and read only inside server-side handlers.
• Only the publishable client key and public configuration reach the browser; the architecture keeps privileged keys out of client bundles by construction.
• Destructive scheduled endpoints (account purge, audio retention sweep) require a dedicated bearer secret, compare it in constant time, and fail closed if that secret is not configured. Publishable keys are never accepted for them.
• Inbound integration endpoints authenticate the caller with a per-practice or per-user token before accepting content.

There is no documented secret rotation cadence. We do not claim one.

• All AI requests are made server-side and routed through the Lovable AI Gateway.
• Speech-to-text transcription is performed by an OpenAI model reached through that gateway.
• Analysis, structuring and coaching output is produced by Google Gemini models reached through that gateway.
• Requests carry the content needed for the specific function requested — the transcript or passage being worked on and the relevant context — rather than a user’s whole history.
• We do not submit content to model providers for the purpose of training models. We do not claim a contractual training exclusion: the account is on the Lovable Pro plan, and the model-training opt-out Lovable offers on Business is not available to it. This is recorded as an open supplier governance item in the register below.

What we do not claim: each provider’s contractual retention, processing region and training position. Those sit with the provider and are recorded per provider in the Subprocessor Register.

• Recording only ever starts when the user explicitly starts it.
• A consent confirmation step is presented before recording a conversation, so the decision is made deliberately rather than by default.
• Microphone access requires the operating system’s own permission grant.
• The iOS app can require a biometric unlock before the app’s content is shown, if the user enables it.
• There is no background listening and no always-on microphone.

• Account deletion events — scheduled, cancelled, purged, purge failed — are written to a durable audit table that survives the purge itself.
• Inbound integration deliveries are logged so a practice can see whether a recording arrived and why an import failed.
• Application, database, authentication and platform logs are produced and rotated by our infrastructure providers.
• There is no third-party analytics, error-tracking or session replay service in the application — no Sentry, no PostHog, no advertising or cross-site tracking.

We do not operate a 24/7 security operations centre or continuous security monitoring, and we do not claim one. Administrative and support access to member accounts is recorded in a server-side audit log that the application cannot edit or delete: records are written only by trusted server code, administrators can read them, and no interface exists to change them.

• Recorded audio is deleted as soon as processing has completed and the durable outputs have been verified as stored, with a non-audio audit stamp recording the deletion. A scheduled daily sweep catches anything missed and force-deletes audio whose processing never completed after 7 days. Transcript text is not touched.
• Users can delete individual sessions, transcripts and inbox items themselves.
• Account deletion is self-service, requires re-authentication and explicit confirmation, and is scheduled 30 days ahead. During the grace period the account works as normal and deletion can be cancelled.
• After the grace period, a scheduled purge deletes the account and its personal content, including stored audio files and diary page images, and removes the login. Minimal deletion audit records and de-identified practice-level contributions remain.

Full detail, including what has no agreed period yet, is in the Data Retention Schedule.

The application is hosted on the Lovable platform, served through Cloudflare infrastructure. Supabase provides the database, authentication and file storage. AI processing goes through the Lovable AI Gateway to OpenAI and Google models. Push notifications are delivered through Google Firebase Cloud Messaging, and service emails through Lovable’s email service.

Processing locations, transfer mechanisms and contractual terms are set by each provider. The position we state for each one is in the Subprocessor Register.

Our current commitment is to investigate, contain and remediate a security incident, to notify affected controllers without undue delay where their data is involved, and to notify affected individuals and the ICO where the law requires it. That commitment is reflected in clause 9 of the Data Processing Agreement.

A documented internal incident-response playbook covers roles, escalation path and decision recording. It has not been exercised through a live incident or a tabletop test, so we state no fixed response time in hours and describe no on-call rota.

Our infrastructure providers hold routine backups of the managed database as part of their service. The exact backup configuration, retention period and restore behaviour are set by the provider and have not been verified by us.

We have not carried out our own restore test, we have not agreed a recovery point or recovery time objective, and we do not claim geographic redundancy or a tested disaster-recovery plan.

Verifiable from how the service is built and deployed:

• All application code is held in version control, and deployment happens from that codebase through the platform’s build and release pipeline.
• Database schema changes are applied as versioned migration files rather than ad-hoc edits.
• Environment secrets are configured outside the codebase.
• Changes are exercised in a preview environment before publishing.

We do not claim a formal secure development lifecycle, mandatory peer code review, automated dependency scanning, a vulnerability remediation service level, or penetration testing. Our current assurance position is set out below.

Stated plainly, so nobody has to infer it:

• We make no claim to hold ISO 27001 certification.
• We make no claim to hold Cyber Essentials or Cyber Essentials Plus.
• We make no claim to hold a SOC 2 report.
• We make no claim to have completed an independent penetration test.

Each of these will be published here only once it is genuinely held and can be evidenced.