Data Processing Agreement

Article 1 — Parties, subject matter and roles

1.1. This agreement forms part of D-06 · Service Agreement (SaaS Subscription). Parties: the Customer (the «Controller») and Topluyıldız Danışmanlık A.Ş., with its registered office in Türkiye (the «Processor»).

1.2. ROLES. (a) For the personal data of third parties in the records that the Customer enters into or uploads to mybusyness, the Customer is the Controller and Topluyıldız is the Processor (Article 28 GDPR). (b) For the Customer's account, subscription and invoice data, Topluyıldız is itself the controller; this data does not fall under this agreement but under D-02.

1.3. The Processor processes personal data only on the documented instructions of the Controller and within this agreement. It does not process the data for its own purposes, does not sell it and does not pass it on to third parties for marketing purposes.

Article 2 — Description of the processing

Article 3 — Obligations of the Processor

The Processor:

1. processes personal data only on the Controller's instructions; if it is required by law to deviate from them, it informs the Controller beforehand, unless the law prohibits this;
2. informs the Controller without delay if it considers an instruction to be unlawful;
3. ensures that persons with access are bound by confidentiality, and limits access to what is needed for their duties;
4. takes the technical and organisational measures under Article 4 (Article 32 GDPR);
5. assists the Controller with requests from data subjects (Article 6);
6. reports personal data breaches under Article 7;
7. does not use the data under this agreement for its own product development or to train models;
8. proceeds under Article 9 when the agreement ends;
9. allows audits under Article 8.

Article 4 — Technical and organisational measures

The Processor applies at least the following measures and does not weaken them:

4.1. Masking (COPAI). Before every external model call, Turkish identity number, AHV number, BSN, IBAN (each with check-digit validation), telephone, e-mail, tax number, card number and key-like strings are masked.

4.2. Routing by confidentiality class. Content is assigned to classes D0–D5. D0–D2 may go masked to the cloud, D3–D4 only to a local model, D5 to no model. If there is no local model, a visible error appears; there is no silent switch to the cloud.

4.3. Mask vault. The link between placeholder and original value is stored encrypted and destroyed after 24 hours.

4.4. Tenant isolation. On every read and write, the server checks the business identifier and the membership. Permissions cannot be raised from the browser.

4.5. Permissions. Access is limited by role (General Manager / department) and by department.

4.6. Key vault. Access keys that the Customer enters for external services are stored with envelope encryption (a separate key per record, a versioned master key, identity-bound verification data), pass through a single decryption gate, are not shown again, are not logged and are never handed to the virtual collars.

4.7. Audit trail. Every action is written to a record that is linked by a hash chain and has no way to be changed or deleted.

4.8. Lock in code. Money transfers and the submission of tax filings are structurally locked for virtual collars.

4.9. Transmission security. All external connections are encrypted; on the server side, address pinning, timeouts and rate limits apply.

4.10. Logging. The server access log never stores the query string; IP addresses are stored masked or as a salted hash.

4.11. Backup. Backups are made regularly; they are subject to the same security and retention rules and also remain in the Netherlands.

4.12. Fail-visible. If a security or boundary check fails, this is not passed over silently; a visible error appears.

Article 5 — Sub-processors

5.1. The Controller gives a general written authorisation for the following sub-processors:

5.2. The Processor concludes a written agreement with every sub-processor imposing at least equivalent obligations and is liable to the Controller for the sub-processor's acts as for its own.

5.3. CHANGES. The addition or replacement of a sub-processor is communicated to the Controller at least 30 days in advance. If the Controller objects within this period on reasonable grounds, the parties look for a reasonable solution; if none is found, the Controller can terminate the service concerned or the agreement without compensation.

Article 6 — Assistance with data subject requests

6.1. If a data subject contacts the Processor directly, the Processor does not answer the request on the merits but forwards it without delay to the Controller and informs the requesting person of this.

6.2. The Processor provides the technical assistance for access, rectification, erasure, data portability and objection to automated individual decisions, and handles the request within 10 days, so that the Controller can meet the period of one month (Article 12(3) GDPR).

6.3. HOW ERASURE REQUESTS ARE MET. For most records, destruction means reduction rather than erasure: the row remains, but the raw personal data in it is replaced by a masked summary and cannot be recovered. Entries in the audit trail are not erased, as they are kept as proof and because of legal obligations. Whether this approach meets a specific erasure request is assessed case by case with the Controller.

Article 7 — Personal data breaches

7.1. The Processor notifies the Controller in writing of a personal data breach within 24 hours of becoming aware of it.

7.2. The notification contains at least: the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, the measures taken and proposed, and a contact point.

7.3. The Processor provides all the information needed for the Controller's notification to the Autoriteit Persoonsgegevens, which must be made without undue delay and, where feasible, within 72 hours (Article 33 GDPR), and for the communication to the data subjects (Article 34 GDPR).

7.4. The Processor takes measures without delay to remedy the breach and to prevent it from happening again, and reports on them in writing.

7.5. The breach is also recorded in the audit trail.

Article 8 — Audits

8.1. Once a year, with written notice of at least 15 days, the Controller can check, or have an independent auditor check, whether the obligations under this agreement are being met.

8.2. The audit is carried out in such a way that no access to other customers' data arises and operations are not disrupted. The auditor undertakes to keep matters confidential.

8.3. Instead of an audit, the Processor can provide current security and compliance reports; if the Controller considers them insufficient, it can exercise its right under 8.1.

8.4. The Controller bears the reasonable costs of more than one audit per year. An audit following a personal data breach does not count towards this limit.

Article 9 — End of the agreement

9.1. After the agreement ends, the Controller can export its data for 30 days.

9.2. After that, the Processor destroys or reduces the personal data.

9.3. Records that must be kept under statutory retention periods, and the audit trail, are excluded from destruction; they are kept only for retention purposes and with restricted access.

9.4. On request, the Processor confirms the destruction in writing.

Article 10 — Transfers outside the European Union

10.1. Every transfer outside the European Union is based on D-08 · International Data Transfers and on the safeguards of Chapter V GDPR, in particular the Standard Contractual Clauses adopted by Commission Implementing Decision (EU) 2021/914 of 4 June 2021. Without these safeguards, no transfer outside the European Union takes place.

10.2. The Processor transfers personal data only to the recipients and to the countries listed in D-08.

Article 11 — Liability

11.1. The Processor is liable for compliance with the obligations under this agreement and under the GDPR.

11.2. The limitation of liability under D-06 · Article 11.3 does not apply to fines and compensation imposed on the Controller because of a breach of this agreement by the Processor.

11.3. Claims against the Processor that are based on an unlawful instruction or an unlawful entry of data by the Controller are borne by the Controller.

Article 12 — Governing law and precedence

12.1. This agreement is governed by Turkish law; jurisdiction as set out in D-06 · Article 15.2. Mandatory Dutch and European Union data protection law, in particular the GDPR, remains unaffected.

12.2. In the event of a conflict between this agreement and D-06 on matters of data protection, this agreement prevails.

12.3. This agreement enters into force together with the Service Agreement and applies for as long as personal data is processed.

12.4. Please send questions about this agreement to sales@mybusyness.com.

Entry into force: 2026-09-25 · Version v1.0

This document describes the behaviour of mybusyness as measured in the code. This is not legal advice.