Personal Data Protection Notice — English (KVKK)

PERSONAL DATA PROTECTION NOTICE UNDER LAW NO. 6698 ("KVKK")

Data Controller: Fatih Acı Contact: fatihaci79@gmail.com Date: 12/10/2026

This notice has been prepared pursuant to Article 10 of the Personal Data Protection Law No. 6698 of the Republic of Turkey ("KVKK").

Data Controller / Data Processor Distinction. maShop (Fatih Acı) acts as a data controller for the data it collects for authentication, subscription and device management. By contrast, with respect to the customer, supplier and personnel personal data that users enter into the app themselves, maShop acts as a data processor within the meaning of Art. 3 KVKK; the data controller for such data is the user who manages the relevant store account. The obligations to provide a privacy notice, establish a lawful basis and respond to data subject requests for this third-party data belong to the user; maShop stores/processes such data solely on the user's behalf and under their instructions, and does not use it for its own purposes. The instructions and terms for this processing are set out in the User Agreement and this notice; as a data processor, maShop takes the necessary technical and administrative measures under Article 12 of KVKK.

1. Personal Data Processed and Purposes of Processing

The maShop application may process the following personal data:

Data NOT processed: Payment card information, bank account, location data, contacts, photo/media; also crash reporting — no crash reports, app logs or screenshots are collected from your device. App usage analytics, however, is OFF by default; it is collected to a limited extent only if you enable it in Settings, and is set out in the table above. Payment transactions take place exclusively via the Google Play / App Store infrastructure; card/bank information is not transmitted to us.

Important: Transaction data stored under synchronisation and backup is kept on our own server in Turkey (Muğla) while server backup is on and is not transferred abroad; while server backup is off, this data is never sent to the server (Section 6). However, the servers of essential infrastructure providers such as Google and Apple are located abroad (USA / EU); transfers to such providers are detailed in Section 2.

2. Parties to Whom Personal Data Is Transferred (Including Cross-Border Transfers)

The servers of the following service providers are located abroad (USA / EU); a limited part of your personal data is transferred abroad under Article 9 of KVKK. Important notice: These global providers (Google, Apple) do not sign the standard contract of the Personal Data Protection Board (KVKK); instead they apply their own international data processing terms and transfer commitments. We have not filed any standard contract with the Board. The transfer takes place within the scope of a mandatory infrastructure service required for the app to function, and, for optional processing such as advertising, on the basis of your explicit consent:

Personal data is not shared with third parties for commercial purposes. The advertising provider (AdMob) processes only limited technical data to serve non-personalized ads; no profiling/behavioral targeting is performed and personal data is not sold for advertising purposes.

Potential risks of cross-border transfer (KVKK Art. 9/6-a): In the country to which your data is transferred there may not be a level of data protection equivalent to KVKK, and it may become more difficult for you to exercise your rights as a data subject. Non-mandatory transfers (e.g. advertising) rely solely on your explicit consent, which is asked separately each time; an ad request is made only when you choose Watch an ad. To withdraw your consent, simply do not choose the ad the next time; withdrawal takes effect for the future. Transfers that are mandatory for the service to function, such as login and notifications, are necessary for you to use the app.

Domestic storage: The synchronised copy and backups of your transaction data are kept on our own server in Turkey (Muğla) and are not transferred abroad. Details: Section 6.

2.1 Anonymised and Aggregated Data

maShop may make use of anonymised and aggregated data in order to improve the service and to produce sector benchmarking and recommendation features.

Anonymisation means rendering the data such that it can no longer be associated in any way with an identified or identifiable natural person. In this context the user name, email address, business name, customer/supplier/personnel names and account identifiers are removed; the data is used only in groups containing a sufficient number of accounts (for example, "average profit margin by product group"). Aggregation is never carried out at a level that would allow an individual account, business or person to be distinguished.

The daily totals kept to operate and plan the service (numbers of accounts and users, numbers of active users, plan distribution, platform and major operating-system version distribution, activation rate and similar) also fall under this section: they contain no account or personal identifier, values based on fewer than 5 accounts are not kept separately, and the activation rate is calculated over 7-day and 30-day periods rather than per day.

Anonymised data loses its character as personal data within the meaning of Law No. 6698 and therefore falls outside the scope of the Law (Art. 3/1-b definition, Art. 7/3). As anonymisation is irreversible, requests for erasure of or access to such data cannot be fulfilled; however, all of your rights under Section 4 remain fully applicable to your personal data prior to anonymisation.

Your raw transaction data (sales, purchases, expenses, customer, supplier and personnel records) is processed only to provide the service to you (storage, synchronisation, backup); it is not used for any other purpose, including model training, without anonymisation, and is not transferred to third parties. Record contents are not viewed in support or security reviews. The content-free audit trail showing which user changed your records and when is examined only in the context of a related support request or security incident; the technical trace of records not accepted during synchronisation (submission rejection trace) is used to detect and fix submission errors (Section 1).

2.2 Sub-Processors and Hosting

Hosting. The synchronised copy and backups of your transaction data are kept on maShop's own server (Turkey, Muğla); no third-party cloud provider or sub-processor is used for hosting.

Sub-processor list. The table in Section 2 is the current list of the sub-processors (service providers) used by maShop. Where a new sub-processor is added to the list, this notice is updated without undue delay and the change is announced by in-app notification; where the change expands the scope of processing, your explicit consent is obtained again.

3. Method of Collection and Legal Basis

Your personal data is collected via your login and registration actions within the app, Google or Apple Sign-In (OAuth) and automatic system records (Firebase and our own server's records).

Legal bases:

• KVKK Art. 5/2-c (conclusion and performance of a contract) + Art. 9/6-b (cross-border transfer): The core function of the app, the cross-device synchronisation and backup service, the delivery of in-app notifications and the verification of your subscription (RevenueCat) fall under this basis. Only your in-app user identifier and subscription status are transferred to RevenueCat; this transfer is necessary so that we can grant you the entitlements (seat count, feature access) of the subscription you purchased. Your name, email address and payment details are not transferred. Device information (including monitoring whether the app version you use is compatible with the service), your feedback and support requests, and the content-free technical trace of records not accepted during synchronisation (submission rejection trace) also fall under this basis; the submission rejection trace is not used to evaluate users' performance or behaviour and is not shared with third parties.
• KVKK Art. 5/2-ç (compliance with a legal obligation — data security under KVKK Art. 12) — server records (logs) and administrator action record: Server records and the access records at the server entry point kept to secure the service and detect errors, and the record of administrative actions taken on your account, fall under this basis (periods: Section 5).
• KVKK Art. 5/2-e (establishment, exercise or protection of a right) — deletion proof record: The proof record kept so that the deletion of your account can be demonstrated later falls under this basis (5 years, Section 5).
• KVKK Art. 5/1 (explicit consent) + Art. 9/6-a (cross-border transfer): The non-personalized, opt-in rewarded ads (Google AdMob) shown to sustain the free plan, and the associated cross-border transfer, rely on your explicit consent; as the ads are not personalized, no profiling is performed. Before you choose, the in-app choice window briefly shows that the ad is served by Google, the data transferred (advertising identifier and approximate region) and the risk of the cross-border transfer. Watching an ad is your choice each time; if you do not choose it, no ad is shown and no ad request is made. To withdraw your consent, simply do not choose the ad the next time. Paid plans are available for ad-free use.
• KVKK Art. 5/1 (explicit consent) — usage analytics: Limited usage analytics (Firebase Analytics) measuring which parts of the app are used is OFF by default and is collected only if you enable it in Settings. While the preference is off, the analytics infrastructure is never initialised at app start-up; no event is sent at all, including session start and screen views. You may switch it off again at any time. No interest profile is built, it is not used for ad personalization and it is not shared with third parties for commercial purposes. Crash reporting is not collected.
• KVKK Art. 5/1 (explicit consent) — personalised insights (optional): Producing insights and recommendations specific to you from data belonging to your own account. This processing takes place only if you give separate and express consent; the consent prompt will be shown separately in the app when the relevant feature is released. Declining does not restrict any feature of the service and you may withdraw your consent at any time. No other user's data is used for this purpose; cross-account comparisons are produced solely from the anonymised data described in Section 2.1.
• KVKK Art. 5/2-ç (compliance with a legal obligation) + Art. 5/2-e (establishment, exercise or protection of a right) — record of your server-backup preference: Your choice to turn server backup on or off, the date of that choice and the version of the notice shown to you at the time are recorded. This record is kept in order to meet our data security and accountability obligations under KVKK Art. 12 and to be able to demonstrate, at a later date, your choice and the information given to you. It does not rely on explicit consent and is not among the data deleted when backup is turned off (Section 5). Privacy notice acknowledgement records are kept on the same basis, to demonstrate that the obligation to inform (KVKK Art. 10) has been fulfilled.
• KVKK Art. 5/2-c (performance of the contract) + Art. 5/2-e (establishment, exercise or protection of a right) — announcement read record: Important announcements, such as price and contract changes, are shown to you when the app opens; when you tap "Got it", the announcement, the time, the platform and the app version are recorded. This record is kept so that we can demonstrate, at a later date, that the notice reached you; it does not rely on explicit consent.

4. Your Rights as a Data Subject (KVKK Article 11)

Pursuant to Article 11 of KVKK you have the following rights:

• To learn whether your personal data has been processed
• To request information about processing, if any
• To learn the purpose of processing and whether the data is used in accordance with that purpose
• To know the third parties, in Turkey or abroad, to whom the data has been transferred
• To request correction if the data has been processed incompletely or incorrectly
• To request the deletion or destruction of your data within the framework of the conditions set out in Art. 7 of KVKK
• To request that correction, deletion or destruction be notified to third parties to whom the data has been transferred
• To object to a result against you arising from the analysis of the data exclusively by automated systems
• To claim compensation for damage suffered as a result of unlawful processing

Download My Data (convenience): Active users and users within the recovery (grace) period may obtain a machine-readable copy of their account information and the transaction data they entered via the in-app Download My Data button in JSON format. This file does not include the feedback you have sent or technical records such as device records, consent and announcement read records, audit records, the administrator action record, server records (logs) or the submission rejection trace. You may send a request for information about all personal data processed about you, including these, to the address below; after access has been fully removed, requests are also made by email.

Application: You may apply by email to fatihaci79@gmail.com. Applications are answered within 30 days.

5. Data Retention Periods

• Transaction data (device): Until you delete it from your device
• Transaction data (server copy): For as long as your account remains open; permanently deleted upon an account deletion request (at the end of the 30-day grace period) or after 365 days of inactivity (see "Inactive account" below)
• Deleted record marker (tombstone): When you delete a record, it is kept marked as "deleted" on the server for 30 days so the deletion can propagate to your other devices, then permanently removed; during this period the record is not displayed and is excluded from reports
• Google Sign-In: Until the account is closed
• Apple Sign-In: Until the account is closed. When an account deletion request is made, Apple's auth/revoke endpoint is called at the end of the 30-day grace period and the app is removed automatically from "Apps Using Apple ID" in your Apple ID settings. The same call is made when the account is deleted due to inactivity; in both cases your maShop sign-in record (Firebase identity) is also deleted.
• Firebase log data: According to Firebase policy (typically 90 days)
• Push notification token: Deleted from our server when you log out or when your account is deleted
• Personnel / commission data: For as long as the account remains open (subject to the same rules as transaction data)
• Account deletion request: A 30-day grace period after the request; at the end all account data (personal + transaction) is permanently deleted
• Inactive account: If no active user of the account signs in for 365 days (1 year), the account and all its data are permanently deleted. For this rule, "signing in" means opening the app, or bringing it to the foreground, while connected to the internet; if your session is open you do not need to sign in again. When about 335 days have passed since the last sign-in, the account enters a warning stage and a push notification is sent to the account's active users; the notification may not reach you if notification permission is off, the session has been signed out, the device has changed, or the operating system has suspended apps that have not been used for a long time. The account is not deleted until at least 30 days have passed since the warning stage began; signing in during this period stops the deletion and restarts the period. Accounts with an active paid subscription are not deleted under this rule while the subscription continues; after the subscription ends, deletion can take place only after the same warning and waiting period. The app does not send notifications by email
• Deletion proof record: When an account is deleted (on request or due to inactivity), the account identifier, an irreversible digest of the account holder's email address generated with a secret key (the plain email address is not stored), the request and deletion dates, the number of deleted records and the reason for deletion are kept for 5 years so that the deletion can be proven (KVKK Art. 5/2-e); it contains no transaction content
• Security audit log: 365 days, then automatically deleted
• Feedback and support requests: Requests marked "completed" are automatically deleted 1 year after they were created; open requests and requests under review are kept while your account remains open. They are deleted immediately when your account is deleted or when your membership of the account ends and your personal data is destroyed. They are not deleted when server backup is turned off
• Privacy notice acknowledgement records: Kept until your account is deleted or, when your membership of the account ends, until your personal data is destroyed. They are not deleted when server backup is turned off
• Submission rejection trace: The technical trace of a record not accepted during synchronisation is automatically deleted 90 days after that record was last rejected; when the account is deleted (at the end of the grace period or due to inactivity) it is deleted together with the account's other data
• Server records (logs): The application server's records are automatically deleted after 30 days and the access records at the server entry point after at most 15 days; structured error records that cannot be associated with a person or an account are automatically deleted after 90 days
• Device records: Until your membership or your account is deleted; records of devices that have been disconnected are also kept for this period
• Administrator action record: 365 days, then automatically deleted; deleted together with the account's other data when the account is deleted
• Announcement read record: For as long as your account remains open; permanently deleted together with the account upon account deletion (at the end of the 30-day grace period) or inactivity deletion
• When server backup is turned off: The transaction-data copy on the server and the audit records relating to that data are permanently deleted 30 days after the date you turned backup off (the deletion job runs once a day, so deletion takes place after the 30 days have elapsed). They are not deleted if you turn backup back on within that period. Security audit records of account management events remain subject to the 365-day rule (Section 6.1). Your account, membership, device, subscription and consent records, your push notification token, the feedback you have sent, any partnership share/period records, your announcement read records and the record of your server-backup preference are not deleted; nor is the submission rejection trace deleted when backup is turned off — it is deleted automatically once its 90-day period has elapsed
• System backups: Data that has been permanently deleted may remain in our server's system backups until it ages out of the backup rotation schedule (daily / weekly / monthly tiers; longest tier 12 months). These backups are accessed for disaster recovery purposes only; they cannot be viewed through the app and are not used in ordinary processing activities. This rule applies to all deletions, including account deletion
• No retention such as 10 years is applied for commercial records (the Article 82 TCC obligation belongs to the user)

6. Synchronisation, Backup and Multi-User Services

Synchronisation and Backup (on by default):

• Your transaction data is stored primarily on your device and, by the nature of the service (preventing data loss on device change, multi-user / multi-device synchronisation, backup), is synchronised by default with our own server in Turkey (Muğla) over an encrypted connection (HTTPS/TLS); the server-side copy is backed up regularly to separate storage units (Section 7).
• Data is not transferred abroad; KVKK Art. 9 cross-border transfer does not apply to this storage.
• Server-side data is subject to the retention rules in Section 5 (permanently deleted upon an account deletion request or after 365 days of inactivity).

Turning server backup off. A Primary Account Holder who uses the account alone on a single device may turn server backup off under Settings → Backup. While backup is off, your transaction data is not sent to the server and is held only on your device; if the device is lost or damaged, the app is uninstalled, or the session is signed out, this data cannot be recovered and does not transfer to a new device on its own (you can export it to a file at any time via Settings → Download My Data). Server backup must be on in order to invite an employee/partner or to use a second device. The deletion rule for the existing copy on the server is set out in Section 5; the record of your preference is explained in Sections 1 and 3.

Multi-User (invited partner / employee):

• The primary user may invite another user by sharing an invitation link via WhatsApp / SMS.
• The invited user accesses the same store account and works in sync (full or restricted access depending on their role).
• A user in the Employee role only sees their own sales records and commission calculation; they cannot see the store's total turnover or purchase prices.
• Before accepting the invitation, the invited user is shown this KVKK notice in the app and their acknowledgement is recorded; data sharing through the invitation link is approved at that point.

Termination of Working Relationship and Data Requests (2026-05-21):

• The primary user (store owner) may terminate the access of an invited user in two ways:
  1. Standard termination: Access is restricted to their own sales history and own payment/receivable balance (read-only) for 14 days. At the end of 14 days the account is closed entirely.
  2. Immediate termination: Access is cut off at the same moment (for cases such as fraud or theft).
• In addition, when the primary user's subscription ends, the system automatically closes the invited user's access after 14 days; if the subscription is renewed within this period, access is reopened.
• Data entered into the app by the user whose access was terminated (sales they have made, commission records kept under their name) is not deleted; it is retained as sales history in the store owner's reports — this falls under KVKK Art. 5/2-c (mandatory record arising from the performance of a contract).
• Personal data request (KVKK Art. 11): A user whose access has been terminated may apply by email to the data controller address above to request information about and a copy of their personal data (sales records, commission calculation, payment history), to request its correction if it has been processed incompletely or incorrectly, to request its deletion or destruction within the framework of Art. 7 of KVKK, or to exercise the other rights set out in Section 4. Requests are answered within 30 days.

6.1 Partner Role and Asymmetric Authority (as of V1.0)

The maShop account has a multi-user structure consisting of the Primary Account Holder (founder) who created the account and the Partner / Employee role users they have invited.

Allocation of Authority:

• Primary Account Holder: All authority over account deletion, subscription cancellation, ownership transfer, removal of other users and adjusting their permissions rests entirely with this user.
• Partner: Equivalent data access to the owner (sales, purchases, expenses, customers, products); no account management authority.
• Employee: Access only to records of their own sales; analytics, personnel and account management are closed.

Data Visibility and Responsibility:

Users in the Partner role have access to all commercial data within the account (past and future) from the moment the invitation is accepted. This access starts with the consent of the Primary Account Holder and may be restricted or terminated at any time.

Users in the Employee role have access only to records of their own sales and their own commission report.

Account Deletion and Notification:

When the Primary Account Holder requests account deletion:

• The account enters soft delete (pending deletion confirmation) status and a 30-day grace period begins.
• An in-app push notification is sent to active partner and employee users of the account.
• During this period the Primary Account Holder may withdraw the deletion request.
• When 30 days have passed, all account data is permanently deleted (hard delete).

In addition, if no active user of the account signs in for 365 days, the account is permanently deleted due to inactivity; the definition of "signing in", the prior notification, the waiting period of at least 30 days and the exemption for accounts with an active paid subscription are set out in Section 5. A sign-in by any active user within this period restarts the period. In no case does maShop continue to store deleted data on the user's behalf.

If partners or employees suffer data loss as a result of account deletion, they must direct their claims to the Primary Account Holder; maShop assumes no liability in this regard.

Conflict of Data Subject Rights (KVKK Art. 11):

A user's request to have their personal data deleted under KVKK Art. 11 is evaluated independently of any objections by other users (partner or employee). When an employee/partner is removed from an account, the transaction records they entered are retained as part of the store owner's records (KVKK Art. 5/2-c — mandatory record arising from the performance of a contract); this does not mean maShop retains the data "for 10 years under Article 82 TCC" — no such retention is applied. When the Primary Account Holder deletes the entire account, all data including commercial records is permanently deleted from the server at the end of the grace period; only the deletion proof record that demonstrates the deletion remains (its content and retention period: Section 5).

Audit Log Retention:

Security audit records of account management events (invitation, acceptance, role change, removal, account deletion) are retained for 365 days (1 year) for the purpose of KVKK Art. 12 accountability and security, then automatically deleted. They are not intended for commercial document retention.

Audit records relating to your transaction data (sales, purchases, expenses, products and similar records) follow the same rule as that data: if you turn server backup off, they are deleted together with the transaction data after 30 days (Section 5). Records of account management events are unaffected and complete the full 365-day period.

Communication Channel:

Account management notifications (deletion, removal, permission change, inactivity warning) are delivered as in-app push notifications; the app does not send notifications by email. Push notifications may not arrive if notification permission is off or the session has been signed out; you are therefore advised to open the app regularly for critical notifications.

7. Data Security Measures

Technical and administrative measures taken under KVKK Art. 12:

• Encryption in transit: All traffic between the app and the server is encrypted with HTTPS (TLS); certificates are renewed automatically
• Network security: The server's firewall rejects incoming connections by default; only the web ports (80/443) are open to the internet
• Administrative access: Administrative access to the server (SSH) is possible only from the developer's device, with a cryptographic key rather than a password, and only over the local network or an encrypted private network (VPN); no administrative port is open on the router
• Administration screen: Only the developer can access the service's administration screen, only over an encrypted private network (VPN) and with authorisation verified on the server side; the content of your transaction records is not shown on this screen and every administrator action is recorded
• Rate limiting: The server applies per-user and per-IP request limits to restrict abuse and brute-force attempts
• Backup: The database is backed up hourly and daily to two separate storage units (one of them on a separate device); backup completion is monitored automatically and restoration is tested periodically
• Data breach notification: Notification to the Authority and affected data subjects within 72 hours under KVKK Art. 12/5

This notice was last updated on 12/10/2026. With this update it is made clear that push notification content consists only of plain text, the notification type and record/account identifiers and contains no person names, amounts or currencies, and that Apple (APNs) is a recipient for iOS notification delivery. This is not an expansion of the scope of processing — notification delivery was already in effect and was incompletely described in the text (earlier notifications also carried person names, amounts and currencies; that content was removed by a server change); the notice version is retained as v6. The retention period of the deletion-proof record was also shortened from 10 years to 5 years (a narrowing in the user's favour). The previous update is dated 07/10/2026 and contained the following: (1) The ability for the user to turn server backup off was added, and the data processed (Section 1), legal bases (Section 3), retention periods (Section 5), synchronisation and backup (Section 6) and the audit record period (Section 6.1) were corrected accordingly. In this change the purposes of processing, its recipients and the categories of data have not changed; the scope of processing has only narrowed, and only at the user's own choice. (2) An announcement read record was added to evidence that notices such as price and contract changes have reached the user (Sections 1, 3 and 5); this is a new purpose of processing. (3) The incorrect statement that ad consent can be withdrawn from the app settings was corrected (Sections 2 and 3): the app has no such setting; ad consent is obtained separately for each ad, and to withdraw it it is enough not to choose the ad the next time. Before the choice, the ad choice window briefly shows who serves the ad, the data transferred and the risk of the cross-border transfer. This is not an expansion of the scope of processing. (4) The deletion due to inactivity rule was explained as it actually operates (the meaning of "signing in", the notification channel and its limits) and two safeguards were added in the user's favour: no deletion before the warning stage has begun and at least 30 days have passed since then, and an exemption for accounts with an active paid subscription; the forward-looking commitment to notify by email has been removed (Sections 5, 6.1). (5) The content, legal basis and retention period of the deletion proof record are now stated correctly (Sections 3, 5, 6.1). (6) Device information (including the app version used on the device), server records (logs) and the access records at the server entry point, feedback and support requests, privacy notice acknowledgement records and the administrator action record, all already in effect, were added to the data processed, the legal bases and the retention periods (Sections 1, 3, 5); the app began sending its version and platform to the server with every request with version 2.1.9 (05/10/2026). (7) The request rights of a user whose access has been terminated were restated in the terms of KVKK Art. 11 (Section 6) and the list of data subject rights was aligned with Article 11 of the Law (Section 4). (8) The anonymity conditions for daily totals and the limits on the use of raw transaction data and technical traces were explained (Section 2.1). (9) The content-free submission rejection trace for records not accepted during synchronisation (90 days) was added (Sections 1, 3, 5); recording of this trace begins 30 days after the change is announced in the app (Terms of Service, Article 6.1). A retention rule for feedback has been set: completed requests are deleted 1 year after they were created (Section 5). (10) The access safeguard for the administration screen was added to the data security measures (Section 7). The notice version has been retained as v6. Article 5/1(b) of the Communiqué on the Procedures and Principles to be Followed in Fulfilling the Obligation to Inform (Official Gazette 10/03/2018, no. 30356) requires that, where the purpose of processing changes, the obligation to inform be discharged separately for that purpose before the processing; with respect to (2), this is discharged by publishing this updated notice and by an in-app notification. The update is also required by subparagraph (j) of the same article, which prohibits incomplete or misleading information. (5) and (6) correct the incomplete or incorrect disclosure of processing already in effect (precedent of 29/08/2026); keeping the app version in the device record is not a new category of data — this information is already processed in notification, feedback and acknowledgement records — and serves device management and the secure and compatible operation of the service. The submission rejection trace is not a new purpose of processing but a content-free technical record kept to perform the existing synchronisation and backup service (KVKK Art. 5/2-c); and the inactivity safeguards and subscription exemption only limit processing in the user's favour. The option considered and rejected: raising the notice version to 7 and asking all existing users to consent again — this was found unnecessary given that there is no expansion in the scope of processing in (1), (3) and the corrections, that the record in (2) relies not on explicit consent but on Art. 5/2-c and Art. 5/2-e and is created only when the user confirms having read the announcement, that v6 consent was obtained on 09/09/2026, and that consent or approval should not be requested for a privacy notice, only feedback that it has been read (Personal Data Protection Board principle decision no. 2026/347 of 18/02/2026, Official Gazette 24/03/2026, no. 33203). The changes other than the submission rejection trace are not treated as a material change within the meaning of Article 6.1 of the Terms of Service: turning server backup off is optional and the default behaviour is unchanged; the announcement read record serves only to evidence the notice given to the user; the corrections describe processing already in effect accurately and the inactivity safeguards are in the user's favour; pricing principles and limitations of liability are unaffected, and no new obligation is imposed on the user. The submission rejection trace has been treated as a material change and made subject to the 30-day period above. The previous update is the correction dated 24/09/2026: the data security measures (Section 7) were updated to reflect the actual position; statements that could not be verified were removed and the measures actually applied were set out in detail. The statements on transfer/backup encryption in Sections 1 and 6 were aligned accordingly. As the purposes of processing, data categories and recipients have not changed, the notice version remains v6. The previous update is dated 09/09/2026 (v6): Section 2.1 Anonymised and Aggregated Data and Section 2.2 Sub-Processors and Hosting were added, and the legal basis for usage analytics was corrected from legitimate interest to explicit consent, expressly declaring that it is OFF by default. As Section 2.1 expands the scope of processing, the notice version was raised to v6 and existing users were asked to give their consent again. The previous update is dated 29/08/2026: RevenueCat (subscription verification infrastructure, USA) was added to the transfer table and the app usage analytics disclosure was corrected to reflect the actual position. This is not an expansion of the scope of processing — both processing activities were already in effect and had been incompletely/incorrectly disclosed; the notice version therefore remains v5. The previous update is dated 27/07/2026 (correction of the contact/application address; the notice version remains v5 — the scope of processing has not changed). The v5 changes are dated 01/07/2026 (legal correction of the Article 9 cross-border transfer basis under KVKK: express declaration that no standard contract has been filed with the Board, explicit consent for AdMob, cross-border transfer risk notice, merchant-of-record framing for the Store, and alignment of Firebase telemetry). In the event of changes to our policy, this page will be updated and an in-app notification will be issued.