Cybersecurity
We hold as little as we can, and protect what we hold.
What Ostify chooses not to collect, and the layers that protect the rest. Written for you, and for the information governance and IT teams who will ask.
Data minimisation
The safest data is the data we never hold.
Data minimisation means collecting only what a task needs. It is the first security measure on Ostify, because information that is not kept cannot be lost or stolen.
- Who the patient is
- Never askedPatients do not sign in, and your agent does not ask for a name, a date of birth or an NHS number.
- What the patient typed
- Used once, then goneA question is used to write its answer. Neither is kept afterwards. Where this happens is on the trust page.
- What we do record
- Measurements, not wordsWhich agent was asked, which safety check ran, what the outcome was and how long it took. This is how we keep the service running, and it contains no question or answer text.
- Your password
- Never seen by OstifySign-in is handled by Microsoft’s identity service (Microsoft Entra). Ostify receives confirmation of who you are, not your password.
- Your build
- Only what the agent needsThe content you upload and approve, your settings and your test results. An agent works from approved guidance, so there is no reason to upload patient records.
Layers of protection
Several layers, so no single one has to be perfect.
Security people call this defence in depth. Each layer assumes the one before it might fail.
- A firewall in front
All patient traffic passes through a web application firewall (WAF), which filters out known attacks and automated bots and limits how fast anyone can send questions.
- One way in
The firewall is the only route to your agent. There is no side door around it.
- Encrypted on the move and at rest
Data is encrypted as it travels between your browser and Ostify (TLS), and again where it is stored.
- Sign-in checked first
The builder is closed to anyone who is not signed in. A request without a valid sign-in is turned away before it reaches the platform itself.
- No passwords left lying around
Our services prove who they are to each other without shared passwords (managed identities). The few keys that remain are locked in a key vault.
- If in doubt, it stops
If a safety check cannot be reached, your agent declines to answer rather than carrying on without it. Engineers call this failing closed.
Keeping things apart
Each workspace and each agent is kept to itself.
Many clinicians build on the same platform. These are the walls between them, and between patients and your build.
- Your workspace follows your sign-in
What you can see is decided by who you are signed in as. It cannot be changed by editing a web address or anything else your browser sends.
- Agents kept apart
Each patient link is signed, so a question can only go to the agent it was meant for, and each agent can only search its own content.
- Patients cannot reach your build
Patients use a separate service from the one you build in. It has only the access it needs (least privilege): it can read your agent’s settings but cannot change them.
How much we publish
What this page leaves out, on purpose.
We describe how the platform is protected, not its exact settings. Rule lists, thresholds and the names of internal systems would mostly help someone trying to get past them. If your IT or information governance team needs more for their own assessment, we can share it with them directly, in confidence.