Trust
Data protection
Most data-protection pages are a legal document wearing a marketing layout. This one is an inventory instead: what data actually exists in Rydya, what the product does with it, and where the answer is that nobody has decided yet. The legal interpretation is not ours to give and we are not going to pretend otherwise.
- Quality and compliance
- Hospital operations
- Executive and finance
What is the Rydya data boundary?
Definition
The Rydya data boundary
Rydya holds equipment records and the work done to them, the people who did that work, the money it cost, evidence files, and the audit chain that records all of it. It holds no patient clinical records of any kind, and that is a property of the schema rather than a setting.
That last sentence is the most important thing on this page and the easiest to check: schema review confirms there are no patient clinical columns, and it is recorded as a product invariant rather than a configuration choice somebody could reverse in a sprint. It is not that we encrypt patient data carefully. There is none.
The consequence is a ceiling on the worst case. A total compromise of Rydya exposes how your equipment was maintained, what it cost and who worked on it. That is genuinely sensitive and worth protecting. It is a different category of event from the loss of a clinical record, and that difference is deliberate design rather than luck.
The inventory, including the awkward row
Personal data is the fifth row, and it is the one that arrives from people who never agreed to anything.
| Data | Held? | Notes |
|---|---|---|
| Patient clinical records | Never | None at all. A schema-verified product invariant, not a setting. |
| Equipment records and history | Yes | The register, maintenance, calibration, safety tests, downtime. |
| Staff identities and activity | Yes | Who did what, when. Personal data about your employees. |
| Financial records | Yes | Costs, invoicing references, priced downtime. Immutable originals. |
| Fault reporter contact details | Yes | From login-free QR reports. Personal data from people with no account. |
| Uploaded evidence files | Yes | Photos and documents, stored as bytes, permission-checked on download. |
| The audit chain | Yes | Append-only, hash-chained. Cannot be edited or deleted by any role. |
| Retention and deletion rules | Not decided | An open decision. No automated purge or erasure exists today. |
| Malware scanning of uploads | Not built | Users upload files that other users download. Not scanned. |
| Data residency | Not decided | Hosting region and cross-border posture are open. |
What Rydya stores, and the status of the rules around it
Why the reporter contact row deserves its own attention
Because it is personal data collected from people who never signed up for anything, and it is the row most likely to be overlooked by everyone including us.
Login-free fault reporting is one of the most useful things Rydya does: a nurse scans a code, describes a broken pump, and gets a reference to follow. It works precisely because there is no account and no friction. The consequence is that we hold contact details supplied by somebody who has no relationship with us, made no choice about us, and will never log in to check what we kept.
That is a different kind of personal data from a staff record, and it deserves being named rather than folded into a general paragraph. Its retention rule is specifically an open decision on our register, and we have not resolved it. There is no automated purge for it today, which means it persists until somebody decides how long it should.
We are flagging it here because it is exactly the sort of thing a privacy review finds and a marketing page omits. If your DPO would want to know about it, and they would, better that they read it from us than discover it.
How the data is kept inside its boundary
The same four controls as everything else, applied to every surface rather than to the database alone.
Isolation is enforced at the database row
Row level security, forced, on every tenant table, with a structural gate that fails the build if a table is missing it. One organisation cannot read another's data even via a query nobody reviewed.
The boundary covers more than the database
Storage uses organisation-prefixed keys. Search, exports, caches, notifications, API keys, webhooks and audit are all inside it. A scheduled report is not a route around access control.
Evidence files are permission-checked and audited on download
Not served from a guessable URL. Who downloaded what is itself recorded, which matters when the file is a photograph of a device involved in an incident.
We cannot log in as you
There is no impersonation. Support access is reason-required, approval-gated, read-only by default, time-bound, revocable and audited on a separate chain, and never assumes one of your users' identities.
What this page deliberately does not say
It names no regulation, asserts no lawful basis, and does not tell you that Rydya makes you compliant with anything. Those are legal interpretations, they depend on your jurisdiction and your processing, and they belong to your privacy counsel rather than to a vendor's marketing page. Our privacy policy, terms and data-processing terms now exist as working drafts, written against what the product genuinely does, but they are drafts pending review by qualified counsel and they still name the decisions we have not made, including hosting region and retention. We would rather publish a truthful draft that names its open decisions than a polished page that invents answers.
When to bring your DPO in, and what to hand them
Week one, with this page and the security page, because three of the rows above are unresolved and they are the rows a privacy review turns on.
The rows that will matter to a privacy reviewer are the three that say not decided or not built: retention and deletion, residency, and malware scanning. None of them is a detail, and all three are the kind of thing that surfaces at contract stage in a questionnaire, when the cost of a bad answer is highest and the honesty is most expensive.
What we can hand a DPO today is precise: an inventory of what exists, a boundary that is verifiable in the schema, a clear statement of which rules are unresolved, and working drafts of the privacy policy, terms and a data-processing addendum written against the real product. What we cannot yet hand them is a counsel-approved final of any of those, a committed sub-processor list beyond the categories the draft names, or a retention schedule, because those depend on decisions and legal review we have not completed.
If your organisation cannot begin an evaluation without finished, counsel-approved documents, that is a legitimate position and we are not there yet. Saying so now, and handing you honest drafts to read in the meantime, is cheaper for both of us than discovering the gap in month four.
Questions
Does Rydya hold any patient data?
No. No patient clinical records of any kind, and that is a property of the schema rather than a setting somebody could reverse. It puts a ceiling on the worst case: a total compromise of Rydya exposes how your equipment was maintained, what it cost and who worked on it, which is genuinely sensitive and a different category of event from losing a clinical record.
What personal data do you hold?
Staff identities and their activity, and contact details supplied by people making login-free fault reports. The second is the one worth attention: it comes from someone with no account, who made no choice about us and will never log in to check what we kept. Its retention rule is specifically an open decision, and there is no automated purge for it today.
What are your retention periods, and can we request erasure?
Retention and deletion rules are an open decision, and no automated purge or erasure exists today. Retention depends on market and on privacy counsel, and neither is settled. This is one of three unresolved rows on this page, and it is the kind of thing that surfaces in a contract-stage questionnaire when a bad answer is most expensive.
Where is your privacy policy and data-processing agreement?
They now exist as working drafts, written against what the product genuinely does and pending review by qualified counsel. We publish them in that state deliberately, and they name the decisions still open, including hosting region and retention, rather than inventing answers. If your evaluation needs finished, counsel-approved versions today, we are not there yet, and we would rather tell you than hand you a plausible page drafted by people unqualified to write it.
Keep reading
Tenant isolation
The control that keeps one organisation out of another, at the database row.
Fault reporting
Where the login-free reporter contact data comes from.
Backups and recovery
What happens to this data in a failure, honestly.
Privacy policy
The working draft that turns this inventory into a policy, pending counsel.
See it on your equipment
Live in an afternoon, useful the same week. A person replies, usually within one working day.
Contact us