Data processing agreement

1. Parties, subject matter, and duration

This agreement is made between the therapist holding a Stabli account (the “Controller”) and [OPERATOR LEGAL NAME], [ADDRESS], Switzerland (the “Processor”). It governs the processing of personal data — in particular data concerning the Controller’s patients, which is health-related and therefore sensitive personal data under Art. 5 let. c FADP — that the Processor carries out on the Controller’s behalf in operating the Stabli service. It applies for as long as the Controller holds an account and, for the duties that by their nature survive (confidentiality, deletion, breach notification for the period concerned), beyond it. The details of the processing are set out in Annex A; the technical and organisational measures in Annex B; the authorised sub-processors in Annex C.

2. Documented instructions

The Processor processes patient data only on the Controller’s documented instructions. The parties agree that the Controller’s instructions are constituted by:

this agreement and the Terms of Service;
the Controller’s use of the service’s functions — recording a patient, booking a session, writing or amending a note, filing or removing a document on a patient’s record, inviting a patient to complete their own file (which instructs the Processor to send that patient the invitation and, on the patient’s request, a verification code, and to record what the patient enters), preparing the thirty-session report and naming its physicians (which instructs the Processor to mail each physician a link and, on their request, a verification code, to show them the case sheet, to keep the part they write and the evidence of their signature, and to file the signed report on the patient’s record), subscribing a device to the diary, exporting, deleting — each of which is an instruction to perform exactly that operation;
any further written instruction the Controller gives, insofar as the service can technically carry it out.

The Processor processes patient data for no other purpose — not for analytics, advertising, product research, or the training of models — and informs the Controller without delay if, in its view, an instruction violates applicable data protection law.

3. Confidentiality and professional secrecy

a. Auxiliary to Art. 321 SCC secrecy

The Controller is bound by professional secrecy under Art. 321 of the Swiss Criminal Code. The Processor acknowledges that in operating Stabli it acts as the Controller’s auxiliary person (Hilfsperson) within the scope of that secrecy: facts covered by the Controller’s professional secrecy that reach the Processor remain protected by it, the Processor and its staff are themselves bound to the same confidentiality, and unlawful disclosure by an auxiliary is punishable under Art. 321 SCC. The Processor will not disclose patient data to any third party except the sub-processors in Annex C as needed to provide the service, or where a legally binding order of a Swiss authority compels it — in which case it will, unless legally forbidden, inform the Controller before complying and challenge orders it considers unlawful.

b. Staff undertakings (Art. 62 FADP)

Every person the Processor authorises to work on Stabli is bound by a written confidentiality undertaking that survives the end of their engagement, is informed that the data includes matters subject to professional secrecy, and is granted access only to the extent their task requires. Breach of professional confidentiality is additionally a criminal offence under Art. 62 FADP, and staff are informed of this.

c. Practices of several practitioners

Where the Controller is a practice in which several practitioners hold seats, the Controller is the practice as a whole and each practitioner remains individually bound by Art. 321 SCC. The Processor enforces, in the database itself, that no seat in the practice grants access to a clinical record: a record is opened only by the practitioner responsible for it, by the supervisor answerable for a practitioner in postgraduate training, by a colleague the responsible practitioner has admitted to that one record with a recorded reason, or — where the Controller has expressly chosen to share records between its practitioners and has informed its patients accordingly — by the practice’s practitioners. Reception and billing seats reach appointments, contact details and invoices and no clinical content. Each such admission is logged. The Controller is responsible for the confidentiality undertakings of its own members (Art. 62 FADP) and for the content of its patient information notice.

4. Security of processing

The Processor implements and maintains technical and organisational measures appropriate to the risk of processing sensitive health data, as set out in Annex B, and reviews them regularly against the state of the art. Material reductions of the protection described in Annex B are treated as a change requiring the notice mechanism of Section 5.

5. Sub-processors

The Controller authorises the sub-processors listed in Annex C. The Processor imposes on each sub-processor, by contract, data protection obligations materially equivalent to this agreement, and remains fully liable to the Controller for their performance.

Before adding or replacing a sub-processor, the Processor gives the Controller at least 30 days’ notice by email to the account address, identifying the sub-processor, its role, and its processing location. If the Controller objects on reasonable data protection grounds and the parties cannot resolve the objection, the Controller may terminate the account before the change takes effect and export their data; the change does not apply to a Controller who has terminated. Silence past the notice period counts as approval of the specific change announced.

6. Assistance with data subject rights

Patients exercise their FADP rights (access, correction, deletion — Art. 25 ff. FADP) against the Controller. The Processor supports the Controller in answering them, taking into account the nature of the processing:

the service itself provides the means for most requests — the patient record on screen answers access, editing answers correction, deleting a patient answers deletion, and export produces a copy of the record including the notes and the history of their amendment;
for anything the interface cannot do, the Processor assists on written request within 10 working days;
if a data subject approaches the Processor directly, the Processor does not answer on the merits — it is not entitled to know the Controller’s patients, and still less the third parties a note may name — and refers the person to their therapist, informing the Controller where the request identifies them.

Deciding what a patient may read, and whether Art. 26 FADP permits withholding a passage that concerns another person, is the Controller’s assessment and not the Processor’s: the Processor has no basis on which to make it and does not attempt to.

7. Notification of data security breaches

The Processor notifies the Controller without undue delay after becoming aware of a breach of data security (Art. 24 FADP) affecting patient data processed for the Controller. The notification states, as far as then known: the nature of the breach, the categories and approximate scope of data and data subjects concerned, the likely consequences, the measures taken or proposed, and a contact point; information not yet available is supplied as it becomes available. The Processor documents all breaches and reasonably assists the Controller with the Controller’s own assessment and, where required, notification to the FDPIC and to affected patients. The Processor does not notify authorities or data subjects in the Controller’s place unless legally required to do so.

8. Deletion and return of data

The service provides export of the Controller’s complete practice data at any time, in a machine-readable format, including note text and the superseded versions of amended notes; the documents on each patient’s record are listed in that export by name, kind, size and date, and each downloads in full, decrypted, from the record itself — the export file states this division rather than leaving it to be noticed. On termination of the account — by the Controller deleting it, or by termination under the Terms — the Processor deletes all patient data processed for the Controller, the sealed document objects alongside the rows that named them, whereupon it also disappears from database backups as those expire on the schedule described in Annex B. Where the Controller is a practice of several practitioners, the practice is the account whose termination deletes; a practitioner leaving the practice ends their seat and deletes nothing, the records they were responsible for remaining the practice’s, and the service refuses to delete a person’s account while they still hold a seat in a practice with other members.

The Controller is responsible for exporting before deletion, and this matters more since the service began holding clinical notes: where the Controller keeps their patient record here, the record the Controller must retain under cantonal health law for ten to twenty years is the data in this account. That retention duty is the Controller’s own in every configuration — the Processor is not an addressee of those statutes — and it is the reason the deletion flow requires an export confirmation and the reason the Processor does not delete a Controller’s data on its own initiative. No copies are retained except where Swiss law requires retention, and then only for as long and as far as it requires.

Invoices the Controller issues through the service are accounting records the Controller must keep for ten years (Art. 958f CO). They are carried whole in the export above, with their lines and the identity they printed; the service voids an invoice rather than deleting it, and will not delete a patient’s record while an invoice names them. Deleting the account deletes them with everything else, which is one more reason the export comes first.

9. Information and audit rights

The Processor makes available to the Controller the information necessary to demonstrate compliance with this agreement: this document and its annexes, the compliance documentation published with the product (record of processing activities, processing policy, impact assessment), and answers to reasonable written questions within 20 working days. Given that the service is a multi-practice system in which one controller must never gain access to another’s data, on-site inspection of shared infrastructure is replaced by: audit reports and certifications of the sub-processors where available, and — where the Controller demonstrates a legitimate need an answer in writing cannot meet — an audit by a professionally bound independent third party under confidentiality, at the Controller’s cost, scoped to the Controller’s own data and no more than once per year except after a breach.

10. Cross-border processing

Patient data — including notes — is stored in Switzerland (Annex C). Where a sub-processor involves disclosure abroad — Vercel, USA — the Processor ensures a valid transfer basis under Art. 16 f. FADP, currently the Swiss–U.S. Data Privacy Framework, and keeps a fallback of recognised standard contractual clauses for the event that the framework’s adequacy lapses. The Processor does not move storage of patient data out of Switzerland without the Section 5 notice mechanism.

11. Liability and final provisions

Liability follows the Terms of Service. [CONFIRM WITH LAWYER: interaction of the Terms’ liability cap with FADP liability and Art. 321 SCC exposure]. This agreement is governed by Swiss law, with the place of jurisdiction set in the Terms. If a provision is invalid, the remainder stands and the parties replace the invalid provision with a valid one closest to its purpose.

12. Annex A — Details of the processing

ITEM	DESCRIPTION
Nature and purpose	Hosting and operating a practice-management application: storage, retrieval, display, organisation, synchronisation (where the Controller enables it), export, and deletion of the Controller's practice records.
Categories of data subjects	The Controller's patients, and — since 11 August 2026 — third parties named inside the Controller's notes (family members, employers, other treating professionals). Those third parties have no relationship with the Processor, which does not know who they are; the Controller decides what is written about them. Since 6 September 2026 also the physicians the Controller names for a thirty-session report (Art. 11b OPAS) — the prescribing physician and, where required, a psychiatrist — about whom the Processor holds, for the Controller, a name and an email address (stored encrypted), the part they wrote (stored encrypted), the stamps of the page they opened, and the evidence of their electronic signature: the declaration accepted and its version, the moment, the email address verified, the IP address used, and the fingerprint of the document signed. They are the Controller's own recipients, bound by their own professional secrecy, and their counterpart for any right is the Controller. (The Controller's own account data is processed by Stabli as controller — see the Privacy notice.)
Categories of personal data	Patient identity (name, and the referring/primary physician's name where recorded); patient contact and billing identifiers where the Controller records them — telephone number, email address, postal address, and insurance number, each optional and each stored encrypted (in Swiss practice the insurance number is the patient's AVS number, since that is what LAMal billing identifies the insured person by); since 3 September 2026 also, where the Controller records them, the patient's date of birth, the name of their insurer and the number that insurer knows them by, each optional and each stored encrypted, together with which party an invoice for the patient is addressed to (the patient, or their insurer) and, since 8 September 2026, under which law their invoices are raised (basic insurance under LAMal, supplementary insurance under LCA, or the patient's own pocket) — the identity a Tarif 581 invoice requires; since 4 September 2026 also, where the Controller records them for a claim to the insurer, the patient's sex (the electronic invoice standard's required attribute), the insurer's GLN and postal address (both stored encrypted), and on the prescription the prescribing physician's postal address and the ICD-10 diagnosis code the physician wrote (both stored encrypted — the diagnosis is the first clinical classification the service holds, is optional, is never searched or matched, and leaves the service only inside a claim the Controller sends). The Processor stores and displays these to the Controller and uses them for no purpose of its own. Since 6 September 2026 the Processor sends to the patient's email address, on the Controller's instruction per patient and through Resend, Inc. (Annex C), exactly two messages: an invitation to complete their own file, and — only when the patient asks for it from the invitation — a six-digit verification code; both name the Controller's practice and neither names the patient. What the patient then enters through that invitation (the fields above, and photographs of their insurance card) is recorded on their file as the Controller's data, marked as supplied by the patient; the invitation itself — the address it went to (stored encrypted), its language, and when it was sent, opened, verified and completed — is kept beside the file. No other message is sent to any patient by any channel of the Processor's; appointment data (dates, times, durations, recurring-series parameters); prescription tracking (counts and positions of sessions against prescriptions, and — since 3 September 2026, where the Controller records them — the prescribing physician's name and GLN, both stored encrypted, the date on the prescription, and whether it was made under the regular or the crisis track of Art. 11b OPAS); services rendered and acts recorded outside a session; clinical notes written by the Controller, anchored to a session or to the patient's file, together with the superseded text of any note the Controller has amended (the record is append-only: an edit adds a version, it does not erase one), and including notes the Controller has flagged as personal — the Controller's own reflections kept beside the patient file, stored and protected identically to any other note and carried in the export of Section 8 marked as such (the flag is the Controller's working label; whether such a note falls within a data subject's right of access is decided by its content and is the Controller's determination to make); documents the Controller uploads to a patient's record — scanned prescriptions, referral letters, reports, in five file formats the service verifies from the file's own content — together with the filename the Controller gave each, both stored encrypted; invoices the Controller issues (since 3 September 2026) — the number, dates, law, state, amounts and lines of each, the lines frozen at issue, together with a snapshot of the patient's identity as printed and of the prescription claimed against, both stored encrypted — which the Processor renders for the Controller to print and hand over. Since 4 September 2026 a tiers-payant invoice may additionally be transmitted, on the Controller's explicit instruction per invoice, to the insurer the Controller addressed it to, through MediData AG (Annex C), as the Forum Datenaustausch XML claim — carrying the reimbursable lines, the patient's identity, the prescriber and the diagnosis code, and nothing else — and the insurer's answer (pending, accepted, rejected with its reason codes) is recorded on the invoice. No other invoice, copy or payment part leaves the service by any channel of the Processor's. Since 6 September 2026 also the thirty-session report to the insurer's medical adviser (Art. 11b OPAS): the Controller's part (anamnesis, diagnosis, setting, course, proposal — stored encrypted as one value), and per physician the Controller names — the prescribing physician and, where the ordinance requires one, a psychiatrist — their name and email address (both stored encrypted), their language, the part they write through the page the Processor mails them a link to (stored encrypted), the timestamps of that page, and once they sign the evidence of their electronic signature (the version of the declaration accepted, the moment, the email address verified by code, the IP address used, the sha256 fingerprint of the document as shown) or, instead, a one-word decline. The Processor sends each physician, through Resend, Inc. (Annex C), exactly two messages — the link and, on their request, a six-digit code — naming the Controller's practice and the physician's role and never the patient nor a word of the report. The signed report is rendered as a PDF and filed on the patient's record as a document of Annex A (stored encrypted, marked as filed by the report circuit). The Processor transmits the report to nobody: it leaves the service only as a PDF the Controller or the prescribing physician downloads.
Sensitive data	Yes. The fact of being in psychotherapeutic treatment, and everything the appointment history implies, is data concerning health (Art. 5 let. c FADP) for every patient recorded. Since 11 August 2026 the processing also covers the clinical content itself — what was worked on, how the patient presented, correspondence about their care — which is the material the Controller's Art. 321 SCC professional secrecy exists to protect rather than merely a fact about it.
Processing operations	Collection as entered by the Controller; storage; structuring; consultation by the Controller; disclosure to Annex C sub-processors strictly as needed to provide the service; erasure.
Duration	For the life of the Controller's account; deletion per Section 8.

13. Annex B — Technical and organisational measures

Tenant isolation: row-level security enforced in the database itself scopes every query to the authenticated therapist’s rows; anonymous database roles hold no grants on practice tables.
Application-layer encryption of identity and clinical content: patient identity fields, the patient contact and billing identifiers of Annex A, the snapshot of that identity an issued invoice keeps, note bodies (including superseded versions), the thirty-session report’s parts — the Controller’s and each physician’s — together with the physicians’ names and email addresses, and the documents of Annex A — their bytes, sealed before they reach object storage, and their filenames alike — are encrypted (AES-256-GCM) with a key held by the application and never by the database, so the database, the object store, their backups, and database-level personnel never hold a readable patient identity, a readable note, or a readable document. No query sorts, searches or computes over those columns — which is what keeps the encryption real, and why note search is per patient and performed in the application rather than in the database. For the note text, the contact and billing identifiers, and the document filenames, the database itself refuses to store a value that is not encrypted — and the document store accepts no readable file type at all — so the guarantee does not rest on application code alone. The insurance number is additionally never indexed and never used to look a patient up: an index over an identifier that is issued once and never reissued would hand back, in readable form, the very thing the encryption removes.
What the encryption does not do: the application holds the key, so the Processor is technically capable of reading notes. That capability is bounded by Section 3 (professional secrecy and staff undertakings), by need-to-use administrative access, and by the audit log below — not by cryptography. It is stated here rather than left to inference, because the Controller is answerable for choosing a processor (Art. 9 para. 2 FADP) and cannot make that assessment on a description that overstates the guarantee.
Hosting location: database and authentication in the AWS Zurich region, Switzerland; encrypted at rest by the platform.
Transport encryption: TLS on every connection between browser, application, and database.
Access control: authentication with hashed credentials; sessions via secure HTTP-only cookies; administrative access to production limited to named, contractually bound persons on a need-to-use basis. A patient completing their file through an invitation holds no account: the invitation’s link, its verification code and the hour-long session the code buys are three separate secrets, each stored only as a hash, each bounded in time (fourteen days, ten minutes and five attempts, sixty minutes), and the invitation is spent by the patient’s one save. A physician signing a thirty-session report holds no account either: the same three secrets under the same bounds authorise their page, one live link per report and role is enforced by the database, the signature is a single conditional write bound to the session and to the fingerprint of the document shown, and its evidence — the declaration’s version, the moment, the verified email address, the IP address used, the document fingerprint — is kept on that row only, readable by the Controller, and used for nothing else.
Data minimisation at the edges: a subscribed calendar reads appointment times and a link back to the record in Stabli, never a patient name or any part of one, and answers only to a per-device credential the Controller creates and can revoke, so the service exposes no diary that can be read without one; the two emails of the patient invitation name the Controller’s practice and never the patient, so the mail provider and a mistyped address learn that a practice invited somebody and nothing more; the two emails to a physician of the thirty-session report name the Controller’s practice and the physician’s role, never the patient and never a word of the report, which leaves the service only as a PDF somebody downloads; server logs carry status and reason codes, not patient data.
Auditability:access to and changes of patient records are recorded in an audit log the Controller can consult — the Controller’s own trail is included in the data export of Section 8 — retained for a bounded period and then purged. Writing, amending, deleting and reading a note, filing, reading and removing a document, and sending, withdrawing, verifying and completing a patient invitation, and preparing a thirty-session report, mailing, re-mailing and withdrawing a physician’s link, the physician’s code, verification, saves, signature (with the declaration’s version) or one-word decline, and the report’s sending, are recorded as events of their own; the log carries identifiers, roles, counts and timestamps — never note text, never a word of a report, never a filename, never an address, and never the word a physician declined with.
Backups and recovery: automated backups with point-in-time recovery at the database platform; backups expire on the platform’s schedule, which bounds how long deleted data persists in them.
Organisational measures: written confidentiality undertakings for all staff (Section 3); documented breach runbook; processing policy per Art. 5–6 OPDo maintained with the product’s compliance documentation.

14. Annex C — Authorised sub-processors

These are the parties engaged to process the Controller’s patient data on the Controller’s behalf. The list is exhaustive: no other party receives patient data in any form.

SUB-PROCESSOR	ROLE	LOCATION	TRANSFER BASIS
Supabase, Inc.	Database and authentication platform	AWS eu-central-2 (Zurich), Switzerland	No cross-border transfer for storage
Vercel, Inc.	Application hosting and edge network	USA / global edge	Swiss–U.S. Data Privacy Framework
MediData AG	Intermediary for electronic invoicing (Forum Datenaustausch XML): carries a tiers-payant claim from the Controller to the insurer the Controller addressed it to, and the insurer's answer back. Engaged per invoice, on the Controller's explicit instruction, and only where the Controller holds a MediData network subscription of their own	Root (Lucerne), Switzerland	No cross-border transfer
Resend, Inc.	Transactional email delivery (src/lib/mail.ts) for five message types: the patient invitation and its verification code, the physician's link and its verification code for the thirty-session report, and the invitation to a colleague to take a seat in the Controller's practice — each sent on the Controller's instruction (or at the recipient's own request for a code) to the address the Controller entered. The colleague's invitation carries no patient data at all. Receives the recipient address, the practice's display name and a message text naming the practice and, for a physician or a colleague, their role — never a patient and never a word of a report; holds delivery logs on its own retention. Engaged for no other message	AWS eu-west-1 (Ireland), Ireland — the sending domain is created in Resend's EU region	Art. 16 para. 1 FADP — Federal Council adequacy (EEA); corporate access from the USA under Resend's DPA (SCC-based)

Changes to this annex follow the notice-and-objection mechanism in Section 5.

15. Annex D — Other recipients (no patient data)

This annex is not part of the Processor’s sub-processor chain and is published so that the Controller has the complete list of companies behind the service without having to look for it elsewhere. Each party below receives data for which the Processor is controller— the therapist’s own account data — and no personal data of any patient, in any field: no name or part of one, no patient, session, note or prescription identifier, no free text, and no count of any of them.

RECIPIENT	ROLE	LOCATION	TRANSFER BASIS
PostHog, Inc.	Product analytics on the Processor's own account data. Receives no personal data of any patient, in any field, and processes nothing on the Controller's behalf	AWS eu-central-1 (Frankfurt), Germany	Art. 16 para. 1 FADP — Federal Council adequacy (EEA)

Because these parties process no patient data, Section 5 is not engaged by a change to this annex and Section 2’s restriction on the purposes of processing is unaffected — patient data remains processed only on the Controller’s instructions, and never for analytics or product research. The Processor will nonetheless announce additions here alongside any Section 5 notice, so that one message describes every change to who is involved.