CORENTA — ПОЛІТИКА ЗБЕРІГАННЯ ТА ЗНИЩЕННЯ ДАНИХ

Цей переклад надано лише для інформації; юридично обовʼязковим є текст турецькою мовою.

Видалення клієнта без облікового запису: дія «Видалити», виконана адміністратором клініки, вважається запитом; запис негайно вилучається з активного списку, а через 30 днів ідентифікаційні/контактні дані та поля здоровʼя клієнта (група крові, алергії, хронічні стани, ліки) видаляються/очищаються (див. 5.0). Наведений нижче загальний опис видалення облікового запису не тлумачиться як обовʼязок остаточно видалити рядок клієнта в цьому спеціальному випадку. Анамнез, вимірювання, нотатки сеансів і фінансові записи залишаються предметом власних правил зберігання.

Набрання чинності / останнє оновлення: 19 жовтня 2026 р. Версія: 1.9 Володілець даних / видавець: Mertcan Demir — фізична особа-підприємець, що діє під комерційним найменуванням «Teta Studio»

Журнал змін

• 1.9 — 19 жовтня 2026 р.: Формулювання «лише Туреччина» в розділі 14 замінено глобальним наданням послуги; строки зберігання не змінено.
• 1.8 — 19 жовтня 2026 р.: Версія для публікації; дата набрання чинності — 19 жовтня 2026 р. До розділу 4 додано рядок про групові повідомлення клініки та копії повідомлень, відкладені для перевірки командою (№ 12); відповідно розширено перелік періодичного знищення в розділі 7; з таблиці 1.3 вилучено незаповнені відомості MERSİS і KEP.
• 1.7 — 11 жовтня 2026 р.: За результатами перевірки відповідності від 11 жовтня 2026 р. (F01, F02, F08, F11, F13, F19, F21): вилучено формулювання в §11 «Supabase/Франкфурт не є передачею за кордон», а розділ про передачу за кордон переписано відповідно до редакції ст. 9 Закону № 6698 після 2024 року (стандартні договори ще не підписано); формулювання «анонімні» щодо записів про здоровʼя/клінічних/фінансових записів виправлено на зберігання з обмеженим доступом без звʼязку з особою (вільний текст нотаток сеансів не змінюється); правову підставу рядка про докази згоди виправлено на ст. 5/2-e (вилучено помилкове посилання на ст. 20/2); рядок про форму раннього доступу оновлено з урахуванням розмежування інформування та згоди на комерційні повідомлення; для категорій без автоматичного знищення додано принцип періодичного знищення кожні 6 місяців; ідентифікаційні відомості виправлено на фізичну особу-підприємця; розділ про VERBİS переписано відповідно до рішень Ради 2025 року.
• 1.6 — 10 жовтня 2026 р.: Expo (Expo Push Notification Service) вилучено з переліків суброзпорядників/розпорядників; push-сповіщення доставляються лише через Apple (APNs) і Google (FCM), а Expo/EAS — лише інструмент збирання застосунку, який не обробляє дані кінцевих користувачів.
• 1.5 — 10 жовтня 2026 р.: Вилучено формулювання щодо вибору Google Analytics; уточнено, що аналітика третіх сторін не використовується, і які розпорядники обробляють push-сповіщення.
• 1.4 — 4 жовтня 2026 р.: Чинний текст закріплено як затверджену версію. У цій версії відображено лише таке: видалення облікового запису (доступ припиняється негайно, персональні дані видаляються/анонімізуються, платіжні записи, що потребують зберігання за законом, зберігаються без ідентифікації; строку для скасування немає); видалення полів здоровʼя клієнта через 30 днів; строк 7 днів для «осиротілих» квитанцій; приховування контактних даних клієнта в режимі підтримки; вимірювання на боці сервера без ідентифікації; службові листи та Google Workspace; розпорядники push-сповіщень; адреса підтримки; ринок (Туреччина).
• 1.3 — 7 липня 2026 р. (оновлення від 4 серпня 2026 р.): попередня версія.

Важлива примітка щодо статусу володільця даних / розпорядника даних: Ця Політика зберігання та знищення даних («Політика») визначає, протягом якого строку зберігаються персональні дані, оброблювані в межах програмної послуги Corenta («Послуга» або «Застосунок»), яку розробляє та експлуатує Mertcan Demir, що діє як фізична особа-підприємець під комерційним найменуванням «Teta Studio» («Corenta», «Teta Studio», «Компанія»), критерії, на яких ґрунтується визначення цих строків, а також методи, якими ці дані видаляються, безповоротно знищуються або анонімізуються після спливу строку зберігання або зникнення підстави для обробки.

Цю Політику підготовлено відповідно до Закону № 6698 «Про захист персональних даних» («KVKK»), Положення про видалення, безповоротне знищення або анонімізацію персональних даних («Положення») та іншого відповідного законодавства, і вона є невідʼємною частиною реєстру операцій з обробки персональних даних Corenta. Цю Політику слід читати разом із відповідним Інформаційним текстом/Політикою конфіденційності, де докладно пояснено цілі та правові підстави обробки даних; цей документ регулює лише строки зберігання та порядок знищення і не має на меті самостійно повністю виконати обовʼязок інформування за ст. 10 KVKK.

1. Мета та сфера дії

1.1. Мета

Мета цієї Політики — пояснити критерії визначення максимального строку, необхідного для мети, з якою Corenta обробляє персональні дані, застосування строків, передбачених законодавством, а також порядок і принципи видалення, безповоротного знищення або анонімізації персональних даних, строк зберігання яких сплив. Цю Політику підготовлено на основі положень ст. 5, ст. 6, ст. 7, ст. 10, ст. 11 і ст. 12 KVKK та відповідних статей Положення.

1.2. Сфера дії та розподіл ролей — важливе застереження

Ця Політика охоплює дві окремі сфери, у яких Corenta обробляє дані у двох різних статусах; це розмежування послідовно застосовується в усій Політиці й безпосередньо впливає на тлумачення таблиці строків зберігання:

(a) Контекст корпоративного вебсайту (corenta.app — форма запиту на ранній доступ/демо): щодо персональних даних, які потенційні бізнес-клієнти, що цікавляться продуктом, надсилають через форму заявки на ранній доступ, Corenta/Teta Studio діє безпосередньо як Володілець даних відповідно до ст. 3 KVKK.

(b) Контекст SaaS-продукту (app.corenta.app): щодо персональних даних власних клієнтів («Клієнт — субʼєкт даних»), які центри клінічного пілатесу, фізіотерапії, реформера, велнесу/масажу та йоги («Tenant», «Бізнес» або «Клініка»), що користуються платформою Corenta за підпискою, вносять на платформу (контактні дані, анамнез, нотатки сеансів, дані про записи/пакети тощо), Клініка є Володільцем даних відповідно до ст. 3 KVKK; Corenta/Teta Studio лише як Розпорядник даних надає послугу технічної інфраструктури відповідно до вказівок Клініки. Обовʼязок інформування клієнтів, отримання явної згоди та остаточне рішення щодо зберігання/знищення даних клієнтів належать до юридичної відповідальності Клініки. Corenta технічно сприяє виконанню цих обовʼязків у продукті (механізм реєстрації згод consent_logs, мобільний екран підтвердження KVKK kvkk.tsx, журнали аудиту), але не переймає і не бере на себе обовʼязку Клініки щодо дотримання KVKK. Строки зберігання, наведені в цій Політиці для цього контексту, показують, як довго Corenta як розпорядник даних фактично зберігає ці дані у своїй інфраструктурі; остаточне рішення про знищення та його строк можуть визначатися вказівками Клініки та законодавством, якому вона підпорядковується.

Ця Політика також охоплює процеси зберігання/знищення персональних даних працівників, бізнес-партнерів і постачальників Corenta щодо загальних принципів; однак основна увага Політики зосереджена на даних клієнтів-бізнесів/клієнтів клінік, визначених у підпунктах (a) і (b) вище.

1.3. Відомості про володільця даних / розпорядника даних

1.4. Нормативна база

• Закон № 6698 «Про захист персональних даних»,
• Положення про видалення, безповоротне знищення або анонімізацію персональних даних (Офіційний вісник від 28.10.2017 № 30224),
• Настанова щодо видалення, безповоротного знищення або анонімізації персональних даних і рішення Ради із захисту персональних даних («Рада»),
• Торговий кодекс Туреччини № 6102 (зберігання комерційних облікових книг і документів),
• Податковий процесуальний кодекс № 213 (зберігання фінансових записів),
• інше відповідне галузеве законодавство (зокрема, у застосовній мірі, законодавство про надання медичних послуг).

2. Визначення

3. Критерії визначення строків зберігання та знищення (ст. 5, ст. 6 KVKK)

3.1. Підстави, що вимагають зберігання

У Corenta персональні дані зберігаються лише протягом строку, прямо передбаченого відповідним законодавством, або протягом строку, необхідного для мети, з якою вони обробляються. Під час визначення строку зберігання враховуються такі критерії:

1. Чи існує юридичний обовʼязок зберігання? (Наприклад, мінімальні строки зберігання фінансових записів відповідно до Торгового кодексу Туреччини та Податкового процесуального кодексу.)
2. З якою метою оброблено дані і чи ця мета досі актуальна? (ст. 5/2 KVKK — принцип обмеження метою.)
3. Чи це необхідно для укладення/виконання договору? (Наприклад, дані про записи та пакети, поки триває відносини підписки/надання послуг.)
4. Чи це необхідно для встановлення, здійснення або захисту права (як доказ у можливому правовому спорі)? (З урахуванням загальних строків позовної давності за Кодексом зобовʼязань.)
5. Чи є явна згода субʼєкта даних і чи вона досі чинна?
6. Чи є законний інтерес Corenta або Клініки? (Наприклад, журнали безпеки, виявлення шахрайства/зловживань.)
7. Чи належать дані до категорії персональних даних особливої категорії (про здоровʼя)? У такому разі відповідно до ст. 6 KVKK застосовуються суворіші обмеження доступу та обґрунтування; строк зберігання ніколи не продовжується поза межі мети.

Якщо жоден із наведених критеріїв не вимагає зберігання певних персональних даних, дані негайно видаляються, безповоротно знищуються або анонімізуються.

3.2. Підстави, що вимагають знищення

Персональні дані видаляються, безповоротно знищуються або анонімізуються на запит відповідної особи або з власної ініціативи Corenta/Клініки в таких випадках:

a) зміна або скасування положень законодавства, що є підставою для їх обробки, b) зникнення мети, яка вимагає їх обробки або зберігання, c) відкликання субʼєктом даних згоди у випадках обробки на підставі явної згоди, d) подання субʼєктом даних запиту на видалення/знищення в межах прав за ст. 11 KVKK і визнання цього запиту обґрунтованим (запит на видалення облікового запису), e) сплив строку зберігання персональних даних і відсутність будь-якої правової підстави, що вимагає зберігання, f) неукладення договору, його недійсність, розірвання або відмова від договору, g) остаточне завершення запиту на видалення облікового запису в межах процесу, описаного в пункті 5 цієї Політики.

4. Таблиця категорій даних, строків зберігання та методів знищення

Наведена нижче таблиця показує основні категорії персональних даних, що обробляються в інфраструктурі Corenta, строк зберігання, його обґрунтування та метод знищення, що застосовується після спливу строку. Якщо прямо не зазначено інше, загальне правило таке: «Поки повʼязаний обліковий запис/запис активний + 30 днів від початку обробки запиту на видалення облікового запису». Таблицю слід читати разом із процесом видалення облікового запису, описаним у розділі 5. Для деяких категорій крок цього процесу після спливу 30 днів — це не DELETE (остаточне видалення), а анонімізація; це розмежування прямо зазначено у відповідних рядках і в розділі 6.2.

<div style="overflow-x:auto">

</div>

Примітка 1: Формулювання «поки обліковий запис/tenant активний» у наведеній вище таблиці означає період, протягом якого підписка відповідної Клініки на Corenta триває, а запис клієнта не видалено Клінікою. Коли Клініка видаляє дані власного клієнта, визначається власною політикою Клініки щодо KVKK (як Володільця даних) і її відносинами з клієнтом; Corenta надає для цього процесу технічні можливості.

Примітка 2: Строки 2 роки для № 7 (записи журналу аудиту) і 5 років для № 8 (записи згод) є фіксованими строками зберігання, визначеними Corenta (на відміну від строку за Торговим/Податковим процесуальним кодексами в № 6, вони не ґрунтуються безпосередньо на положенні законодавства; це добровільне обовʼязкове зобовʼязання, визначене на підставі законного інтересу та обовʼязку доказування за ст. 5/2-f KVKK). Автоматичного механізму видалення після спливу цих строків у системі наразі немає — після спливу строку видалення/анонімізація виконується вручну; після запровадження автоматизації цю Політику буде оновлено. Формулювання «не більше 2 років» у № 9 (дані форми раннього доступу) має іншу сферу дії й, як пояснено в його рядку, означає окрему юридичну верхню межу.

5. Процес видалення облікового запису — повний опис

Щоб технічно виконувати запити субʼєктів даних на видалення за ст. 11 KVKK, Corenta застосовує двоетапну архітектуру видалення, яка зважує баланс між зручністю користувачів і потребами безпеки даних/юридичного доказування: миттєве мʼяке видалення (soft-delete) і подальше остаточне видалення через 30 днів.

5.0. Зміна від 4 жовтня 2026 р. — у разі суперечності з 5.1–5.7 цей пункт має пріоритет

Видалення облікового запису (станом на 4 жовтня 2026 р.): після підтвердження запиту на видалення доступ до облікового запису негайно припиняється (сесії завершуються, вхід неможливий); персональні дані видаляються або анонімізуються (очищаються імʼя, адреса електронної пошти, телефон, зображення, а також ідентифікаційні й контактні дані клієнта та поля здоровʼя — група крові, алергії, хронічні стани, ліки); записи про платежі та нарахування, які потрібно зберігати за законом, не видаляються; вони зберігаються без звʼязку з особою та з обмеженим доступом. Після запиту строку для скасування немає; остаточне видалення запису автентифікації та файлів завершується в межах наявного тридцятиденного фонового процесу.

Видалення запису клієнта і поля здоровʼя (станом на 4 жовтня 2026 р.): коли бізнес видаляє запис клієнта, який не має облікового запису, запис негайно вилучається з активного списку; через 30 днів разом з ідентифікаційними та контактними даними видаляються/очищаються також поля здоровʼя клієнта (група крові, алергії, хронічні стани, ліки). Це положення не впливає на правила зберігання анкет анамнезу, вимірювань і нотаток сеансів.

Файли квитанцій (станом на 4 жовтня 2026 р.): файли квитанцій, не привʼязані до жодного платежу («осиротілі»), автоматично видаляються через 7 днів; квитанцію, привʼязану до платежу, не може видалити жодна роль.

Контактні дані клієнта в режимі підтримки (станом на 4 жовтня 2026 р.): у сесії підтримки Corenta (суперадміністратора) адреса електронної пошти й номер телефону клієнта не показуються персоналу підтримки; персонал підтримки бачить лише обмежене ідентифікаційне резюме (імʼя, статус облікового запису, активність, дату створення).

Право записувати в поля здоровʼя (станом на 4 жовтня 2026 р.): у поля здоровʼя клієнта (група крові, алергії, хронічні стани, ліки) можуть записувати лише сам клієнт і призначений йому спеціаліст; власник/адміністратор бізнесу не може записувати в ці поля (він може редагувати контактну особу на випадок надзвичайної ситуації та ідентифікаційні поля).

Псевдонімне вимірювання продукту: для вдосконалення продукту лише на боці сервера можуть вимірюватися агреговані події використання з псевдонімним ідентифікатором клініки; це вимірювання не включає IP-адреси, даних про здоровʼя чи відстеження джерела/реклами. Псевдонімний ідентифікатор клініки є псевдонімом (а не знеособленими даними). Наразі функцію вимкнено.

5.1. Етап 1 — миттєве мʼяке видалення (soft-delete)

Щойно користувач підтверджує в застосунку запит на видалення облікового запису, система одночасно й миттєво виконує такі операції:

1. Запис профілю користувача стає неактивним шляхом заповнення поля deleted_at; обліковий запис стає недоступним/невидимим для звичайного використання й не може використовуватися для входу.
2. Заплановані (ще не проведені) записи на прийом користувача автоматично скасовуються.
3. Призначення, у яких користувач фігурує як спеціаліст/ресурс (привʼязки клієнт—спеціаліст, призначення програм), знімаються.
4. Усі згоди користувача відкликаються (це фіксується заповненням поля revoked_at у записах consent_logs).

На цьому етапі дані фізично не видалено, але вони стали недоступними для цілей звичайної обробки та перегляду. Це перший крок процесу видалення, що має характер «приведення до стану недоступності» у значенні ст. 7 KVKK і Положення.

5.2. Етап 2 — остаточне видалення (через 30 днів)

Через 30 (тридцять) днів після мʼякого видалення заплановане завдання (cron job), що автоматично працює в системі, безповоротно виконує такі операції:

1. Запис автентифікації користувача (auth.users) остаточно й безповоротно видаляється.
2. Записи бази даних, повʼязані з користувачем, обробляються диференційовано залежно від категорії: записи, що не мають самостійної бізнесової/доказової цінності (наприклад, сповіщення), остаточно видаляються (DELETE/cascade); дані про здоровʼя (anamnesis_forms, session_notes, measurements) і клінічні/фінансові записи (payments, attendance, consent_logs) натомість не видаляються, а звʼязок з особою розривається — посилання на особу розривається на рівні бази даних, деякі поля вільного тексту очищуються, і запис залишається як запис tenant без звʼязку з особою з обмеженим доступом (оскільки вільний текст нотаток сеансів не змінюється, вони не вважаються анонімними) (див. розділ 4, № 2-5, 8, 10 і розділ 6.2).
3. Цю операцію автоматично запускає лише привілейований (захищений service-role) фоновий процес системи; жоден користувач, зокрема адміністративний персонал, чи адміністратор Бізнесу не може вручну запустити, достроково ініціювати або зупинити цей процес через звичайні інтерфейси продукту — це свідома безпекова архітектура, що має на меті запобігти передчасному/запізнілому видаленню через помилку чи зловживання. (Ця гарантія охоплює звичайні користувацькі та адміністративні інтерфейси продукту; технічні операційні процеси, які на привілейованому інфраструктурному рівні системи можуть мати прямий доступ до бази даних, не охоплюються цією гарантією і підлягають окремому внутрішньому контролю доступу.)

Мета 30-денного фонового процесу (станом на 4 жовтня 2026 р.): оскільки доступ до облікового запису припиняється одразу після запиту на видалення, цей строк не надає можливості скасування/відмови; він використовується для завершення остаточного видалення запису автентифікації та файлів і для можливої перевірки на зловживання. Цей строк є розумним і обмеженим строком, що відповідає принципу пропорційності за ст. 5 KVKK. Щодо статусу запиту на видалення можна звернутися на адресу hello@corenta.app.

5.3. Виняток: дані, щодо яких є юридичний обовʼязок зберігання

Наведений вище 30-денний процес остаточного видалення не охоплює записів, зазначених у розділі 4, у рядку таблиці № 6 (метадані підписки/транзакцій), щодо яких діє юридичний обовʼязок зберігання за Торговим кодексом Туреччини/Податковим процесуальним кодексом. Ці записи навіть після остаточного видалення облікового запису окремо зберігаються до спливу відповідного строку зберігання, встановленого законом, відокремлено від мети обробки персональних даних і з доступом, обмеженим лише метою виконання юридичного обовʼязку. Так само записи журналу аудиту (audit_logs) і мінімальне доказове ядро записів згод (див. розділ 4, № 7-8) можуть і далі зберігатися з окремою й обмеженою метою поза цим 30-денним строком на підставі законного інтересу/юридичного доказування. У розділі 4, Примітці 2, прямо зазначено, що строкам, охопленим цим винятком, не відповідає технічний механізм, який автоматично застосовується в системі.

5.4. Спеціальне пояснення щодо збережених вкладень (важливо — прозорість)

Відповідно до принципу прозорості прямо зазначається: під час остаточного видалення записи бази даних (профіль, записи на прийом, призначення, згоди тощо) повністю видаляються або (для записів про здоровʼя/клінічних/фінансових записів, див. розділ 6.2) анонімізуються; вкладення, що належать користувачу і зберігаються в окремому сховищі (Storage), обробляються так: аватар/фото профілю, документ/фото, додане до анкети анамнезу, і зображення платіжної квитанції автоматично (за принципом best-effort) видаляються зі Storage як частина кроку остаточного видалення — це підтверджена поведінка, яка наразі фактично працює в системі. Якщо операція видалення в одному бакеті не вдається, це фіксується в журналі; однак це не перешкоджає очищенню інших бакетів чи крокам анонімізації/остаточного видалення облікового запису (архітектура best-effort).

Чесна межа: єдина категорія файлів, що залишається поза межами цього автоматичного процесу, — документи для перевірки особи/диплома, завантажені в процесі реєстрації спеціаліста/соло-спеціаліста (бакет specialist-verification-docs). Технічно ці документи привʼязані не до користувача, а до процесу перевірки відповідного tenant (Клініки) і не містять посилання на користувача в записі бази даних; тому їх не можна автоматично включити до наявного процесу видалення облікового запису користувача. Знищення цього документа буде окремо розглянуто в процесі закриття відповідною Клінікою облікового запису/підписки на рівні tenant (див. розділ 5.6); до завершення цього виняткові запити розглядаються вручну через hello@corenta.app.

Тому в цій Політиці не дається абсолютного зобовʼязання про те, що в разі запиту на видалення облікового запису «всі дані/файли користувача видаляються повністю й миттєво» (зокрема щодо технічних залишків у резервних копіях див. розділ 6.3, а також зазначений вище виняток); однак щодо описаних вище категорій файлів автоматичне видалення фактично застосовується.

5.5. Спеціальна примітка щодо даних про здоровʼя

Персональні дані особливої категорії про здоровʼя, як-от анкети анамнезу, нотатки сеансів і записи вимірювань, також підпадають під наведений вище загальний процес видалення (мʼяке видалення → 30 днів → остаточне видалення); однак, як пояснено в розділі 4, № 2-4, і в розділі 6.2, у цих таблицях крок остаточного видалення застосовується шляхом розриву звʼязку з особою та часткового очищення — запис не видаляється через DELETE, посилання на особу розривається, а деякі поля вільного тексту очищуються; клінічний запис (зокрема вміст нотаток сеансів append-only) зберігається як запис tenant без звʼязку з особою з обмеженим доступом і не вважається анонімним. Крім того, оскільки ця категорія даних переплетена із записами, які Клініка веде як володілець даних, запит клієнта на видалення облікового запису/даних може суперечити власним юридичним обовʼязкам Клініки щодо зберігання (наприклад, обовʼязкам вести записи, що можуть випливати із законодавства про надання медичних послуг); метод розриву звʼязку з особою та обмеженого зберігання має на меті збалансувати ці два обовʼязки (права клієнта щодо персональних даних і обовʼязок Клініки вести записи). У таких випадках остаточним органом прийняття рішень є Клініка як володілець даних; Corenta діє відповідно до вказівок Клініки.

5.6. Видалення на рівні Клініки (tenant)

Якщо Клініка повністю припиняє підписку на Corenta, та сама двоетапна архітектура (мʼяке видалення → 30 днів → остаточне видалення) застосовується також до даних tenant, що належать Клініці, і до всіх записів клієнтів у межах цього tenant. Оскільки Клініка є Володільцем даних своїх клієнтів, вона зобовʼязана до припинення підписки поінформувати своїх клієнтів у межах власних обовʼязків за KVKK; цей обовʼязок не може бути переданий Corenta.

5.7. Звʼязок із режимом підтримки суперадміністратора (імперсонація)

Процеси видалення облікового запису та зберігання працюють незалежно від механізму підтримки/імперсонації Corenta. Сесії імперсонації обмежені в часі (30 хвилин) і за замовчуванням працюють лише в режимі читання; доступ до категорій даних про здоровʼя (анамнез, нотатки сеансів, вимірювання) потребує окремого кроку підтвердження (health_data_enabled), а операції запису/видалення в цих таблицях через імперсонацію за жодних умов не дозволяються (політики RLS не передбачають жодного винятку для імперсонації). Уточнення: це обмеження стосується сесій імперсонації, ініційованих людиною, у яких працівник підтримки входить і виконує дії вручну; автоматичний (без втручання людини) процес cron із service-role, описаний у розділі 5.2, є окремим рівнем, відокремленим від цього обмеження, і воно на нього не впливає — обмеження імперсонації не блокує механізму автоматичного остаточного видалення в процесі видалення облікового запису, і їх не слід плутати. Отже, процеси видалення облікового запису/знищення здійснюються лише через автоматичні механізми, визначені в цій Політиці.

6. Методи знищення

Методи видалення/безповоротного знищення/анонімізації, що застосовуються залежно від середовища зберігання відповідно до ст. 8 і наступних статей Положення, описано нижче.

6.1. Видалення

Це операція, унаслідок якої персональні дані стають жодним чином недоступними та непридатними для повторного використання для відповідних користувачів (зокрема користувачів застосунку та персоналу з доступом до панелі адміністрування). У Corenta цей метод застосовується в процесі мʼякого видалення на етапі 1: хоча дані фізично не вилучаються з бази даних, вони стають повністю недоступними через повноваження доступу та інтерфейси.

6.2. Безповоротне знищення (остаточне видалення)

Це операція, унаслідок якої персональні дані стають жодним чином недоступними, невідновлюваними та непридатними для повторного використання для будь-кого. У процесі остаточного видалення на етапі 2 Corenta реалізує цей принцип двома різними технічними методами залежно від категорії даних:

• Запис автентифікації та записи, що не мають самостійної бізнесової цінності: запис автентифікації користувача (auth.users) безповоротно видаляється безпосередньо через DELETE в автоматичному процесі, захищеному service-role; повʼязані записи, які після видалення облікового запису самі по собі не мають бізнесової/доказової цінності (наприклад, сповіщення, notifications — див. розділ 4, № 10), видаляються разом на рівні бази даних через ON DELETE CASCADE.
• Записи про здоровʼя, клінічні та фінансові записи: для anamnesis_forms, session_notes, measurements, payments, attendance і consent_logs крок остаточного видалення застосовується не шляхом DELETE запису, а шляхом розриву звʼязку з особою та часткового очищення (див. розділ 6.6): стовпці зовнішніх ключів, що ідентифікують особу (client_id, specialist_id, user_id тощо), безповоротно встановлюються в NULL обмеженням FK ON DELETE SET NULL; стовпці вмісту, що можуть містити явні ідентифікатори або PII у вільному тексті (відповіді анамнезу, вільний текст приміток до вимірювань/платежів, посилання на квитанцію про оплату, IP-адреса запису згоди), очищуються або замінюються анонімною позначкою функцією anonymize_user_relations() (може викликатися лише service-role, default-deny). Натомість клінічний/фінансовий числовий та історичний вміст (дата, сума, значення вимірювання, залишок сеансів, статус «прийшов/не прийшов», час надання/відкликання згоди) і далі зберігається як запис tenant без звʼязку з особою відповідно до обовʼязку Клініки вести записи та (для нотаток сеансів) принципу append-only; оскільки вільний текст нотаток сеансів не змінюється, ці записи не вважаються анонімними і зберігаються з обмеженим доступом.

У нотатках сеансів (session_notes) обмеження append-only не дозволяє змінювати вміст; передбачено лише вузький виняток для однієї мети — встановлення в NULL стовпців посилань на осіб (client_id, specialist_id); сам вміст нотатки і в цьому процесі на жодному етапі не видаляється й не змінюється.

Межа: для персональних даних у тексті полів вільного тексту, що можуть траплятися поза явними ідентифікаційними стовпцями (наприклад, імʼя в тілі нотатки сеансу), механізму перевірки/очищення немає. Тому ці записи не вважаються анонімними; вони зберігаються як персональні дані з обмеженим доступом і знищуються після спливу строку.

Обидва наведені вище методи захищені service-role, тому їх неможливо запустити або скасувати через звичайні інтерфейси продукту.

6.3. Видалення з резервних копій (backup)

Резервні копії бази даних автоматично перезаписуються/знищуються через певний строк у межах звичайного циклу резервного копіювання (ротації). Прямо зазначається, що хоча остаточне видалення набирає чинності в основній базі даних негайно, у раніше створених резервних копіях дані можуть технічно існувати до спливу стандартного строку ротації резервних копій постачальника резервного копіювання (Supabase). Це стандартна практика в межах договору про обробку даних (DPA) відповідного суброзпорядника (Supabase).

6.4. Вкладення в сховищі файлів (Storage)

Файли, завантажені користувачами, як-от зображення аватарів, платіжні квитанції та вкладення до анамнезу, зберігаються в окремому сховищі (Storage). Див. розділ 5.4 — там докладно й прозоро пояснено поточний стан цього вмісту в процесі видалення облікового запису (автоматичне видалення для аватарів/вкладень до анамнезу/платіжних квитанцій, єдиний виняток — specialist-verification-docs).

6.5. Дані на паперових носіях

Персональні дані, що обробляються в межах SaaS-продукту Corenta, зберігаються в цифровому середовищі; обробка персональних даних на паперових носіях не передбачається. Якщо в комерційному/адміністративному листуванні Компанії у виняткових випадках використовуються паперові носії, знищення здійснюється методом затемнення/спалювання/безповоротного подрібнення за допомогою знищувача паперу.

6.6. Анонімізація

Як частину процесу остаточного видалення облікового запису (див. розділ 6.2) Corenta застосовує до даних про здоровʼя та клінічних/фінансових записів метод розриву звʼязку з особою та часткового очищення. Оскільки вільний текст нотаток сеансів не змінюється, а в малих бізнесах дат і серій вимірювань може бути достатньо для повторної ідентифікації особи, цей метод не в усіх випадках відповідає наведеному нижче стандарту анонімізації; ці записи не вважаються анонімними, вони зберігаються як персональні дані з обмеженим доступом і знищуються після спливу строку. Крім того, Corenta може використовувати для цілей розробки продукту, статистичного аналізу або дослідження ринку дані, анонімізовані так, що їх неможливо повʼязати з ідентифікованою або ідентифіковуваною фізичною особою. Анонімізація вимагає приведення даних до стану, у якому їх безповоротно неможливо повʼязати з особою навіть у разі поєднання з іншими даними; операції маскування/псевдонімізації, виконані без дотримання цього стандарту, не вважаються анонімізацією і залишаються предметом режиму обробки персональних даних. Анонімізовані дані розглядаються як такі, що перебувають поза сферою дії KVKK, і на них не поширюються обмеження строків зберігання, передбачені цією Політикою.

6.7. Вибір методу

Метод знищення, що застосовується, визначає Corenta та/або Клініка з урахуванням характеру даних (чи належать вони до особливої категорії), середовища, у якому вони зберігаються (база даних, файлове сховище, система журналів, система резервного копіювання), юридичних і технічних можливостей, а також принципів, визначених у рішеннях Ради та Положенні. Під час знищення персональних даних особливої категорії (зокрема даних про здоровʼя) виявляється максимальна обачність.

7. Процес періодичного знищення

Відповідно до ст. 11 Положення Corenta зобовʼязана з власної ініціативи (не чекаючи запиту) видаляти, безповоротно знищувати або анонімізувати персональні дані, строк зберігання яких сплив та/або мета обробки яких зникла; передбачений у цьому контексті строк періодичного знищення не може перевищувати 6 (шести) місяців. У цих межах прямо розмежовуються механізми, які наразі фактично працюють у системі, і ті, що не працюють:

1. 30-денний процес остаточного видалення після запиту на видалення облікового запису періодично (щодня) перевіряється автоматичним запланованим завданням (cron job), і облікові записи, строк яких сплив, обробляються пакетно. Це підтверджена автоматизація, яка наразі фактично працює в системі.
2. Строк зберігання, передбачений для записів журналу аудиту (audit_logs), періодично переглядається; однак механізму видалення, який автоматично виконував би цей перегляд, наразі не запроваджено (див. розділ 4, № 7).
3. Максимальний строк зберігання, визначений для даних форми раннього доступу (див. розділ 4, № 9), є юридичною верхньою межею для обовʼязку періодичного знищення за ст. 11 Положення; однак автоматичного механізму перевірки/видалення, що працював би в системі відповідно до цього строку, наразі немає. До запровадження автоматизації видалення/анонімізація для цієї категорії даних розглядається вручну та на запит (див. розділ 4, Примітку 2). Це питання висвітлюється прозоро, узгоджено з іншими непідтвердженими твердженнями про автоматизацію (див. пункти 2 і 4).
4. Окреме автоматичне й періодичне очищення прострочених/недійсних токенів push-сповіщень є запланованим у дорожній карті продукту вдосконаленням; технічно не підтверджено, що цей механізм наразі фактично працює в системі (див. розділ 4, № 10). Після підтвердження або запровадження цю Політику буде оновлено.
5. Періодичне знищення кожні 6 місяців: для категорій, які в цьому розділі не мають автоматичного знищення (журнал аудиту, докази дозволів без звʼязку з особою, дані форми раннього доступу, документи для перевірки спеціалістів, копії групових повідомлень для модерації), Corenta проводить періодичне знищення кожні 6 місяців і для кожного циклу складає акт про знищення. Запланованих завдань, які автоматизували б ці цикли, ще немає; цикли виконуються вручну.

Процес періодичного знищення незалежно від строків, зазначених у цій Політиці, не перешкоджає індивідуальному запиту субʼєкта даних на видалення/знищення за ст. 11 KVKK; субʼєкт даних може подати запит на видалення, навіть якщо строк зберігання не сплив, якщо зникла правова підстава відповідної діяльності з обробки (наприклад, відкликання згоди). Щодо категорій, для яких автоматизацію ще не запроваджено, індивідуальний запит субʼєкта даних, надісланий через hello@corenta.app, також розглядається та вирішується вручну.

8. Права субʼєкта даних і порядок звернення (ст. 11 KVKK)

8.1. Права за статтею 11 KVKK

Відповідно до ст. 11 KVKK субʼєкти даних мають такі права:

1. дізнатися, чи обробляються їхні персональні дані,
2. якщо персональні дані оброблено, запитати інформацію про це,
3. дізнатися мету обробки персональних даних і чи використовуються вони відповідно до цієї мети,
4. знати третіх осіб в Туреччині чи за кордоном, яким передано персональні дані,
5. вимагати виправлення персональних даних, якщо їх оброблено неповно або неточно,
6. вимагати видалення або безповоротного знищення персональних даних у межах ст. 7 KVKK,
7. вимагати повідомлення про операції, здійснені відповідно до наведених вище підпунктів (5) і (6), третіх осіб, яким передано персональні дані,
8. заперечувати проти несприятливого для особи результату, що виник унаслідок аналізу оброблених даних виключно автоматизованими системами,
9. вимагати відшкодування шкоди, якщо особі завдано шкоди внаслідок протиправної обробки персональних даних.

8.2. Чесний підсумок поточної технічної реалізації

Наведені нижче положення подано як чесний і реалістичний підсумок поточної технічної реалізації:

• Запит на видалення (видалення облікового запису): його можна подати безпосередньо через відповідне меню налаштувань у мобільному застосунку; цей запит автоматично виконується через двоетапний процес, описаний у розділі 5 (миттєве мʼяке видалення → 30 днів → остаточне видалення) (ст. 11/6).
• Запит інформації / переносимість даних: виконується шляхом надання субʼєкту даних протягом розумного строку його даних у межах його tenant у структурованому, машиночитаному форматі (функція export_user_data, обмеження межами tenant підтверджено). Механізм надання в цьому процесі (формат файлу, спосіб надання, такі функції, як підписане посилання для завантаження) постійно вдосконалюється; у межах цієї Політики не надається зобовʼязань щодо конкретного строку надання чи конкретного формату файлу/доступу (ст. 11/1-2).
• Інформація про передачу третім особам (ст. 11/4): інформацію про третіх осіб/суброзпорядників у Туреччині чи за кордоном, яким передаються персональні дані, наведено в таблиці розділу 11 цієї Політики (Суброзпорядники та локалізація даних).
• Запит на виправлення (ст. 11/5): технічно може бути виконаний вручну через панель адміністрування Клініки; окремого автоматизованого процесу «запиту на виправлення» немає. У контексті SaaS-продукту запити на виправлення даних клієнтів слід насамперед спрямовувати до відповідної Клініки; Corenta як Розпорядник даних надає технічну підтримку відповідно до вказівок Клініки.
• Повідомлення третіх осіб (ст. 11/7): запит на повідомлення третіх осіб, яким передано дані, про операції видалення/виправлення розглядається, якщо його надіслано каналами, зазначеними в порядку звернення; наразі цей процес виконується не автоматично, а вручну.
• Заперечення проти автоматизованого рішення/профілювання (ст. 11/8): у системі немає автоматизованого ухвалення рішень чи профілювання, що призводять до несприятливого для субʼєкта даних результату внаслідок аналізу оброблених даних виключно автоматизованими системами; тому наразі немає потреби в окремому механізмі заперечень, що фактично діяв би щодо цього пункту.
• Відповідно до ст. 13 KVKK звернення розглядаються безкоштовно не пізніше ніж протягом 30 днів (якщо операція потребує додаткових витрат, може стягуватися плата за тарифом, визначеним Радою).

8.3. Порядок звернення

Запити щодо наведених вище прав

• на адресу електронної пошти hello@corenta.app,
• через відповідні екрани налаштувань/підтримки в застосунку,
• або в інші способи, передбачені KVKK,

можна надсилати Corenta.

Важлива примітка щодо даних клієнтів: якщо ти клієнт Клініки й хочеш подати запит щодо своїх даних, тобі насамперед слід звернутися до відповідної Клініки (Володільця даних), оскільки щодо даних клієнтів саме Клініка є остаточним органом прийняття рішень і адресатом. Corenta як розпорядник даних надає необхідні технічні інструменти (функції перегляду, експорту, видалення даних) відповідно до вказівок Клініки.

9. Ролі та обовʼязки

10. Заходи безпеки (протягом строку зберігання)

Протягом строку зберігання персональні дані захищаються такими технічними та організаційними заходами (ст. 12 KVKK):

• У багатоорендній (multi-tenant) архітектурі застосовується принцип заборони за замовчуванням (default-deny) з обовʼязковим tenant_id у кожній таблиці та політиками безпеки на рівні рядків (Row Level Security) (37/37 таблиць, 86 політик); у такий спосіб технічно запобігається витоку даних між орендарями.
• Доступ до таблиць, що містять дані про здоровʼя, обмежено відповідним клієнтом, призначеним спеціалістом і адміністратором tenant; контроль доступу застосовується на рівні бази даних (RLS). Нотатки сеансів після надсилання не можна змінити/видалити (append-only); щодо анкет анамнезу жоден користувач (зокрема адміністратор) не має права видалення.
• Режим підтримки суперадміністратора (імперсонація) обмежений у часі (30 хвилин) і за замовчуванням працює лише в режимі читання; операції запису та доступ до даних про здоровʼя потребують окремих кроків із додатковим підтвердженням; у жодному сценарії імперсонації доступ на запис до таблиць даних про здоровʼя не відкривається. (Це обмеження стосується сесій імперсонації, ініційованих людиною; автоматичні процеси cron із service-role є окремим рівнем — див. розділ 5.7.)
• Під час передавання даних використовується наскрізне шифрування (TLS); у мобільному застосунку токени сесії зберігаються в зашифрованому вигляді в захищеному апаратно підтримуваному сховищі ключів пристрою (Keychain/Keystore).
• На чутливих екранах вжито технічних заходів для обмеження створення знімків екрана.
• Для облікових записів суперадміністраторів обовʼязкова двофакторна автентифікація (2FA/MFA).
• Криптографічну перевірку підпису сповіщень (webhook) про платіжні операції передбачено в архітектурі й застосовується; тривають роботи з повного завершення відповідної конфігурації/керування ключами в усіх середовищах (зокрема prod).
• Ці заходи безпеки постійно переглядаються та вдосконалюються; однак жоден технічний захід не гарантує абсолютної безпеки, і в межах цієї Політики не надається зобовʼязання щодо абсолютної безпеки.

11. Суброзпорядники та локалізація даних

Протягом строку зберігання персональні дані обробляються або розміщуються через наведених нижче суброзпорядників/постачальників послуг. Договори з цими постачальниками передбачають обовʼязки обробляти дані лише з метою надання зазначеної послуги; ці відносини стосуються не строків зберігання, а технічного середовища, у якому розміщуються дані, — рішення про знищення технічно виконується також у цих постачальників. Наведена нижче таблиця також забезпечує реалізацію права «знати третіх осіб, яким передано дані» за ст. 11/4 KVKK:

Крім того:

• Інфраструктура електронної пошти: службові листи надсилаються через Google Workspace (Google); листи для автентифікації ініціює Supabase Auth. Рекламні листи надсилаються лише за умови окремої згоди та реєстрації в İYS. Push-сповіщення доставляються через Apple (APNs) і Google (FCM).
• Інструмент аналітики: сторонній інструмент аналітики (наприклад, Google Analytics) не використовується. Вимірювання використання продукту в застосунку наразі не ввімкнено; якщо його буде ввімкнено, вимірювання записуватимуться до власної таблиці першої сторони, що зберігається у власній базі даних Corenta (Supabase, Франкфурт/Німеччина), не міститимуть даних про здоровʼя та вільного тексту, а цю Політику буде оновлено до ввімкнення; після ввімкнення строк зберігання записів вимірювань буде зазначено в цій Політиці.
• Моніторинг помилок: сторонній інструмент моніторингу помилок не використовується; помилки клієнтських застосунків записуються до власної бази даних Corenta.
• Інфраструктури для оплати кредитною карткою безпосередньо через веб немає; платежі здійснюються лише через механізми покупок у застосунку (IAP) Apple/Google; остаточний рахунок/квитанцію оформлює Apple/Google (див. розділ 4, № 6).

Обмін даними з наведеними вище суброзпорядниками здійснюється лише в обсязі, необхідному для надання відповідної послуги, і в межах ст. 8/ст. 9 KVKK. Передача за кордон: усі наведені вище постачальники обробляють дані за межами Туреччини; розміщення в Німеччині також є передачею за кордон у значенні KVKK. Оскільки ця передача є регулярною і постійною, вона не ґрунтується на явній згоді; вона ґрунтуватиметься на стандартних договорах, оголошених Радою відповідно до ст. 9/4-c. Станом на дату цього тексту стандартні договори ще не підписано, і Раду про них не повідомлено; про кожен договір буде повідомлено Раду протягом 5 робочих днів із дати підписання, а цю таблицю буде оновлено із зазначенням дат. Рішення Ради про належний рівень захисту щодо цих країн немає (остання перевірка: 11 жовтня 2026 р.). Цей перелік може оновлюватися залежно від зміни постачальників послуг; актуальний перелік можна переглянути в Політиці конфіденційності та/або на відповідному інформаційному екрані в продукті Corenta.

12. Реєстрація у VERBİS

Станом на дату цього документа Teta Studio не зареєстрована у VERBİS. Обовʼязок реєстрації оцінюється відповідно до критеріїв рішень Ради № 2025/1572 (для володільців даних, основною діяльністю яких є обробка персональних даних особливої категорії, поріг звільнення становить 10 працівників на рік і 10 мільйонів TL балансу) і № 2025/2393 (критерій кількості працівників для тих, хто не веде облікових книг на основі балансу). Оскільки Teta Studio обробляє клінічні дані про здоровʼя не як володілець даних, а як розпорядник даних, оцінка щодо її власної діяльності як володільця даних (Частини A і C) здійснюється за цими критеріями. Після завершення письмової оціночної записки та підтвердження Органу (ALO 198) цей розділ буде оновлено із зазначенням дати та обґрунтування; якщо реєстрація потрібна, її буде здійснено до продовження діяльності.

Уточнення щодо ролей: обовʼязок реєстрації у VERBİS оцінюється для контексту корпоративного вебсайту (форма раннього доступу corenta.app), у якому Corenta діє як Володілець даних, і його стан описано вище. У контексті SaaS-продукту (app.corenta.app), оскільки Володільцем даних щодо даних клієнтів є Клініка, наявність обовʼязку реєстрації у VERBİS слід оцінювати окремо й незалежно за власними критеріями кожної Клініки (кількість працівників, річний обсяг обробки даних, сфера діяльності, рішення Ради про винятки тощо); ця оцінка та обовʼязок реєстрації, якщо він є, належать Клініці й не можуть бути передані Corenta.

13. Оновлення Політики

Цю Політику може бути оновлено відповідно до змін законодавства, рішень Ради, удосконалень технічної інфраструктури Corenta (наприклад, додавання перевірки PII у тексті вмісту вільного тексту нотаток сеансів, зазначеної в розділі 4, № 3, і розділі 6.2; привʼязки документів для перевірки спеціалістів (specialist-verification-docs), зазначених у розділі 5.4/розділі 4, № 11, до процесу закриття tenant; підтвердження/запровадження очищення push-токенів, зазначеного в розділі 4, № 10, і розділі 7, пункт 4; створення механізму автоматичної перевірки для даних форми раннього доступу, зазначеного в розділі 7, пункт 3; удосконалення процесу переносимості даних, зазначеного в розділі 8.2; завершення правових підстав передачі за кордон, наведених у розділі 11; змін у переліку суброзпорядників) або змін у бізнес-процесах. Актуальну версію публікують на відповідних платформах Corenta (корпоративний вебсайт та/або в застосунку), і щодо положень, що суперечать попередній версії, переважає актуальна версія. У разі суттєвих змін користувачів/Клініки, наскільки це можливо, додатково інформують.

14. Контакти

З питань щодо цієї Політики або зберігання/знищення персональних даних:

Електронна пошта: hello@corenta.app Володілець даних: Mertcan Demir — фізична особа-підприємець, що діє під комерційним найменуванням «Teta Studio» Підтримка: support@corenta.app Сфера надання послуги: Corenta надається глобально через App Store і Google Play у країнах, де ці магазини працюють. Строки, зазначені в цій Політиці, застосовуються до користувачів у кожній країні; якщо імперативне законодавство країни передбачає коротший строк видалення або довший обовʼязок зберігання, застосовується це положення.

Останнє оновлення: 19 жовтня 2026 р. Версія 1.9 · 19 жовтня 2026 р.