Sync Server Data Processing Agreement (GDPR/UK)

Sync Server Data Processing Agreement

(GDPR / UK GDPR processor terms for the SideClick sync server and patient portal)

This instrument covers the sync server, which every edition includes, and the Practice edition's patient portal. South African customers: the POPIA schedule applies in addition. Annex A is written from the sync server's actual database structure and is kept factually exact.

This Sync Server 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's people sign in to the sync server or the Controller enables the patient portal.

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 sync server: it stores and routes end-to-end-encrypted content between the Controller's signed-in 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

The sync server that holds the Controller's data is hosted in the region stated in the sub-processor register, and its backup copies are kept in the second region stated there, in the same country. Data is not moved between regions in normal operation except as those backup copies. 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 the content on the sync server 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 a practice; 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 the sync server's 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 state of a subscription (including expiry, non-payment, suspension or termination), the sync server continues to serve download and acknowledgement of the Controller's already-stored data for 90 days after the subscription a person's seat comes from ends; during those days nothing new is accepted for that person, and the Processor sends them a warning on day 1, day 60 and day 83. After the 90 days the Processor deletes that person's sealed copies and every entry, media item and key that nobody holds any more — the one deletion the Processor performs on its own. The Controller's own record is never touched by it: a practice's record stays for as long as the practice is subscribed, and leaves the sync server when the practice deletes it. Deletions the Controller itself instructs through the software are not limited by this floor and are honoured as documented instructions under §2(1). Every copy of a record has one keeper — the practice for the practice's record, a person for a copy they hold (the copy they took when they left a practice, or a copy sent to them) — and that keeper's Delete under Retention removes their copy from the sync server; a copy another keeper holds is untouched by it, and a key nobody holds any more is deleted with the copy. Where law requires retention, 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 sync server 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. Device records: device identifier, account identifier, device public keys, sign-in and last-seen timestamps, the device's name as its operating system gives it (sealed, so that only the person's own devices can read it), platform label, origin type, status.
2. Encrypted content ("sealed envelopes"): every sealed entry (notes, bookings, invoices, payments), the keys of each patient file and of each entry wrapped for every person who may open them, portal messages, forms and documents, and field-capture media (photos and voice memos captured on the Controller's 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. The Processor keeps the sealed entries and media for as long as the Controller's people are subscribed and for the 90 read-only days after a subscription ends (§8). A single media file is subject to a size ceiling; storage is included in the subscription, measured (every sealed entry and media item counts) and shown to the payer, never capped.
3. Portal accounts: a random 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 portal account's 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. Account and subscription records: each account's email address, a verifier derived from its password (never the password), its public keys and its private keys sealed under the password and the recovery code (which the Processor cannot open), and an authenticator secret if one is turned on; each subscription's payer, edition, seat count, kind and end date, which account holds each seat, and the storage each holder uses; and the structure of the Controller's practices and clinics — which accounts belong to which, in which role and, where a membership has an end date, until when; invitations; grants and their end dates; which copies were sent, by whom, to whom and when, each with an opaque reference to the consent recorded on the sending device (the consent itself never leaves it); and the retention number of the practice and of each person. The account email is the only directly identifying personal data at rest on the sync server. The sync server also discloses a subscription's edition and state to the account's own authenticated devices at sign-in. The sync server can see which sign-in sent each sealed entry, when, and which sealed file it belongs to — never the patient's name or what the entry says.
7. Push-notification subscriptions (if the Controller's users enable notifications): for browser clients, the browser push endpoint and its keys; for signed-in 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 sync server's connecting address (see Annex C).

Duration: for the subscription term plus the 90 read-only days of §8, except content its keeper deletes through the software — the practice its record, a person a copy they hold (§8). Special categories: contained only within ciphertext the Processor cannot access; the Processor processes no readable health data.

Annex B — Technical and organisational measures (sync server)

• 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 sync server's own database is encrypted (SQLCipher); its backups hold only the same sealed content.
• Transport security: TLS with modern configuration for all connections.
• Data minimisation by construction: an automated schema test forbids clinical column names in the sync server's 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: a size ceiling per media file; storage is measured and shown to the payer, and media is kept for the life of the subscription and the 90 days after it (Annex A item 2).
• Access control: a new device signs in with the person's password and is approved from another of their devices (or with their recovery code or authenticator); 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.7 · Published 2026-10-26