What we hold, where it lives, and what we have not done yet.
Striova holds a record about a child, written by the people who know them. That is about as sensitive as personal data gets, so this page is written to be checked rather than admired — including the parts that are still open.
Last reviewed 24 August 2026.
- ICO registration
- ZC190656
- Company number
- 17322340 (England and Wales)
- VAT number
- GB525574969
- Operated by
- QuoVira Health Ltd
- Registered office
- 128 City Road, London EC1V 2NX
- Where the data lives
- United Kingdom — London region
What we commit to if something fails
These are objectives — the outer limits we hold ourselves to, not the times we expect. What we last measured is below them.
1 hour
Recovery time objective
The longest we commit to taking to bring the service back after a serious failure, including the application and not only the database.
4 hours
Recovery point objective
The most data we commit to losing in that situation. Point-in-time recovery is in place and was exercised on 24 August 2026, so in practice we expect far less.
Why those are more than aspirations
Recovery plans are common. Recovery plans somebody has actually run are not.
The restore is exercised, not just designed
A full recovery has been run end to end against real infrastructure — restoring the database, bringing it online and verifying the data — rather than existing only as a written procedure. It is repeated every six months.
Two independent daily backups
The managed platform's own daily backup, plus a nightly encrypted copy to separate storage. The machine that makes the second copy holds only the public half of the encryption key, so it cannot read its own backups.
Ninety days of history on the independent copy
The managed backups roll on a seven-day window. The encrypted nightly copy is what covers anything older, so a problem noticed late is still recoverable.
An honest assurance position
Where each control stands today. The rows that say “not yet” are the reason to believe the ones that do not.
| Control | Status | Detail |
|---|---|---|
| ICO registration | In place | ZC190656, on the public register. |
| UK GDPR programme | In place | Data protection impact assessment, record of processing, and a documented position for every processor. |
| ICO Children's Code | In place | The data subject is the child. Defaults, retention and profiling are set against the fifteen standards. |
| Information security policies | In place | Secure development, acceptable use, records management and retention — written down and dated. |
| Incident response | In place | A written plan, an exercised tabletop, and a 72-hour reporting commitment. |
| Backup and disaster recovery | In place | Two independent daily backups, and a restore that has been run end to end rather than only designed. |
| Internal security testing | In place | A grey-box test of the web app, API, mobile client and infrastructure in August 2026. Findings fixed and re-tested. |
| NHS Data Security and Protection Toolkit | In progress | Answer pack prepared. Not yet submitted. |
| Cyber Essentials | In progress | Gap analysis complete against the live stack. Not yet certified. |
| Clinical safety standards | In progress | Striova is self-assessed as not a medical device, and the MHRA raised no concerns. The clinical safety documentation is still being written. |
| Independent penetration test | Not yet | Scope written and requirements set, including CREST accreditation. No independent test has been carried out. |
Controls in the code, not in a policy binder
The record stays in the UK
Application, database and file storage are all in London, checked against the hosting provider's own API rather than taken from a brochure. Error monitoring uses the European region.
Uploads are read, not trusted
A file a parent uploads is read from its actual bytes rather than trusted to be whatever the sending device says it is, and anything that is not a real image is refused. Anything that is not an image or a PDF downloads rather than opens.
Encryption keys are not in the backups
The two keys protecting the most sensitive columns are held separately by design, so a copy of the database on its own does not reveal them.
Staff access is logged, and needs a second factor
Two-factor authentication is required for staff accounts in production, and administrative views of a family's material are written to an append-only audit log.
Dependencies are watched and patched
Automated alerting on known vulnerabilities in the software we depend on, with a written log of what was found and what was done about it.
Releases only ship checked code
Type checking, linting and the test suite all run before anything is released, and a release is blocked if any of them fail.
What we do not claim
Every assurance page lists what a company has. This is the other half, and it is here on purpose.
- We are not Cyber Essentials certified. The gap analysis is done; the certification is not.
- No independent penetration test has been carried out. The security testing described above was internal.
- We have not appointed a data protection officer. We are not required to, and the scope for one is written.
- We do not describe the platform as highly available. The database runs on a single node, so a hardware failure means a restore rather than an instant failover.
- We have not submitted the NHS Data Security and Protection Toolkit.
Reporting something, or asking for evidence
Found a security problem?
Email [email protected] with SECURITY in the subject line. Machine-readable details are at /.well-known/security.txt. We will not pursue anyone who reports a genuine issue to us in good faith.
Schools, trusts and NHS teams
The documents behind this page — impact assessment, record of processing, retention schedule, incident plan and supplier register — are available for due diligence. Ask through our contact page. A personal data breach affecting UK individuals is reported to the ICO within 72 hours of us becoming aware.