Healable

Security

Security at Healable

Security is part of how Healable is built, not a layer added afterwards. Clinical work is organized into access-controlled vaults, sensitive material is encrypted, access is logged, and data handling is scoped to the purpose each vault is created for. This page describes the technical and organizational measures behind the service.

The technical and organizational measures described here are a summary; the specific measures in effect for a customer are set out in the signed agreement.

Encryption

Vault content is encrypted at rest using authenticated encryption — AES-256-GCM-SIV via Google's Tink library — so stored data is both confidential and tamper-evident. Even file and folder names are encrypted deterministically, so the structure of a vault never reveals patient information. Data is also encrypted in transit (TLS) as it moves between your browser and the service.

Key management (Google Cloud KMS)

We use envelope encryption: each vault has its own data key, wrapped by a per-vault key-encryption key held in Google Cloud KMS. Keys live in a dedicated key ring in an EU region and rotate automatically every 90 days. Audio sent for transcription is protected by a separate, dedicated KMS key rather than the vault keys.

Duties are separated: the ability to decrypt is isolated to a single key-custody service that cannot create keys, while the rest of the platform — including the application and the AI workspace — has no access to KMS at all. Data is decrypted only for an authorized session, and the key is discarded afterwards.

Access control and vaults

Work is organized into purpose-bound vaults. Access is personal and restricted to authorized users, and changes are designed to be audit-logged so that activity can be accounted for. Each vault is scoped to a specific purpose, so data handling stays limited to the work being done.

Sign-in and vault unlock

Sign-in runs on Google Cloud Identity Platform with mandatory two-factor authentication — a TOTP authenticator app or SMS — and the server only accepts a session whose token is two-factor-stamped. Sessions are capped at 24 hours, time out after an hour of inactivity, and re-require two-factor verification once a day.

Vaults lock on their own: a vault re-locks after a few minutes of inactivity, on sign-out, and on page reload. Unlocking a vault takes a step-up TOTP code, and the unlocked state is held only in memory — never written to disk.

Where data is processed

We process data within the EU/EEA, on EU cloud regions, with Norway as our first market. We do not transfer personal data outside the EEA. An up-to-date list of sub-processors and processing locations is available on request at hei@healable.no.

Sub-processors

We use a small number of vetted providers to run the service, each bound by data-processing terms:

  • Google Cloud — hosting and AI processing (including Vertex AI) in EU regions.
  • Stripe — payment processing for billing.
  • Google Workspace (Gmail) — email and day-to-day business operations.

AI as work support — not a medical device

Healable produces drafts and organizes the clinician's own source material for review. It does not produce independent clinical findings and does not make diagnostic, prognostic, monitoring, or treatment decisions, and nothing is transferred to a medical record automatically — the clinician reviews, edits, and decides what to keep. Healable is a work-support tool, not a decision-support tool; it is not a CE-marked medical device and is not intended for diagnosis, prognosis, monitoring, or treatment decisions. The clinician and the organization remain fully responsible for any clinical content.

Handling security incidents

We work to detect, contain, and respond to security incidents. Where a personal data breach affects a customer's data, we notify the affected customer without undue delay and provide the information they need to meet their own obligations under the GDPR. Customers acting as controllers remain responsible for notifying their supervisory authority and, where required, the people affected.

Shared responsibility

Security depends on how the service is used as well as how it is built. Organizations should use individual accounts, protect login credentials, limit vault access to those who need it, remove access when staff change roles, and keep their own devices secure.

Frameworks we build around

Healable is built with the GDPR and Normen — the Norwegian code of conduct for information security and privacy in the health and care sector — in mind, alongside Norwegian healthcare requirements such as the duty of confidentiality and record-keeping obligations. For how patient data is processed on a controller's behalf, see our data processing agreement.

Reporting a security concern

If you believe you have found a security issue, or have a question about how we protect data, contact us at hei@healable.no.

Security, answered

Is Healable built for Norwegian healthcare?

Yes. The Norwegian product position is built around health data, GDPR, Normen, EU/EEA storage, and clinician-controlled review.

Is access logged?

Yes. Access and changes are designed to be audit-logged.

Where is data stored?

The marketing position for Healable is EU/EEA data storage, with Norway as the first market.