Legal

Data processing addendum

This is a draft data processing addendum, written in a GDPR-style structure so your privacy team can read it against the framework they already use. This document may require legal review before execution, and it is not legal advice. It describes real product behaviour, but its legal characterisation and the specifics of any signed version are matters for qualified counsel on both sides.

Quality and compliance
Executive and finance
Hospital operations

What is a data processing addendum, and when it applies

Definition

A data processing addendum is the part of an agreement that governs how a supplier processes personal data on a customer's behalf: what may be processed, for what purpose, under what security, and with what obligations on return, deletion and disclosure. This draft covers Rydya acting as a processor for the organisations that use it.

It sits alongside the terms of service and the privacy policy rather than replacing them. The terms govern the commercial relationship, the privacy policy describes what Rydya does with data generally, and this addendum sets the specific processor obligations a data-protection regime expects.

It applies where your organisation is the controller of personal data and Rydya processes that data to provide the service. Because Rydya stores no patient clinical records, the personal data in scope is operational: staff identities, the records they create, and contact details supplied through login-free fault reporting.

Controller and processor: who decides and who acts

Your organisation is the controller and decides the purposes. Rydya is the processor and acts on your documented instructions.

You are the controller

Your organisation determines the purposes and means of processing the personal data you put into Rydya, and is responsible for having a lawful basis for it. You decide who to invite, what to record, and what to ask people reporting faults to provide.

Rydya is the processor

Rydya processes that personal data on your behalf to provide the service, and on your documented instructions, which include using the product as intended and any written agreement between us. It does not process your data for its own separate purposes.

Purpose limitation

Rydya uses the personal data to run the product for you, and for no undisclosed purpose. There is no advertising or analytics use, because the product contains neither, so there is no secondary processing to disclose.

Instructions and the limits of them

If an instruction would require Rydya to act unlawfully, it will say so rather than comply. And some behaviour is fixed by design: the audit trail is immutable, so an instruction to alter it cannot be honoured without breaking the property that makes it trustworthy.

Subject matter, duration and categories of data

The processing lasts as long as your agreement, covers operational personal data, and never includes patient clinical records.

The subject matter is the provision of Rydya as described in the terms of service. The duration is the term of your agreement, plus any limited period needed to return or delete data afterwards, subject to the immutable parts of the audit trail.

The categories of data subject are your staff and other authorised users, and members of the public who submit login-free fault reports. The categories of personal data are identity and contact details, the operational records and evidence those people create, and technical and audit logs. Rydya does not process special-category health data about patients, because it holds no patient clinical records at all, and this is a fixed product boundary rather than a configurable one.

Subprocessors, and how changes are handled

Rydya uses a small set of infrastructure subprocessors by category. The definitive list is maintained and provided, and material changes are notified so you can object.

By category, because the specifics are not yet fixed

Rydya relies on a hosted application and database platform, and on infrastructure such as content delivery, to run the service. Where message delivery is enabled, a delivery provider would be a further subprocessor. The definitive, named list is maintained and made available rather than invented here, because the hosting region and some providers are still being decided.

Flow-down obligations

A signed version commits Rydya to imposing data-protection obligations on its subprocessors that are materially equivalent to those in this addendum, and to remaining responsible to you for their performance.

Notice and objection

A signed version provides for advance notice of a new or replacement subprocessor and a mechanism to object on reasonable data-protection grounds, so a change of infrastructure is never something that simply happens to your data without you.

Security measures

The technical measures Rydya genuinely enforces, described at the level a reviewer can test, with the current gaps stated rather than hidden.

Tenant isolation at the database

Every tenant record carries an organisation identifier under forced database row level security, so one customer's data is not accessible to another even through an unreviewed query. This is enforced structurally rather than by application convention.

Immutable audit and no impersonation

Changes are recorded in an append-only, hash-chained audit trail with no update or delete path at the database. Rydya staff cannot impersonate your users; support access is reason-required, approval-gated, read-only by default, time-bound and separately audited.

Authentication and encryption in transit and at rest

Access uses multi-factor authentication with step-up and server-side session revocation. Data is encrypted in transit, and encrypted at rest by the hosted platform the service runs on. Rydya applies application-layer encryption to sensitive secrets such as webhook signing keys.

Stated gaps

Uploaded files are not scanned for malware, there is no enterprise single sign-on, the restore procedure has not been drilled, and Rydya holds no SOC 2, ISO 27001 or independent penetration test. These are published rather than concealed, so your risk assessment is based on the real posture.

International transfers, confidentiality and audit

The hosting region is not yet committed, so transfer mechanisms are for the signed version. Confidentiality and reasonable audit cooperation are part of this draft.

Because the hosting region and data residency are open decisions, this draft does not assert a particular transfer location or mechanism such as standard contractual clauses. A signed version will set the transfer basis appropriate to where the service is actually hosted and to your requirements. If residency is a hard requirement for you, it is better raised now than discovered later.

Rydya commits to keeping your data confidential and to ensuring that personnel authorised to process it are bound by confidentiality. On audit, a signed version provides for you to verify compliance through the information Rydya makes available, including the trust documentation, and through reasonable audit cooperation, balanced against the need to protect other customers' data and the security of the platform.

How data is returned and deleted, and how breaches are handled

You can export your data, and Rydya will delete it on request within the honest limits of a product that has no automated erasure yet. Breaches are notified without undue delay.

At the end of the agreement, Rydya will, at your choice, return or delete the personal data it processes for you, within a reasonable period, except where retention is genuinely required and except for the immutable parts of the audit trail that cannot be altered without breaking their integrity. Because there is no automated purge or erasure in the product today, deletion is currently a manual operation, and this draft does not pretend otherwise.

Rydya will assist you, taking into account the nature of the processing, in meeting your own obligations: responding to data-subject requests, and notifying you without undue delay after becoming aware of a personal-data breach affecting your data, with the information you need to meet your notification duties. The precise timeframes and the mechanics belong in the signed version and to counsel.

Why this is a draft, and what must happen before it is executed

This document may require legal review before execution, and Rydya recommends it. It is a working draft, not a signed instrument, and it is not legal advice. Several parts are deliberately left for the signed version and for qualified counsel on both sides: the transfer mechanism, the named subprocessor list, the audit specifics, breach-notification timeframes, and the interaction with your own regime. It describes real product behaviour, verified against the code, but the legal effect of that behaviour in your jurisdiction is a matter for your advisers.

Questions

Is Rydya the controller or the processor of our data?

Rydya acts as the processor, and your organisation is the controller. You decide the purposes and means of processing the personal data you put into the product and are responsible for the lawful basis; Rydya processes that data on your documented instructions to provide the service, and not for any separate purpose of its own, because the product has no advertising or analytics use to serve.

Who are your subprocessors?

Rydya uses a small set of infrastructure subprocessors, such as a hosted application and database platform and content delivery, and a message-delivery provider where that is enabled. This draft describes them by category rather than naming a definitive list, because the hosting region and some providers are still being decided. The named, maintained list is made available, and a signed version provides for notice of and objection to changes.

Can you sign standard contractual clauses for international transfers?

Not in this draft, because the hosting region and data residency are open decisions and it would be dishonest to assert a transfer mechanism before the transfer location is fixed. A signed version will set the appropriate transfer basis for where the service is actually hosted and for your requirements. If a specific residency or transfer mechanism is a hard requirement, raise it before evaluating further.

What happens to our data when we stop using Rydya?

At the end of the agreement, Rydya will return or delete the personal data it processes for you, at your choice, within a reasonable period. Two honest limits apply: there is no automated erasure in the product yet, so deletion is a manual operation, and the append-only audit trail is immutable by design, so entries that form part of it cannot be altered without breaking the integrity that makes them trustworthy.

Keep reading

What personal data is processed, and the rights over it, in plain terms.

The agreement this addendum sits alongside, in the same draft state.

Cookie policy

What the product stores in the browser, and why it is not tracking.

Tenant isolation

The isolation security measure above, described so a reviewer can test it.

Data protection

The data inventory: what is processed, and what is never held.

See it on your equipment

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