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 متناسب با آن گسترش یافت؛ اطلاعات MERSİS و KEP که خالی مانده بود از جدول 1.3 حذف شد.
• 1.7 — 11 اکتبر 2026: بر اساس بررسی انطباق 11 اکتبر 2026 (F01، F02، F08، F11، F13، F19، F21): عبارت "Supabase/فرانکفورت انتقال به خارج از کشور نیست" در §11 حذف شد و بخش انتقال به خارج از کشور بر اساس صورت پس از 2024 ماده 9 قانون شماره 6698 نوشته شد (قراردادهای استاندارد هنوز امضا نشده‌اند)؛ عبارت "بی‌نام" برای سوابق سلامت/بالینی/مالی به نگهداری محدود با قطع پیوند شخص اصلاح شد (متن آزاد یادداشت جلسه تغییر داده نمی‌شود)؛ مبنای حقوقی سطر ادله رضایت به ماده 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 در آن‌ها با دو عنوان متفاوت داده پردازش می‌کند؛ این تفکیک در سراسر سیاست به‌طور یکسان اعمال می‌شود و مستقیماً بر نحوه تفسیر جدول مدت‌های نگهداری اثر می‌گذارد:

(الف) زمینه وب‌سایت شرکتی (corenta.app — فرم درخواست دسترسی زودهنگام/دمو): در مورد داده‌های شخصی‌ای که مشتریان تجاری بالقوه علاقه‌مند به محصول از طریق فرم درخواست دسترسی زودهنگام ارسال می‌کنند، Corenta/Teta Studio بر اساس ماده 3 KVKK مستقیماً با عنوان کنترل‌کننده داده عمل می‌کند.

(ب) زمینه محصول SaaS (app.corenta.app): در مورد داده‌های شخصی مربوط به مراجعان خودِ مراکز پیلاتس بالینی، فیزیوتراپی، ریفورمر، تندرستی/ماساژ و یوگا که از طریق اشتراک از پلتفرم Corenta استفاده می‌کنند ("مستأجر"، "کسب‌وکار" یا "مرکز") ("مراجعِ صاحب داده") و آن مراکز وارد پلتفرم می‌کنند (اطلاعات تماس، سوابق سلامت، یادداشت‌های جلسه، داده نوبت/بسته و غیره)، مرکز بر اساس ماده 3 KVKK کنترل‌کننده داده است؛ Corenta/Teta Studio فقط با عنوان پردازشگر داده و مطابق دستورهای مرکز خدمت زیرساخت فنی ارائه می‌دهد. تکلیف اطلاع‌رسانی به مراجعان، کسب رضایت صریح و تصمیم نهایی نگهداری/امحا درباره داده‌های مراجعان بر عهده حقوقی مرکز است. Corenta اجرای این تکالیف را درون محصول (سازوکار ثبت رضایت consent_logs، صفحه تأیید KVKK موبایل kvkk.tsx، ردپاهای حسابرسی) از نظر فنی تسهیل می‌کند، اما تکلیف انطباق مرکز با KVKK را به عهده نمی‌گیرد یا تقبل نمی‌کند. مدت‌های نگهداری که در این سیاست برای این زمینه توضیح داده شده، نشان می‌دهد Corenta با عنوان پردازشگر داده این داده‌ها را عملاً چه مدت در زیرساخت خود نگه می‌دارد؛ تصمیم و مدت نهایی امحا ممکن است در چارچوب دستور مرکز و مقرراتی که مرکز تابع آن است شکل بگیرد.

این سیاست همچنین فرایندهای نگهداری/امحای داده‌های شخصی کارکنان، شرکای تجاری و تأمین‌کنندگان Corenta را از نظر اصول کلی در بر می‌گیرد؛ اما تمرکز اصلی سیاست بر داده‌های مشتری/مراجع است که در بندهای (الف) و (ب) بالا تعریف شده‌اند.

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/مرکز، حذف، نابود یا بی‌نام می‌شوند:

الف) تغییر یا لغو مقررات قانونی‌ای که مبنای پردازش آن‌هاست، ب) از بین رفتن هدفی که پردازش یا نگهداری آن‌ها را لازم می‌کند، پ) پس گرفتن رضایت توسط صاحب داده در مواردی که پردازش مبتنی بر رضایت صریح است، ت) درخواست حذف/نابودی توسط صاحب داده در چارچوب حقوق موضوع ماده 11 KVKK و پذیرفته شدن این درخواست (درخواست حذف حساب)، ث) پایان مدت نگهداری داده‌های شخصی و باقی نماندن هیچ دلیل حقوقی که نگهداری را لازم کند، ج) منعقد نشدن، بی‌اعتبار بودن، فسخ یا انصراف از قرارداد، چ) تکمیل نهایی درخواست حذف حساب در فرایندی که در ماده 5 این سیاست مشخص شده است.

4. جدول دسته‌های داده، مدت‌های نگهداری و روش‌های امحا

جدول زیر دسته‌های اصلی داده شخصی پردازش‌شده در زیرساخت Corenta، مدت نگهداری، دلیل آن و روش امحایی را که در پایان مدت اعمال می‌شود نشان می‌دهد. جز در جایی که خلاف آن صراحتاً ذکر شده باشد، قاعده کلی این است: "تا زمانی که حساب/سابقه مرتبط فعال است + 30 روز از زمان رسیدگی به درخواست حذف حساب." جدول باید همراه با جریان حذف حساب که در بخش 5 توضیح داده شده خوانده شود. برای برخی دسته‌ها، گام پایان 30 روزه این جریان DELETE (حذف دائمی) نیست، بلکه بی‌نام‌سازی است — این تفکیک در سطرهای مربوط و در بخش 6.2 صراحتاً بیان شده است.

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

</div>

یادداشت 1: عبارت "تا زمانی که حساب/مستأجر فعال است" در جدول بالا به مدتی اشاره دارد که اشتراک Corenta مرکز مربوط ادامه دارد و سابقه مراجع توسط مرکز حذف نشده است. اینکه مرکز داده مراجع خود را چه زمانی حذف کند، در چارچوب سیاست KVKK خود مرکز (با عنوان کنترل‌کننده داده) و رابطه‌اش با مراجع تعیین می‌شود؛ Corenta امکان فنی این فرایند را فراهم می‌کند.

یادداشت 2: مدت‌های 2 سال در ردیف 7 (سوابق ردپای حسابرسی) و 5 سال در ردیف 8 (سوابق رضایت)، مدت‌های نگهداری ثابتی هستند که Corenta تعیین کرده است (برخلاف مدت قانون تجارت/قانون آیین مالیاتی در ردیف 6، مستقیماً بر حکم قانونی متکی نیستند؛ تعهدی خودالزام‌آور هستند که در چارچوب منفعت مشروع و تکلیف اثبات در ماده 5/2-f KVKK تعیین شده است). در حال حاضر در سامانه سازوکار حذف خودکار پایان نگهداری در پایان این مدت‌ها اجرا نمی‌شود — هنگام پایان مدت، عملیات حذف/بی‌نام‌سازی به‌صورت دستی انجام می‌شود و با فعال شدن خودکارسازی، این سیاست به‌روزرسانی خواهد شد. عبارت "حداکثر 2 سال" در ردیف 9 (داده فرم دسترسی زودهنگام) دامنه متفاوتی دارد و چنان‌که در سطر خود توضیح داده شده، سقف حقوقی جداگانه‌ای را بیان می‌کند.

5. فرایند حذف حساب — عملکرد سرتاسری

Corenta برای پاسخ فنی به درخواست حذف صاحبان داده در چارچوب ماده 11 KVKK، معماری حذف دومرحله‌ای را اعمال می‌کند که توازن میان تجربه کاربری و نیاز امنیت داده/اثبات حقوقی را در نظر می‌گیرد: حذف نرم آنی (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) حذف نمی‌شوند، پیوند شخص قطع می‌شود — پیوند شخص در سطح پایگاه داده قطع می‌شود، برخی فیلدهای متن آزاد پاک می‌شوند و سابقه به‌عنوان سابقه مستأجر با پیوند شخصِ قطع‌شده و با دسترسی محدود باقی می‌ماند (چون متن آزاد یادداشت جلسه تغییر داده نمی‌شود، بی‌نام تلقی نمی‌شود) (نگاه کنید به بخش 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 روزه و با هدفی جداگانه و محدود همچنان نگهداری شوند. اینکه مدت‌های مشمول این استثنا با هیچ سازوکار فنی که به‌طور خودکار در سامانه اعمال شود متناظر نیستند، در یادداشت 2 بخش 4 صراحتاً بیان شده است.

5.4. توضیح ویژه درباره پیوست‌های فایل ذخیره‌شده (مهم — شفافیت)

به اقتضای اصل شفافیت صراحتاً بیان می‌شود: در جریان عملیات حذف دائمی، سوابق پایگاه داده (نمایه، نوبت، انتساب، رضایت و غیره) به‌طور کامل حذف یا (برای سوابق سلامت/بالینی/مالی، نگاه کنید به بخش 6.2) بی‌نام می‌شوند؛ اما پیوست‌های فایلی که متعلق به کاربرند و در فضای ذخیره‌سازی (Storage) جداگانه نگهداری می‌شوند به این شکل رسیدگی می‌شوند: آواتار/عکس نمایه، سند/عکس پیوست‌شده به فرم سوابق سلامت و تصویر رسید پرداخت، به‌عنوان بخشی از گام حذف دائمی به‌طور خودکار (best-effort) از Storage حذف می‌شوند — این رفتاری تأییدشده است که در حال حاضر عملاً در سامانه اجرا می‌شود. اگر عملیات حذف در یک bucket ناموفق شود، این وضعیت در لاگ ثبت می‌شود؛ اما مانع پاک‌سازی bucketهای دیگر یا گام‌های بی‌نام‌سازی/حذف دائمی حساب نمی‌شود (طراحی best-effort).

مرز صادقانه: تنها دسته فایلی که خارج از دامنه این فرایند خودکار می‌ماند، اسناد تأیید هویت/مدرک است که در فرایند ثبت‌نام متخصص/متخصص مستقل بارگذاری می‌شوند (bucket specialist-verification-docs). این اسناد از نظر فنی نه به کاربر بلکه به فرایند تأیید مستأجر (مرکز) مربوط وابسته‌اند و در سابقه پایگاه داده ارجاعی به کاربر ندارند؛ بنابراین نمی‌توان آن‌ها را به‌طور خودکار در جریان فعلی حذف حساب کاربر گنجاند. امحای این سند در فرایندی که مرکز مربوط حساب/اشتراک خود را در سطح مستأجر می‌بندد جداگانه بررسی خواهد شد (نگاه کنید به بخش 5.6)؛ تا تکمیل این کار، در درخواست‌های استثنایی از طریق hello@corenta.app ارزیابی دستی انجام می‌شود.

بنابراین در این سیاست تعهد مطلقی مبنی بر اینکه با درخواست حذف حساب "همه داده‌ها/فایل‌های متعلق به کاربر به‌طور کامل و بی‌درنگ حذف می‌شوند" داده نمی‌شود (به‌ویژه برای باقی‌مانده فنی در نسخه‌های پشتیبان نگاه کنید به بخش 6.3، و برای استثنای بالا)؛ اما در مورد دسته‌های فایلی که در بالا شرح داده شد، حذف خودکار عملاً اعمال می‌شود.

5.5. یادداشت ویژه درباره داده‌های سلامت

داده‌های سلامت ویژه مانند فرم‌های سوابق سلامت، یادداشت‌های جلسه و سوابق اندازه‌گیری نیز تابع جریان کلی حذف بالا (حذف نرم ← 30 روز ← حذف دائمی) هستند؛ اما چنان‌که در بخش 4 ردیف 2-4 و بخش 6.2 توضیح داده شده، در این جدول‌ها گام حذف دائمی از طریق قطع پیوند شخص و پاک‌سازی جزئی اعمال می‌شود — سابقه DELETE نمی‌شود، پیوند شخص قطع می‌شود و برخی فیلدهای متن آزاد پاک می‌شوند؛ سابقه بالینی (به‌ویژه محتوای فقط-افزودنی یادداشت جلسه) به‌عنوان سابقه مستأجر با پیوند شخصِ قطع‌شده و با دسترسی محدود نگهداری می‌شود و بی‌نام تلقی نمی‌شود. همچنین، به سبب درهم‌تنیدگی این دسته داده با سوابقی که مرکز با عنوان کنترل‌کننده داده نگه می‌دارد، درخواست حذف حساب/داده یک مراجع ممکن است با تکالیف نگهداری قانونی خود مرکز (برای نمونه الزامات نگهداری سوابق که ممکن است از مقررات ارائه خدمات سلامت ناشی شود) در تعارض باشد؛ روش قطع پیوند شخص و نگهداری محدود می‌کوشد میان این دو تکلیف (حقوق مراجع بر داده شخصی و تکلیف نگهداری سوابق مرکز) توازن برقرار کند. در چنین مواردی مرجع تصمیم نهایی، مرکز با عنوان کنترل‌کننده داده است؛ Corenta مطابق دستور مرکز عمل می‌کند.

5.6. حذف در سطح مرکز (مستأجر)

در صورتی که مرکز اشتراک Corenta خود را به‌طور کامل پایان دهد، برای داده مستأجرِ متعلق به مرکز و همه سوابق مراجعان زیر این مستأجر نیز همان معماری دومرحله‌ای (حذف نرم ← 30 روز ← حذف دائمی) اعمال می‌شود. مرکز، چون کنترل‌کننده داده مراجعان خود است، موظف است پیش از پایان دادن به اشتراک خود، در چارچوب تکالیف 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) در فرایند خودکار محافظت‌شده با service-role مستقیماً با DELETE به‌طور برگشت‌ناپذیر حذف می‌شود؛ سوابق مرتبطی که پس از حذف حساب به‌تنهایی ارزش کاری/اثباتی ندارند (برای نمونه اعلان‌ها، notifications — نگاه کنید به بخش 4 ردیف 10) در سطح پایگاه داده با ON DELETE CASCADE همراه آن حذف می‌شوند.
• سابقه سلامت، بالینی و مالی: برای anamnesis_forms، session_notes، measurements، payments، attendance و consent_logs، گام حذف دائمی به جای DELETE کردن سابقه، از طریق قطع پیوند شخص و پاک‌سازی جزئی (نگاه کنید به بخش 6.6) اعمال می‌شود: ستون‌های کلید خارجی که شخص را شناسایی می‌کنند (client_id، specialist_id، user_id و غیره) با محدودیت FK ON DELETE SET NULL به‌طور برگشت‌ناپذیر به NULL تبدیل می‌شوند؛ ستون‌های محتوایی که ممکن است هویت آشکار یا PII متن آزاد داشته باشند (پاسخ‌های سوابق سلامت، یادداشت‌های متن آزاد اندازه‌گیری/پرداخت، ارجاع رسید پرداخت، نشانی IP سابقه رضایت) توسط تابع anonymize_user_relations() (فقط توسط service-role قابل فراخوانی، default-deny) پاک یا با یک نشانه بی‌نام جایگزین می‌شوند. اما محتوای عددی و تاریخی بالینی/مالی (تاریخ، مبلغ، مقدار اندازه‌گیری، مانده جلسه‌ها، وضعیت آمد/نیامد، زمان اعطا/پس گرفتن رضایت) به اقتضای تکلیف نگهداری سوابق مرکز و (برای یادداشت‌های جلسه) اصل فقط-افزودنی، به‌عنوان سابقه مستأجر با پیوند شخصِ قطع‌شده همچنان نگهداری می‌شود؛ چون متن آزاد یادداشت جلسه تغییر داده نمی‌شود، این سوابق بی‌نام تلقی نمی‌شوند و با دسترسی محدود نگهداری می‌شوند.

در یادداشت‌های جلسه (session_notes) محدودیت فقط-افزودنی اجازه تغییر محتوا را نمی‌دهد؛ فقط برای تبدیل ستون‌های پیوند شخص (client_id، specialist_id) به NULL استثنایی محدود و ویژه یک هدف در نظر گرفته شده است — خود محتوای یادداشت در این فرایند نیز در هیچ مرحله‌ای حذف یا تغییر داده نمی‌شود.

مرز: برای داده شخصیِ درون متن که ممکن است در فیلدهای متن آزاد بیرون از ستون‌های هویت آشکار بیاید (برای نمونه نامی که در بدنه یک یادداشت جلسه آمده است) سازوکار پویش/پاک‌سازی وجود ندارد. بنابراین این سوابق بی‌نام تلقی نمی‌شوند؛ به‌عنوان داده شخصی با دسترسی محدود نگهداری و در پایان مدت امحا می‌شوند.

هر دو روش بالا چون با service-role محافظت می‌شوند، از طریق رابط‌های عادی محصول قابل راه‌اندازی یا بازگردانی نیستند.

6.3. حذف از نسخه‌های پشتیبان (Backup)

نسخه‌های پشتیبان پایگاه داده در چارچوب چرخه عادی پشتیبان‌گیری (چرخش) پس از مدتی معین به‌طور خودکار رونویسی/امحا می‌شوند. هرچند عملیات حذف دائمی در پایگاه داده اصلی بی‌درنگ مؤثر است، صراحتاً بیان می‌شود که داده ممکن است در نسخه‌های پشتیبانی که پیش‌تر گرفته شده‌اند، تا پایان مدت چرخش استاندارد پشتیبان ارائه‌دهنده پشتیبان‌گیری (Supabase) از نظر فنی همچنان وجود داشته باشد. این وضعیت، رویه استاندارد در دامنه قرارداد پردازش داده (DPA) پردازشگر فرعی مربوط (Supabase) است.

6.4. پیوست‌ها در فضای ذخیره‌سازی فایل (Storage)

فایل‌هایی مانند تصاویر آواتار، رسیدهای پرداخت و پیوست‌های سوابق سلامت که کاربران بارگذاری می‌کنند در فضای ذخیره‌سازی (Storage) جداگانه‌ای نگهداری می‌شوند. نگاه کنید به بخش 5.4 — وضعیت فعلی این محتواها در فرایند حذف حساب (حذف خودکار برای آواتار/پیوست سوابق سلامت/رسید پرداخت، تنها استثنا برای specialist-verification-docs) در آنجا به تفصیل و به‌طور شفاف توضیح داده شده است.

6.5. داده‌های کاغذی

داده‌های شخصی‌ای که در دامنه محصول SaaS Corenta پردازش می‌شوند در محیط دیجیتال نگهداری می‌شوند؛ پردازش داده شخصی در محیط کاغذی پیش‌بینی نشده است. در صورتی که در مکاتبات تجاری/اداری شرکت به‌طور استثنایی از محیط کاغذی استفاده شود، امحا با روش سیاه کردن/سوزاندن/خرد کردن برگشت‌ناپذیر با دستگاه کاغذخردکن انجام می‌شود.

6.6. بی‌نام‌سازی

Corenta به‌عنوان بخشی از فرایند حذف دائمی حساب (نگاه کنید به بخش 6.2)، برای داده سلامت و سوابق بالینی/مالی از روش قطع پیوند شخص و پاک‌سازی جزئی استفاده می‌کند. چون متن آزاد یادداشت جلسه تغییر داده نمی‌شود و در کسب‌وکارهای کوچک سری تاریخ و اندازه‌گیری ممکن است برای شناسایی دوباره شخص کافی باشد، این روش در همه موارد معیار بی‌نام‌سازی زیر را برآورده نمی‌کند؛ این سوابق بی‌نام تلقی نمی‌شوند، به‌عنوان داده شخصی با دسترسی محدود نگهداری و در پایان مدت امحا می‌شوند. جدا از این، 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. خلاصه صادقانه پیاده‌سازی فنی فعلی

موارد زیر به‌عنوان خلاصه‌ای صادقانه و واقع‌بینانه از پیاده‌سازی فنی فعلی ارائه می‌شوند:

• درخواست حذف (حذف حساب): می‌توان آن را مستقیماً از منوی تنظیمات مربوط درون برنامه موبایل درخواست کرد؛ این درخواست با فرایند دومرحله‌ای (حذف نرم آنی ← 30 روز ← حذف دائمی) که در بخش 5 توضیح داده شده به‌طور خودکار پاسخ داده می‌شود (ماده 11/6).
• درخواست اطلاعات / قابلیت انتقال داده: از طریق ارائه داده‌های صاحب داده در دامنه مستأجر خودش در قالبی ساختاریافته و ماشین‌خوان، ظرف مدتی معقول، به او پاسخ داده می‌شود (تابع export_user_data، دامنه مستأجر تأیید شده است). سازوکار تحویل این فرایند (ویژگی‌هایی مانند قالب فایل، روش تحویل، پیوند دانلود امضاشده) پیوسته در حال توسعه است؛ در چارچوب این سیاست تعهدی درباره مهلت تحویل معین یا قالب فایل/دسترسی خاصی داده نمی‌شود (ماده 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)، با الزام tenant_id در هر جدول و سیاست‌های امنیت سطح سطر (Row Level Security)، اصل رد پیش‌فرض (default-deny) اعمال می‌شود (37/37 جدول، 86 سیاست)؛ به این ترتیب نشت داده میان مستأجران از نظر فنی جلوگیری می‌شود.
• دسترسی به جدول‌هایی که داده سلامت دارند فقط به مراجع مربوط، متخصص منصوب و مدیر مستأجر محدود است؛ کنترل دسترسی در سطح پایگاه داده (RLS) اعمال می‌شود. یادداشت‌های جلسه پس از ارسال قابل تغییر/حذف نیستند (فقط-افزودنی)؛ برای فرم‌های سوابق سلامت به هیچ کاربری (از جمله مدیر) اختیار حذف داده نشده است.
• حالت پشتیبانی ابرمدیر (جانشینی) مدت‌دار (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 ذکر شده به فرایند بستن مستأجر، تأیید/فعال‌سازی پاک‌سازی توکن 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