Data Processing Agreement

This Data Processing Agreement ("DPA") is concluded pursuant to Article 28(3) of Regulation (EU) 2016/679 ("GDPR") between the User-Controller (the licensed clinician or organization using the Service) and the Operator-Processor (the entity operating under the brand "ICD Diagnostica"). It is incorporated by reference into the Terms and Conditions at Section 13.2 and applies whenever the User submits Patient Data through the Service.

1.Definitions & parties

Parties. "Controller" means the User (a licensed mental-health professional, clinic, hospital, university, or other entity) accessing the Service. "Processor" means the entity operating the Service under the brand "ICD Diagnostica" (full statutory identity to be published at /en/imprint upon completion of registration formalities), with contact at [email protected] and DPO at [email protected].

Defined terms. Capitalised terms not defined here have the meaning given in the Terms and Conditions. "Patient Data" has the meaning in Section 1 of the Terms. "personal data", "processing", "controller", "processor", "data subject", and "personal-data breach" have the meaning given in Article 4 GDPR.

Hierarchy. In the event of conflict between this DPA and the Terms and Conditions, this DPA prevails on data-protection matters relating to Patient Data; the Terms prevail on commercial matters.

2.Subject-matter and duration

Subject-matter. The Processor processes Patient Data on behalf of the Controller for the purpose of providing the ICD Diagnostica Service (informational decision-support, differential ranking, AI-Assist verification, patient-record management, and related workflow tools).

Duration. This DPA is effective from the date the Controller first accepts the Terms and remains in force for as long as the Processor processes Patient Data on behalf of the Controller (i.e., until the Controller's account is deleted or the contractual relationship is otherwise terminated). Provisions that by their nature should survive termination – confidentiality, return/deletion, audit rights for data already processed, liability, governing law – survive.

3.Nature and purpose of processing

Nature. Processing operations include collection, recording, organization, structuring, storage, adaptation, retrieval, consultation, use, transmission to sub-processors, restriction, erasure, and destruction of Patient Data – strictly as required to provide the Service.

Purpose. The sole purpose is provision of the Service to the Controller. The Processor will not process Patient Data for any other purpose, including (without limitation): marketing, advertising, behavioral profiling, sale or sharing with third parties, training of generalized AI/ML models (whether internal or external), or any secondary research without separate written authorization.

4.Type of personal data and categories of data subjects

Categories of data subjects. Patients (third-party natural persons) about whom the Controller records information through the Service.

Categories of personal data.

• Identification: pseudonymous identifiers chosen by the Controller (initials, internal patient ID, age, sex). The Service strongly discourages and does not require direct identifiers (national ID, full name, full address).
• Special-category data (Article 9(1) GDPR): health data – symptoms, mental-health complaints, prior diagnoses, ICD-11 codes selected, clinical observations, free-text notes, episode timelines.
• Diagnostic-session metadata: selected symptoms, locked disorder code, AI-Assist output, timestamps, session duration.

Lawful basis of the Controller. The Controller represents that it has identified a lawful basis under Article 6 GDPR (typically Article 6(1)(b) or 6(1)(c)) and Article 9 GDPR (typically Article 9(2)(h) – provision of healthcare or treatment, read together with Article 9(3) – professional secrecy of the Controller as a licensed practitioner). The Processor relies on the Controller's representation and is not required to independently verify the lawful basis.

5.Controller's obligations and rights

The Controller warrants that: (a) it has identified a valid lawful basis under Article 6 and (where applicable) Article 9 GDPR for each processing activity; (b) it has provided all required notices to data subjects under Articles 13–14 GDPR; (c) it complies with professional-secrecy and code-of-conduct obligations applicable in its jurisdiction (including, in Poland, the Act on the Profession of Physician of 1996 and the Act on Patient Rights of 2008); (d) it will not submit to the Service any personal data of any data subject for whom no lawful basis exists.

The Controller has the right to: (a) issue documented instructions (Section 6); (b) exercise audit and inspection rights (Section 13); (c) receive cooperation on data-subject rights (Section 10); (d) receive the assistance set out in Section 11; (e) require return or deletion at end of processing (Section 12).

6.Documented instructions (Article 28(3)(a) GDPR)

The Processor processes Patient Data only on documented instructions from the Controller. The Controller's initial documented instructions are the Terms and Conditions, this DPA, and any configuration the Controller makes within the Service.

Additional written instructions may be issued by the Controller via e-mail to [email protected]. The Processor will inform the Controller without undue delay if, in the Processor's opinion, an instruction infringes the GDPR or other Union or Member-State data-protection law (Article 28(3) second sub-paragraph).

Transfer of Patient Data to a third country is permitted only if required by Union or Member-State law to which the Processor is subject; in that case, the Processor will inform the Controller of that legal requirement before processing, unless the law prohibits such information on important grounds of public interest (Article 28(3)(a) GDPR).

Means vs purpose – no joint-controllership. The Processor's technical and organizational delivery choices (default soft-delete and backup roll-off windows in Section 12, security architecture in Annex B, sub-processor selection in Annex A, AI-Assist availability under the Clinical plan, data-residency configuration of the Firebase region) constitute means of processing chosen by the Processor as expressly permitted by Article 28(3)(c) GDPR – they do not amount to determining the purpose. The Controller retains the sole determination of purpose and may at any time issue earlier-deletion instructions, restrict processing, or terminate the engagement under Section 15.3. The parties accordingly reject any construction of their relationship as a joint-controllership within the meaning of Article 26 GDPR or the case law of the Court of Justice (Cases C-40/17 Fashion ID, C-210/16 Wirtschaftsakademie) read in light of EDPB Guidelines 07/2020. Where applicable national or sectoral law re-characterises a specific processing operation as joint-controllership, the parties will execute a separate Article 26 arrangement allocating responsibilities for that operation.

7.Confidentiality (Article 28(3)(b) GDPR)

The Processor ensures that persons authorized to process Patient Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality. This commitment survives termination of the engagement.

The Processor restricts access to Patient Data to personnel and contractors who have a strict need-to-know in the performance of the Service.

8.Security of processing (Article 28(3)(c) + Article 32 GDPR)

The Processor implements appropriate technical and organizational measures to ensure a level of security appropriate to the risk, having regard to the state of the art, the costs of implementation, the nature, scope, context, and purposes of processing, and the risks of varying likelihood and severity for the rights and freedoms of natural persons.

The current set of measures is set out in Annex B. The Processor may update Annex B from time to time provided that the level of protection is not reduced.

9.Sub-processors (Article 28(3)(d) + Article 28(2)+(4) GDPR)

General authorization. The Controller grants the Processor general authorization to engage sub-processors for the provision of the Service. The current list of sub-processors is in Annex A.

Notification of changes. The Processor will inform the Controller of any intended changes concerning the addition or replacement of sub-processors at least thirty (30) days in advance, by e-mail or in-app notification, thereby giving the Controller the opportunity to object.

Right to object. Where the Controller objects to a new sub-processor on reasonable data-protection grounds, the parties will discuss in good faith. If no resolution is reached within thirty (30) days of objection, the Controller may terminate the affected portion of the Service with prorated refund of unused prepaid fees.

Sub-processor obligations. The Processor imposes on each sub-processor data-protection obligations no less protective than those in this DPA, in particular in relation to security (Section 8) and breach-notification (Section 11).

Liability. Where a sub-processor fails to fulfil its data-protection obligations, the Processor remains fully liable to the Controller for the performance of those obligations.

10.Assistance for data-subject rights (Article 28(3)(e) GDPR)

The Processor assists the Controller, by appropriate technical and organizational measures, insofar as possible, to help fulfill the Controller's obligation to respond to requests from data subjects exercising their rights under Articles 15–22 GDPR (access, rectification, erasure, restriction, portability, objection, no automated decision-making).

If the Processor receives a data-subject request directed to the Controller, the Processor will, without undue delay, forward the request to the Controller and will not respond to the request itself except on the Controller's instructions.

In-app self-service tools (export, deletion) are made available to the Controller. Where the Controller requires bespoke assistance, the Processor may charge reasonable fees only for manifestly unfounded or excessive requests; standard requests are handled at no charge.

11.Assistance with security, breach-notification, and DPIA (Article 28(3)(f) GDPR)

Article 32 – security. The Processor assists the Controller in ensuring compliance with Article 32 GDPR by implementing the security measures in Annex B and providing such information as the Controller reasonably requires.

Article 33 – breach notification to supervisory authority. The Processor will notify the Controller without undue delay after becoming aware of a personal-data breach affecting Patient Data, and in any event within seventy-two (72) hours of becoming aware where reasonably practicable. The notification will include the information set out in Article 33(3) GDPR insofar as available, and updates as further information becomes available.

Article 34 – communication to data subject. The Processor assists the Controller in fulfilling the Article 34 obligation where the Controller determines that direct communication to data subjects is required.

Articles 35–36 – DPIA and prior consultation. The Processor assists the Controller in carrying out Data Protection Impact Assessments and, where required, in prior consultation with the supervisory authority, by providing information about the Service's processing operations.

12.Return or deletion at end of processing (Article 28(3)(g) GDPR)

At the choice of the Controller, on termination of the contract or earlier on Controller's instruction, the Processor will (a) return all Patient Data to the Controller in a structured, commonly used, machine-readable format, or (b) delete all Patient Data, unless Union or Member-State law requires storage of the personal data.

Default: where no choice is made, the Processor will delete Patient Data. Soft-deleted (archived) records are retained for a limited recovery window before being permanently purged via an automated job. Active-system data is removed within a reasonable period of termination, followed by a backup-roll-off interval to allow legitimate recovery requests, in line with the Processor's documented retention policy.

The Processor will provide written confirmation of return or deletion to the Controller on request.

13.Audit and inspection rights (Article 28(3)(h) GDPR)

The Processor makes available to the Controller all information necessary to demonstrate compliance with Article 28 GDPR, and allows for and contributes to audits, including inspections, conducted by the Controller or another auditor mandated by the Controller.

Audit modalities. Audits will be (a) conducted on reasonable prior notice (at least thirty (30) days for routine audits; shorter notice for audits triggered by a personal-data breach or supervisory-authority order); (b) limited to one audit per calendar year unless additional audits are required by law or by a personal-data breach; (c) subject to confidentiality obligations on the auditor; (d) conducted at the Controller's expense (other than where the audit reveals material non-compliance, in which case the Processor bears reasonable audit costs).

Independent audit reports. The Processor may satisfy the audit obligation by providing recent independent third-party audit reports (e.g., SOC 2, ISO 27001, or sub-processor reports) to the extent that these cover the relevant processing.

14.International transfers

Patient Data is processed primarily within the European Union. Onward transfer to a third country occurs only via approved sub-processors listed in Annex A and only under one or more of the following safeguards: EU-US Data Privacy Framework adequacy decision (Decision (EU) 2023/1795); Standard Contractual Clauses approved by Decision (EU) 2021/914 (Module 2 controller-to-processor or Module 3 processor-to-processor); supplementary measures per EDPB Recommendations 01/2020.

A copy of the relevant SCCs is available on request to [email protected].

15.Liability, indemnity, term & termination

Liability. The liability of each party under this DPA is governed by the limitation-of-liability clauses of the Terms and Conditions (Section 18). Liability for damage caused intentionally cannot be excluded (Article 473 § 2 of the Polish Civil Code).

Term. This DPA is co-terminous with the Terms and Conditions and the Controller's use of the Service.

Termination for cause. The Controller may terminate this DPA (and consequently the underlying Service) for material breach by the Processor that is not cured within thirty (30) days of written notice; the Processor may suspend processing where required by law or to protect data-subject rights.

16.Governing law & final provisions

Governing law. This DPA is governed by the laws of Poland and the GDPR.

Jurisdiction. Disputes are subject to the jurisdiction provisions of the Terms and Conditions Section 22.

Severability. If any provision is held invalid, illegal, or unenforceable, the remainder remains in full force and effect.

Updates. The Processor may update this DPA to reflect changes in law or sub-processor list. Material changes will be notified at least thirty (30) days in advance; non-material updates take effect on publication.

A.Annex A – Sub-processors

Current list, effective 6 May 2026:

WHO ICD-11 API (Geneva, Switzerland) is consulted server-side for canonical ICD-11 entity look-ups – no User personal data and no Patient Data is transmitted to WHO; therefore WHO is not a sub-processor of personal data within Article 28 GDPR. Switzerland in any event benefits from a European Commission adequacy decision (Decision 2000/518/EC).

B.Annex B – Security measures (Article 32 GDPR)

Encryption & transport

• HTTPS-only with HSTS preload; TLS 1.3 where supported by the client.
• AES-GCM client-side encryption (PBKDF2 key derivation tied to user UID) for sensitive fields stored in localStorage.
• Encryption-at-rest for all Firestore data and Cloud Storage objects (Google-managed AES-256).
• Passwords stored as salted hashes by Firebase Authentication – the Processor never sees plain-text passwords.
• API keys and secrets stored in Google Secret Manager with scoped IAM access.

Identity, authentication, access control

• Firestore security rules with owner-safe validators preventing privilege escalation (admin / plan / billing / 2FA fields server-only).
• Identity Platform with email-enumeration protection and Account Defender.
• Optional two-factor authentication (2FA) via e-mail one-time codes.
• Custom-claim-based admin authorization; MFA gate on high-risk admin operations with time-limited re-verification.
• Need-to-know principle for personnel access to Patient Data.

Application security

• Firebase App Check + reCAPTCHA Enterprise (v3, score-only) on every callable Cloud Function and Firestore client request.
• Per-user rate limiting on rate-sensitive endpoints (account-deletion, e-mail verification, password reset, subscription cancellation).
• Strict Content Security Policy (CSP) with violation reporting.
• Storage rules restricting upload size and MIME type (image-only).
• Input validation and output escaping at server boundaries.

Operational and organizational

• Automated Firestore backups under a documented rotation policy; backups isolated from operational processing.
• Cloud Monitoring alerts on anomaly detection (function errors, request spikes, scraping signatures).
• Incident-response procedure with explicit Article 33/34 commitments – 72-hour notification (Section 11).
• Documented Article 30 records of processing.
• Documented Article 35 DPIA for the Service's large-scale Article 9 processing.
• DPO appointed and notified to UODO under Article 37(7) GDPR.
• Cloudflare WAF and DDoS protection.
• Stripe-handled payments – no card data stored on the Processor's platform.

Patient-data minimization

• The Service does not require direct identifiers (national ID, full name, full address) and discourages their entry.
• Free-text notes are stored client-side AES-GCM-encrypted where applicable; server-side at-rest encryption applies in all cases.
• Soft-delete with a documented recovery window before permanent purge.