Relay Data Processing Agreement (GDPR/UK)

Data Processing Agreement — SideClick sync relay & patient portal

(GDPR / UK GDPR processor terms for the Practice edition and legacy Sync licences)

This instrument covers the relay tiers; the Cloud edition's instruments are provided at onboarding. South African customers: the POPIA schedule applies in addition. Annex A is written from the actual relay schema and is kept factually exact.

This Data Processing Agreement ("DPA") forms part of the Terms of Service between SideClick (Pty) Ltd ("Processor") and the subscribing practice ("Controller"), and applies whenever the Controller enables the sync relay or patient portal services.

1. Roles and subject matter

The Controller determines the purposes and means of processing its patients' and staff's personal data. The Processor operates a zero-knowledge relay: it stores and routes end-to-end-encrypted content between the Controller's enrolled devices and portal accounts. The Processor holds no decryption keys for that content and cannot access it; the personal data the Processor can actually process is the service metadata inventoried in Annex A.

2. Processor obligations (Art. 28(3) GDPR)

The Processor shall:

1. process personal data only on the Controller's documented instructions — which are, exhaustively: store, route, and deliver encrypted content and service metadata as configured by the Controller in the software — unless required otherwise by law, in which case the Processor informs the Controller unless prohibited;
2. ensure persons authorised to process the data are bound by confidentiality;
3. implement the technical and organisational measures of Annex B (Art. 32);
4. engage sub-processors only per §4;
5. taking into account the nature of the processing (zero-knowledge — see §6), assist the Controller with data-subject rights requests;
6. assist the Controller with Articles 32–36 obligations, including breach notification per §7;
7. at the Controller's choice, delete or return the personal data at the end of services per §8;
8. make available information necessary to demonstrate compliance and allow audits per §9; and
9. inform the Controller immediately if, in the Processor's opinion, an instruction infringes the GDPR, the UK GDPR, or other data-protection law.

3. Controller obligations

The Controller warrants it has the lawful bases and, where required, consents for the personal data it processes with the software, and that its instructions comply with data-protection law. The Controller is responsible for the content it chooses to publish on the two plaintext-by-design surfaces (Annex A §4).

4. Sub-processors

The Controller grants general authorisation to the sub-processors in the sub-processor register (incorporated as Annex C). The Processor gives the Controller's administrative contact 30 days' notice of intended changes, with a right to object; on unresolved objection, the Controller may terminate the affected service and drain its data (§8). The Processor flows the obligations of this DPA down to every sub-processor and remains fully liable for them.

5. International transfers

Relay infrastructure for the Controller's organisation is hosted in the region stated in the sub-processor register, and data is not moved between regions in normal operation. Where a transfer to a third country occurs, the parties rely on the European Commission's standard contractual clauses (controller-to-processor module) and, for Controllers subject to the UK GDPR, the UK International Data Transfer Addendum — or on an adequacy decision where one applies — which are incorporated by reference and prevail over this DPA to the extent of conflict.

6. Data-subject rights — the zero-knowledge division of labour

Because relay content is encrypted end-to-end, the Processor cannot read, extract, correct, or selectively delete clinical content: those requests are fulfilled by the Controller using the software's built-in access-request, rectification, and erasure tooling on its own devices. The Processor's assistance obligation therefore consists of: (a) maintaining the availability and portability guarantees (§8) that let the Controller retrieve its data; (b) acting on Controller instructions to delete stored ciphertext, portal accounts, or device records for an organisation; and (c) forwarding to the Controller without undue delay any data-subject request the Processor receives directly.

7. Personal-data breach

The Processor notifies the Controller without undue delay and in any event within 72 hours of becoming aware of a personal-data breach affecting the Controller's data — a contractual commitment deliberately stricter than the "without undue delay" floor Art. 33(2) sets for processors, so the Controller can meet its own Art. 33(1) 72-hour duty to the supervisory authority — with the information Art. 33(3) requires (as available), and reasonably assists with notifications to authorities and data subjects. The parties record that a breach of relay storage exposes only Annex A metadata and ciphertext — a fact relevant to Art. 33(1)'s risk assessment — but notification obligations are assessed per event.

8. Return and deletion; the portability floor

The following are contractual floors, engineered into the service: whatever the licence state (including expiry, non-payment, or termination), the relay continues to serve download and acknowledgement of the Controller's already-stored data, and the Processor does not delete queued ciphertext or backup archives on lapse. Deletions the Controller itself instructs through the software are not limited by this floor and are honoured as documented instructions under §2(1) — including the software's audited archive-delete command and the Controller-configured backup-retention setting, which automatically prunes the organisation's oldest automatic backup archives fleet-wide (including archives uploaded by the Controller's other devices) once the configured count is exceeded. Field-capture media frames are additionally deleted on the automatic schedule in Annex A item 2. On the Controller's instruction, or 90 days after account closure, the Processor deletes the organisation's stored ciphertext, metadata, and backups, except where law requires retention (in which case the data stays protected under this DPA and is deleted when the requirement ends).

This is a ciphertext floor: the Processor holds no decryption keys and operates no key escrow, so it can return the Controller's stored data only in the encrypted form it was given. It cannot produce plaintext or assist in recovering data whose client-held keys or recovery material the Controller has lost (the no-vendor-recovery rule, EULA §7.6).

9. Audit

The Processor makes available the security documentation in Annex B, the public engineering record of the zero-knowledge design, and independent assurance reports (such as penetration-test summaries) as they become available. Audits beyond documentation review require 30 days' notice, at most annually, during business hours, without access to other customers' data — noting that the zero-knowledge architecture itself is independently verifiable from the published design and the software's behaviour.

10. Liability, precedence, UK addendum

Liability follows the Terms of Service. For personal-data obligations this DPA prevails over the Terms and over any marketplace or app-store terms. For Controllers subject to the UK GDPR, references to the GDPR read as the UK GDPR and the UK International Data Transfer Addendum applies to transfers.

---

Annex A — What the relay actually processes (exhaustive inventory)

Categories of data subjects: the Controller's practitioners and staff; the Controller's patients (and their authorised caregivers) who accept portal invitations.

1. Enrolled-device records: device identifier, organisation identifier, device public keys, enrolment and last-seen timestamps, client-supplied device name (e.g. "Reception laptop"), platform label, origin type, status.
2. Encrypted content ("sealed envelopes"): sync operations, key shares, portal messages, forms and documents, backup archives, the mobile read-model, and field-capture media frames (photos and voice memos captured on the Controller's enrolled phones, sealed on the capturing device before upload) — all opaque ciphertext the Processor cannot decrypt, each with identifiers, sizes, timestamps, and a per-device delivery ledger. Media frames are delivered only to the Controller's desktop devices, are subject to a per-frame size ceiling and a per-organisation storage quota, and are deleted once every active desktop has acknowledged them or after a fixed retention period (30 days by default), whichever comes first.
3. Portal principals: a random principal identifier per portal account, its public keys, and invitation records that store only a one-way hash of the invitation token. The link between a principal identifier and a person exists only in the Controller's local encrypted database — the Processor cannot identify portal patients.
4. Plaintext-by-design surfaces (Controller-published): the open-slot availability board (appointment types, times, durations — engineered to carry no patient data) and calendar feeds sanitised before publication (names reduced to initials or a generic label).
5. Connection and session records: connect and disconnect timestamps, TLS version, and the connecting network address stored only as a one-way hash.
6. Entitlement record: edition, seat and device caps, expiry, and the signed licence key itself — whose payload embeds the licensee's (not patients') name and email, and may additionally embed relay connection parameters (the relay address and its certificate fingerprint) and an organisation binding derived from the payment processor's customer identifier — configuration data, not patient data. The licensee contact is the only directly identifying personal data at rest on the relay. The relay also discloses the organisation's licensed edition to its own enrolled, authenticated devices during connection.
7. Push-notification subscriptions (if the Controller's users enable notifications): for browser clients, the browser push endpoint and its keys; for enrolled iPhones, the Apple Push Notification service device token. Pushed payloads are content-free by design — a fixed alert text, an opaque record identifier, and a count, never names or clinical content (enforced by automated test). For iPhone delivery, Apple — as the delivery carrier — additionally observes the device token, delivery timestamps, and the relay's connecting address (see Annex C).

Duration: for the subscription term plus the §8 drain and deletion window — except field-capture media frames (item 2), which are deleted earlier on acknowledgement by every active desktop or at the end of their fixed retention period, and content the Controller itself deletes or prunes through the software (§8). Special categories: contained only within ciphertext the Processor cannot access; the Processor processes no readable health data.

Annex B — Technical and organisational measures (relay)

• End-to-end encryption: content sealed on the Controller's devices (AES-256-GCM data keys; X25519 sealed boxes for key material); the Processor holds no decryption keys — a "no-view" architecture.
• Encrypted at rest: the relay's own database is encrypted (SQLCipher); backups are client-side-encrypted archives.
• Transport security: TLS with modern configuration for all connections.
• Data minimisation by construction: an automated schema test forbids clinical column names in the relay database (including the media store); invitation tokens and network addresses are stored only as one-way hashes.
• Media minimisation on the capturing device: photos are downscaled and stripped of embedded metadata (including location) on the capturing phone before sealing and upload; voice memos are transcribed only on the Controller's desktop devices — audio never leaves the Controller's devices in readable form.
• Media containment: per-frame size ceiling and per-organisation storage quota, with automatic deletion on full acknowledgement or at the end of the fixed retention period (Annex A item 2).
• Access control: device enrolment requires cryptographic device trust approved inside the Controller's practice; portal accounts are invitation-only.
• Auditability: the software maintains tamper-evident audit logging on the Controller's side; the Processor operates a documented incident-response process with the notification commitments of §7.

Annex C — Sub-processors

The sub-processor register, incorporated by reference, with the notice and objection rights of §4.

---

Signatures

	Controller	Processor
Entity	______________________	SideClick (Pty) Ltd
Name, title	______________________	______________________
Date, signature	______________________	______________________

Version 1.1 · Published 2026-09-12