In a health service, security is not a feature added at the end but the starting point the structure is built around. In this post I explain, for the technically curious reader, how Treat is built: where the data is, how it is encrypted, who can reach it and what happens if something goes wrong. I am not listing certifications; I am describing what has been built. The binding description is in our privacy policy.
I joined Treat in August 2026, the same month as doctor Antti Mauno. Onni Hakala and Sami Marttinen had started building Treat in April, and Henri Heliö joined in June. In August, Treat also became an ASTORI class B patient-information system. This post describes the architecture behind that stage of development.
Where the data is
The Treat application runs on Google Cloud in Finland, in the europe-north1 region, and the project is fenced with the Assured Workloads EU Data Boundary. We use Cloud Run, Cloud SQL (PostgreSQL), Cloud Storage, Secret Manager, KMS and Vertex AI. All patient conversations, case data and user accounts live here.
Cloudflare serves only the marketing site, treat.health. It never handles patient conversations, case data or account data. Personal data stays in the EEA.
Encryption at rest and in transit
The database, object storage and secrets are encrypted with customer-managed KMS keys in europe-north1. The difference from a cloud provider's default encryption is control: the keys' lifecycle, rotation and access rights are ours to define and to log, rather than a platform default.
In transit, every endpoint requires TLS 1.2 or newer, and the database currently accepts only encrypted connections.
Least privilege, no shared credentials
Access to the production environment is restricted with Google IAM per service account. Each service has its own identity and only the permissions its job requires. There are no shared credentials, and access is logged.
In practice this means three things:
- Each service has only the permissions its job requires, which limits the consequences if a single component is compromised.
- Every access can be traced to a specific identity, not to "admin".
- Adding permissions is a deliberate, recorded change.
Authentication
Patients identify themselves with strong authentication through Idura, a Nordic identity broker: Finnish bank credentials and Mobiilivarmenne (mobile certificate), Swedish BankID and Freja ID, Norwegian BankID and Vipps, or Danish MitID. We require the "substantial" assurance level of the Finnish Trust Network. Treat never receives your bank credentials, PIN or biometrics, only your name, national identity code and a persistent identifier.
The application supports passkey sign-in, and passwords are protected with the Argon2 hashing algorithm.
Logs without sensitive content
Service logs are essential for troubleshooting and security monitoring, but patient data must not leak into them. So the personal identity code and free-text clinical fields are redacted from application-level logs before they are written. What remains is the IP address, request timestamps and browser details.
Logs are kept for 90 days by default; longer only for a named security investigation.
Backups
The database is backed up with point-in-time recovery, meaning its state can be restored to a given moment rather than only to the last full copy. Backups are encrypted with the same KMS keys as production data and kept up to the statutory limits. A backup protected less well than the original would be the weakest point in the system.
AI inside the same boundary
The AI in the symptom interview is Google's Vertex AI (Gemini) in the EU (eu.rep.googleapis.com), not the consumer Gemini product. Prompt caching is disabled, and calls are authenticated with a service account. Your data is never used to train AI models; product development uses anonymised data only. We have applied for an exemption from Google's abuse-monitoring logging; until it is granted, we do not assume full zero data retention for these calls and mark this clearly in our internal logs.
The AI only asks structured follow-up questions and prepares a summary. It does not diagnose, make treatment decisions or assess urgency. Every clinical decision is made by a licensed doctor.
People and contracts
Technology is not enough if the obligations on people are missing. Every employment and subcontracting contract includes a confidentiality commitment, and healthcare professionals are additionally bound by the Finnish Act on Health Care Professionals (559/1994, section 17). When we add or replace a processor, we update the processor list in the privacy policy before the new processor starts.
If something happens
Nobody can promise that a data breach will never happen. That is why the process is defined too: we notify the Data Protection Ombudsman within 72 hours and affected users without undue delay when the GDPR notification threshold is met.
Why I am telling you this
A patient does not need to understand KMS keys to use Treat. But if you want to know how your data is protected, the answer should be concrete, not vague. This post is an overview; the exact commitments are in the privacy policy: https://treat.health/privacy/