Data protection
Where data lives, how it is isolated, and what is not true yet.
Where the data lives
Development and staging are hosted in Microsoft Azure's UK South region, in the United Kingdom.
The region is a deployment parameter, not a value written into the code. That was checked by deploying the entire infrastructure to a second region and then deleting it.
A customer's data therefore lives wherever their deployment lives, which is decided when it is set up.
One deployment per customer
Each customer gets its own database and its own application instance. Facilities are separated within that instance by the permission model.
Isolation between customers is enforced at the database boundary. It is also the only shape that lets two customers sit in two different regions.
Encryption and secrets
Traffic is encrypted in transit. Storage is encrypted at rest by the host.
Operational secrets live in a managed vault, never in the code repository. Deployment authenticates by federated identity, so there is no shared password to leak.
Access by role, and the audit trail
Every route in the application interface declares the permission it requires. A route without a declared permission stops the application from starting: forgetting is an outage, not a silent hole.
Every read of patient data and every change writes an audit record. Those records are appended, never updated or deleted.
Sub-processors
Microsoft Azure, for hosting, the database and the secret vault.
Cloudflare, for DNS, delivery, the web application firewall and document storage.
No other third party receives patient data. Adding one would be an explicit decision, recorded before it was made.
What is not true yet
The platform is under construction and holds no real patient data today.
No external security audit has been carried out, and no certification is claimed.
This document describes the design and the parts already built. It is updated as they are built, rather than written at the end.