Trust
Security
Security pages usually list what a vendor has. This one also lists what we have not done, because you are going to find out either way, and the second list tells you more about us than the first. Everything here is something an engineer could be asked to demonstrate rather than describe.
- Quality and compliance
- Hospital operations
- Clinical engineering
What is the security model?
Definition
The Rydya security model
The Rydya security model is deny by default, checked on the server for every protected action, and enforced underneath that at the database row by PostgreSQL row level security, so that isolation does not depend on application code remembering to filter.
The load-bearing idea is that the boundary lives below the code. Server-side permission checks are the first layer, and they are only as good as the developer who wrote them. Row level security is the second, and it holds even for a query nobody reviewed, because the database refuses rather than the application declining.
The most important sentence on this page is the shortest: Rydya stores no patient clinical records. Not encrypted ones, not restricted ones. None. That is a product invariant confirmed by schema review, and it puts a hard ceiling on what a breach of Rydya could ever expose.
How isolation and audit are actually enforced
At the database, by structures rather than by convention, with a gate that fails the build if any of it slips.
Every tenant table carries an organisation id under row level security
Enabled and forced. A structural audit scans the whole schema for tables missing it, for grants to anonymous or public roles, for unpinned search paths on privileged functions, and fails on any finding rather than reporting it. Isolation that relies on developers remembering a WHERE clause is isolation that fails on a Friday.
The audit trail has no update path and no delete path
Database triggers raise an exception on any UPDATE or DELETE against audit events, for every role including the table owner. This is not a convention or a code review rule. Events are hash-chained per tenant and written in the same transaction as the change they record.
There is no impersonation
Our own platform console cannot log in as one of your users. Support access is reason-required, approval-gated, read-only by default, time-bound, revocable and audited on its own chain. It is a real constraint on our support team, which is exactly why it is worth having.
Isolation covers more than the database
Storage uses organisation-prefixed keys; search, exports, caches, notifications, API keys, webhooks and audit are all inside the boundary. A notification is not a side channel around access control, and neither is a scheduled report.
Machine identities can do less than people
Service accounts are scoped credentials with their own rate limits and location scope, revocable independently of any human account. Secrets are shown once and redacted everywhere afterwards, including from our own console. If one is lost it is rotated rather than retrieved.
What is built, and what is deliberately not
The honest state. Nothing in the left column is aspirational, and nothing in the right column is hidden.
| Area | Status | Detail |
|---|---|---|
| Tenant isolation | Built | Row level security, forced, with a whole-schema structural gate. |
| Audit immutability | Built | Trigger-enforced: no update or delete path exists for any role. |
| Impersonation | Deliberately absent | Cannot be done. Support access is bounded and audited instead. |
| Break-glass override | Deliberately not built | An emergency-access route is an open decision, not a quiet feature. |
| Multi-factor authentication | Built | TOTP, with step-up enforcement on sensitive actions. |
| Session revocation | Built | Server side, checked before tenant context resolves. |
| Webhook security | Built | HMAC signed, private and loopback endpoints blocked, https only. |
| Export safety | Built | Spreadsheet formula injection neutralised in CSV and XLSX. |
| Rate limiting | Built | Server side, per source and per service-account credential. |
| Single sign-on, SAML, SCIM | Not built | No enterprise SSO and no directory sync today. |
| Malware scanning of uploads | Not built | Files uploaded by users are not scanned today. |
| Certifications | None | No SOC 2, no ISO 27001, and no penetration test yet. |
Security capabilities by actual status
Why we publish the gaps
Because the alternative is that you find them during diligence, and by then the omission is the story rather than the gap.
A security page that lists only strengths is doing marketing, and every buyer knows it, which is why the first question in a diligence session is always about what is not on the page. Publishing the gaps costs us the illusion and buys the conversation, and in healthcare the conversation is the thing that matters.
It also keeps us honest internally. A published gap is a commitment with a witness. An unpublished one is a backlog item that quietly does not get done, and we would rather be uncomfortable in public than comfortable in private about a product that hospitals depend on.
The gaps below are not a roadmap and we are not attaching dates to them here, because a date we miss is worse than an absence we admitted. They are the current state, stated plainly, so that you can decide whether it is acceptable for your organisation rather than discovering later that it was not.
What we have not done yet
Read this before you evaluate us. If any of it is disqualifying, it is better established now.
No certifications, and no penetration test yet
We hold no SOC 2 and no ISO 27001, and we have not commissioned an independent penetration test. If your procurement requires any of these today, or an equivalent scheme in your market, we do not meet that bar and we would rather say so than manage the conversation.
Hosting region and data residency are not committed
Where data lives, what residency we commit to, and the cross-border posture are an open decision rather than an answer we are withholding. If residency is a hard requirement for you, ask before you evaluate further.
Backups are planned and the restore has not been drilled
We have a documented backup and restore procedure. What we do not have is a verified restore, and until a restore has actually been performed, a backup is a belief rather than a capability. We do not claim recovery objectives we have not measured.
No retention or erasure policy yet
Retention periods and deletion rules depend on the market and on privacy counsel, and neither is settled. There is no automated purge or erasure today. Login-free fault reporting collects reporter contact details, and the retention rule for those is specifically open.
Uploaded files are not scanned for malware
Users upload evidence and other users download it. Scanning is not implemented today. Downloads are permission-checked and audited, which is a different control addressing a different risk, and it is not a substitute.
No enterprise single sign-on
No SAML, no OIDC login, no SCIM provisioning. Authentication is email and password with TOTP multi-factor. If your identity team requires SSO, that is a real gap rather than a configuration conversation.
Two precise statements, because precision matters more than reassurance here
On audit: the chain is tamper-evident, not tamper-proof. No update or delete path exists at the database for any role, and the chain detects alteration, but nothing is externally anchored and detection depends on the verification being run. On encryption: data at rest is encrypted by the hosted platform we run on, which is a property of that provider rather than of our engineering, and the only thing Rydya itself encrypts at the application layer is webhook signing secrets. We would rather draw those lines exactly than let a reasonable reader infer more.
Who to involve, and when to ask us the hard questions
Your security and privacy people, before the pilot rather than after it, and with the list above in front of them.
The failure mode in this category is that security review happens at contract stage, after clinical stakeholders are invested and the awkward questions have become expensive to ask. Everything on this page is designed to be raised in week one instead, when the answer can still change the decision cheaply.
If something here is disqualifying, we would genuinely rather know early. A pilot that fails a security review in month four has cost your team more than it cost us, and the gaps above are not going to be argued away in the meeting. Ask early, ask specifically, and hold us to the distinction between what is built and what is documented.
Questions
Do you hold any patient data?
No. Rydya stores no patient clinical records at all, and that is a product invariant rather than a configuration. It manages equipment: registers, maintenance, calibration, safety tests, downtime, cost and the audit trail. We do hold your operational and financial data, staff identities, uploaded evidence, and contact details supplied by people making login-free fault reports.
Are you SOC 2 or ISO 27001 certified? Have you been penetration tested?
No to all three. We hold no certifications and have not commissioned an independent penetration test. If your procurement requires either today, we do not meet that bar, and we would rather tell you here than let you discover it in month four when your clinical stakeholders are already invested.
Can Rydya staff log in as one of our users?
No. There is no impersonation, and it is not a setting. Support access is requested with a reason, approved, read-only by default, time-bound, revocable, and recorded on a separate audit chain, and a session never assumes one of your users' identities. It constrains our own support team, which is precisely the point: an override that exists will eventually be used.
Can your audit trail be edited or deleted?
There is no update path and no delete path at the database, enforced by triggers that fire for every role including the table owner, and events are hash-chained per tenant. To be precise rather than reassuring: that makes the chain tamper-evident, not tamper-proof. Nothing is externally anchored, and detection depends on the verification being run.
Do you support SAML single sign-on or SCIM provisioning?
No. Neither is built. Authentication is email and password with TOTP multi-factor and step-up enforcement on sensitive actions, plus server-side session revocation. If your identity team requires enterprise SSO, that is a genuine gap today rather than a configuration conversation, and it is worth raising before you evaluate further.
Where is our data hosted, and what are your recovery objectives?
Both are honest unknowns rather than answers we are withholding. Hosting region and residency posture are an open decision. We have a documented backup and restore procedure but have not yet drilled a restore, and we do not publish recovery objectives we have not measured, because an unmeasured objective is a wish with a number attached.
Keep reading
Tenant isolation
How one organisation never sees another, in full: row level security, forced.
Role based access
The scope model, and why hiding a button is never the boundary.
Audit trails
The append-only chain in detail, and what it does not promise.
Integrations
Machine identities, signed webhooks, and what is not built there either.
Buyer's guide
The security questions to ask us and every competitor, before you evaluate.
Responsible AI
Why there is no model anywhere in the decision path.
See it on your equipment
Live in an afternoon, useful the same week. A person replies, usually within one working day.
Contact us