মূল বিষয়ে যান
সাইন ইন
অ্যাপ ডাউনলোড করুন
Bağlayıcı metin TürkçedirBu çeviri bilgilendirme amaçlıdır. Türkçe metni açın.

1.9

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/Frankfurt বিদেশে স্থানান্তর নয়" কথাটি সরানো হয়েছে এবং বিদেশে স্থানান্তরের অংশ 6698 নম্বর আইনের ধারা 9-এর 2024-পরবর্তী রূপ অনুযায়ী লেখা হয়েছে (মানক চুক্তিগুলো এখনও স্বাক্ষরিত হয়নি); স্বাস্থ্য/ক্লিনিক্যাল/আর্থিক রেকর্ডের জন্য "বেনামী" কথাটি ব্যক্তির সঙ্গে সংযোগ বিচ্ছিন্ন সীমিত সংরক্ষণ হিসেবে সংশোধন করা হয়েছে (সেশন নোটের মুক্ত লেখা বদলানো হয় না); সম্মতির প্রমাণের সারির আইনি ভিত্তি ধারা 5(2)(e) হিসেবে সংশোধন করা হয়েছে (ভুল ধারা 20(2) উল্লেখ সরানো হয়েছে); আর্লি অ্যাক্সেস ফর্মের সারি অবহিতকরণ ও বাণিজ্যিক বার্তার সম্মতি আলাদা করা অনুযায়ী হালনাগাদ করা হয়েছে; স্বয়ংক্রিয় বিনষ্টকরণ নেই এমন শ্রেণির জন্য 6 মাস অন্তর পর্যায়ক্রমিক বিনষ্টকরণের নীতি যোগ করা হয়েছে; পরিচয়ের তথ্য একক মালিকানাধীন ব্যবসা হিসেবে সংশোধন করা হয়েছে; VERBİS অংশ 2025 সালের বোর্ডের সিদ্ধান্ত অনুযায়ী লেখা হয়েছে।
  • 1.6 — 10 অক্টোবর 2026: Expo (Expo Push Notification Service) সাব-প্রসেসর/প্রসেসরের রেকর্ড থেকে সরানো হয়েছে; পুশ নোটিফিকেশন শুধু Apple (APNs) ও Google (FCM)-এর মাধ্যমে পাঠানো হয়, Expo/EAS শুধু অ্যাপ বিল্ড করার টুল এবং শেষ ব্যবহারকারীর কোনো ডেটা প্রক্রিয়া করে না।
  • 1.5 — 10 অক্টোবর 2026: Google Analytics বাছাই সংক্রান্ত কথা সরানো হয়েছে; তৃতীয় পক্ষের অ্যানালিটিক্স ব্যবহার না করা এবং পুশ প্রসেসরদের বিষয়টি স্পষ্ট করা হয়েছে।
  • 1.4 — 4 অক্টোবর 2026: বর্তমান লেখাটি অনুমোদিত সংস্করণ হিসেবে স্থির করা হয়েছে। এই সংস্করণে শুধু এগুলো যুক্ত করা হয়েছে: অ্যাকাউন্ট মুছে ফেলা (প্রবেশ সঙ্গে সঙ্গে বন্ধ, ব্যক্তিগত ডেটা মুছে ফেলা/বেনামী করা হয়, আইনগতভাবে সংরক্ষণ করতে হয় এমন পেমেন্টের রেকর্ড পরিচয়হীনভাবে রাখা হয়; ফিরিয়ে নেওয়ার মেয়াদ নেই); 30 দিন শেষে ক্লায়েন্টের স্বাস্থ্যের ঘর মুছে ফেলা; 7 দিনের মালিকানাহীন রসিদের মেয়াদ; সাপোর্ট মোডে ক্লায়েন্টের যোগাযোগ তথ্য গোপন রাখা; পরিচয়হীন সার্ভার-পার্শ্বের পরিমাপ; সেবা ইমেইল ও Google Workspace; পুশ প্রসেসর; সাপোর্টের ঠিকানা; বাজার (তুরস্ক)।
  • 1.3 — 7 জুলাই 2026 (4 আগস্ট 2026-এর হালনাগাদ): আগের সংস্করণ।

ডেটা নিয়ন্ত্রক / ডেটা প্রসেসরের অবস্থান সম্পর্কে গুরুত্বপূর্ণ নোট: এই ডেটা সংরক্ষণ ও বিনষ্টকরণ নীতি ("নীতি") "Teta Studio" ব্যবসায়িক নামে একক মালিকানাধীন ব্যবসা হিসেবে কাজ করা Mertcan Demir ("Corenta", "Teta Studio", "কোম্পানি") কর্তৃক তৈরি ও পরিচালিত Corenta সফটওয়্যার সেবার ("সেবা" বা "অ্যাপ") আওতায় প্রক্রিয়াকৃত ব্যক্তিগত ডেটা কত দিন সংরক্ষণ করা হবে, এই মেয়াদ নির্ধারণে কোন মানদণ্ড ভিত্তি হিসেবে নেওয়া হয় এবং সংরক্ষণের মেয়াদ শেষ হলে বা প্রক্রিয়াকরণের কারণ দূর হলে এই ডেটা কোন পদ্ধতিতে মুছে ফেলা, ধ্বংস বা বেনামী করা হবে তা নিয়ন্ত্রণ করে।

এই নীতি 6698 নম্বর ব্যক্তিগত তথ্য সুরক্ষা আইন ("KVKK"), ব্যক্তিগত ডেটা মুছে ফেলা, ধ্বংস করা বা বেনামী করা সংক্রান্ত প্রবিধান ("প্রবিধান") ও সংশ্লিষ্ট অন্যান্য আইনের কাঠামোয় প্রস্তুত করা হয়েছে এবং Corenta-র ব্যক্তিগত ডেটা প্রক্রিয়াকরণের তালিকার অবিচ্ছেদ্য অংশ। এই নীতি প্রক্রিয়াকরণের উদ্দেশ্য ও আইনি ভিত্তি বিস্তারিতভাবে ব্যাখ্যা করা সংশ্লিষ্ট গোপনীয়তা বিজ্ঞপ্তি/গোপনীয়তা নীতির সঙ্গে মিলিয়ে পড়তে হবে; এই নথি শুধু সংরক্ষণের মেয়াদ ও বিনষ্টকরণের পদ্ধতি নিয়ন্ত্রণ করে এবং KVKK ধারা 10-এর আওতায় অবহিতকরণের সম্পূর্ণ বাধ্যবাধকতা একাই পূরণ করার উদ্দেশ্য রাখে না।

1. উদ্দেশ্য ও পরিধি

1.1. উদ্দেশ্য

এই নীতির উদ্দেশ্য হলো Corenta-র প্রক্রিয়াকৃত ব্যক্তিগত ডেটা যে উদ্দেশ্যে প্রক্রিয়া করা হয় তার জন্য প্রয়োজনীয় সর্বোচ্চ মেয়াদ নির্ধারণের মানদণ্ড, আইনে নির্ধারিত মেয়াদের প্রয়োগ এবং সংরক্ষণের মেয়াদ শেষ হওয়া ব্যক্তিগত ডেটা মুছে ফেলা, ধ্বংস বা বেনামী করার পদ্ধতি ও নীতি ব্যাখ্যা করা। এই নীতি KVKK ধারা 5, ধারা 6, ধারা 7, ধারা 10, ধারা 11 ও ধারা 12-এর বিধান এবং প্রবিধানের সংশ্লিষ্ট ধারাগুলোর ভিত্তিতে প্রস্তুত করা হয়েছে।

1.2. পরিধি ও ভূমিকার বিভাজন — গুরুত্বপূর্ণ সতর্কতা

এই নীতি Corenta যে দুটি ভিন্ন অবস্থানে ডেটা প্রক্রিয়া করে সেই দুটি আলাদা ক্ষেত্র অন্তর্ভুক্ত করে; এই বিভাজন নীতি জুড়ে সামঞ্জস্যপূর্ণভাবে প্রয়োগ করা হয় এবং সংরক্ষণের মেয়াদের টেবিল কীভাবে ব্যাখ্যা করা হবে তাতে সরাসরি প্রভাব ফেলে:

(a) প্রাতিষ্ঠানিক ওয়েবসাইটের প্রসঙ্গ (corenta.app — আর্লি অ্যাক্সেস/ডেমো অনুরোধের ফর্ম): প্রোডাক্টে আগ্রহী সম্ভাব্য ব্যবসায়িক সাবস্ক্রাইবাররা আর্লি অ্যাক্সেস আবেদন ফর্মের মাধ্যমে যে ব্যক্তিগত ডেটা পাঠান সে ক্ষেত্রে Corenta/Teta Studio KVKK ধারা 3 অনুযায়ী সরাসরি ডেটা নিয়ন্ত্রক হিসেবে কাজ করে।

(b) SaaS প্রোডাক্টের প্রসঙ্গ (app.corenta.app): সাবস্ক্রিপশনের মাধ্যমে Corenta প্ল্যাটফর্ম ব্যবহারকারী ক্লিনিক্যাল পিলাটিস, ফিজিওথেরাপি, রিফর্মার, ওয়েলনেস/ম্যাসাজ ও যোগব্যায়াম কেন্দ্রগুলো ("Tenant", "ব্যবসা" বা "ক্লিনিক") নিজের ক্লায়েন্টদের ("ডেটা মালিক ক্লায়েন্ট") সম্পর্কিত যে ব্যক্তিগত ডেটা (যোগাযোগের তথ্য, অ্যানামনেসিস, সেশন নোট, অ্যাপয়েন্টমেন্ট/প্যাকেজের ডেটা ইত্যাদি) প্ল্যাটফর্মে প্রবেশ করায় সে ক্ষেত্রে ক্লিনিক KVKK ধারা 3 অনুযায়ী ডেটা নিয়ন্ত্রক; Corenta/Teta Studio শুধু ডেটা প্রসেসর হিসেবে, ক্লিনিকের নির্দেশ অনুযায়ী প্রযুক্তিগত অবকাঠামো সেবা দেয়। ক্লায়েন্টদের অবহিত করার বাধ্যবাধকতা, স্পষ্ট সম্মতি নেওয়া এবং ক্লায়েন্টের ডেটা সংক্রান্ত চূড়ান্ত সংরক্ষণ/বিনষ্টকরণের সিদ্ধান্ত ক্লিনিকের আইনি দায়িত্ব। Corenta এই বাধ্যবাধকতা পালন প্রোডাক্টের ভেতরে (সম্মতি রেকর্ডের ব্যবস্থা consent_logs, মোবাইল KVKK নিশ্চিতকরণ স্ক্রিন kvkk.tsx, অডিট ট্রেইল) প্রযুক্তিগতভাবে সহজ করে, তবে ক্লিনিকের KVKK সম্মতির বাধ্যবাধকতা হস্তগত বা গ্রহণ করে না। এই প্রসঙ্গের জন্য এই নীতিতে ব্যাখ্যা করা সংরক্ষণের মেয়াদ দেখায় যে Corenta ডেটা প্রসেসর হিসেবে নিজের অবকাঠামোতে এই ডেটা বাস্তবে কত দিন রাখে; চূড়ান্ত বিনষ্টকরণের সিদ্ধান্ত ও মেয়াদ ক্লিনিকের নির্দেশ ও তার প্রযোজ্য আইনের কাঠামোয় নির্ধারিত হতে পারে।

এই নীতি Corenta-র কর্মী, ব্যবসায়িক অংশীদার ও সরবরাহকারীদের ব্যক্তিগত ডেটার সংরক্ষণ/বিনষ্টকরণের প্রক্রিয়াও সাধারণ নীতির ক্ষেত্রে অন্তর্ভুক্ত করে; তবে নীতির মূল মনোযোগ ওপরের (a) ও (b) উপধারায় সংজ্ঞায়িত সাবস্ক্রাইবার/ক্লায়েন্টের ডেটা।

1.3. ডেটা নিয়ন্ত্রক / ডেটা প্রসেসরের তথ্য

ডেটা নিয়ন্ত্রকMertcan Demir — "Teta Studio" ব্যবসায়িক নামে একক মালিকানাধীন ব্যবসা (আলাদা আইনি সত্তা নেই) · কর শনাক্তকরণ নম্বর 2771408706
প্রোডাক্টCorenta
যোগাযোগhello@corenta.app (সাধারণ যোগাযোগ ও KVKK আবেদন) · সাপোর্ট: support@corenta.app
প্রাতিষ্ঠানিক ওয়েবসাইটcorenta.app
অ্যাপ/প্রোডাক্টের ঠিকানাapp.corenta.app
VERBİS নিবন্ধনএই লেখার তারিখ পর্যন্ত নিবন্ধন নেই; বাধ্যবাধকতা বোর্ডের 2025/1572 ও 2025/2393 মানদণ্ড অনুযায়ী মূল্যায়ন করা হচ্ছে (দেখুন অংশ 12)

1.4. ভিত্তি আইন

  • 6698 নম্বর ব্যক্তিগত তথ্য সুরক্ষা আইন,
  • ব্যক্তিগত ডেটা মুছে ফেলা, ধ্বংস করা বা বেনামী করা সংক্রান্ত প্রবিধান (28.10.2017 তারিখের 30224 নম্বর সরকারি গেজেট),
  • ব্যক্তিগত ডেটা মুছে ফেলা, ধ্বংস করা বা বেনামী করা সংক্রান্ত নির্দেশিকা এবং ব্যক্তিগত তথ্য সুরক্ষা বোর্ডের ("বোর্ড") সিদ্ধান্ত,
  • 6102 নম্বর তুর্কি বাণিজ্যিক আইন (বাণিজ্যিক হিসাবখাতা ও নথি সংরক্ষণ),
  • 213 নম্বর কর পদ্ধতি আইন (আর্থিক রেকর্ড সংরক্ষণ),
  • সংশ্লিষ্ট অন্যান্য খাতভিত্তিক আইন (প্রযোজ্য মাত্রায় স্বাস্থ্যসেবা প্রদান সংক্রান্ত আইন সহ)।

2. সংজ্ঞা

পরিভাষাসংজ্ঞা
ব্যক্তিগত ডেটাপরিচয় জানা বা জানা সম্ভব এমন প্রাকৃতিক ব্যক্তি সম্পর্কিত যেকোনো তথ্য (KVKK ধারা 3(1)(d))।
বিশেষ শ্রেণির ব্যক্তিগত ডেটাস্বাস্থ্য ডেটা সহ KVKK ধারা 6-এ তালিকাভুক্ত, জানা গেলে সংশ্লিষ্ট ব্যক্তির প্রতি বৈষম্য বা ক্ষতির কারণ হতে পারে এমন প্রকৃতির ডেটা।
ডেটা নিয়ন্ত্রকব্যক্তিগত ডেটা প্রক্রিয়াকরণের উদ্দেশ্য ও উপায় নির্ধারণকারী, ডেটা রেকর্ড ব্যবস্থা প্রতিষ্ঠা ও পরিচালনার জন্য দায়ী প্রাকৃতিক/আইনি ব্যক্তি।
ডেটা প্রসেসরডেটা নিয়ন্ত্রকের দেওয়া অনুমোদনের ভিত্তিতে তার পক্ষে ব্যক্তিগত ডেটা প্রক্রিয়াকারী প্রাকৃতিক/আইনি ব্যক্তি।
রেকর্ডের মাধ্যমব্যক্তিগত ডেটা স্বয়ংক্রিয় বা অ-স্বয়ংক্রিয় উপায়ে প্রক্রিয়া করা হয় এমন যেকোনো মাধ্যম (এখানে: Supabase (Frankfurt, ইইউ)-তে হোস্ট করা ডেটাবেস, অ্যাপের ভেতরের স্টোরেজ, ব্যাকআপ)।
মুছে ফেলাব্যক্তিগত ডেটাকে সংশ্লিষ্ট ব্যবহারকারীদের জন্য কোনোভাবেই প্রবেশযোগ্য ও পুনরায় ব্যবহারযোগ্য না রাখার প্রক্রিয়া।
ধ্বংস করাব্যক্তিগত ডেটাকে কারও জন্যই কোনোভাবে প্রবেশযোগ্য, পুনরুদ্ধারযোগ্য ও পুনরায় ব্যবহারযোগ্য না রাখার প্রক্রিয়া।
বেনামী করাব্যক্তিগত ডেটাকে, অন্য ডেটার সঙ্গে মেলানো হলেও, কোনোভাবেই পরিচয় জানা বা জানা সম্ভব এমন প্রাকৃতিক ব্যক্তির সঙ্গে যুক্ত করা যায় না এমন অবস্থায় আনা।
সংরক্ষণের মেয়াদসংশ্লিষ্ট আইনে নির্ধারিত বা প্রক্রিয়াকরণের উদ্দেশ্যের জন্য প্রয়োজনীয় সময় ধরে ব্যক্তিগত ডেটা রক্ষা করা।
পর্যায়ক্রমিক বিনষ্টকরণআইনে নির্ধারিত শর্ত অনুযায়ী, স্বতঃপ্রণোদিতভাবে ও নিয়মিত বিরতিতে করা মুছে ফেলা, ধ্বংস বা বেনামী করার প্রক্রিয়া।
Tenant / ব্যবসা / ক্লিনিকCorenta প্ল্যাটফর্মে একটি আলাদা অ্যাকাউন্টের সমতুল্য, ডেটা অন্য ব্যবসা থেকে যৌক্তিকভাবে বিচ্ছিন্ন, ক্লিনিক্যাল পিলাটিস/ফিজিওথেরাপি/রিফর্মার/ওয়েলনেস/যোগব্যায়াম কেন্দ্রের ভাড়াটে একক।
বিনষ্টকরণব্যক্তিগত ডেটা মুছে ফেলা, ধ্বংস বা বেনামী করার প্রক্রিয়ার সাধারণ নাম।

3. সংরক্ষণ ও বিনষ্টকরণের মেয়াদ নির্ধারণের মানদণ্ড (KVKK ধারা 5, ধারা 6)

3.1. সংরক্ষণের প্রয়োজনীয়তা সৃষ্টিকারী কারণ

Corenta-র ভেতরে ব্যক্তিগত ডেটা শুধু সংশ্লিষ্ট আইনে স্পষ্টভাবে নির্ধারিত মেয়াদ পর্যন্ত বা প্রক্রিয়াকরণের উদ্দেশ্যের জন্য প্রয়োজনীয় মেয়াদ পর্যন্ত রক্ষা করা হয়। সংরক্ষণের মেয়াদ নির্ধারণে নিচের মানদণ্ডগুলো ভিত্তি হিসেবে নেওয়া হয়:

  1. আইনগত সংরক্ষণের বাধ্যবাধকতা আছে কি? (যেমন তুর্কি বাণিজ্যিক আইন, কর পদ্ধতি আইনের আওতাভুক্ত আর্থিক রেকর্ডের সর্বনিম্ন সংরক্ষণের মেয়াদ।)
  2. ডেটা কোন উদ্দেশ্যে প্রক্রিয়া করা হয়েছে এবং সেই উদ্দেশ্য এখনও বৈধ কি? (KVKK ধারা 5(2) — উদ্দেশ্যের মধ্যে সীমাবদ্ধতার নীতি।)
  3. চুক্তি সম্পাদন/বাস্তবায়নের জন্য প্রয়োজনীয় কি? (যেমন সাবস্ক্রিপশন/সেবার সম্পর্ক চলাকালীন অ্যাপয়েন্টমেন্ট ও প্যাকেজের ডেটা।)
  4. কোনো অধিকার প্রতিষ্ঠা, প্রয়োগ বা সুরক্ষার জন্য (সম্ভাব্য আইনি বিরোধে প্রমাণ হিসেবে) প্রয়োজনীয় কি? (দায়বদ্ধতা আইনের সাধারণ তামাদির মেয়াদ বিবেচনায় নিয়ে।)
  5. ডেটা মালিকের স্পষ্ট সম্মতি আছে কি এবং সেই সম্মতি এখনও বৈধ কি?
  6. Corenta-র বা ক্লিনিকের বৈধ স্বার্থ আছে কি? (যেমন নিরাপত্তা লগ, প্রতারণা/অপব্যবহার শনাক্তকরণ।)
  7. ডেটা কি বিশেষ শ্রেণির (স্বাস্থ্য) ডেটার শ্রেণিতে পড়ে? সে ক্ষেত্রে KVKK ধারা 6 অনুযায়ী আরও কঠোর প্রবেশ সীমা ও যৌক্তিকতা প্রয়োগ করা হয়; সংরক্ষণের মেয়াদ কখনো উদ্দেশ্যের বাইরে বাড়ানো হয় না।

ওপরের কোনো মানদণ্ডই নির্দিষ্ট কোনো ব্যক্তিগত ডেটার জন্য সংরক্ষণ প্রয়োজনীয় না করলে ডেটা অবিলম্বে মুছে ফেলা, ধ্বংস বা বেনামী করা হয়।

3.2. বিনষ্টকরণের প্রয়োজনীয়তা সৃষ্টিকারী কারণ

ব্যক্তিগত ডেটা নিচের ক্ষেত্রে, সংশ্লিষ্ট ব্যক্তির অনুরোধে বা Corenta/ক্লিনিক স্বতঃপ্রণোদিতভাবে মুছে ফেলে, ধ্বংস বা বেনামী করে:

a) প্রক্রিয়াকরণের ভিত্তি আইনি বিধান পরিবর্তন বা বাতিল হওয়া, b) প্রক্রিয়াকরণ বা সংরক্ষণ প্রয়োজনীয় করা উদ্দেশ্য দূর হওয়া, c) স্পষ্ট সম্মতিভিত্তিক প্রক্রিয়াকরণে ডেটা মালিক নিজের সম্মতি প্রত্যাহার করা, d) KVKK ধারা 11-এর আওতায় অধিকারের কাঠামোয় ডেটা মালিক মুছে ফেলা/ধ্বংস করার অনুরোধ করা এবং সেই অনুরোধ যথাযথ বিবেচিত হওয়া (অ্যাকাউন্ট মুছে ফেলার অনুরোধ), e) ব্যক্তিগত ডেটার সংরক্ষণের মেয়াদ শেষ হওয়া এবং সংরক্ষণ প্রয়োজনীয় করে এমন কোনো আইনি কারণ অবশিষ্ট না থাকা, f) চুক্তি একেবারেই সম্পাদিত না হওয়া, অবৈধ হওয়া, অবসান হওয়া বা চুক্তি থেকে সরে আসা, g) অ্যাকাউন্ট মুছে ফেলার অনুরোধ এই নীতির ধারা 5-এ উল্লিখিত প্রক্রিয়ার মধ্যে চূড়ান্তভাবে সম্পন্ন হওয়া।

4. ডেটার শ্রেণি, সংরক্ষণের মেয়াদ ও বিনষ্টকরণের পদ্ধতির টেবিল

নিচের টেবিল Corenta অবকাঠামোতে প্রক্রিয়াকৃত প্রধান ব্যক্তিগত ডেটার শ্রেণি, সংরক্ষণের মেয়াদ, তার কারণ এবং মেয়াদ শেষে প্রয়োগ করা বিনষ্টকরণের পদ্ধতি দেখায়। স্পষ্টভাবে ভিন্ন কিছু বলা না থাকলে সাধারণ নিয়ম হলো: "সংশ্লিষ্ট অ্যাকাউন্ট/রেকর্ড সক্রিয় থাকা পর্যন্ত + অ্যাকাউন্ট মুছে ফেলার অনুরোধ প্রক্রিয়ায় নেওয়ার সময় থেকে 30 দিন।" টেবিলটি অংশ 5-এ ব্যাখ্যা করা অ্যাকাউন্ট মুছে ফেলার প্রক্রিয়ার সঙ্গে মিলিয়ে পড়তে হবে। কিছু শ্রেণির জন্য এই প্রক্রিয়ার 30 দিন শেষের ধাপ DELETE (স্থায়ী মুছে ফেলা) নয়, বেনামী করা — সংশ্লিষ্ট সারিতে ও অংশ 6.2-এ এই পার্থক্য স্পষ্টভাবে উল্লেখ করা হয়েছে।

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

#ডেটার শ্রেণিডেটার ঘরের উদাহরণসংরক্ষণের মেয়াদকারণ / আইনি ভিত্তিবিনষ্টকরণের পদ্ধতি
1পরিচয় ও যোগাযোগের ডেটা (ব্যবহারকারী/স্পেশালিস্ট/ক্লায়েন্ট)নাম-পদবি, ইমেইল, ফোন, জন্মতারিখ, প্রোফাইলের তথ্যঅ্যাকাউন্ট/ক্লায়েন্ট রেকর্ড সক্রিয় থাকা পর্যন্ত + মুছে ফেলার অনুরোধের পরে 30 দিনKVKK ধারা 5 — চুক্তি সম্পাদন/বাস্তবায়ন; সেবায় প্রবেশ নিশ্চিত করা। ক্লায়েন্টের ডেটার ক্ষেত্রে ডেটা নিয়ন্ত্রক হলো ক্লিনিক।ধাপ-1 soft-delete → ধাপ-2 স্থায়ী মুছে ফেলা (দেখুন ধারা 5)
2স্বাস্থ্য ডেটা / অ্যানামনেসিস ফর্ম (anamnesis_forms)স্বাস্থ্যের ইতিহাস, ব্যথা/অভিযোগের তথ্য, চিকিৎসাগত নিষেধাজ্ঞাক্লায়েন্ট রেকর্ড সক্রিয় থাকা পর্যন্ত + মুছে ফেলার অনুরোধের পরে 30 দিন। anamnesis_forms-এর জন্য সিস্টেমে কোনো DELETE (মুছে ফেলা) নীতি সংজ্ঞায়িত নেই — রেকর্ডটি কেউ (প্রশাসনিক ব্যবহারকারী সহ) দৈনন্দিন ব্যবহারে হাতে মুছতে পারে না। 30 দিনের মেয়াদ শেষে রেকর্ডটি DELETE করা হয় না; ব্যক্তির সঙ্গে সংযোগ বিচ্ছিন্ন করা হয়: ব্যক্তির সংযোগ (client_id) ডেটাবেস পর্যায়ে অপরিবর্তনীয়ভাবে বিচ্ছিন্ন করা হয় (FK ON DELETE SET NULL) এবং প্রশ্নাবলির বিষয়বস্তু (answers) ও সংযুক্ত ফাইলের উল্লেখ (attached_files) একটি বেনামী চিহ্ন দিয়ে বদলানো হয়; সংযুক্ত ফাইলটিও Storage থেকে আলাদাভাবে স্বয়ংক্রিয়ভাবে মুছে ফেলা হয় (দেখুন ক্রম 11)।KVKK ধারা 6 — বিশেষ শ্রেণির ডেটা; ক্লিনিক্যাল সেবা দিতে পারা এবং সম্ভাব্য চিকিৎসাগত/আইনি দায় প্রমাণের জন্য প্রয়োজনীয় (ডেটা নিয়ন্ত্রক: ক্লিনিক); ক্লিনিকের রেকর্ড রাখার বাধ্যবাধকতার কারণে ক্লিনিক্যাল রেকর্ডটি নিজে (ক্লায়েন্টের সঙ্গে সংযোগ বিচ্ছিন্ন অবস্থায়) tenant-এ সীমিত প্রবেশাধিকারসহ সংরক্ষিত থাকে; এই রেকর্ড বেনামী হিসেবে গণ্য হয় না। প্রবেশ সংশ্লিষ্ট ক্লায়েন্ট/নির্ধারিত স্পেশালিস্ট/tenant অ্যাডমিনে সীমিত (RLS)।ধাপ-1 soft-delete (প্রবেশ বন্ধ) → ধাপ-2 বেনামী করা (anonymize_user_relations() RPC, শুধু service-role) + ব্যক্তির সঙ্গে সংযোগ FK দিয়ে বিচ্ছিন্ন করা
3সেশন নোট (session_notes)সেশনের সময় স্পেশালিস্টের প্রবেশ করানো ক্লিনিক্যাল নোটওপরের মতোই। নোট পাঠানোর পরে (submitted_at ঘর পূরণ হওয়ার পরে) UPDATE/DELETE দিয়ে বদলানো বা মুছে ফেলা যায় না (append-only কাঠামো, ডেটাবেস পর্যায়ে প্রয়োগ করা) এবং অ্যাকাউন্ট মুছে ফেলার প্রক্রিয়াতেও এই বিষয়বস্তু বদলানো হয় না। ধাপ-2-এ শুধু ব্যক্তির সংযোগ (client_id, specialist_id) FK ON DELETE SET NULL দিয়ে বিচ্ছিন্ন করা হয়; append-only ট্রিগারে এই একক উদ্দেশ্যের জন্য একটি সংকীর্ণ ব্যতিক্রম সংজ্ঞায়িত আছে (শুধু সংযোগের কলাম NULL করার অনুমতি দেয়, নোটের বিষয়বস্তুতে একটি অক্ষরও বদলানোর অনুমতি দেয় না)। ফলাফল: নোটের মূল অংশের মুক্ত লেখায় নাম/পরিচয়ের তথ্য থেকে যেতে পারে বলে এই রেকর্ডগুলো অ্যাকাউন্ট মুছে ফেলার পরে বেনামী হিসেবে গণ্য হয় না; ক্লিনিকের রেকর্ড রাখার বাধ্যবাধকতার মেয়াদ জুড়ে সীমিত প্রবেশাধিকারসহ সংরক্ষণ করা হয় এবং মেয়াদ শেষে বিনষ্ট করা হয়। মুছে ফেলার সময় মুক্ত লেখা পরিষ্কার করা আলাদাভাবে বিবেচনা করা হবে এমন একটি প্রোডাক্ট সিদ্ধান্ত।KVKK ধারা 6 — বিশেষ শ্রেণির ডেটা; ক্লিনিক্যাল রেকর্ডের অখণ্ডতা এবং সম্ভাব্য চিকিৎসাগত দায়ের ক্ষেত্রে প্রমাণ। অপরিবর্তনীয়তা রেকর্ডের নির্ভরযোগ্যতা রক্ষার উদ্দেশ্যে সচেতনভাবে নেওয়া একটি নকশাগত পছন্দ; অ্যাকাউন্ট মুছে ফেলার পরেও ক্লিনিক্যাল রেকর্ডের অখণ্ডতা একই নীতিতে রক্ষা করা হয়।একই; append-only সীমা বজায় রেখে শুধু ব্যক্তির সংযোগ FK দিয়ে বিচ্ছিন্ন করা হয় — নোটের বিষয়বস্তু কোনো ধাপেই মুছে ফেলা বা বদলানো হয় না
4পরিমাপের ডেটা (measurements)শরীরের পরিমাপ, অগ্রগতি অনুসরণের মতো ক্লিনিক্যাল পরিমাপওপরের মতোই। ধাপ-2-এ রেকর্ড মুছে ফেলা হয় না; ব্যক্তির সঙ্গে সংযোগ বিচ্ছিন্ন করা হয়: ব্যক্তির সংযোগ (client_id) FK ON DELETE SET NULL দিয়ে বিচ্ছিন্ন করা হয়, মুক্ত লেখার notes ঘর (নাম/পরিচয় থাকতে পারে) NULL করা হয়; সংখ্যাগত/শ্রেণিগত পরিমাপের মান (ওজন, VAS, ঘুম ইত্যাদি) tenant-এর ব্যক্তির সঙ্গে সংযোগ বিচ্ছিন্ন ক্লিনিক্যাল রেকর্ড হিসেবে সংরক্ষিত থাকে (ছোট ব্যবসায় পরিমাপের ধারা ব্যক্তিকে আবার শনাক্ত করতে যথেষ্ট হতে পারে বলে বেনামী হিসেবে গণ্য হয় না)।KVKK ধারা 6 — বিশেষ শ্রেণির ডেটা; সেবা (অগ্রগতি অনুসরণ) বাস্তবায়নের জন্য প্রয়োজনীয় (ডেটা নিয়ন্ত্রক: ক্লিনিক); সংখ্যাগত পরিমাপের ধারা ক্লিনিকের রেকর্ড রাখার বাধ্যবাধকতা ও অগ্রগতি অনুসরণের অখণ্ডতার জন্য ব্যক্তির সঙ্গে সংযোগ বিচ্ছিন্ন অবস্থায় রক্ষা করা হয়।ধাপ-1 soft-delete → ধাপ-2 বেনামী করা (anonymize_user_relations() RPC) + ব্যক্তির সঙ্গে সংযোগ FK দিয়ে বিচ্ছিন্ন করা
5অ্যাপয়েন্টমেন্ট, প্যাকেজ ও পেমেন্টের ডেটাঅ্যাপয়েন্টমেন্টের তারিখ, প্যাকেজ/সেশনের ব্যালান্স, বাতিলের রেকর্ড, পেমেন্ট/সংগ্রহের রেকর্ড (payments), উপস্থিতির রেকর্ড (attendance)অ্যাকাউন্ট সক্রিয় থাকা পর্যন্ত + মুছে ফেলার অনুরোধের পরে 30 দিন। অ্যাপয়েন্টমেন্টের রেকর্ড নিজে (appointments.client_id) নকশাগতভাবে আগে থেকেই nullable; মুছে ফেলার পরে ব্যক্তির সঙ্গে সংযোগ বিচ্ছিন্ন করা হয় এবং অ্যাপয়েন্টমেন্টের ইতিহাস (তারিখ/সেবা/অবস্থা) tenant-এর রেকর্ড হিসেবে থেকে যায়। পেমেন্টের রেকর্ড (payments) ও উপস্থিতির রেকর্ডও (attendance) একইভাবে DELETE করা হয় না; ব্যক্তির সঙ্গে সংযোগ বিচ্ছিন্ন করা হয়: ব্যক্তির সংযোগ (client_id) FK ON DELETE SET NULL দিয়ে বিচ্ছিন্ন করা হয়; পেমেন্টে মুক্ত লেখার নোট, রিফান্ডের কারণ ও রসিদের ছবির উল্লেখ (নাম থাকতে পারে) NULL করা হয় এবং রসিদের ফাইলটি Storage থেকে আলাদাভাবে স্বয়ংক্রিয়ভাবে মুছে ফেলা হয় (দেখুন ক্রম 11), পরিমাণ/তারিখ/অবস্থার তথ্য থেকে যায়; উপস্থিতিতে মুক্ত লেখার notes NULL করা হয়, এসেছেন/আসেননি অবস্থা থেকে যায়। client_packages (প্যাকেজের ব্যালান্স) টেবিলে সরাসরি ব্যক্তিগত/মুক্ত লেখার ডেটার কলাম নেই বলে এই টেবিল অপরিবর্তিত থেকে tenant-এর রেকর্ড হিসেবে থেকে যায়।KVKK ধারা 5 — চুক্তির বাস্তবায়ন; এ ছাড়া বিরোধ হলে (প্যাকেজের প্রাপ্যতা/ফি নিয়ে মতবিরোধ ইত্যাদি) প্রমাণ হতে পারে; ক্লিনিকের রেকর্ড রাখার বাধ্যবাধকতা এই ডেটা ব্যক্তির সঙ্গে সংযোগ বিচ্ছিন্ন অবস্থায় সংরক্ষণ প্রয়োজনীয় করে।ধাপ-1 soft-delete → ধাপ-2: অ্যাপয়েন্টমেন্ট/প্যাকেজের রেকর্ড থেকে যায়, পেমেন্ট ও উপস্থিতির রেকর্ড বেনামী করা (anonymize_user_relations() RPC) + ব্যক্তির সঙ্গে সংযোগ FK দিয়ে বিচ্ছিন্ন করার মাধ্যমে প্রক্রিয়া করা হয়; client_packages-এর জন্য কোনো পরিবর্তন প্রয়োজন নেই (PII কলাম নেই)
6সাবস্ক্রিপশন/লেনদেনের মেটাডেটা (IAP)প্ল্যানের নাম, সাবস্ক্রিপশনের অবস্থা, লেনদেনের তারিখ, IAP লেনদেন/সাবস্ক্রিপশনের মেটাডেটাকোম্পানির নিজস্ব হিসাবরক্ষণ/আর্থিক আইনের বাধ্যবাধকতার আওতাভুক্ত রেকর্ডের জন্য তুর্কি বাণিজ্যিক আইনের ধারা 82 ও কর পদ্ধতি আইনের ধারা 253 অনুযায়ী নির্ধারিত আইনগত সংরক্ষণের মেয়াদ জুড়ে (সাধারণ চর্চায় সর্বনিম্ন 10 বছর পর্যন্ত)6102 নম্বর TTK ধারা 82, 213 নম্বর VUK ধারা 253 — আইনগত সংরক্ষণের বাধ্যবাধকতা। গুরুত্বপূর্ণ স্পষ্টীকরণ: Corenta-র পেমেন্ট মডেল একচেটিয়াভাবে Apple/Google অ্যাপের ভেতরের কেনাকাটার (IAP) মাধ্যমে চলে; চূড়ান্ত ভোক্তার বিলিং/রসিদ Apple/Google প্রস্তুত ও সংরক্ষণ করে, Corenta এই নথিগুলো তৈরি বা সংরক্ষণ করে না। Corenta-র IAP মডেলে কার্ড/পেমেন্ট মাধ্যমের তথ্য Apple/Google প্রক্রিয়া ও সংরক্ষণ করে; Corenta-র নিজস্ব অবকাঠামোতে (ডেটাবেস, লগ) এ ধরনের পেমেন্ট মাধ্যমের তথ্য সংরক্ষিত থাকার কিছু শনাক্ত হয়নি। Corenta শুধু যাচাই করা IAP সাবস্ক্রিপশনের মেটাডেটা (প্ল্যানের নাম, লেনদেনের তারিখ, সাবস্ক্রিপশনের অবস্থা) TTK/VUK-এ নির্ধারিত আইনগত মেয়াদ জুড়ে সংরক্ষণ করে। কোম্পানি এর বাইরে আলাদাভাবে সাধারণ হিসাবখাতা ও নথি রাখলে, সেই রেকর্ডগুলোও একই TTK/VUK মেয়াদের আওতায় থাকে, তবে এই নীতির বিষয় ব্যক্তিগত ডেটার শ্রেণি থেকে আলাদা, নিজস্ব আর্থিক আইনি ব্যবস্থার অধীন একটি পরিধি গঠন করে; এই নথি সেই আলাদা পরিধির অস্তিত্ব বা বিষয়বস্তু দাবি করে না। এই শ্রেণি অ্যাকাউন্ট মুছে ফেলার অনুরোধে প্রভাবিত হয় না; অ্যাকাউন্ট মুছে ফেলা হলেও সংশ্লিষ্ট আইনগত মেয়াদ শেষ না হওয়া পর্যন্ত, প্রক্রিয়াকরণের উদ্দেশ্য থেকে আলাদা করে এবং শুধু আইনগত বাধ্যবাধকতা পালনের উদ্দেশ্যে সীমিত প্রবেশাধিকারসহ আলাদাভাবে রক্ষা করা হয়।আইনগত মেয়াদ শেষে মুছে ফেলা বা বেনামী করা
7অডিট ট্রেইলের রেকর্ড (audit_logs)সিস্টেমের ভেতরের গুরুত্বপূর্ণ কাজের (ইমপারসোনেশন, অনুমতির পরিবর্তন, ডেটায় প্রবেশ ইত্যাদি) রেকর্ডরেকর্ড তৈরির তারিখ থেকে 2 বছর সংরক্ষণ করা হয় — নিরাপত্তা ঘটনা শনাক্তকরণ, অননুমোদিত প্রবেশের তদন্ত ও অপব্যবহার প্রতিরোধের উদ্দেশ্যে বৈধ স্বার্থ এবং সম্ভাব্য আইনি বিরোধে প্রমাণের বাধ্যবাধকতার কাঠামোয় নির্ধারিত একটি নির্দিষ্ট মেয়াদ। মেয়াদ শেষ হওয়া রেকর্ড 6 মাস অন্তর করা পর্যায়ক্রমিক বিনষ্টকরণে মুছে ফেলা হয়; এই বিনষ্টকরণ আজ হাতে করা হচ্ছে, নির্ধারিত সময়সূচির স্বয়ংক্রিয় বিনষ্টকরণের কাজ এখনও নেই। অ্যাকাউন্ট মুছে ফেলা হলেও এই রেকর্ড 2 বছরের মেয়াদ শেষ না হওয়া পর্যন্ত আলাদাভাবে রক্ষা করা হয়।KVKK ধারা 5(2)(f) — বৈধ স্বার্থ (নিরাপত্তা ঘটনা শনাক্তকরণ, অননুমোদিত প্রবেশের তদন্ত, অপব্যবহার প্রতিরোধ) এবং সম্ভাব্য আইনি বিরোধে প্রমাণ হওয়া। এই রেকর্ডগুলো প্রকৃতিগতভাবে সংশ্লিষ্ট ব্যক্তির মধ্যে সীমিত নয়, সিস্টেমের নিরাপত্তা/জবাবদিহির উদ্দেশ্য পূরণ করে; সংশ্লিষ্ট ব্যবহারকারীর অ্যাকাউন্ট মুছে ফেলার অনুরোধ এই রেকর্ডগুলো স্বয়ংক্রিয়ভাবে মুছে ফেলে না।সংরক্ষণের মেয়াদ শেষে মুছে ফেলা বা বেনামী করা (স্বয়ংক্রিয় পরিষ্কারের ব্যবস্থা এখনও প্রয়োগ করা হয়নি)
8অবহিতকরণ ও অনুমতির রেকর্ড (consent_logs)অবহিতকরণ দেখানো ("পড়েছি, বুঝেছি"; সম্মতি নয়), স্বাস্থ্য ডেটার সম্মতি, ক্যাম্পেইন নোটিফিকেশনের অনুমতি, পুশ অনুমতির রেকর্ড; সময়, IP ঠিকানা, সংস্করণের তথ্য, প্রত্যাহারের (revoked_at) রেকর্ডঅ্যাকাউন্ট সক্রিয় থাকা পর্যন্ত + মুছে ফেলার অনুরোধের পরে 30 দিন; এই 30 দিনের মেয়াদের পরে, সম্মতি দেওয়া বা প্রত্যাহারের প্রমাণের উদ্দেশ্যে (সম্ভাব্য KVKK অভিযোগ/পরিদর্শনের জন্য আলাদা প্রমাণ-রেকর্ড হিসেবে) 5 বছর আলাদাভাবে সংরক্ষণ করা হয় — বৈধ স্বার্থ ও প্রমাণের বাধ্যবাধকতার কাঠামোয় নির্ধারিত একটি নির্দিষ্ট মেয়াদ। এই 5 বছরের প্রমাণ-সংরক্ষণ বাস্তবে সম্ভব করা হয়েছে স্থায়ী মুছে ফেলার ধাপে রেকর্ডের ব্যক্তির সঙ্গে সংযোগ (user_id) FK ON DELETE SET NULL দিয়ে বিচ্ছিন্ন করে এবং IP ঠিকানা (ip_address) খালি করে, ব্যক্তির সঙ্গে সংযোগ বিচ্ছিন্ন একটি প্রমাণ-রেকর্ড হিসেবে; সম্মতির ধরন, সংস্করণ এবং দেওয়া/প্রত্যাহারের সময়ের তথ্য ব্যক্তি থেকে স্বাধীনভাবে সংরক্ষিত থাকে। 5 বছরের মেয়াদ শেষ হওয়া রেকর্ড 6 মাস অন্তর করা পর্যায়ক্রমিক বিনষ্টকরণে মুছে ফেলা হয় (আজ হাতে; নির্ধারিত সময়সূচির স্বয়ংক্রিয় বিনষ্টকরণের কাজ এখনও নেই)।KVKK ধারা 5(2)(e) (অধিকার প্রতিষ্ঠা, প্রয়োগ বা সুরক্ষা) ও ধারা 5(2)(f); স্পষ্ট সম্মতির প্রমাণের দায় ডেটা নিয়ন্ত্রকের (বোর্ডের নীতিগত সিদ্ধান্ত 2026/347); দায়বদ্ধতা আইনের সাধারণ তামাদির মেয়াদের সঙ্গে সামঞ্জস্যপূর্ণ।অ্যাকাউন্ট স্থায়ীভাবে মুছে ফেলার প্রক্রিয়ায় রেকর্ড DELETE করা হয় না; ব্যক্তির সংযোগ FK দিয়ে বিচ্ছিন্ন করা হয় এবং IP ঠিকানা বেনামী করা হয় (anonymize_user_relations() RPC) — ব্যক্তির সঙ্গে সংযোগ বিচ্ছিন্ন প্রমাণ-রেকর্ড 5 বছর সংরক্ষিত থাকে (5 বছর পরের জন্য 6 মাস অন্তর পর্যায়ক্রমিক বিনষ্টকরণ; স্বয়ংক্রিয় কাজ এখনও নেই)
9আর্লি অ্যাক্সেস ফর্মের ডেটা (প্রাতিষ্ঠানিক ওয়েব)নাম-পদবি, ইমেইল, ফোন (ঐচ্ছিক), ব্যবসার নাম, শহর, ব্যবসার ধরন, স্পেশালিস্ট/ইনস্ট্রাক্টরের সংখ্যা, মেসেজ/পরিচালনাগত সমস্যার বিষয়বস্তু, IP ঠিকানা/ডিভাইস/ব্রাউজার/কুকির তথ্যআবেদনের মূল্যায়ন ও যোগাযোগ প্রক্রিয়া শেষ হওয়ার পর থেকে সর্বোচ্চ 2 বছর; এই সময়ের মধ্যে যোগাযোগ না হলে বা প্রক্রিয়া শেষ হলে আরও কম সময়ে মুছে ফেলা/বেনামী করা হয়। স্বচ্ছতার নোট: এই সর্বোচ্চ মেয়াদের সঙ্গে মেলে এমন, সিস্টেমে স্বয়ংক্রিয়ভাবে চলা কোনো স্ক্যান/মুছে ফেলার ব্যবস্থা এখন নেই (দেখুন নোট 2 ও অংশ 7, উপধারা 3) — মেয়াদটি একটি আইনি ঊর্ধ্বসীমা; মেয়াদ শেষ হওয়া রেকর্ড 6 মাস অন্তর করা পর্যায়ক্রমিক বিনষ্টকরণে (আজ হাতে) বা অনুরোধে মুছে ফেলা হয়।KVKK ধারা 5 — চুক্তি-পূর্ব আলোচনা (ধারা 5(2)(c)); বৈধ স্বার্থ (লক্ষ্য সাবস্ক্রাইবার প্রোফাইলের সঙ্গে মিলের মূল্যায়ন, বাজার গবেষণা, প্রোডাক্ট উন্নয়নের তথ্য, সাইটের নিরাপত্তা/পারফরম্যান্স); বাণিজ্যিক বার্তার সম্মতি দেওয়া থাকলে 6563 নম্বর আইনের ধারা 6 অনুযায়ী আলাদা সম্মতি। বাণিজ্যিক বার্তার সম্মতি সংক্রান্ত স্পষ্টীকরণ: ফর্মে অবহিতকরণের জন্য কোনো সম্মতির ঘর নেই (KVKK গোপনীয়তা বিজ্ঞপ্তি A.7; অবহিতকরণ ও সম্মতি আলাদা)। বাণিজ্যিক বার্তার সম্মতি একটি আলাদা ও আগে থেকে টিক না দেওয়া ঘরে নেওয়া হয় ("Teta Studio-কে ইমেইলে Corenta-র ঘোষণা ও ক্যাম্পেইন পাঠাতে আমি সম্মতি দিচ্ছি।"); ঘরে টিক না দিলে আবেদনের মূল্যায়নে প্রভাব পড়ে না।মুছে ফেলা বা বেনামী করা (এখন হাতে/অনুরোধে প্রয়োগ করা হয়)
10পুশ নোটিফিকেশনের সম্মতি/টোকেন ডেটা ও নোটিফিকেশনের রেকর্ড (notifications)নোটিফিকেশনের অনুমতি দেওয়া/প্রত্যাখ্যানের রেকর্ড, ডিভাইসের পুশ টোকেন (Apple APNs / Google FCM), পাঠানো নোটিফিকেশন নিজে (শিরোনাম/বিষয়বস্তু/ডিপ লিংক — notifications টেবিল)অ্যাকাউন্ট/ডিভাইসের রেকর্ড সক্রিয় থাকা / নোটিফিকেশনের অনুমতি বৈধ থাকা পর্যন্ত + অ্যাকাউন্ট মুছে ফেলার অনুরোধের পরে 30 দিন; ব্যবহারকারী অনুমতি প্রত্যাহার করলে টোকেন সঙ্গে সঙ্গে অকার্যকর করা হয়। পাঠানো নোটিফিকেশনের রেকর্ডের (notifications) অ্যাকাউন্ট মুছে ফেলার পরে স্বাধীন কোনো ব্যবসায়িক/প্রমাণমূল্য নেই; তাই স্থায়ী মুছে ফেলার ধাপে অ্যাকাউন্টের সঙ্গে সম্পূর্ণ মুছে ফেলা হয় (ON DELETE CASCADE) — বেনামী করা হয় না, আলাদাভাবে সংরক্ষণও করা হয় না। স্বচ্ছতার নোট: অকার্যকর/মেয়াদোত্তীর্ণ পুশ টোকেন অ্যাকাউন্ট সক্রিয় থাকা অবস্থায়ও আলাদাভাবে স্বয়ংক্রিয় ও পর্যায়ক্রমিকভাবে পরিষ্কার করা হয় — এমন কোনো ব্যবস্থা এই নীতি প্রস্তুতের সময় প্রযুক্তিগতভাবে যাচাই করা যায়নি; বিষয়টি যাচাই করা হয়নি; যাচাই হলে বা যোগ করা হলে এই নীতি হালনাগাদ করা হবে।KVKK ধারা 5(2)(c) — চুক্তির বাস্তবায়ন (অ্যাপয়েন্টমেন্টের রিমাইন্ডারের মতো লেনদেনমূলক নোটিফিকেশন); ক্যাম্পেইন নোটিফিকেশনের জন্য আলাদা ঐচ্ছিক অনুমতি।ধাপ-1 soft-delete → ধাপ-2: notifications রেকর্ড অ্যাকাউন্টের সঙ্গে সম্পূর্ণ মুছে ফেলা হয় (DELETE/cascade); অ্যাকাউন্ট সক্রিয় থাকা অবস্থায় অকার্যকর/মেয়াদোত্তীর্ণ টোকেন আলাদাভাবে পরিষ্কার করা একটি পরিকল্পিত উন্নয়ন, এর স্বয়ংক্রিয় প্রয়োগ এখন যাচাই করা হয়নি
11ফাইল সংযুক্তি (অ্যাভাটার, পেমেন্টের রসিদ, অ্যানামনেসিসের সংযুক্তি, স্পেশালিস্ট যাচাইয়ের নথি — Supabase Storage)ক্যামেরা/গ্যালারি থেকে আপলোড করা ছবি/নথির সংযুক্তিঅ্যাকাউন্ট/tenant সক্রিয় থাকা পর্যন্ত; অ্যাকাউন্ট স্থায়ীভাবে মুছে ফেলার ধাপে ব্যবহারকারীর প্রোফাইল/অ্যানামনেসিস ফোল্ডারের ফাইল (avatars, anamnesis-attachments, user-data-exports bucket) এবং পেমেন্টের রসিদের ছবি (payment-receipts bucket, DB রেকর্ড থেকে পড়া ফাইলের পথ দিয়ে) স্বয়ংক্রিয়ভাবে (best-effort) Storage থেকে মুছে ফেলা হয় — কোনো bucket-এ মুছে ফেলা ব্যর্থ হলে ত্রুটি লগ করা হয়, তবে অন্য bucket-এর পরিষ্কারকরণ বা অ্যাকাউন্টের বেনামীকরণ/স্থায়ী মুছে ফেলার ধাপ আটকায় না। সৎ সীমা: স্পেশালিস্টের পরিচয়/ডিপ্লোমা যাচাইয়ের নথি (specialist-verification-docs bucket) এই স্বয়ংক্রিয় প্রক্রিয়ায় অন্তর্ভুক্ত নয় — এই নথি ব্যবহারকারীর নয়, tenant-এর (ক্লিনিকের) একক-স্পেশালিস্ট যাচাই প্রক্রিয়ার এবং ডেটাবেসের রেকর্ডে কোনো ব্যবহারকারীর উল্লেখ বহন করে না, তাই বর্তমান ব্যবহারকারী-অ্যাকাউন্ট মুছে ফেলার প্রক্রিয়ার সঙ্গে যুক্ত করা যায় না; এর বিনষ্টকরণ ক্লিনিক tenant পর্যায়ে নিজের অ্যাকাউন্ট/সাবস্ক্রিপশন বন্ধ করার প্রক্রিয়ায় আলাদাভাবে বিবেচনা করা হবে (দেখুন অংশ 5.4 ও 5.6)KVKK ধারা 7 ও প্রবিধান — প্রক্রিয়াকরণের উদ্দেশ্য দূর হলে মুছে ফেলার বাধ্যবাধকতা।স্বয়ংক্রিয় মুছে ফেলা: avatars, anamnesis-attachments, user-data-exports, payment-receipts। specialist-verification-docs-এর জন্য স্বয়ংক্রিয় বিনষ্টকরণ এখনও নেই; tenant বন্ধের প্রক্রিয়ায় বিবেচনা করা হয়, ব্যতিক্রমী অনুরোধ hello@corenta.app-এর মাধ্যমে হাতে মূল্যায়ন করা হয়
12ক্লিনিকের গ্রুপ মেসেজ ও মডারেশনের রেকর্ড (group_messages, group_message_moderation; 18 অক্টোবর 2026 থেকে)গ্রুপ মেসেজের লেখা, স্টিকার, পোল ও ভোট, অভিযোগের কারণ, লুকানো/মুছে ফেলা/মিউট করার রেকর্ড, টিম পর্যালোচনার জন্য রাখা লুকানো মেসেজের কপিগ্রুপ মেসেজ গ্রুপ ও ক্লিনিকের Corenta অ্যাকাউন্ট যতদিন থাকে ততদিন সংরক্ষণ করা হয়; সদস্য নিজের মেসেজ যেকোনো সময় মুছতে পারেন এবং মুছে ফেলা মেসেজের লেখা রেকর্ড থেকে সরানো হয়। অ্যাকাউন্ট স্থায়ীভাবে মুছে ফেলা হলে গ্রুপ সদস্যপদ মুছে ফেলা হয়; গ্রুপে আগে পাঠানো মেসেজের লেখা প্রেরকের তথ্য সরিয়ে গ্রুপে থেকে যায়। টিম পর্যালোচনার জন্য রাখা কপি মেসেজ লুকানোর তারিখ থেকে সর্বোচ্চ 1 বছর সংরক্ষণ করা হয় এবং 6 মাস অন্তর করা পর্যায়ক্রমিক বিনষ্টকরণে মুছে ফেলা হয়; এই বিনষ্টকরণ এখন হাতে চালানো হয়, নির্ধারিত সময়সূচির স্বয়ংক্রিয় বিনষ্টকরণের কাজ এখনও নেই। ক্লিনিক পর্যায়ে মুছে ফেলায় অংশ 5.6 প্রযোজ্য।KVKK ধারা 5(2)(c) (গ্রুপে অংশগ্রহণ ও যোগাযোগ); ধারা 5(2)(f) (অভিযোগ ও মডারেশন, অপব্যবহার প্রতিরোধ)। ডেটা নিয়ন্ত্রক: ক্লিনিক। Corenta গ্রুপে স্বাস্থ্য রেকর্ড দেখায় না; মেসেজ মুক্ত লেখা বলে সদস্যদের স্বাস্থ্য তথ্য শেয়ার না করতে সতর্ক করা হয়।সদস্যের মুছে ফেলা: লেখা সরানো; অ্যাকাউন্ট স্থায়ীভাবে মুছে ফেলায়: প্রেরকের সংযোগ বিচ্ছিন্ন করা; মডারেশনের কপি: 1 বছর শেষে মুছে ফেলা (6 মাস অন্তর পর্যায়ক্রমিক বিনষ্টকরণ, এখন হাতে)

</div>

নোট 1: ওপরের টেবিলে "অ্যাকাউন্ট/tenant সক্রিয় থাকা পর্যন্ত" কথাটি সেই সময়কে বোঝায় যখন সংশ্লিষ্ট ক্লিনিকের Corenta সাবস্ক্রিপশন চলছে এবং ক্লায়েন্টের রেকর্ড ক্লিনিক মুছে ফেলেনি। ক্লিনিক নিজের ক্লায়েন্টের ডেটা কখন মুছবে তা ক্লিনিকের (ডেটা নিয়ন্ত্রক হিসেবে) নিজস্ব KVKK নীতি ও ক্লায়েন্টের সঙ্গে সম্পর্কের কাঠামোয় নির্ধারিত হয়; Corenta এই প্রক্রিয়ার প্রযুক্তিগত সুযোগ দেয়।

নোট 2: ক্রম 7-এর (অডিট ট্রেইলের রেকর্ড) 2 বছর ও ক্রম 8-এর (সম্মতির রেকর্ড) 5 বছর মেয়াদ Corenta-র নির্ধারিত নির্দিষ্ট সংরক্ষণের মেয়াদ (ক্রম 6-এর TTK/VUK মেয়াদের বিপরীতে সরাসরি কোনো আইনি বিধানের ওপর নির্ভর করে না; KVKK ধারা 5(2)(f)-এর বৈধ স্বার্থ ও প্রমাণের বাধ্যবাধকতার কাঠামোয় নির্ধারিত, স্বতঃপ্রণোদিতভাবে বাধ্যতামূলক একটি অঙ্গীকার)। এই মেয়াদ শেষে স্বয়ংক্রিয় সংরক্ষণ-শেষের মুছে ফেলার ব্যবস্থা এখন সিস্টেমে চলে না — মেয়াদ শেষ হলে মুছে ফেলা/বেনামী করা হাতে করা হয়, স্বয়ংক্রিয়করণ চালু হলে এই নীতি হালনাগাদ করা হবে। ক্রম 9-এর (আর্লি অ্যাক্সেস ফর্মের ডেটা) "সর্বোচ্চ 2 বছর" কথাটি ভিন্ন পরিধির এবং নিজের সারিতে ব্যাখ্যা করা অনুযায়ী আলাদা একটি আইনি ঊর্ধ্বসীমা প্রকাশ করে।

5. অ্যাকাউন্ট মুছে ফেলার প্রক্রিয়া — শুরু থেকে শেষ পর্যন্ত কার্যপ্রণালী

Corenta, ডেটা মালিকদের KVKK ধারা 11-এর আওতায় মুছে ফেলার অনুরোধ প্রযুক্তিগতভাবে পূরণ করতে, ব্যবহারকারীর অভিজ্ঞতা এবং ডেটার নিরাপত্তা/আইনি প্রমাণের প্রয়োজনের মধ্যে ভারসাম্য বিবেচনা করে একটি দুই ধাপের মুছে ফেলার কাঠামো প্রয়োগ করে: তাৎক্ষণিক নরম মুছে ফেলা (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. ব্যবহারকারীর সব সম্মতি প্রত্যাহার করা হয় (consent_logs রেকর্ডে revoked_at ঘর পূরণ করে প্রক্রিয়া করা হয়)।

এই ধাপে ডেটা শারীরিকভাবে মুছে ফেলা হয়নি, তবে সাধারণ প্রক্রিয়াকরণ ও দেখার উদ্দেশ্যে প্রবেশযোগ্য না করে রাখা হয়েছে। এটি KVKK ধারা 7 ও প্রবিধানের অর্থে "প্রবেশযোগ্য না করে রাখা" প্রকৃতির মুছে ফেলার প্রক্রিয়ার প্রথম ধাপ।

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 থেকে): মুছে ফেলার অনুরোধে অ্যাকাউন্টে প্রবেশ সঙ্গে সঙ্গে বন্ধ হয় বলে এই মেয়াদ ফিরিয়ে নেওয়ার/মত পরিবর্তনের সুযোগ দেয় না; পরিচয় যাচাইয়ের রেকর্ড ও ফাইলের স্থায়ী মুছে ফেলা সম্পন্ন করতে এবং সম্ভাব্য অপব্যবহার পর্যালোচনায় ব্যবহৃত হয়। এই মেয়াদ KVKK ধারা 5-এর আওতায় আনুপাতিকতার নীতির সঙ্গে সামঞ্জস্যপূর্ণ, যুক্তিসঙ্গত ও সীমিত একটি মেয়াদ। মুছে ফেলার অনুরোধের অবস্থা সম্পর্কে hello@corenta.app ঠিকানায় আবেদন করা যায়।

5.3. ব্যতিক্রম: আইনগত সংরক্ষণের বাধ্যবাধকতা থাকা ডেটা

ওপরের 30 দিনের স্থায়ী মুছে ফেলার প্রক্রিয়া অংশ 4, টেবিলের ক্রম নং 6-এ (সাবস্ক্রিপশন/লেনদেনের মেটাডেটা) উল্লিখিত এবং তুর্কি বাণিজ্যিক আইন/কর পদ্ধতি আইনের আওতায় আইনগত সংরক্ষণের বাধ্যবাধকতা থাকা রেকর্ড অন্তর্ভুক্ত করে না। এই রেকর্ডগুলো অ্যাকাউন্ট স্থায়ীভাবে মুছে ফেলা হলেও সংশ্লিষ্ট আইনগত সংরক্ষণের মেয়াদ শেষ না হওয়া পর্যন্ত ব্যক্তিগত ডেটা প্রক্রিয়াকরণের উদ্দেশ্য থেকে আলাদা করে, শুধু আইনগত বাধ্যবাধকতা পালনের উদ্দেশ্যে সীমিত প্রবেশাধিকারসহ আলাদাভাবে রক্ষা করা হয়। একইভাবে অডিট ট্রেইলের রেকর্ড (audit_logs) এবং সম্মতির রেকর্ডের প্রমাণ-উদ্দেশ্যের ন্যূনতম মূল অংশও (দেখুন অংশ 4, ক্রম 7-8) বৈধ স্বার্থ/আইনি প্রমাণের কারণে এই 30 দিনের মেয়াদের বাইরে, আলাদা ও সীমিত উদ্দেশ্যে সংরক্ষিত থাকতে পারে। এই ব্যতিক্রমের আওতাভুক্ত মেয়াদ যে সিস্টেমে স্বয়ংক্রিয়ভাবে প্রয়োগ করা কোনো প্রযুক্তিগত ব্যবস্থার সঙ্গে মেলে না, তা অংশ 4 নোট 2-এ স্পষ্টভাবে বলা হয়েছে।

5.4. সংরক্ষিত ফাইল সংযুক্তি সম্পর্কে বিশেষ ব্যাখ্যা (গুরুত্বপূর্ণ — স্বচ্ছতা)

স্বচ্ছতার নীতি অনুযায়ী স্পষ্টভাবে বলা হচ্ছে: স্থায়ী মুছে ফেলার কাজের সময় ডেটাবেসের রেকর্ড (প্রোফাইল, অ্যাপয়েন্টমেন্ট, নিয়োগ, সম্মতি ইত্যাদি) সম্পূর্ণ মুছে ফেলা হয় বা (স্বাস্থ্য/ক্লিনিক্যাল/আর্থিক রেকর্ডের জন্য, দেখুন অংশ 6.2) বেনামী করা হয়; ব্যবহারকারীর এবং আলাদা স্টোরেজ (Storage) এলাকায় রাখা ফাইল সংযুক্তি অবশ্য এভাবে পরিচালিত হয়: অ্যাভাটার/প্রোফাইল ছবি, অ্যানামনেসিস ফর্মে যুক্ত নথি/ছবি ও পেমেন্টের রসিদের ছবি স্থায়ী মুছে ফেলার ধাপের অংশ হিসেবে স্বয়ংক্রিয়ভাবে (best-effort) Storage থেকে মুছে ফেলা হয় — এটি সিস্টেমে এখন বাস্তবে চলা, যাচাই করা একটি আচরণ। কোনো bucket-এ মুছে ফেলা ব্যর্থ হলে বিষয়টি লগ করা হয়; তবে অন্য bucket-এর পরিষ্কারকরণ বা অ্যাকাউন্টের বেনামীকরণ/স্থায়ী মুছে ফেলার ধাপ আটকায় না (best-effort নকশা)।

সৎ সীমা: এই স্বয়ংক্রিয় প্রক্রিয়ার পরিধির বাইরে থাকা একমাত্র ফাইলের শ্রেণি হলো স্পেশালিস্ট/একক-নিবন্ধন প্রক্রিয়ায় আপলোড করা পরিচয়/ডিপ্লোমা যাচাইয়ের নথি (specialist-verification-docs bucket)। এই নথিগুলো প্রযুক্তিগতভাবে ব্যবহারকারীর সঙ্গে নয়, সংশ্লিষ্ট tenant-এর (ক্লিনিকের) যাচাই প্রক্রিয়ার সঙ্গে যুক্ত এবং ডেটাবেসের রেকর্ডে কোনো ব্যবহারকারীর উল্লেখ বহন করে না; তাই বর্তমান ব্যবহারকারী-অ্যাকাউন্ট মুছে ফেলার প্রক্রিয়ায় স্বয়ংক্রিয়ভাবে অন্তর্ভুক্ত করা যায় না। এই নথির বিনষ্টকরণ সংশ্লিষ্ট ক্লিনিক tenant পর্যায়ে নিজের অ্যাকাউন্ট/সাবস্ক্রিপশন বন্ধ করার প্রক্রিয়ায় আলাদাভাবে বিবেচনা করা হবে (দেখুন অংশ 5.6); তা সম্পন্ন না হওয়া পর্যন্ত ব্যতিক্রমী অনুরোধে hello@corenta.app-এর মাধ্যমে হাতে মূল্যায়ন করা হয়।

তাই এই নীতিতে অ্যাকাউন্ট মুছে ফেলার অনুরোধে "ব্যবহারকারীর সব ডেটা/ফাইল সম্পূর্ণ ও তাৎক্ষণিকভাবে মুছে ফেলা হয়" এমন কোনো নিরঙ্কুশ অঙ্গীকার দেওয়া হয় না (বিশেষত ব্যাকআপে থাকা প্রযুক্তিগত অবশিষ্টাংশের জন্য দেখুন অংশ 6.3, এবং ওপরের ব্যতিক্রমের জন্য); তবে ওপরে বর্ণিত ফাইলের শ্রেণির ক্ষেত্রে স্বয়ংক্রিয় মুছে ফেলা বাস্তবে প্রয়োগ করা হচ্ছে।

5.5. স্বাস্থ্য ডেটা সম্পর্কে বিশেষ নোট

অ্যানামনেসিস ফর্ম, সেশন নোট ও পরিমাপের রেকর্ডের মতো বিশেষ শ্রেণির স্বাস্থ্য ডেটাও ওপরের সাধারণ মুছে ফেলার প্রক্রিয়ার (soft-delete → 30 দিন → স্থায়ী মুছে ফেলা) অধীন; তবে অংশ 4 ক্রম 2-4 ও অংশ 6.2-এ যেমন ব্যাখ্যা করা হয়েছে, এই টেবিলগুলোতে স্থায়ী মুছে ফেলার ধাপ ব্যক্তির সঙ্গে সংযোগ বিচ্ছিন্ন করা ও আংশিক পরিষ্কারকরণের মাধ্যমে প্রয়োগ করা হয় — রেকর্ড DELETE করা হয় না, ব্যক্তির সংযোগ বিচ্ছিন্ন করা হয় এবং কিছু মুক্ত লেখার ঘর খালি করা হয়; ক্লিনিক্যাল রেকর্ড (বিশেষত append-only সেশন নোটের বিষয়বস্তু) tenant-এর ব্যক্তির সঙ্গে সংযোগ বিচ্ছিন্ন রেকর্ড হিসেবে সীমিত প্রবেশাধিকারসহ সংরক্ষণ করা হয় এবং বেনামী হিসেবে গণ্য হয় না। এ ছাড়া এই ডেটার শ্রেণি ক্লিনিকের ডেটা নিয়ন্ত্রক হিসেবে রাখা রেকর্ডের সঙ্গে জড়িত বলে, কোনো ক্লায়েন্টের অ্যাকাউন্ট/ডেটা মুছে ফেলার অনুরোধ ক্লিনিকের নিজস্ব আইনগত সংরক্ষণের বাধ্যবাধকতার (যেমন স্বাস্থ্যসেবা প্রদান সংক্রান্ত আইন থেকে উদ্ভূত হতে পারে এমন রেকর্ড রাখার বাধ্যবাধকতা) সঙ্গে সংঘাতপূর্ণ হতে পারে; ব্যক্তির সঙ্গে সংযোগ বিচ্ছিন্ন করা ও সীমিত সংরক্ষণের পদ্ধতি এই দুটি বাধ্যবাধকতার (ব্যক্তিগত ডেটার ওপর ক্লায়েন্টের অধিকার এবং ক্লিনিকের রেকর্ড রাখার বাধ্যবাধকতা) মধ্যে ভারসাম্য আনার লক্ষ্য রাখে। এমন ক্ষেত্রে চূড়ান্ত সিদ্ধান্তদাতা ডেটা নিয়ন্ত্রক হিসেবে ক্লিনিক; Corenta ক্লিনিকের নির্দেশ অনুযায়ী কাজ করে।

5.6. ক্লিনিক (Tenant) পর্যায়ে মুছে ফেলা

কোনো ক্লিনিক নিজের Corenta সাবস্ক্রিপশন সম্পূর্ণ শেষ করলে, ক্লিনিকের tenant ডেটা এবং এই tenant-এর অধীন সব ক্লায়েন্ট রেকর্ডের জন্যও একই দুই ধাপের (soft-delete → 30 দিন → স্থায়ী মুছে ফেলা) কাঠামো প্রয়োগ করা হয়। ক্লিনিক নিজের ক্লায়েন্টদের ডেটা নিয়ন্ত্রক হওয়ায়, সাবস্ক্রিপশন শেষ করার আগে নিজের KVKK বাধ্যবাধকতার কাঠামোয় ক্লায়েন্টদের জানাতে বাধ্য; এই বাধ্যবাধকতা Corenta-র কাছে হস্তান্তর করা যায় না।

5.7. সুপার-অ্যাডমিন সাপোর্ট মোডের (ইমপারসোনেশন) সঙ্গে সম্পর্ক

অ্যাকাউন্ট মুছে ফেলা ও সংরক্ষণের প্রক্রিয়া Corenta-র সাপোর্ট/ইমপারসোনেশন ব্যবস্থা থেকে স্বাধীনভাবে চলে। ইমপারসোনেশন সেশন সময়সীমাবদ্ধ (30 মিনিট) এবং ডিফল্টভাবে শুধু পড়ার জন্য; স্বাস্থ্য ডেটার শ্রেণিতে (অ্যানামনেসিস, সেশন নোট, পরিমাপ) প্রবেশে আলাদা অনুমোদনের ধাপ (health_data_enabled) লাগে এবং এই টেবিলগুলোর লেখা/মুছে ফেলার কাজ ইমপারসোনেশনের মাধ্যমে কোনো অবস্থাতেই অনুমোদিত নয় (RLS নীতিতে ইমপারসোনেশনের জন্য কোনো ব্যতিক্রম রাখা হয়নি)। স্পষ্টীকরণ: এখানকার সীমাবদ্ধতা সাপোর্ট কর্মী লগইন করে হাতে কাজ করেন এমন মানুষের চালু করা ইমপারসোনেশন সেশনের ক্ষেত্রে প্রযোজ্য; অংশ 5.2-এ ব্যাখ্যা করা স্বয়ংক্রিয় (মানুষের হস্তক্ষেপ ছাড়া) service-role cron প্রক্রিয়া এই সীমাবদ্ধতা থেকে আলাদা একটি স্তর এবং এতে প্রভাবিত হয় না — ইমপারসোনেশনের সীমাবদ্ধতা অ্যাকাউন্ট মুছে ফেলার প্রক্রিয়ার স্বয়ংক্রিয় স্থায়ী মুছে ফেলার ব্যবস্থা আটকায় না এবং এর সঙ্গে গুলিয়ে ফেলা উচিত নয়। তাই অ্যাকাউন্ট মুছে ফেলা/বিনষ্টকরণের প্রক্রিয়া শুধু এই নীতিতে সংজ্ঞায়িত স্বয়ংক্রিয় ব্যবস্থার মাধ্যমে চালানো হয়।

6. বিনষ্টকরণের পদ্ধতি

প্রবিধানের ধারা 8 ও পরবর্তী বিধান অনুযায়ী, রেকর্ডের মাধ্যম অনুযায়ী প্রয়োগ করা মুছে ফেলা/ধ্বংস/বেনামী করার পদ্ধতি নিচে ব্যাখ্যা করা হয়েছে।

6.1. মুছে ফেলা

ব্যক্তিগত ডেটাকে সংশ্লিষ্ট ব্যবহারকারীদের (অ্যাপের ব্যবহারকারী, অ্যাডমিন প্যানেলে প্রবেশাধিকার থাকা কর্মী সহ) জন্য কোনোভাবেই প্রবেশযোগ্য ও পুনরায় ব্যবহারযোগ্য না রাখার প্রক্রিয়া। Corenta-তে এই পদ্ধতি ধাপ-1 soft-delete প্রক্রিয়ায় প্রয়োগ করা হয়: ডেটা ডেটাবেস থেকে শারীরিকভাবে সরানো না হলেও প্রবেশের অনুমতি ও ইন্টারফেসের মাধ্যমে সম্পূর্ণ প্রবেশযোগ্য না করে রাখা হয়।

6.2. ধ্বংস করা (স্থায়ী মুছে ফেলা)

ব্যক্তিগত ডেটাকে কারও জন্যই কোনোভাবে প্রবেশযোগ্য, পুনরুদ্ধারযোগ্য ও পুনরায় ব্যবহারযোগ্য না রাখার প্রক্রিয়া। Corenta-র ধাপ-2 স্থায়ী মুছে ফেলার প্রক্রিয়ায় এই নীতি ডেটার শ্রেণি অনুযায়ী দুটি ভিন্ন প্রযুক্তিগত পদ্ধতিতে বাস্তবায়িত হয়:

  • পরিচয় যাচাইয়ের রেকর্ড ও স্বাধীন ব্যবসায়িক মূল্য নেই এমন রেকর্ড: ব্যবহারকারীর পরিচয় যাচাইয়ের রেকর্ড (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 ইত্যাদি) ON DELETE SET NULL FK সীমা দিয়ে অপরিবর্তনীয়ভাবে NULL করা হয়; স্পষ্ট পরিচয় বা মুক্ত লেখার PII থাকতে পারে এমন বিষয়বস্তুর কলাম (অ্যানামনেসিসের উত্তর, পরিমাপ/পেমেন্টের মুক্ত লেখার নোট, পেমেন্টের রসিদের উল্লেখ, সম্মতির রেকর্ডের IP ঠিকানা) anonymize_user_relations() ফাংশন (শুধু service-role ডাকতে পারে, default-deny) খালি করে বা একটি বেনামী চিহ্ন দিয়ে বদলায়। ক্লিনিক্যাল/আর্থিক সংখ্যাগত ও তারিখসংক্রান্ত বিষয়বস্তু (তারিখ, পরিমাণ, পরিমাপের মান, বাকি সেশনের ব্যালান্স, এসেছেন/আসেননি অবস্থা, সম্মতি দেওয়া/প্রত্যাহারের সময়) অবশ্য ক্লিনিকের রেকর্ড রাখার বাধ্যবাধকতা এবং (সেশন নোটের জন্য) append-only নীতির কারণে tenant-এর ব্যক্তির সঙ্গে সংযোগ বিচ্ছিন্ন রেকর্ড হিসেবে সংরক্ষিত থাকে; সেশন নোটের মুক্ত লেখা বদলানো হয় না বলে এই রেকর্ডগুলো বেনামী হিসেবে গণ্য হয় না এবং সীমিত প্রবেশাধিকারসহ সংরক্ষণ করা হয়।

সেশন নোটে (session_notes) append-only সীমা বিষয়বস্তুর পরিবর্তনের অনুমতি দেয় না; শুধু ব্যক্তির সংযোগের কলাম (client_id, specialist_id) NULL করার জন্য একটি সংকীর্ণ, একক উদ্দেশ্যের ব্যতিক্রম দেওয়া হয়েছে — নোটের বিষয়বস্তু নিজে এই প্রক্রিয়াতেও কোনো ধাপে মুছে ফেলা বা বদলানো হয় না।

সীমা: মুক্ত লেখার ঘরে স্পষ্ট পরিচয়ের কলামের বাইরে আসতে পারে এমন লেখার ভেতরের ব্যক্তিগত ডেটার (যেমন একটি সেশন নোটের মূল অংশে থাকা একটি নাম) জন্য কোনো স্ক্যান/পরিষ্কারের ব্যবস্থা নেই। তাই এই রেকর্ডগুলো বেনামী হিসেবে গণ্য হয় না; ব্যক্তিগত ডেটা হিসেবে সীমিত প্রবেশাধিকারসহ সংরক্ষণ করা হয় এবং মেয়াদ শেষে বিনষ্ট করা হয়।

ওপরের দুটি পদ্ধতিই service-role দিয়ে সুরক্ষিত বলে সাধারণ প্রোডাক্ট ইন্টারফেসের মাধ্যমে চালু বা ফিরিয়ে আনা যায় না।

6.3. ব্যাকআপ (Backup) থেকে মুছে ফেলা

ডেটাবেসের ব্যাকআপ স্বাভাবিক ব্যাকআপ চক্রের (রোটেশন) কাঠামোয় নির্দিষ্ট সময় পরে স্বয়ংক্রিয়ভাবে ওভাররাইট/বিনষ্ট করা হয়। স্থায়ী মুছে ফেলা প্রাথমিক ডেটাবেসে সঙ্গে সঙ্গে কার্যকর হলেও, আগে নেওয়া ব্যাকআপে ডেটা ব্যাকআপ প্রদানকারীর (Supabase) মানক ব্যাকআপ রোটেশনের মেয়াদ শেষ না হওয়া পর্যন্ত প্রযুক্তিগতভাবে থেকে যেতে পারে — এটি স্পষ্টভাবে বলা হচ্ছে। এই অবস্থা সংশ্লিষ্ট সাব-প্রসেসরের (Supabase) ডেটা প্রক্রিয়াকরণ চুক্তির (DPA) আওতায় মানক চর্চা।

6.4. ফাইল স্টোরেজ (Storage) এলাকার সংযুক্তি

ব্যবহারকারীদের আপলোড করা অ্যাভাটারের ছবি, পেমেন্টের রসিদ ও অ্যানামনেসিসের সংযুক্তির মতো ফাইল আলাদা একটি স্টোরেজ (Storage) এলাকায় রাখা হয়। দেখুন অংশ 5.4 — অ্যাকাউন্ট মুছে ফেলার প্রক্রিয়ায় এই বিষয়বস্তুর বর্তমান অবস্থা (অ্যাভাটার/অ্যানামনেসিসের সংযুক্তি/পেমেন্টের রসিদের জন্য স্বয়ংক্রিয় মুছে ফেলা, specialist-verification-docs-এর জন্য একমাত্র ব্যতিক্রম) সেখানে বিস্তারিত ও স্বচ্ছভাবে ব্যাখ্যা করা হয়েছে।

6.5. কাগজের মাধ্যমের ডেটা

Corenta-র SaaS প্রোডাক্টের আওতায় প্রক্রিয়াকৃত ব্যক্তিগত ডেটা ডিজিটাল মাধ্যমে রাখা হয়; কাগজের মাধ্যমে ব্যক্তিগত ডেটা প্রক্রিয়াকরণের পরিকল্পনা নেই। কোম্পানির বাণিজ্যিক/প্রশাসনিক চিঠিপত্রে ব্যতিক্রম হিসেবে কাগজের মাধ্যম ব্যবহার করা হলে বিনষ্টকরণ কালো করে ঢেকে দেওয়া/পুড়িয়ে ফেলা/কাগজ কাটার যন্ত্রে অপরিবর্তনীয়ভাবে টুকরো করার পদ্ধতিতে করা হয়।

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. মেয়াদোত্তীর্ণ/অকার্যকর পুশ নোটিফিকেশন টোকেন আলাদাভাবে স্বয়ংক্রিয় ও পর্যায়ক্রমিকভাবে পরিষ্কার করা প্রোডাক্ট রোডম্যাপে পরিকল্পিত একটি উন্নয়ন; এই ব্যবস্থা যে সিস্টেমে এখন বাস্তবে চলছে তা প্রযুক্তিগতভাবে যাচাই করা হয়নি (দেখুন অংশ 4, ক্রম 10)। যাচাই হলে বা চালু হলে এই নীতি হালনাগাদ করা হবে।
  5. 6 মাস অন্তর পর্যায়ক্রমিক বিনষ্টকরণ: এই অংশে স্বয়ংক্রিয় বিনষ্টকরণ নেই এমন শ্রেণির (অডিট ট্রেইল, ব্যক্তির সঙ্গে সংযোগ বিচ্ছিন্ন অনুমতির প্রমাণ, আর্লি অ্যাক্সেস ফর্মের ডেটা, স্পেশালিস্ট যাচাইয়ের নথি, গ্রুপ মেসেজের মডারেশনের কপি) জন্য Corenta 6 মাস অন্তর পর্যায়ক্রমিক বিনষ্টকরণ প্রয়োগ করে এবং প্রতিটি চক্রের জন্য বিনষ্টকরণের প্রতিবেদন প্রস্তুত করে। এই চক্রগুলো স্বয়ংক্রিয় করার নির্ধারিত সময়সূচির কাজ এখনও নেই; চক্রগুলো হাতে চালানো হয়।

পর্যায়ক্রমিক বিনষ্টকরণের প্রক্রিয়া, এই নীতিতে উল্লিখিত মেয়াদ থেকে স্বাধীনভাবে, ডেটা মালিক KVKK ধারা 11-এর আওতায় যে ব্যক্তিগত মুছে ফেলা/ধ্বংসের অনুরোধ করবেন তা আটকায় না; সংরক্ষণের মেয়াদ শেষ না হলেও সংশ্লিষ্ট প্রক্রিয়াকরণ কার্যক্রমের আইনি ভিত্তি দূর হলে (যেমন সম্মতি প্রত্যাহার) ডেটা মালিক মুছে ফেলার অনুরোধ করতে পারেন। স্বয়ংক্রিয়তা এখনও প্রয়োগ করা হয়নি এমন শ্রেণির ক্ষেত্রেও, ডেটা মালিকের ব্যক্তিগত অনুরোধ hello@corenta.app-এর মাধ্যমে পাঠানো হলে হাতে মূল্যায়ন করে নিষ্পত্তি করা হয়।

8. ডেটা মালিকের অধিকার ও আবেদনের পদ্ধতি (KVKK ধারা 11)

8.1. KVKK ধারা 11-এর আওতায় অধিকার

ডেটা মালিকদের KVKK ধারা 11 অনুযায়ী নিচের অধিকারগুলো আছে:

  1. নিজের ব্যক্তিগত ডেটা প্রক্রিয়া করা হচ্ছে কি না জানা,
  2. ব্যক্তিগত ডেটা প্রক্রিয়া করা হলে সে সম্পর্কে তথ্য চাওয়া,
  3. ব্যক্তিগত ডেটা প্রক্রিয়াকরণের উদ্দেশ্য এবং তা উদ্দেশ্য অনুযায়ী ব্যবহার হচ্ছে কি না জানা,
  4. দেশে বা বিদেশে যে তৃতীয় পক্ষের কাছে ব্যক্তিগত ডেটা স্থানান্তর করা হয়েছে তাদের জানা,
  5. ব্যক্তিগত ডেটা অসম্পূর্ণ বা ভুলভাবে প্রক্রিয়া করা হলে তা সংশোধনের অনুরোধ,
  6. KVKK ধারা 7-এর কাঠামোয় ব্যক্তিগত ডেটা মুছে ফেলা বা ধ্বংস করার অনুরোধ,
  7. ওপরের (5) ও (6) উপধারা অনুযায়ী করা কাজগুলো, যে তৃতীয় পক্ষের কাছে ব্যক্তিগত ডেটা স্থানান্তর করা হয়েছে তাদের জানানোর অনুরোধ,
  8. প্রক্রিয়াকৃত ডেটা একচেটিয়াভাবে স্বয়ংক্রিয় ব্যবস্থার মাধ্যমে বিশ্লেষণের ফলে ব্যক্তির বিরুদ্ধে কোনো ফলাফল দেখা দিলে তাতে আপত্তি,
  9. আইনবিরোধীভাবে ব্যক্তিগত ডেটা প্রক্রিয়াকরণের কারণে ক্ষতিগ্রস্ত হলে ক্ষতিপূরণের দাবি।

8.2. বর্তমান প্রযুক্তিগত প্রয়োগের সৎ সারসংক্ষেপ

নিচের বিষয়গুলো বর্তমান প্রযুক্তিগত প্রয়োগের একটি সৎ ও বাস্তবসম্মত সারসংক্ষেপ হিসেবে উপস্থাপন করা হলো:

  • মুছে ফেলার অনুরোধ (অ্যাকাউন্ট মুছে ফেলা): মোবাইল অ্যাপের ভেতরের সংশ্লিষ্ট সেটিংস মেনু থেকে সরাসরি অনুরোধ করা যায়; এই অনুরোধ অংশ 5-এ ব্যাখ্যা করা দুই ধাপের (তাৎক্ষণিক soft-delete → 30 দিন → স্থায়ী মুছে ফেলা) প্রক্রিয়ায় স্বয়ংক্রিয়ভাবে পূরণ করা হয় (ধারা 11(6))।
  • তথ্যের অনুরোধ / ডেটার বহনযোগ্যতা: ডেটা মালিকের নিজের tenant পরিধির ডেটা কাঠামোবদ্ধ, মেশিনে পড়া যায় এমন ফরম্যাটে, যুক্তিসঙ্গত সময়ের মধ্যে তাঁকে দিয়ে পূরণ করা হয় (export_user_data ফাংশন, tenant-scope যাচাই করা হয়েছে)। এই প্রক্রিয়ার হস্তান্তর ব্যবস্থা (ফাইলের ফরম্যাট, হস্তান্তরের পদ্ধতি, স্বাক্ষরিত ডাউনলোড লিংকের মতো ফিচার) ধারাবাহিকভাবে উন্নত করা হচ্ছে; এই নীতির আওতায় নির্দিষ্ট কোনো হস্তান্তরের মেয়াদ বা নির্দিষ্ট ফাইল/প্রবেশের ফরম্যাট সম্পর্কে অঙ্গীকার দেওয়া হয় না (ধারা 11(1)-(2))।
  • তৃতীয় পক্ষের কাছে স্থানান্তরের তথ্য (ধারা 11(4)): ব্যক্তিগত ডেটা যে দেশি/বিদেশি তৃতীয় পক্ষ/সাব-প্রসেসরের কাছে স্থানান্তর করা হয়েছে তাদের সম্পর্কে তথ্য এই নীতির অংশ 11-এর (সাব-প্রসেসর ও ডেটার অবস্থান) টেবিলে পূরণ করা হয়েছে।
  • সংশোধনের অনুরোধ (ধারা 11(5)): প্রযুক্তিগতভাবে ক্লিনিকের ম্যানেজমেন্ট প্যানেলের মাধ্যমে হাতে করা সম্ভব; আলাদা, স্বয়ংক্রিয় কোনো "সংশোধনের অনুরোধ" কর্মপ্রবাহ নেই। SaaS প্রোডাক্টের প্রসঙ্গে ক্লায়েন্টের ডেটা সংক্রান্ত সংশোধনের অনুরোধ প্রথমে সংশ্লিষ্ট ক্লিনিকের কাছে পাঠাতে হবে; Corenta ডেটা প্রসেসর হিসেবে ক্লিনিকের নির্দেশ অনুযায়ী প্রযুক্তিগত সহায়তা দেয়।
  • তৃতীয় পক্ষকে জানানো (ধারা 11(7)): মুছে ফেলা/সংশোধনের কাজ স্থানান্তরের প্রাপক তৃতীয় পক্ষকে জানানোর অনুরোধ আবেদনের পদ্ধতিতে উল্লিখিত চ্যানেল দিয়ে পাঠানো হলে মূল্যায়ন করা হয়; এই প্রক্রিয়া এখন স্বয়ংক্রিয় নয়, হাতে চালানো হয়।
  • স্বয়ংক্রিয় সিদ্ধান্ত/প্রোফাইলিংয়ে আপত্তি (ধারা 11(8)): সিস্টেমে প্রক্রিয়াকৃত ডেটা একচেটিয়াভাবে স্বয়ংক্রিয় ব্যবস্থার মাধ্যমে বিশ্লেষণের ফলে ডেটা মালিকের বিরুদ্ধে ফল তৈরি করে এমন কোনো স্বয়ংক্রিয় সিদ্ধান্ত গ্রহণ বা প্রোফাইলিং কার্যক্রম নেই; তাই এই ধারা সংক্রান্ত বাস্তবে চালানো আলাদা কোনো আপত্তির ব্যবস্থার প্রয়োজন এখন নেই।
  • আবেদনের উত্তর KVKK ধারা 13 অনুযায়ী সর্বোচ্চ 30 দিনের মধ্যে বিনামূল্যে দেওয়া হয় (কাজটিতে আলাদা খরচ লাগলে বোর্ড নির্ধারিত তালিকার ফি চাওয়া যেতে পারে)।

8.3. আবেদনের পদ্ধতি

ওপরের অধিকার সংক্রান্ত অনুরোধ:

  • hello@corenta.app ইমেইল ঠিকানায়,
  • অ্যাপের ভেতরের সংশ্লিষ্ট সেটিংস/সাপোর্ট স্ক্রিনের মাধ্যমে,
  • বা KVKK-এর নির্ধারিত অন্যান্য পদ্ধতিতে,

Corenta-র কাছে পাঠানো যায়।

ক্লায়েন্টের ডেটা সম্পর্কে গুরুত্বপূর্ণ নোট: আপনি কোনো ক্লিনিকের ক্লায়েন্ট হলে এবং আপনার ডেটা সম্পর্কে অনুরোধ করতে চাইলে প্রথমে সংশ্লিষ্ট ক্লিনিকের (ডেটা নিয়ন্ত্রক) কাছে আবেদন করতে হবে; কারণ ক্লায়েন্টের ডেটার ক্ষেত্রে ক্লিনিকই চূড়ান্ত সিদ্ধান্তদাতা ও দায়ী পক্ষ। Corenta ডেটা প্রসেসর হিসেবে ক্লিনিকের নির্দেশ অনুযায়ী প্রয়োজনীয় প্রযুক্তিগত টুল (ডেটা দেখা, এক্সপোর্ট, মুছে ফেলার ফাংশন) দেয়।

9. ভূমিকা ও দায়িত্ব

ভূমিকাদায়িত্ব
Corenta / [Teta Studio]প্রাতিষ্ঠানিক ওয়েবসাইটের প্রসঙ্গে ডেটা নিয়ন্ত্রক হিসেবে এই নীতি প্রয়োগের জন্য; SaaS প্রোডাক্টের প্রসঙ্গে ডেটা প্রসেসর হিসেবে, ক্লিনিকের নির্দেশ অনুযায়ী প্রযুক্তিগত সংরক্ষণ/বিনষ্টকরণের অবকাঠামো (soft-delete, cron-ভিত্তিক স্থায়ী মুছে ফেলা, RLS প্রবেশ সীমা) দেওয়ার জন্য দায়ী।
ক্লিনিক (Tenant/ব্যবসা)SaaS প্রোডাক্টের প্রসঙ্গে নিজের ক্লায়েন্টদের ব্যক্তিগত ডেটার ক্ষেত্রে ডেটা নিয়ন্ত্রক হিসেবে, ক্লায়েন্টদের প্রতি অবহিতকরণের বাধ্যবাধকতা, স্পষ্ট সম্মতি নেওয়া এবং নিজের অভ্যন্তরীণ সংরক্ষণ/বিনষ্টকরণের সিদ্ধান্তের (যেমন কোন ক্লায়েন্টের রেকর্ড কখন মুছে ফেলা হবে) জন্য দায়ী।
সিস্টেম / স্বয়ংক্রিয় প্রক্রিয়ানির্ধারিত সময়সূচির কাজের (cron) মাধ্যমে পর্যায়ক্রমিক বিনষ্টকরণ ও 30 দিনের স্থায়ী মুছে ফেলার প্রক্রিয়া প্রযুক্তিগতভাবে সম্পাদনের জন্য দায়ী; এই প্রক্রিয়াগুলো শুধু বিশেষ সুবিধাপ্রাপ্ত (service-role) অনুমতি দিয়ে চালু করা যায়।
সাপোর্ট/সাবস্ক্রাইবার সম্পর্ক টিমসংশ্লিষ্ট ব্যক্তির আবেদন গ্রহণ, পথনির্দেশ ও প্রক্রিয়া অনুসরণের জন্য দায়ী।
ডেটা নিয়ন্ত্রকের যোগাযোগ ব্যক্তিKVKK আবেদন আইন অনুযায়ী নিষ্পত্তি করা এবং প্রয়োজনে ব্যক্তিগত তথ্য সুরক্ষা কর্তৃপক্ষের সঙ্গে যোগাযোগের জন্য দায়ী।

10. নিরাপত্তা ব্যবস্থা (সংরক্ষণের মেয়াদ জুড়ে)

ব্যক্তিগত ডেটা সংরক্ষণের মেয়াদ জুড়ে নিচের প্রযুক্তিগত ও প্রশাসনিক ব্যবস্থা দিয়ে সুরক্ষিত রাখা হয় (KVKK ধারা 12):

  • বহু-ভাড়াটে (multi-tenant) কাঠামোয় প্রতিটি টেবিলে tenant_id বাধ্যতামূলক এবং সারি-স্তরের নিরাপত্তা (Row Level Security) নীতি দিয়ে ডিফল্ট-প্রত্যাখ্যান (default-deny) নীতি প্রয়োগ করা হয় (37/37 টেবিল, 86টি নীতি); ভাড়াটেদের মধ্যে ডেটা ফাঁস এভাবে প্রযুক্তিগতভাবে আটকানো হয়।
  • স্বাস্থ্য ডেটা থাকা টেবিলে প্রবেশ শুধু সংশ্লিষ্ট ক্লায়েন্ট, নির্ধারিত স্পেশালিস্ট ও tenant অ্যাডমিনে সীমিত; প্রবেশ নিয়ন্ত্রণ ডেটাবেস পর্যায়ে (RLS) প্রয়োগ করা হয়। সেশন নোট পাঠানোর পরে বদলানো/মুছে ফেলা যায় না (append-only); অ্যানামনেসিস ফর্মের জন্য কোনো ব্যবহারকারীকে (অ্যাডমিন সহ) মুছে ফেলার অধিকার দেওয়া হয়নি।
  • সুপার-অ্যাডমিন সাপোর্ট মোড (ইমপারসোনেশন) সময়সীমাবদ্ধ (30 মিনিট), ডিফল্টভাবে শুধু পড়ার জন্য; লেখার কাজ ও স্বাস্থ্য ডেটায় প্রবেশ আলাদা, অতিরিক্ত অনুমোদন লাগে এমন ধাপের অধীন; কোনো ইমপারসোনেশন পরিস্থিতিতে স্বাস্থ্য ডেটার টেবিলে লেখার প্রবেশ খোলা হয় না। (এই সীমাবদ্ধতা মানুষের চালু করা ইমপারসোনেশন সেশনের ক্ষেত্রে প্রযোজ্য; স্বয়ংক্রিয় service-role cron প্রক্রিয়া আলাদা একটি স্তর — দেখুন অংশ 5.7।)
  • ডেটা স্থানান্তরে শুরু থেকে শেষ পর্যন্ত এনক্রিপশন (TLS) ব্যবহার করা হয়; মোবাইল অ্যাপে লগইন টোকেন ডিভাইসের নিরাপদ হার্ডওয়্যার-সমর্থিত কী-স্টোরে (Keychain/Keystore) এনক্রিপ্ট করে রাখা হয়।
  • সংবেদনশীল স্ক্রিনে স্ক্রিনশট নেওয়া সীমিত করার প্রযুক্তিগত ব্যবস্থা নেওয়া হয়েছে।
  • সুপার-অ্যাডমিন অ্যাকাউন্টের জন্য দুই ধাপের পরিচয় যাচাই (2FA/MFA) বাধ্যতামূলক।
  • পেমেন্ট সংক্রান্ত বিজ্ঞপ্তির (webhook) ক্রিপ্টোগ্রাফিক স্বাক্ষর যাচাই কাঠামোয় পরিকল্পিত এবং প্রয়োগ করা হচ্ছে; সংশ্লিষ্ট কনফিগারেশন/কী ব্যবস্থাপনা সব পরিবেশে (prod সহ) সম্পূর্ণ করার কাজ চলছে।
  • এই নিরাপত্তা ব্যবস্থা ধারাবাহিকভাবে পর্যালোচনা ও উন্নত করা হচ্ছে; তবে কোনো প্রযুক্তিগত ব্যবস্থাই সম্পূর্ণ নিরাপত্তার নিশ্চয়তা দেয় না এবং এই নীতির আওতায় সম্পূর্ণ নিরাপত্তার অঙ্গীকার দেওয়া হয় না।

11. সাব-প্রসেসর ও ডেটার অবস্থান

ব্যক্তিগত ডেটা সংরক্ষণের মেয়াদ জুড়ে নিচের সাব-প্রসেসর/সেবা প্রদানকারীদের মাধ্যমে প্রক্রিয়া বা হোস্ট করা হচ্ছে। এই প্রদানকারীদের সঙ্গে করা চুক্তিতে ডেটা শুধু উল্লিখিত সেবা বাস্তবায়নের উদ্দেশ্যে প্রক্রিয়া করার বাধ্যবাধকতা রাখা হয়েছে; এই সম্পর্ক সংরক্ষণের মেয়াদ নয়, ডেটা যে প্রযুক্তিগত পরিবেশে হোস্ট করা হয় তা প্রকাশ করে — বিনষ্টকরণের সিদ্ধান্তের প্রয়োগ এই প্রদানকারীদের কাছেও প্রযুক্তিগতভাবে করা হয়। নিচের টেবিল KVKK ধারা 11(4)-এর আওতায় "ডেটা যে তৃতীয় পক্ষের কাছে স্থানান্তর করা হয়েছে তাদের জানা" অধিকারও পূরণ করে:

সাব-প্রসেসরভূমিকাডেটার অবস্থানবিদেশে স্থানান্তর (KVKK ধারা 9)
Supabaseডেটাবেস, পরিচয় যাচাই, ফাইল স্টোরেজ, সার্ভার-পার্শ্বের ফাংশন হোস্টিংFrankfurt, জার্মানিবিদেশে স্থানান্তর; KVKK ধারা 9(4)(c) মানক চুক্তি (মডিউল 3): এখনও স্বাক্ষরিত হয়নি এবং বোর্ডকে জানানো হয়নি
AppleApp Store বিতরণ, অ্যাপের ভেতরে কেনাকাটার (IAP) বিলিং, পুশ নোটিফিকেশন (APNs)বৈশ্বিক অবকাঠামোবিদেশে স্থানান্তর; KVKK মানক চুক্তি: এখনও স্বাক্ষরিত হয়নি
GooglePlay Store বিতরণ, অ্যাপের ভেতরে কেনাকাটার (IAP) বিলিং, পুশ নোটিফিকেশন (FCM)বৈশ্বিক অবকাঠামোবিদেশে স্থানান্তর; KVKK মানক চুক্তি: এখনও স্বাক্ষরিত হয়নি
Vercelওয়েব (ম্যানেজমেন্ট প্যানেল / Next.js) হোস্টিংবৈশ্বিক অবকাঠামোবিদেশে স্থানান্তর; KVKK মানক চুক্তি: এখনও স্বাক্ষরিত হয়নি
Framercorenta.app প্রাতিষ্ঠানিক/মার্কেটিং সাইটের হোস্টিংবৈশ্বিক অবকাঠামোবিদেশে স্থানান্তর; KVKK মানক চুক্তি (মডিউল 2): এখনও স্বাক্ষরিত হয়নি
Google Workspace (Google)সেবা ইমেইল পাঠানো (ট্রায়াল, আমন্ত্রণ, সাপোর্ট) এবং সাপোর্ট/যোগাযোগের ইনবক্সবৈশ্বিক অবকাঠামোবিদেশে স্থানান্তর; KVKK মানক চুক্তি: এখনও স্বাক্ষরিত হয়নি

এ ছাড়া:

  • ইমেইল অবকাঠামো: সেবা ইমেইল Google Workspace (Google)-এর মাধ্যমে পাঠানো হয়; পরিচয় যাচাইয়ের ইমেইল Supabase Auth চালু করে। প্রচারমূলক ইমেইল শুধু আলাদা সম্মতি ও İYS নিবন্ধনের শর্তে পাঠানো হয়। পুশ নোটিফিকেশন Apple (APNs) ও Google (FCM)-এর মাধ্যমে পাঠানো হয়।
  • অ্যানালিটিক্স টুল: তৃতীয় পক্ষের কোনো অ্যানালিটিক্স টুল (যেমন Google Analytics) ব্যবহার করা হয় না। অ্যাপের ভেতরের প্রোডাক্ট ব্যবহারের পরিমাপ এখন সক্রিয় নয়; সক্রিয় করা হলে পরিমাপ Corenta-র নিজস্ব ডেটাবেসে (Supabase, Frankfurt/জার্মানি) রাখা প্রথম পক্ষের একটি টেবিলে লেখা হবে, স্বাস্থ্য ডেটা ও মুক্ত লেখা থাকবে না এবং সক্রিয় করার আগে এই নীতি হালনাগাদ করা হবে; সক্রিয় করা হলে পরিমাপের রেকর্ডের সংরক্ষণের মেয়াদ এই নীতিতে উল্লেখ করা হবে।
  • ত্রুটি পর্যবেক্ষণ: তৃতীয় পক্ষের ত্রুটি পর্যবেক্ষণ টুল ব্যবহার করা হয় না; ক্লায়েন্ট-পার্শ্বের ত্রুটি Corenta-র নিজস্ব ডেটাবেসে রেকর্ড করা হয়।
  • ওয়েবের মাধ্যমে সরাসরি ক্রেডিট কার্ডে পেমেন্টের অবকাঠামো নেই; পেমেন্ট শুধু Apple/Google অ্যাপের ভেতরে কেনাকাটার (IAP) ব্যবস্থার মাধ্যমে করা হয়; চূড়ান্ত ইনভয়েস/রসিদ Apple/Google প্রস্তুত করে (দেখুন অংশ 4, ক্রম 6)।

ওপরের সাব-প্রসেসরদের সঙ্গে ডেটা শেয়ার শুধু সংশ্লিষ্ট সেবা দিতে যতটুকু প্রয়োজন ততটুকু এবং KVKK ধারা 8/ধারা 9-এর কাঠামোয় করা হয়। বিদেশে স্থানান্তর: ওপরের সব প্রদানকারী তুরস্কের বাইরে ডেটা প্রক্রিয়া করে; জার্মানিতে হোস্টিংও KVKK-এর অর্থে বিদেশে স্থানান্তর। এই স্থানান্তরগুলো নিয়মিত ও চলমান হওয়ায় স্পষ্ট সম্মতির ওপর ভিত্তি করে না; ধারা 9(4)(c) অনুযায়ী বোর্ডের ঘোষিত মানক চুক্তির ওপর ভিত্তি করা হবে। এই লেখার তারিখ পর্যন্ত মানক চুক্তিগুলো এখনও স্বাক্ষরিত হয়নি এবং বোর্ডকে জানানো হয়নি; প্রতিটি চুক্তি স্বাক্ষরের তারিখ থেকে 5 কার্যদিবসের মধ্যে বোর্ডকে জানানো হবে এবং এই টেবিল তারিখসহ হালনাগাদ করা হবে। এই দেশগুলো সম্পর্কে বোর্ডের ঘোষিত কোনো পর্যাপ্ততার সিদ্ধান্ত নেই (সর্বশেষ যাচাই: 11 অক্টোবর 2026)। এই তালিকা সেবা প্রদানকারীর পরিবর্তনের ওপর নির্ভর করে হালনাগাদ হতে পারে; বর্তমান তালিকা গোপনীয়তা নীতি থেকে এবং/অথবা Corenta প্রোডাক্টের ভেতরের সংশ্লিষ্ট তথ্যের স্ক্রিন থেকে অনুসরণ করা যায়।

12. VERBİS নিবন্ধন

এই নথির তারিখ পর্যন্ত Teta Studio-র VERBİS নিবন্ধন নেই। নিবন্ধনের বাধ্যবাধকতা বোর্ডের 2025/1572 (প্রধান কার্যক্রম বিশেষ শ্রেণির ডেটা প্রক্রিয়াকরণ এমন ডেটা নিয়ন্ত্রকদের জন্য ছাড়ের সীমা বার্ষিক 10 জন কর্মী ও 10 মিলিয়ন তুর্কি লিরার ব্যালান্স শিট) ও 2025/2393 (ব্যালান্স শিট ভিত্তিতে হিসাবখাতা রাখেন না এমনদের জন্য কর্মীর সংখ্যার মানদণ্ড) নম্বর সিদ্ধান্তের মানদণ্ড অনুযায়ী মূল্যায়ন করা হচ্ছে। Teta Studio ক্লিনিক্যাল স্বাস্থ্য ডেটা ডেটা নিয়ন্ত্রক হিসেবে নয়, ডেটা প্রসেসর হিসেবে প্রক্রিয়া করে বলে নিজের ডেটা নিয়ন্ত্রক কার্যক্রমের (অংশ A ও C) ক্ষেত্রে মূল্যায়ন এই মানদণ্ডে করা হয়। লিখিত মূল্যায়ন নোট ও কর্তৃপক্ষের (ALO 198) নিশ্চিতকরণ সম্পন্ন হলে এই অংশ তারিখ ও কারণসহ হালনাগাদ করা হবে; নিবন্ধন প্রয়োজন হলে কার্যক্রম চালিয়ে যাওয়ার আগে করা হবে।

ভূমিকাভিত্তিক স্পষ্টীকরণ: VERBİS-এ নিবন্ধনের বাধ্যবাধকতা Corenta যেখানে ডেটা নিয়ন্ত্রক হিসেবে কাজ করে সেই প্রাতিষ্ঠানিক ওয়েবসাইটের (corenta.app আর্লি অ্যাক্সেস ফর্ম) প্রসঙ্গের জন্য মূল্যায়ন করা হচ্ছে এবং তার অবস্থা ওপরে ব্যাখ্যা করা হয়েছে। SaaS প্রোডাক্টের প্রসঙ্গে (app.corenta.app) ক্লায়েন্টের ডেটা সংক্রান্ত ডেটা নিয়ন্ত্রক ক্লিনিক হওয়ায়, VERBİS-এ নিবন্ধনের বাধ্যবাধকতা আছে কি না তা প্রতিটি ক্লিনিকের নিজস্ব মানদণ্ড (কর্মীর সংখ্যা, বার্ষিক ডেটা প্রক্রিয়াকরণের পরিমাণ, কার্যক্রমের ক্ষেত্র, বোর্ডের ছাড়ের সিদ্ধান্ত ইত্যাদি) অনুযায়ী আলাদাভাবে ও স্বাধীনভাবে মূল্যায়ন করতে হবে; এই মূল্যায়ন ও থাকলে নিবন্ধনের বাধ্যবাধকতা ক্লিনিকের এবং Corenta-র কাছে হস্তান্তর করা যায় না।

13. নীতির হালনাগাদ

এই নীতি; আইনের পরিবর্তন, বোর্ডের সিদ্ধান্ত, Corenta-র প্রযুক্তিগত অবকাঠামোতে করা উন্নয়ন (যেমন অংশ 4 ক্রম 3 ও অংশ 6.2-এ উল্লিখিত সেশন নোটের মুক্ত লেখায় লেখার ভেতরের PII স্ক্যান যোগ করা, অংশ 5.4/অংশ 4 ক্রম 11-এ উল্লিখিত স্পেশালিস্ট যাচাইয়ের নথি (specialist-verification-docs) tenant বন্ধের প্রক্রিয়ার সঙ্গে যুক্ত করা, অংশ 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

Sürüm bilgisi
Sürüm
1.9
sha256
dcf84eeff695e9461d0143729613ab4709b43a2a2a67b7b539f222455257ee09
Kaynak (TR) sha256
e923834cce3f0acab0b0eb1bdf599ae761c4e3ba6bc90a9ede9adc99e546fcbf