Data Processing Addendum (DPA)

Effective date: 5 July 2026 · Version: 2.0

This Data Processing Addendum ("DPA") forms an integral part of the UDENTIVA Terms of Use and governs the rights and obligations relating to the processing of personal data between the Clinic using the UDENTIVA Service ("Data Controller") and Arı Bulut Depolama Bilişim ve Ticaret A.Ş. ("Company", "Data Processor"), under Law No. 6698 on the Protection of Personal Data ("KVKK"), the Regulation on Personal Health Data, the Regulation on Health Information Management Systems, and the relevant secondary legislation.

In the event of any conflict between the Terms of Use and this DPA with respect to the protection of personal data, the provisions of this DPA shall prevail.

1. Roles and Subject Matter

1.1. With respect to the personal data entered by the Clinic into the Platform or processed on the Platform ("Clinic Data"; including patient data), the Clinic is the Data Controller and the Company is the Data Processor (KVKK arts. 3 and 12).

1.2. The Company processes Clinic Data solely for the purpose of providing the Service and within the framework of the Clinic's documented instructions. The Company does not process Clinic Data for its own purposes; it does not sell, rent, or disclose the data to third parties for any purpose not contemplated in this DPA.

1.3. Special categories of data. Patient data (dental/health records, images, prescriptions) constitutes special categories of personal data within the meaning of KVKK art. 6 and personal health data within the scope of the Regulation on Personal Health Data. The enhanced measures of this DPA (Article 8) apply to the processing of such data.

2. Nature of the Processing Activity (Summary of Annex 1)

3. Obligations of the Data Controller (Clinic)

3.1. The Clinic warrants that the personal data it enters into the Platform has been obtained lawfully, that it has fulfilled the required duty to inform, and that, where required (in particular for health data), it has secured the appropriate legal basis (KVKK art. 6), including explicit consent.

3.2. The Clinic ensures that the instructions it gives to the Company are lawful.

3.3. The preparation, versioning, and presentation of the information notices addressed to patients and other data subjects are the responsibility of the Clinic. The Company provides the technical infrastructure within the Platform for versioned information-notice/consent management and for consent timestamping.

3.4. The Clinic is obliged to keep user authorizations (on a role/branch basis) up to date and to remove the access of departing staff without delay.

4. Obligations of the Data Processor (Company)

The Company shall:

4.1. Process Clinic Data solely in accordance with the Clinic's documented instructions; where a legal obligation requires otherwise, inform the Clinic (unless such notice is prohibited).

4.2. Ensure that its personnel who access the data are bound by a written confidentiality undertaking and apply the principle of least privilege.

4.3. Apply appropriate technical and administrative measures (see Article 8) within the scope of KVKK art. 12 and the Personal Data Security Guide.

4.4. Provide the Clinic with reasonable technical support in responding to data subjects' requests under KVKK art. 11 (access, rectification, erasure, portability) (see Article 12).

4.5. Assist the Clinic to a reasonable extent in data-breach, audit, and impact-assessment processes (see Articles 7 and 10).

4.6. Upon termination of the processing activity, return/export or delete/anonymize the data in accordance with Article 9.

4.7. Undertake that health data will not be transferred abroad and will be hosted solely in Turkey (see Article 6).

5. Sub-Processors

5.1. The Clinic generally consents to the Company's use of the sub-processors categorized below for the purpose of providing the Service:

5.2. The Company ensures that each sub-processor is subject, by written contract, to data protection obligations equivalent to those in this DPA, and remains liable to the Clinic for the activities of the sub-processors.

5.3. The current list of sub-processors is provided upon request. In the event of the addition or replacement of a sub-processor, the Company shall inform the Clinic a reasonable time in advance; the Clinic has a reasonable and justified right to object on data protection grounds. If the objection cannot be resolved, the Clinic may terminate its subscription within the framework of the Terms of Use.

5.4. No sub-processor may host or process health data outside Turkey.

6. Data Residency and Cross-Border Transfer

6.1. Domestic hosting commitment. All Clinic Data, including personal health data, is hosted and processed solely within the borders of the Republic of Turkey. This is not merely a commercial preference; it is a legal requirement under arts. 15-16 of the Regulation on Personal Health Data and art. 16 of the Regulation on Health Information Management Systems.

6.2. No cross-border transfer. The Company does not transfer personal health data abroad. Even where, for administrative/technical support purposes, a mandatory transfer of de-identified data not containing health data is at issue, such transfer is carried out only in accordance with the conditions prescribed by KVKK art. 9 (adequacy decision, undertaking, standard contractual clauses, etc.) and subject to prior notice to the Clinic; health data is excluded from this exception.

7. Data-Breach Notification

7.1. Upon becoming aware of a personal data breach affecting Clinic Data, the Company shall notify the Clinic (Data Controller) without undue delay. This notification shall be made within the shortest reasonable time so as to enable the Clinic to notify the Personal Data Protection Board within 72 hours (KVKK art. 12; Board decisions; by reference to art. 18/2 of the Regulation on Personal Health Data).

7.2. The notification shall contain reasonable information about the nature of the breach, the categories of affected data and data subjects, the estimated number of affected records, the likely consequences, and the measures taken or to be taken.

7.3. Notifications to be made to the Personal Data Protection Authority and to the data subjects are the responsibility of the Clinic in its capacity as Data Controller; the Company provides the necessary information, records, and log support in this process.

7.4. The Company maintains the audit trail (append-only audit log) and access records in a manner that supports such an investigation (see Articles 8 and 11).

8. Technical and Administrative Measures

In line with KVKK art. 12 and the Personal Data Security Guide, and having regard also to the special-category (health) nature of the data, the Company applies the following measures. The measures stated below as "applied" are already present in the Platform architecture; those stated as "targeted/on the roadmap" are commitments.

8.1. Technical measures currently applied

• Row-level tenant isolation (RLS — FORCE, fail-closed): A tenant_id is mandatory in every table; PostgreSQL Row-Level Security policies run in FORCE mode. If the session context is not set, no rows are returned (fail-closed). In a multi-tenant structure, this prevents at the architectural level one clinic's data from being seen by another clinic.
• Password security: User passwords are hashed with argon2id; plaintext passwords are not stored.
• Encryption in transit and at rest: Data transmission is via TLS; stored data and backups are encrypted. The Turkish ID number (TCKN) and sensitive fields are protected using a masking/encryption approach.
• Role-based access control (RBAC): Authorization is enforced at the API layer (Go); visibility restrictions in the interface are for user experience only and do not constitute security.
• Two-factor authentication (2FA/TOTP): Two-factor authentication is supported for accounts.
• Append-only audit log: Transaction and access records are kept immutably (append-only); access to health data is also logged.
• Session security: An opaque session key is held on the server side; it is reflected to the browser only as an HttpOnly + Secure + SameSite cookie; the session key is not exposed to JavaScript.
• Network isolation (loopback): The application that is the domain authority (the Go API) listens only on 127.0.0.1 (loopback) and is never directly exposed to the internet; the outside world sees only the thin front-end (BFF) layer.
• Sensitive-field masking: The TCKN and health data are masked in logs.
• Soft-delete and reversing entries: For patient-facing records, soft-delete (deleted_at) is applied instead of physical deletion, and reversing entries (void/refund) are applied for financial records.

8.2. Administrative measures

• Written confidentiality undertakings and awareness training for personnel;
• An authorization matrix and the principle of least privilege; removal of the access of departing staff;
• Subjecting sub-processors to equivalent obligations by contract, and their audit;
• Regular backups and a point-in-time recovery window of at least 7 days.

8.3. Roadmap / targeted measures

The following elements are on the development roadmap and are not yet presented as completed documentation/infrastructure commitments: TS ISO/IEC 27001 certification, deployment into production of a periodic (six-monthly) automated destruction job, regular penetration-test reporting, and full alignment of timestamped logging with SAMİLOG field mapping. The Company aims to bring these elements into effect within a reasonable timeframe.

For special-category (health) data, the additional measures prescribed by Board decisions and the requirements of arts. 18-20 of the Regulation on Personal Health Data are applied.

9. Data Ownership, Retention, Export, and Destruction

9.1. Data ownership. All Clinic Data processed on the Platform belongs to the relevant Clinic. The Company disposes of such data only in its capacity as Data Processor and solely for the purpose of providing the Service; ownership always remains with the Clinic. The Company does not claim any right of ownership or exclusive use over Clinic Data in its own name.

9.2. Retention periods by data category. Retention is determined on a data-category basis, based on the "Regulation on the Deletion, Destruction or Anonymization of Personal Data" (28/10/2017-30224) and sectoral legislation:

9.3. Periodic destruction. For data whose maximum retention period has expired and which is not under a legal retention obligation/legal hold, the Company adopts a periodic-destruction approach of once every six months (in the months of June and December). Running this periodic-destruction job automatically in production is on the roadmap within the scope of Article 8.3; until then, destruction is carried out in a controlled and documented manner.

9.4. Legal hold (suspension of period). Where an ongoing judicial or administrative investigation or audit review is at issue, the retention period of the relevant records is suspended; once the ground ceases to exist, the record is processed in the first periodic-destruction period.

9.5. KVKK erasure = anonymization. A physical hard-delete approach is not adopted in the system. Erasure requests under KVKK are met by "rendering inaccessible to the relevant user" and, once the maximum period has expired, by irreversible anonymization/destruction (in compliance with Regulation No. 30224).

9.6. Export upon request (at any time). During the Service or upon its termination, the Clinic may export all or part of its own Clinic Data at any time and in the format it requests (e.g. CSV, JSON, SQL/VIEW output). The Company fulfills this request within a reasonable time and without raising any additional obstacle. UDENTIVA does not practice "vendor lock-in."

9.7. Export via a legislation-compliant VEM View. The export of health data is provided within the framework of data portability prescribed by art. 14 of the Regulation on Health Information Management Systems, through database VIEW schemas compliant with the Minimum Data Model (VEM) ("VEM View"). The Company has established and maintains a read-only, tenant-locked Export API infrastructure capable of producing Clinic Data in these standard outputs; thus the Clinic can obtain its data in a legislation-compliant format for the purposes of audit, provider change, portability, or official notification.

9.8. Handover at the end of the contract. Upon termination of the contract, the Company shall ensure the handover of the data in its original/standard format and as a VEM View within a reasonable export window. At the end of this window, the Company shall — subject to statutory retention obligations — delete or anonymize Clinic Data and its backups within a reasonable time, and shall provide the Clinic with written confirmation upon request.

10. Right to Audit

10.1. The Clinic (Data Controller) has the right, upon reasonable notice and no more than once per year (save in cases of breach/suspicion), to audit, or have an independent auditor audit, compliance with this DPA and with KVKK art. 12.

10.2. In place of or in addition to an audit, the Company cooperates to a reasonable extent by providing independent audit reports, certificates (where available), penetration-test summaries, or written information.

11. Logging and Traceability

11.1. The Company keeps access and transaction logs in an append-only (immutable) manner.

11.2. In line with art. 17 of the Regulation on Health Information Management Systems (the SAMİLOG approach), access/transaction logs are, as a rule, retained for at least 5 years. Synchronization of the logs to a single time source, their timestamped signing, and full alignment of the SAMİLOG field mapping are on the roadmap within the scope of Article 8.3.

12. Data Subject (Patient) Rights

The Company provides the Clinic with reasonable technical support in responding to requests from data subjects under KVKK arts. 11-13 (access, rectification, erasure/destruction, restriction of processing, data portability). Requests that reach the Company directly from data subjects are directed to the Clinic to be answered in its capacity as Data Controller.

13. Liability

The liability of the parties under this DPA is subject to the limitations of liability set out in the Terms of Use. The parties' own legal responsibilities before the KVKK and health legislation are reserved.

14. Relevant Legislation

• Law No. 6698 on the Protection of Personal Data (KVKK): https://www.mevzuat.gov.tr/mevzuat?MevzuatNo=6698&MevzuatTur=1&MevzuatTertip=5
• Regulation on Personal Health Data (Legislation No. 32610): https://www.mevzuat.gov.tr/mevzuat?MevzuatNo=32610&MevzuatTur=7&MevzuatTertip=5
• Regulation on Health Information Management Systems (Legislation No. 39682): https://www.mevzuat.gov.tr/mevzuat?MevzuatNo=39682&MevzuatTur=7&MevzuatTertip=5
• Regulation on the Deletion, Destruction or Anonymization of Personal Data (28/10/2017-30224): https://www.mevzuat.gov.tr/mevzuat?MevzuatNo=23391&MevzuatTur=7&MevzuatTertip=5
• Personal Data Security Guide (KVKK): https://www.kvkk.gov.tr/