How your record is protected
A record of your health is worth protecting properly. Here is what that means in practice, in enough detail that you can check it.
Last updated:
Where the data lives
The application runs in the Frankfurt region and its database is in eu-central-1. Both are inside the European Union.
This site — the one you are reading — is served from the same region and stores nothing at all.
Closed by default, at the database level
Every user-facing table has row-level security with a deny-by-default policy. A request that does not match an explicit rule returns nothing, and that decision is made by the database itself.
This matters because it does not depend on the application getting authorisation right. A bug in application code cannot hand you somebody else’s record, because the database was never willing to return it.
Two-step sign-in
You can add a second factor with an authenticator app (TOTP). When it is on, the session must reach the higher assurance level before protected areas open — enforcement happens on the server, not in the interface.
An audit that only grows
Access events are written through a narrow database function that only the service role can execute. Application roles have no permission to update or delete audit entries.
In plain terms: opening a record leaves a trace, and nobody can tidy that trace away afterwards — including us.
Documents
Uploads go to private storage with owner-bound paths. There is no public address for a document. When you open one, the application issues a signed link that expires in sixty seconds and is bound to you.
Before a document becomes available it sits in quarantine until a scan clears it, and the adapter fails closed: if the scan cannot run, the document does not pass.
What the assistant may and may not do
The assistant can read the part of your record you are asking about and cite it. It has no permission to create, change or delete anything.
Requests to the AI provider are sent with storage switched off. We do not claim a processing region for that provider, because we have not established one we can prove.
Logs that cannot leak your health data
Application logging is structured and restricted to an allow-list of fields. Free-form messages and provider payloads are not permitted, so health information cannot end up in an operational log by accident.
This website
No cookies, no analytics, no third-party scripts, no fonts loaded from anyone else. The content security policy allows connections to this origin only, and an automated test fails the build if any request leaves it.
What we do not claim
- We hold no security certification, and we do not claim one.
- No independent penetration test has been carried out yet.
- We do not promise that a breach is impossible — only that access is closed by default, that documents have no public address, and that traces of access cannot be erased.
Reporting a vulnerability
If you find a weakness, write to zen@kanzenkai.org with enough detail to reproduce it. We will confirm receipt within five working days and tell you what we intend to do.
We will not pursue anyone who reports a genuine finding in good faith, provided you do not access other people’s data, do not degrade the service, and give us reasonable time before publishing.