Legal

Privacy policy

This policy describes what Rydya does with information, in plain terms and only where the product genuinely does it. It is a working draft pending review by qualified privacy counsel, and it is not legal advice. Where a decision has not been made, such as where data is hosted or how long it is retained, this says so rather than inventing an answer.

Quality and compliance
Executive and finance
Hospital operations

What is in this privacy policy, and what is not

Definition

Scope of this policy

This policy covers the personal data Rydya processes to run the product: the identities of the people who use it, the operational records they create, and the technical logs the service produces. It does not cover patient clinical data, because Rydya stores none.

The single most important fact for a privacy reviewer is the one that shrinks the rest: Rydya stores no patient clinical records at all. It manages equipment, not people receiving care. That is a product boundary confirmed by schema review, not a setting, and it places a hard ceiling on what any incident involving Rydya could expose.

What the product does hold is the operational information a healthcare organisation needs to keep its equipment safe and accountable: who your staff are, what devices you own, what was done to them, what it cost, and what a person reported when something failed. This policy explains each of those, why it exists, and what you can ask us to do about it.

What information Rydya holds about you

Account and organisation identities, the operational records your team creates, files you upload, and technical logs. No patient records, and no advertising or tracking profiles.

Account and organisation identities

The name, work email and role of each person you invite, and which organisation and locations they belong to. Accounts are created by invitation rather than public sign-up, so we hold identities for people your administrators have added, not for the general public.

Equipment records and asset metadata

The devices you register and the data attached to them: identifiers, models, locations, maintenance and calibration history, safety-test results against the limits you configure, downtime, and the cost figures you enter. This is the substance of the product and it is your organisation's data.

Uploaded files and images

Photographs and documents your team attaches as evidence, such as a picture of a fault or a service report. You control what is uploaded. These files are not scanned for malware today, which is stated plainly on the security page rather than buried here.

QR code identifiers

The codes printed on your equipment carry an identifier that resolves to a device record. Scanning one identifies the device; it does not identify the person scanning unless they are signed in and choose to act.

When someone scans a device code to report a fault without an account, they may give contact details so you can follow up. Those details are held so your team can respond. The retention rule for them specifically is an open decision, covered below.

Log and technical data

The service records technical logs needed to operate and secure it: request metadata, timestamps, and the append-only audit trail of who did what. These exist to keep the system accountable and diagnosable, and the audit trail cannot be edited or deleted.

Why we hold each kind of data, and why we hold no more

Every category exists to run a specific part of the product. We collect the operational minimum and deliberately hold no marketing or tracking data.

Identities exist so people can sign in, so work can be assigned to a named owner, and so the audit trail can attribute a change to a person rather than a mystery. Equipment records exist because they are the product. Uploaded evidence exists because a fault with a photograph is easier to resolve than one described from memory. Logs exist to operate and secure the service. Contact details on login-free reports exist so your team can reply to the person who found the problem.

Just as important is what we do not collect. There is no analytics package, no advertising pixel, no cross-site tracker and no third-party behavioural profiling anywhere in the product. We verified this rather than asserting it: the application ships no such code. Your session is kept in your browser's own local storage so you stay signed in, which is a functional necessity, not a tracking mechanism, and it is covered in the cookie policy.

How your data is protected

Isolation enforced at the database, an audit trail that cannot be rewritten, multi-factor authentication, no impersonation, and a published list of the gaps.

One organisation never sees another

Every tenant record carries an organisation identifier and is protected by database row level security that is forced rather than optional, so isolation holds even for a query no reviewer checked. This is described in full on the tenant isolation page.

The audit trail cannot be altered

Changes are written to an append-only, hash-chained audit trail with no update or delete path at the database, for any role. It is tamper-evident rather than tamper-proof, and we say so precisely rather than overclaiming.

Authentication and access

Sign-in is email and password with time-based multi-factor authentication and step-up on sensitive actions, plus server-side session revocation. There is no enterprise single sign-on yet, which the security page states rather than hides.

No impersonation, and honest gaps

Our support team cannot log in as one of your users. Support access is reason-required, approval-gated, read-only by default, time-bound and audited. Where a control is not yet built, such as malware scanning of uploads, it is published rather than implied.

How long data is kept, and where it is processed

Retention periods are not yet set, and the hosting region is not yet committed. Both are open decisions we will not pretend to have made.

We have not set retention periods, and there is no automated purge or erasure in the product today. That is an honest limitation rather than a policy, and the retention rule for contact details captured by login-free fault reporting is specifically open. Until these are decided with counsel, we will act on a deletion request manually rather than point you at automation that does not exist.

Where your data is hosted, what residency we commit to, and the cross-border posture are also open decisions rather than answers we are withholding. Your data is processed on the hosted platform the service runs on and by the subprocessors listed in the data processing terms. If data residency is a hard requirement for your organisation, raise it before you evaluate further, because today we cannot commit to a specific region.

Your rights, and how to use them

You can ask to see, correct, export or delete the personal data we hold about you. Today those requests are handled by a person, not a self-service tool.

Access and correction

You can ask what personal data we hold about you and ask us to correct it. Much of it is already visible and editable inside the product by your own administrators; for anything that is not, write to us.

Export

The product exports operational data in common formats. For a copy of the personal data specifically held about you as an individual, contact us and we will assemble it.

Deletion

You can ask us to delete personal data we hold about you. Because there is no automated erasure yet, we act on these requests manually. Some records may need to be retained where they form part of the immutable audit trail, and we will tell you where that applies.

How to make a request

Email us and we will respond. We will verify that a request genuinely comes from the person or organisation it concerns before acting, because acting on an unverified request would itself be a privacy failure.

Children, changes to this policy, and how to reach us

Rydya is a workplace tool, not intended for children. We will post material changes here, and you can always reach us at one address.

Rydya is an operational tool for healthcare organisations and their staff. It is not directed at children and is not intended for use by anyone under the age at which they can hold a work account in their jurisdiction. We do not knowingly collect data from children.

If we change this policy in a way that materially affects how we handle your data, we will update this page and its date. Because the product is still maturing and decisions such as hosting region and retention are still open, expect this policy to become more specific over time rather than less.

Questions about privacy, or a request about your data, can be sent to hello@rydya.com. A person reads it. This remains a working draft pending review by qualified privacy counsel, and nothing here is legal advice or a substitute for your own assessment.

This is a working draft, and why that is the honest state

Rydya would rather publish a truthful draft that names its open decisions than a polished policy that quietly invents answers about hosting region, retention and lawful basis. This document has not yet been reviewed by qualified privacy counsel and must be before it is relied upon. It describes real product behaviour, verified against the code, but the legal characterisation of that behaviour in your jurisdiction is a matter for your own advisers and ours.

Questions

Does Rydya hold any patient data?

No. Rydya stores no patient clinical records at all, and that is a product boundary confirmed by schema review rather than a configuration. It manages equipment, maintenance, calibration, safety tests, downtime and cost. It does hold your staff identities, the operational records your team creates, uploaded evidence, and contact details supplied by people making login-free fault reports.

Do you track me or use analytics and advertising cookies?

No. There is no analytics package, advertising pixel or cross-site tracker anywhere in the product, which we verified in the code rather than merely asserting. Your session is kept in your browser's local storage so you stay signed in, which is a functional necessity rather than tracking. The cookie policy explains this in more detail.

How long will you keep my data, and can I have it deleted?

Retention periods are not yet set and there is no automated purge or erasure in the product today, which is an honest limitation rather than a policy. You can ask us to delete personal data we hold about you and we will act on it manually, though some entries may need to be retained where they form part of the immutable audit trail, and we will tell you where that applies.

Where is my data hosted?

The hosting region and data residency commitment are open decisions rather than answers we are withholding. Your data is processed on the hosted platform the service runs on and by the subprocessors named in the data processing terms. If a specific residency is a hard requirement for you, raise it before evaluating further, because today we cannot commit to one.

Is this privacy policy legally reviewed and final?

Not yet. It is a working draft that describes real, code-verified product behaviour, but it has not been reviewed by qualified privacy counsel and it is not legal advice. We publish it in this state deliberately, because a truthful draft that names its open decisions is more useful to a buyer than a polished template that invents answers.

Keep reading

The agreement for using Rydya, in the same honest draft state.

Cookie policy

Why Rydya keeps your session in local storage rather than a tracking cookie.

Data processing addendum

The controller, processor and subprocessor terms, drafted for review.

Data protection

The data inventory behind this policy: what is held, and what is never held.

Security

How the data described here is protected, gaps included.

See it on your equipment

Live in an afternoon, useful the same week. A person replies, usually within one working day.