Security that depends on people remembering to be careful is not security. Every control here is structural — enforced by the architecture and checked by the build pipeline — and where something is a target or a roadmap item rather than a shipped control, this page says so.
Principle
Every control below resolves to a mechanism in the platform, and most resolve to a test that runs on every commit. Where something is a target rather than a shipped control, it says so.
Every request authenticated, authorized and tenant-scoped. No implicit trust from network position.
One physical database per hospital, plus token scoping and RLS as defence in depth.
AES-256-GCM field encryption, separate key families, TLS in transit.
Secrets provider chain, versioned rotation, production boot that refuses weak configuration.
Hash-chained, append-only, re-verifiable end to end — including after a restore.
Encrypted archives, a rehearsed restore drill, published RPO and RTO targets.
Threat model, gate ladder, dependency and secret scanning on every change.
Penetration testing, disclosure policy and the assurance roadmap, stated honestly.
01
Being inside the network grants nothing. Every request carries its own proof, and every check runs again at the point of use rather than at the perimeter.
No endpoint infers authority from network location, VPN membership or an internal hostname. Tokens carry the tenant claim, and services scope every query by it, so a valid token from one deployment returns nothing in another.
Permissions are evaluated with context — assignment, admission state, ward, shift, time of day. "A doctor may edit only admitted patients assigned to them today" is a policy expression, not code someone has to remember to write.
Patients authenticate on a cryptographically separate identity plane. A portal token is not merely unauthorized against a staff endpoint — it is unusable, because it is not the same kind of credential.
Passkeys and WebAuthn as the flagship staff login, with TOTP and one-time codes as fallbacks and SSO where you already have an identity provider. Passkey cloning is detected by counter regression and flags the credential permanently.
One-time-code requests, password resets and method lookups answer identically whether or not the account exists, so an attacker cannot harvest valid usernames before attempting anything else.
A federated login matches an existing staff record or it fails. An identity provider — or anyone who compromises one — cannot mint a new user in your hospital, and a locked account stays locked through SSO.
02
The strongest isolation guarantee is the one where the data is not there to be returned. Three independent layers, so a failure in any one does not expose anything.
Physical separation, not a tenant column. There is no query that could return another hospital's rows, because those rows are in a different database — self-hosted on your infrastructure if you prefer.
isolation by topology, not by filter
Every service scopes each query by the tenant claim carried in the token. Co-resident lookups and cross-deployment token replay both return nothing rather than an error that confirms existence.
verified by cross-tenant integration tests
Postgres RLS keyed to the hospital context set per transaction, beneath the application entirely — so an application defect cannot bypass it.
defence in depth at the database
Tenant administration is bounded too: a hospital administrator can edit only the policies their own tenant owns, and platform-wide policies are invisible to them. A suspended tenant stops serving at the gate, before routing. Each of these is proven by a test that runs on every commit, not by a paragraph in a document.
03
Encryption is only as good as what it covers and who holds the keys. Both are stated here precisely, including one thing we have deliberately not done yet.
04
Three independent key families — data encryption, audit integrity and backup — never shared, never in the repository, and rotated as versions rather than as a risky cutover.
Secrets resolve through a provider abstraction: environment values in development, mounted files or a vault or cloud KMS in production. No vendor is hard-wired — the provider is deployment configuration behind a stable port.
A production boot refuses to run unless the token-signing, data-encryption and audit keys arrive as real secret references from a non-environment provider. There is no development default that can accidentally reach production.
The active key version signs and encrypts; retired versions inside an overlap window continue to verify and decrypt. Rotation is therefore a rolling change with no window where existing data becomes unreadable.
A drill rehearses rotation across all three key families on every gate run. Rotation is exercised continuously rather than attempted for the first time during an incident.
A lost backup key makes every archive permanently unreadable. It is generated separately, stored with the same care as the data-encryption key, and belongs in your key-escrow procedure — we say so in the runbook rather than leaving you to find out.
On a self-hosted deployment the secrets provider is yours: your vault, your KMS, your rotation policy. We do not require custody of your keys in order for the platform to function.
05
An audit log that can be edited is a record of what someone was willing to leave behind. Ospia's is hash-chained, so tampering is detectable rather than merely discouraged.
The permanent event store sits alongside the audit chain: every action is an event, and events are retained rather than rotated away. That is what makes "replay what happened in March" a query instead of an archaeology project — and it is the same mechanism your assessors and insurers will ask about.
06
Backups that have never been restored are a hypothesis. Ours are exercised automatically, and the targets below are the ones we plan around rather than aspire to.
The starting target for a single-node deployment, with at least daily backups. Where a hospital's risk tolerance requires closer, write-ahead-log archiving or managed-Postgres point-in-time recovery tightens it.
target — contracted per deployment
Decrypt, restore and verify is I/O-bound; the remaining budget covers provisioning a fresh database or host. Per tenant, because tenants are separate databases and recover independently.
target — contracted per deployment
Back up, wipe, restore, verify the audit chain, compare row counts — run automatically as part of the gate ladder, not annually by hand.
a restore proves data and chain integrity
Archives are encrypted with a dedicated key family separate from live data, so a stolen backup is not a breach of the database. Restores are performed into a freshly migrated database with audit triggers quiesced, so the hash chain restores byte-identical rather than being re-signed — a restored system can still prove nobody altered its history. See also: migration & cutover →
07
Security controls that are not tested are intentions. These run on every change, and a failure blocks the merge rather than raising a ticket.
STRIDE per surface. Every threat resolves to a mitigation in code with its reference, or to an explicitly accepted risk with an owner and a revisit milestone.
A mitigation without a verification hook is treated as unproven. Where a test proves a control, the threat model names that test.
Endpoints tested against roles, so a permission regression cannot ship silently.
Credentials committed to the repository fail the build. Production additionally refuses to boot on environment-supplied keys.
Known-vulnerable dependencies fail the build rather than appearing in a report nobody reads.
Module isolation and SQL ownership are enforced by CI, which is what keeps the blast radius of any single defect inside one module.
Anomaly detection is deliberately deterministic and threshold-configured — no machine-learning pretences in the security pipeline. Each firing is itself an auditable security event. In this phase it is detection-only: we do not yet trigger automated lockout or step-up from the pipeline, and we would rather say so than imply a response capability we have not shipped.
08
This is the section most vendors write optimistically. Here is the actual status of each item, with nothing described as complete that is not.
Status labels are used strictly. "In place" means shipped and exercised by automation. "Roadmap" and "readiness" mean not yet achieved. If a status here ever reads better than reality, that is a defect and we want to be told.
Security questionnaires, architecture review sessions and the threat model itself are available to prospective customers — including the accepted-risk register, which is usually the part that tells you most about how a vendor actually works. Request a security review →
Next step
An executive demonstration takes forty-five minutes. We seed a hospital with synthetic data shaped like yours, put the digital workforce on duty, and answer the hard questions with the architecture open.
synthetic data · zero real patients
self-hosted or managed cloud
one database per hospital