CORENTA — ນະໂຍບາຍການເກັບຮັກສາ ແລະ ການກຳຈັດຂໍ້ມູນ

ຄຳແປນີ້ສະໜອງໃຫ້ເພື່ອເປັນຂໍ້ມູນເທົ່ານັ້ນ; ສະບັບພາສາຕວກກີແມ່ນສະບັບທີ່ມີຜົນຜູກພັນທາງກົດໝາຍ.

ການລຶບຜູ້ໃຊ້ບໍລິການທີ່ບໍ່ມີບັນຊີ: ການດຳເນີນການ "ລຶບ" ຂອງຜູ້ດູແລສູນຖືວ່າເປັນຄຳຮ້ອງຂໍ; ບັນທຶກຈະຖືກເອົາອອກຈາກລາຍການທີ່ໃຊ້ງານທັນທີ ແລະ ຫຼັງຈາກ 30 ວັນ ຂໍ້ມູນລະບຸຕົວຕົນ/ການຕິດຕໍ່ ແລະ ຊ່ອງຂໍ້ມູນສຸຂະພາບຂອງຜູ້ໃຊ້ບໍລິການ (ກຸ່ມເລືອດ, ອາການແພ້, ພາວະຊຳເຮື້ອ, ຢາ) ຈະຖືກລຶບ/ລ້າງ (ເບິ່ງ 5.0). ຄຳອະທິບາຍທົ່ວໄປກ່ຽວກັບການລຶບບັນຊີຂ້າງລຸ່ມນີ້ ບໍ່ໄດ້ຕີຄວາມວ່າເປັນພັນທະຕ້ອງລຶບແຖວຂໍ້ມູນຜູ້ໃຊ້ບໍລິການຢ່າງຖາວອນໃນຂອບເຂດສະເພາະນີ້. ແບບປະຫວັດສຸຂະພາບ, ການວັດແທກ, ບັນທຶກເຊດຊັນ ແລະ ບັນທຶກການເງິນ ຍັງຄົງຢູ່ພາຍໃຕ້ບົດບັນຍັດການເກັບຮັກສາຂອງຕົນເອງ.

ມີຜົນບັງຄັບໃຊ້ / ອັບເດດຫຼ້າສຸດ: 19 ຕຸລາ 2026 ສະບັບ: 1.9 ຜູ້ຄວບຄຸມຂໍ້ມູນ / ຜູ້ເຜີຍແຜ່: Mertcan Demir — ວິສາຫະກິດສ່ວນບຸກຄົນພາຍໃຕ້ຊື່ການຄ້າ "Teta Studio"

ບັນທຶກການປ່ຽນແປງ

• 1.9 — 19 ຕຸລາ 2026: ຖ້ອຍຄຳ "ສະເພາະຕວກກີ" ໃນພາກທີ 14 ຖືກປ່ຽນເປັນການໃຫ້ບໍລິການທົ່ວໂລກ; ໄລຍະເວລາການເກັບຮັກສາບໍ່ປ່ຽນແປງ.
• 1.8 — 19 ຕຸລາ 2026: ສະບັບເຜີຍແຜ່; ວັນທີມີຜົນບັງຄັບໃຊ້ແມ່ນ 19 ຕຸລາ 2026. ເພີ່ມແຖວຂໍ້ຄວາມກຸ່ມຂອງສູນ ແລະ ສຳເນົາຂໍ້ຄວາມທີ່ແຍກໄວ້ໃຫ້ທີມພິຈາລະນາ (ລຳດັບທີ 12) ເຂົ້າໃນພາກທີ 4; ຂະຫຍາຍລາຍການການກຳຈັດເປັນໄລຍະໃນພາກທີ 7 ຕາມນັ້ນ; ເອົາຂໍ້ມູນ MERSİS ແລະ KEP ທີ່ປະໄວ້ຫວ່າງອອກຈາກຕາຕະລາງ 1.3.
• 1.7 — 11 ຕຸລາ 2026: ຕາມການກວດສອບການປະຕິບັດຕາມກົດໝາຍວັນທີ 11 ຕຸລາ 2026 (F01, F02, F08, F11, F13, F19, F21): ເອົາຖ້ອຍຄຳ "Supabase/ແຟຣງເຟີດ ບໍ່ແມ່ນການໂອນຂໍ້ມູນໄປຕ່າງປະເທດ" ໃນ §11 ອອກ ແລະ ຂຽນພາກການໂອນຂໍ້ມູນໄປຕ່າງປະເທດຕາມມາດຕາ 9 ຂອງກົດໝາຍເລກທີ 6698 ສະບັບຫຼັງປີ 2024 (ສັນຍາມາດຕະຖານຍັງບໍ່ທັນລົງນາມ); ແກ້ໄຂຖ້ອຍຄຳ "ນິລະນາມ" ສຳລັບບັນທຶກສຸຂະພາບ/ຄລີນິກ/ການເງິນ ເປັນການເກັບຮັກສາແບບຈຳກັດທີ່ຕັດການເຊື່ອມໂຍງກັບບຸກຄົນແລ້ວ (ຂໍ້ຄວາມອິດສະຫຼະໃນບັນທຶກເຊດຊັນບໍ່ຖືກແກ້ໄຂ); ແກ້ໄຂພື້ນຖານທາງກົດໝາຍຂອງແຖວຫຼັກຖານຄວາມຍິນຍອມເປັນມາດຕາ 5 ວັກ 2 (e) (ເອົາການອ້າງອີງມາດຕາ 20 ວັກ 2 ທີ່ຜິດອອກ); ອັບເດດແຖວແບບຟອມຂໍສິດເຂົ້າໃຊ້ກ່ອນຕາມການແຍກການແຈ້ງຂໍ້ມູນອອກຈາກການອະນຸມັດຂໍ້ຄວາມທາງການຄ້າ; ເພີ່ມຫຼັກການກຳຈັດເປັນໄລຍະທຸກ 6 ເດືອນສຳລັບປະເພດທີ່ບໍ່ມີການກຳຈັດອັດຕະໂນມັດ; ແກ້ໄຂຂໍ້ມູນລະບຸຕົວຕົນໃຫ້ເປັນວິສາຫະກິດສ່ວນບຸກຄົນ; ຂຽນພາກ VERBİS ຕາມຄຳຕັດສິນຂອງຄະນະກຳມະການປີ 2025.
• 1.6 — 10 ຕຸລາ 2026: ເອົາ Expo (Expo Push Notification Service) ອອກຈາກບັນທຶກຜູ້ປະມວນຜົນຂໍ້ມູນຊ່ວງ/ຜູ້ປະມວນຜົນຂໍ້ມູນ; ການແຈ້ງເຕືອນແບບ push ສົ່ງຜ່ານ Apple (APNs) ແລະ Google (FCM) ເທົ່ານັ້ນ, Expo/EAS ເປັນພຽງເຄື່ອງມືສ້າງແອັບ ແລະ ບໍ່ປະມວນຜົນຂໍ້ມູນຂອງຜູ້ໃຊ້ປາຍທາງ.
• 1.5 — 10 ຕຸລາ 2026: ເອົາຖ້ອຍຄຳກ່ຽວກັບການເລືອກ Google Analytics ອອກ; ເຮັດໃຫ້ຊັດເຈນວ່າບໍ່ໃຊ້ການວິເຄາະຂອງບຸກຄົນທີສາມ ແລະ ລະບຸຜູ້ປະມວນຜົນການແຈ້ງເຕືອນແບບ push.
• 1.4 — 4 ຕຸລາ 2026: ກຳນົດເອກະສານປັດຈຸບັນເປັນສະບັບທີ່ອະນຸມັດແລ້ວ. ສະບັບນີ້ເພີ່ມພຽງສິ່ງຕໍ່ໄປນີ້: ການລຶບບັນຊີ (ການເຂົ້າເຖິງຖືກຕັດທັນທີ, ຂໍ້ມູນສ່ວນບຸກຄົນຖືກລຶບ/ເຮັດໃຫ້ເປັນນິລະນາມ, ບັນທຶກການຊຳລະເງິນທີ່ກົດໝາຍກຳນົດໃຫ້ເກັບຮັກສາຖືກເກັບໄວ້ໂດຍບໍ່ລະບຸຕົວຕົນ; ບໍ່ມີໄລຍະເວລາຍົກເລີກ); ການລຶບຊ່ອງຂໍ້ມູນສຸຂະພາບຂອງຜູ້ໃຊ້ບໍລິການຫຼັງຈາກ 30 ວັນ; ໄລຍະເວລາ 7 ວັນສຳລັບໃບຮັບເງິນທີ່ບໍ່ມີການເຊື່ອມໂຍງ; ການປິດບັງຂໍ້ມູນຕິດຕໍ່ຂອງຜູ້ໃຊ້ບໍລິການໃນໂໝດຊ່ວຍເຫຼືອ; ການວັດແທກຝັ່ງເຊີບເວີແບບບໍ່ລະບຸຕົວຕົນ; ອີເມວບໍລິການ ແລະ Google Workspace; ຜູ້ປະມວນຜົນການແຈ້ງເຕືອນແບບ push; ທີ່ຢູ່ຝ່າຍຊ່ວຍເຫຼືອ; ຕະຫຼາດ (ຕວກກີ).
• 1.3 — 7 ກໍລະກົດ 2026 (ການອັບເດດວັນທີ 4 ສິງຫາ 2026): ສະບັບກ່ອນໜ້າ.

ໝາຍເຫດສຳຄັນກ່ຽວກັບຖານະຜູ້ຄວບຄຸມຂໍ້ມູນ / ຜູ້ປະມວນຜົນຂໍ້ມູນ: ນະໂຍບາຍການເກັບຮັກສາ ແລະ ການກຳຈັດຂໍ້ມູນສະບັບນີ້ ("ນະໂຍບາຍ") ກຳນົດໄລຍະເວລາການເກັບຮັກສາຂໍ້ມູນສ່ວນບຸກຄົນທີ່ຖືກປະມວນຜົນໃນຂອບເຂດຂອງບໍລິການຊອບແວ Corenta ("ບໍລິການ" ຫຼື "ແອັບ") ເຊິ່ງພັດທະນາ ແລະ ດຳເນີນການໂດຍ Mertcan Demir ຜູ້ດຳເນີນທຸລະກິດໃນຮູບແບບວິສາຫະກິດສ່ວນບຸກຄົນພາຍໃຕ້ຊື່ການຄ້າ "Teta Studio" ("Corenta", "Teta Studio", "ບໍລິສັດ"), ເກນທີ່ໃຊ້ໃນການກຳນົດໄລຍະເວລາເຫຼົ່ານີ້ ແລະ ວິທີການທີ່ຂໍ້ມູນເຫຼົ່ານີ້ຈະຖືກລຶບ, ທຳລາຍ ຫຼື ເຮັດໃຫ້ເປັນນິລະນາມ ເມື່ອໄລຍະເວລາການເກັບຮັກສາສິ້ນສຸດລົງ ຫຼື ເຫດຜົນຂອງການປະມວນຜົນໝົດໄປ.

ນະໂຍບາຍນີ້ຈັດທຳຂຶ້ນພາຍໃນກອບຂອງກົດໝາຍວ່າດ້ວຍການປົກປ້ອງຂໍ້ມູນສ່ວນບຸກຄົນເລກທີ 6698 ຂອງຕວກກີ ("KVKK"), ລະບຽບການວ່າດ້ວຍການລຶບ, ການທຳລາຍ ຫຼື ການເຮັດໃຫ້ຂໍ້ມູນສ່ວນບຸກຄົນເປັນນິລະນາມ ("ລະບຽບການ") ແລະ ກົດໝາຍອື່ນທີ່ກ່ຽວຂ້ອງ ແລະ ເປັນສ່ວນທີ່ບໍ່ສາມາດແຍກອອກໄດ້ຂອງບັນຊີລາຍການການປະມວນຜົນຂໍ້ມູນສ່ວນບຸກຄົນຂອງ Corenta. ນະໂຍບາຍນີ້ຄວນອ່ານປະກອບກັບເອກະສານຊີ້ແຈງ/ນະໂຍບາຍຄວາມເປັນສ່ວນຕົວທີ່ກ່ຽວຂ້ອງ ເຊິ່ງອະທິບາຍຈຸດປະສົງ ແລະ ພື້ນຖານທາງກົດໝາຍຂອງການປະມວນຜົນຢ່າງລະອຽດ; ເອກະສານນີ້ກຳນົດພຽງໄລຍະເວລາການເກັບຮັກສາ ແລະ ຂັ້ນຕອນການກຳຈັດເທົ່ານັ້ນ ແລະ ບໍ່ໄດ້ມີຈຸດປະສົງເພື່ອປະຕິບັດພັນທະແຈ້ງຂໍ້ມູນທັງໝົດຕາມມາດຕາ 10 ຂອງ KVKK ພຽງຢ່າງດຽວ.

1. ຈຸດປະສົງ ແລະ ຂອບເຂດ

1.1. ຈຸດປະສົງ

ຈຸດປະສົງຂອງນະໂຍບາຍນີ້ ແມ່ນເພື່ອອະທິບາຍເກນໃນການກຳນົດໄລຍະເວລາສູງສຸດທີ່ຈຳເປັນສຳລັບຈຸດປະສົງທີ່ຂໍ້ມູນສ່ວນບຸກຄົນຖືກປະມວນຜົນໂດຍ Corenta, ການນຳໃຊ້ໄລຍະເວລາທີ່ກົດໝາຍກຳນົດ ແລະ ຫຼັກການ ແລະ ຂັ້ນຕອນກ່ຽວກັບການລຶບ, ການທຳລາຍ ຫຼື ການເຮັດໃຫ້ຂໍ້ມູນສ່ວນບຸກຄົນທີ່ໝົດໄລຍະເວລາການເກັບຮັກສາເປັນນິລະນາມ. ນະໂຍບາຍນີ້ຈັດທຳຂຶ້ນໂດຍອີງໃສ່ບົດບັນຍັດຂອງມາດຕາ 5, ມາດຕາ 6, ມາດຕາ 7, ມາດຕາ 10, ມາດຕາ 11 ແລະ ມາດຕາ 12 ຂອງ KVKK ແລະ ມາດຕາທີ່ກ່ຽວຂ້ອງຂອງລະບຽບການ.

1.2. ຂອບເຂດ ແລະ ການແບ່ງບົດບາດ — ຄຳເຕືອນສຳຄັນ

ນະໂຍບາຍນີ້ກວມເອົາສອງຂົງເຂດທີ່ແຍກກັນ ເຊິ່ງ Corenta ປະມວນຜົນຂໍ້ມູນໃນສອງຖານະທີ່ແຕກຕ່າງກັນ; ການແຍກນີ້ຖືກນຳໃຊ້ຢ່າງສອດຄ່ອງຕະຫຼອດນະໂຍບາຍ ແລະ ມີຜົນໂດຍກົງຕໍ່ການຕີຄວາມໝາຍຕາຕະລາງໄລຍະເວລາການເກັບຮັກສາ:

(a) ບໍລິບົດເວັບໄຊຂອງບໍລິສັດ (corenta.app — ແບບຟອມຂໍສິດເຂົ້າໃຊ້ກ່ອນ/ຂໍສາທິດ): ກ່ຽວກັບຂໍ້ມູນສ່ວນບຸກຄົນທີ່ລູກຄ້າທຸລະກິດທີ່ມີທ່າແຮງທີ່ສົນໃຈຜະລິດຕະພັນສົ່ງມາຜ່ານແບບຟອມສະໝັກຂໍສິດເຂົ້າໃຊ້ກ່ອນ, Corenta/Teta Studio ດຳເນີນການໃນຖານະຜູ້ຄວບຄຸມຂໍ້ມູນໂດຍກົງຕາມມາດຕາ 3 ຂອງ KVKK.

(b) ບໍລິບົດຜະລິດຕະພັນ SaaS (app.corenta.app): ກ່ຽວກັບຂໍ້ມູນສ່ວນບຸກຄົນ (ຂໍ້ມູນການຕິດຕໍ່, ປະຫວັດສຸຂະພາບ, ບັນທຶກເຊດຊັນ, ຂໍ້ມູນນັດໝາຍ/ແພັກເກັດ ແລະ ອື່ນໆ) ທີ່ສູນພີລາທິສທາງຄລີນິກ, ກາຍະພາບບຳບັດ, ຣີຟໍເມີ, ເວລເນສ/ນວດ ແລະ ໂຍຄະ ("Tenant", "ທຸລະກິດ" ຫຼື "ສູນ") ທີ່ໃຊ້ແພລັດຟອມ Corenta ໂດຍການສະໝັກໃຊ້ ປ້ອນເຂົ້າແພລັດຟອມໃນນາມຜູ້ໃຊ້ບໍລິການຂອງຕົນ ("ຜູ້ໃຊ້ບໍລິການທີ່ເປັນເຈົ້າຂອງຂໍ້ມູນ"), ສູນເປັນຜູ້ຄວບຄຸມຂໍ້ມູນຕາມມາດຕາ 3 ຂອງ KVKK; ສ່ວນ Corenta/Teta Studio ເປັນພຽງຜູ້ປະມວນຜົນຂໍ້ມູນ ທີ່ໃຫ້ບໍລິການໂຄງສ້າງພື້ນຖານທາງເຕັກນິກຕາມຄຳສັ່ງຂອງສູນ. ພັນທະແຈ້ງຂໍ້ມູນຕໍ່ຜູ້ໃຊ້ບໍລິການ, ການຂໍຄວາມຍິນຍອມຢ່າງຊັດເຈນ ແລະ ການຕັດສິນໃຈສຸດທ້າຍກ່ຽວກັບການເກັບຮັກສາ/ການກຳຈັດຂໍ້ມູນຜູ້ໃຊ້ບໍລິການ ເປັນຄວາມຮັບຜິດຊອບທາງກົດໝາຍຂອງສູນ. Corenta ອຳນວຍຄວາມສະດວກທາງເຕັກນິກໃນການປະຕິບັດພັນທະເຫຼົ່ານີ້ພາຍໃນຜະລິດຕະພັນ (ກົນໄກບັນທຶກຄວາມຍິນຍອມ consent_logs, ໜ້າຈໍອະນຸມັດ KVKK ໃນມືຖື kvkk.tsx, ຮ່ອງຮອຍການກວດສອບ) ແຕ່ບໍ່ຮັບໂອນ ຫຼື ຮັບເອົາພັນທະການປະຕິບັດຕາມ KVKK ຂອງສູນ. ໄລຍະເວລາການເກັບຮັກສາທີ່ອະທິບາຍໃນນະໂຍບາຍນີ້ສຳລັບບໍລິບົດນີ້ ສະແດງໃຫ້ເຫັນວ່າ Corenta ໃນຖານະຜູ້ປະມວນຜົນຂໍ້ມູນ ເກັບຂໍ້ມູນເຫຼົ່ານີ້ໄວ້ໃນໂຄງສ້າງພື້ນຖານຂອງຕົນແທ້ດົນປານໃດ; ການຕັດສິນໃຈ ແລະ ໄລຍະເວລາການກຳຈັດສຸດທ້າຍອາດຖືກກຳນົດພາຍໃນກອບຂອງຄຳສັ່ງຂອງສູນ ແລະ ກົດໝາຍທີ່ສູນຢູ່ພາຍໃຕ້.

ນອກຈາກນີ້ ນະໂຍບາຍນີ້ຍັງກວມເອົາຂະບວນການເກັບຮັກສາ/ການກຳຈັດຂໍ້ມູນສ່ວນບຸກຄົນຂອງພະນັກງານ, ຄູ່ຮ່ວມທຸລະກິດ ແລະ ຜູ້ສະໜອງຂອງ Corenta ໃນດ້ານຫຼັກການທົ່ວໄປ; ແຕ່ຈຸດສຸມຫຼັກຂອງນະໂຍບາຍແມ່ນຂໍ້ມູນລູກຄ້າ/ຜູ້ໃຊ້ບໍລິການທີ່ນິຍາມໄວ້ໃນຂໍ້ (a) ແລະ (b) ຂ້າງເທິງ.

1.3. ຂໍ້ມູນຜູ້ຄວບຄຸມຂໍ້ມູນ / ຜູ້ປະມວນຜົນຂໍ້ມູນ

1.4. ກົດໝາຍພື້ນຖານ

• ກົດໝາຍວ່າດ້ວຍການປົກປ້ອງຂໍ້ມູນສ່ວນບຸກຄົນເລກທີ 6698,
• ລະບຽບການວ່າດ້ວຍການລຶບ, ການທຳລາຍ ຫຼື ການເຮັດໃຫ້ຂໍ້ມູນສ່ວນບຸກຄົນເປັນນິລະນາມ (ລັດຖະກິດຂອງຕວກກີ (Resmî Gazete) ລົງວັນທີ 28.10.2017 ສະບັບເລກທີ 30224),
• ຄູ່ມືວ່າດ້ວຍການລຶບ, ການທຳລາຍ ຫຼື ການເຮັດໃຫ້ຂໍ້ມູນສ່ວນບຸກຄົນເປັນນິລະນາມ ແລະ ຄຳຕັດສິນຂອງຄະນະກຳມະການປົກປ້ອງຂໍ້ມູນສ່ວນບຸກຄົນ ("ຄະນະກຳມະການ"),
• ປະມວນກົດໝາຍການຄ້າຕວກກີເລກທີ 6102 (ການເກັບຮັກສາບັນຊີ ແລະ ເອກະສານທາງການຄ້າ),
• ກົດໝາຍວ່າດ້ວຍຂັ້ນຕອນອາກອນເລກທີ 213 (ການເກັບຮັກສາບັນທຶກການເງິນ),
• ກົດໝາຍສະເພາະຂະແໜງອື່ນທີ່ກ່ຽວຂ້ອງ (ລວມທັງກົດໝາຍກ່ຽວກັບການໃຫ້ບໍລິການສຸຂະພາບ ໃນຂອບເຂດທີ່ນຳໃຊ້ໄດ້).

2. ນິຍາມ

3. ເກນໃນການກຳນົດໄລຍະເວລາການເກັບຮັກສາ ແລະ ການກຳຈັດ (ມາດຕາ 5, ມາດຕາ 6 ຂອງ KVKK)

3.1. ເຫດຜົນທີ່ຕ້ອງເກັບຮັກສາ

ໃນ Corenta, ຂໍ້ມູນສ່ວນບຸກຄົນຖືກເກັບຮັກສາໄວ້ສະເພາະຕາມໄລຍະເວລາທີ່ກົດໝາຍທີ່ກ່ຽວຂ້ອງກຳນົດໄວ້ຢ່າງຊັດເຈນ ຫຼື ຕາມໄລຍະເວລາທີ່ຈຳເປັນສຳລັບຈຸດປະສົງທີ່ຂໍ້ມູນຖືກປະມວນຜົນເທົ່ານັ້ນ. ໃນການກຳນົດໄລຍະເວລາການເກັບຮັກສາ ຈະອີງໃສ່ເກນຕໍ່ໄປນີ້:

1. ມີພັນທະການເກັບຮັກສາຕາມກົດໝາຍຫຼືບໍ່? (ເຊັ່ນ ໄລຍະເວລາການເກັບຮັກສາຂັ້ນຕ່ຳສຳລັບບັນທຶກການເງິນຕາມປະມວນກົດໝາຍການຄ້າຕວກກີ ແລະ ກົດໝາຍວ່າດ້ວຍຂັ້ນຕອນອາກອນ.)
2. ຂໍ້ມູນຖືກປະມວນຜົນເພື່ອຈຸດປະສົງໃດ ແລະ ຈຸດປະສົງນີ້ຍັງໃຊ້ໄດ້ຢູ່ຫຼືບໍ່? (ມາດຕາ 5 ວັກ 2 ຂອງ KVKK — ຫຼັກການຈຳກັດຕາມຈຸດປະສົງ.)
3. ຈຳເປັນສຳລັບການສ້າງ/ການປະຕິບັດສັນຍາຫຼືບໍ່? (ເຊັ່ນ ຂໍ້ມູນນັດໝາຍ ແລະ ແພັກເກັດ ໃນຂະນະທີ່ຄວາມສຳພັນການສະໝັກໃຊ້/ການໃຫ້ບໍລິການຍັງດຳເນີນຢູ່.)
4. ຈຳເປັນສຳລັບການສ້າງຕັ້ງ, ການໃຊ້ ຫຼື ການປົກປ້ອງສິດ (ເປັນເຄື່ອງມືພິສູດໃນຂໍ້ຂັດແຍ່ງທາງກົດໝາຍທີ່ອາດເກີດຂຶ້ນ) ຫຼືບໍ່? (ໂດຍຄຳນຶງເຖິງອາຍຸຄວາມທົ່ວໄປຂອງກົດໝາຍວ່າດ້ວຍໜີ້ສິນ.)
5. ມີຄວາມຍິນຍອມຢ່າງຊັດເຈນຂອງເຈົ້າຂອງຂໍ້ມູນຫຼືບໍ່ ແລະ ຄວາມຍິນຍອມນີ້ຍັງມີຜົນຢູ່ຫຼືບໍ່?
6. Corenta ຫຼື ສູນມີຜົນປະໂຫຍດອັນຊອບທຳຫຼືບໍ່? (ເຊັ່ນ ບັນທຶກຄວາມປອດໄພ, ການກວດຫາການສໍ້ໂກງ/ການໃຊ້ໃນທາງທີ່ຜິດ.)
7. ຂໍ້ມູນຢູ່ໃນປະເພດຂໍ້ມູນປະເພດພິເສດ (ສຸຂະພາບ) ຫຼືບໍ່? ໃນກໍລະນີນີ້ ຕາມມາດຕາ 6 ຂອງ KVKK ຈະນຳໃຊ້ການຈຳກັດການເຂົ້າເຖິງ ແລະ ການໃຫ້ເຫດຜົນທີ່ເຂັ້ມງວດກວ່າ; ໄລຍະເວລາການເກັບຮັກສາຈະບໍ່ຖືກຂະຫຍາຍເກີນຈຸດປະສົງເດັດຂາດ.

ຖ້າບໍ່ມີເກນໃດຂ້າງເທິງທີ່ຮຽກຮ້ອງໃຫ້ເກັບຮັກສາຂໍ້ມູນສ່ວນບຸກຄົນໃດໜຶ່ງ, ຂໍ້ມູນນັ້ນຈະຖືກລຶບ, ທຳລາຍ ຫຼື ເຮັດໃຫ້ເປັນນິລະນາມທັນທີ.

3.2. ເຫດຜົນທີ່ຕ້ອງກຳຈັດ

ຂໍ້ມູນສ່ວນບຸກຄົນຈະຖືກລຶບ, ທຳລາຍ ຫຼື ເຮັດໃຫ້ເປັນນິລະນາມ ຕາມຄຳຮ້ອງຂໍຂອງເຈົ້າຂອງຂໍ້ມູນ ຫຼື ຕາມໜ້າທີ່ໂດຍ Corenta/ສູນ ໃນກໍລະນີຕໍ່ໄປນີ້:

a) ການປ່ຽນແປງ ຫຼື ການຍົກເລີກບົດບັນຍັດຂອງກົດໝາຍທີ່ເປັນພື້ນຖານຂອງການປະມວນຜົນ, b) ຈຸດປະສົງທີ່ຮຽກຮ້ອງໃຫ້ປະມວນຜົນ ຫຼື ເກັບຮັກສາໝົດໄປ, c) ໃນກໍລະນີການປະມວນຜົນທີ່ອີງໃສ່ຄວາມຍິນຍອມຢ່າງຊັດເຈນ ເຈົ້າຂອງຂໍ້ມູນຖອນຄວາມຍິນຍອມ, d) ເຈົ້າຂອງຂໍ້ມູນຮ້ອງຂໍໃຫ້ລຶບ/ທຳລາຍພາຍໃນກອບຂອງສິດຕາມມາດຕາ 11 ຂອງ KVKK ແລະ ຄຳຮ້ອງຂໍນີ້ຖືກເຫັນວ່າເໝາະສົມ (ຄຳຮ້ອງຂໍລຶບບັນຊີ), e) ໄລຍະເວລາການເກັບຮັກສາຂໍ້ມູນສ່ວນບຸກຄົນໝົດລົງ ແລະ ບໍ່ມີເຫດຜົນທາງກົດໝາຍໃດທີ່ຮຽກຮ້ອງໃຫ້ເກັບຮັກສາອີກ, f) ສັນຍາບໍ່ເຄີຍຖືກສ້າງຂຶ້ນ, ບໍ່ມີຜົນ, ຖືກບອກເລີກ ຫຼື ມີການຖອນຕົວຈາກສັນຍາ, g) ຄຳຮ້ອງຂໍລຶບບັນຊີສຳເລັດສົມບູນຕາມຂະບວນການທີ່ລະບຸໄວ້ໃນມາດຕາ 5 ຂອງນະໂຍບາຍນີ້.

4. ຕາຕະລາງປະເພດຂໍ້ມູນ, ໄລຍະເວລາການເກັບຮັກສາ ແລະ ວິທີການກຳຈັດ

ຕາຕະລາງຂ້າງລຸ່ມນີ້ສະແດງປະເພດຂໍ້ມູນສ່ວນບຸກຄົນຫຼັກທີ່ຖືກປະມວນຜົນໃນໂຄງສ້າງພື້ນຖານຂອງ Corenta, ໄລຍະເວລາການເກັບຮັກສາ, ເຫດຜົນ ແລະ ວິທີການກຳຈັດທີ່ຈະນຳໃຊ້ເມື່ອສິ້ນສຸດໄລຍະເວລາ. ເວັ້ນເສຍແຕ່ໄດ້ລະບຸໄວ້ຢ່າງຊັດເຈນເປັນຢ່າງອື່ນ ກົດທົ່ວໄປມີດັ່ງນີ້: "ຕາບໃດທີ່ບັນຊີ/ບັນທຶກທີ່ກ່ຽວຂ້ອງຍັງໃຊ້ງານຢູ່ + 30 ວັນນັບແຕ່ຄຳຮ້ອງຂໍລຶບບັນຊີຖືກດຳເນີນການ." ຕາຕະລາງນີ້ຄວນອ່ານປະກອບກັບຂັ້ນຕອນການລຶບບັນຊີທີ່ອະທິບາຍໃນພາກທີ 5. ສຳລັບບາງປະເພດ ຂັ້ນຕອນຫຼັງຈາກ 30 ວັນຂອງຂະບວນການນີ້ບໍ່ແມ່ນ DELETE (ການລຶບຖາວອນ) ແຕ່ແມ່ນການເຮັດໃຫ້ເປັນນິລະນາມ — ການແຍກນີ້ໄດ້ລະບຸໄວ້ຢ່າງຊັດເຈນໃນແຖວທີ່ກ່ຽວຂ້ອງ ແລະ ໃນພາກທີ 6.2.

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

</div>

ໝາຍເຫດ 1: ໃນຕາຕະລາງຂ້າງເທິງ ຖ້ອຍຄຳ "ຕາບໃດທີ່ບັນຊີ/tenant ຍັງໃຊ້ງານຢູ່" ໝາຍເຖິງໄລຍະເວລາທີ່ການສະໝັກໃຊ້ Corenta ຂອງສູນທີ່ກ່ຽວຂ້ອງຍັງດຳເນີນຢູ່ ແລະ ບັນທຶກຜູ້ໃຊ້ບໍລິການຍັງບໍ່ຖືກສູນລຶບ. ເວລາທີ່ສູນຈະລຶບຂໍ້ມູນຂອງຜູ້ໃຊ້ບໍລິການຂອງຕົນ ຖືກກຳນົດພາຍໃນກອບຂອງນະໂຍບາຍ KVKK ຂອງສູນເອງ (ໃນຖານະຜູ້ຄວບຄຸມຂໍ້ມູນ) ແລະ ຄວາມສຳພັນຂອງສູນກັບຜູ້ໃຊ້ບໍລິການ; Corenta ສະໜອງຄວາມສາມາດທາງເຕັກນິກສຳລັບຂະບວນການນີ້.

ໝາຍເຫດ 2: ໄລຍະເວລາ 2 ປີ ໃນລຳດັບທີ 7 (ບັນທຶກຮ່ອງຮອຍການກວດສອບ) ແລະ 5 ປີ ໃນລຳດັບທີ 8 (ບັນທຶກຄວາມຍິນຍອມ) ເປັນໄລຍະເວລາການເກັບຮັກສາຄົງທີ່ທີ່ Corenta ກຳນົດ (ບໍ່ຄືກັບໄລຍະເວລາ TTK/VUK ໃນລຳດັບທີ 6, ບໍ່ໄດ້ອີງໃສ່ບົດບັນຍັດກົດໝາຍໂດຍກົງ; ເປັນຄຳໝັ້ນສັນຍາທີ່ຜູກພັນດ້ວຍຕົນເອງ ທີ່ກຳນົດພາຍໃນກອບຂອງຜົນປະໂຫຍດອັນຊອບທຳ ແລະ ພັນທະການພິສູດຕາມມາດຕາ 5 ວັກ 2 (f) ຂອງ KVKK). ເມື່ອສິ້ນສຸດໄລຍະເວລາເຫຼົ່ານີ້ ປັດຈຸບັນຍັງບໍ່ມີກົນໄກການລຶບເມື່ອສິ້ນສຸດການເກັບຮັກສາແບບອັດຕະໂນມັດເຮັດວຽກໃນລະບົບ — ເມື່ອໝົດໄລຍະເວລາ ການລຶບ/ການເຮັດໃຫ້ເປັນນິລະນາມຈະຖືກດຳເນີນດ້ວຍມື, ເມື່ອນຳລະບົບອັດຕະໂນມັດມາໃຊ້ ນະໂຍບາຍນີ້ຈະຖືກປັບປຸງ. ຖ້ອຍຄຳ "ບໍ່ເກີນ 2 ປີ" ໃນລຳດັບທີ 9 (ຂໍ້ມູນແບບຟອມຂໍສິດເຂົ້າໃຊ້ກ່ອນ) ຢູ່ໃນຂອບເຂດທີ່ແຕກຕ່າງກັນ ແລະ ສະແດງຂີດຈຳກັດສູງສຸດທາງກົດໝາຍທີ່ແຍກຕ່າງຫາກ ຕາມທີ່ອະທິບາຍໄວ້ໃນແຖວຂອງມັນເອງ.

5. ຂະບວນການລຶບບັນຊີ — ການເຮັດວຽກຕັ້ງແຕ່ຕົ້ນຈົນຈົບ

ເພື່ອຕອບສະໜອງຄຳຮ້ອງຂໍລຶບຂອງເຈົ້າຂອງຂໍ້ມູນຕາມມາດຕາ 11 ຂອງ KVKK ທາງເຕັກນິກ, Corenta ນຳໃຊ້ສະຖາປັດຕະຍະກຳການລຶບສອງຂັ້ນຕອນ ທີ່ຄຳນຶງເຖິງຄວາມສົມດຸນລະຫວ່າງປະສົບການຂອງຜູ້ໃຊ້ ກັບ ຄວາມຕ້ອງການດ້ານຄວາມປອດໄພຂອງຂໍ້ມູນ/ການພິສູດທາງກົດໝາຍ: ການລຶບແບບອ່ອນທັນທີ (soft-delete) ແລະ ຕໍ່ມາແມ່ນການລຶບຖາວອນຫຼັງຈາກ 30 ວັນ.

5.0. ການປ່ຽນແປງວັນທີ 4 ຕຸລາ 2026 — ໃນຈຸດທີ່ຂັດກັບ 5.1–5.7 ໃຫ້ມາດຕານີ້ມີຄວາມສຳຄັນກ່ອນ

ການລຶບບັນຊີ (ນັບແຕ່ 4 ຕຸລາ 2026): ເມື່ອຄຳຮ້ອງຂໍລຶບໄດ້ຮັບການຢືນຢັນ, ການເຂົ້າເຖິງບັນຊີຈະຖືກຕັດທັນທີ (ເຊດຊັນຖືກປິດ, ເຂົ້າສູ່ລະບົບບໍ່ໄດ້); ຂໍ້ມູນສ່ວນບຸກຄົນຖືກລຶບ ຫຼື ເຮັດໃຫ້ເປັນນິລະນາມ (ຊື່, ອີເມວ, ໂທລະສັບ, ຮູບພາບ ແລະ ຂໍ້ມູນລະບຸຕົວຕົນ/ການຕິດຕໍ່ຂອງຜູ້ໃຊ້ບໍລິການ ແລະ ຊ່ອງຂໍ້ມູນສຸຂະພາບ — ກຸ່ມເລືອດ, ອາການແພ້, ພາວະຊຳເຮື້ອ, ຢາ — ຖືກລ້າງ); ບັນທຶກການຊຳລະເງິນ ແລະ ຄ່າຕອບແທນທີ່ກົດໝາຍກຳນົດໃຫ້ເກັບຮັກສາບໍ່ຖືກລຶບ; ຖືກເກັບໄວ້ໂດຍຕັດການເຊື່ອມໂຍງກັບບຸກຄົນ ແລະ ຈຳກັດການເຂົ້າເຖິງ. ບໍ່ມີໄລຍະເວລາຍົກເລີກຫຼັງຈາກການຮ້ອງຂໍ; ການລຶບບັນທຶກການຢືນຢັນຕົວຕົນ ແລະ ໄຟລ໌ຖາວອນ ຈະສຳເລັດໃນຂະບວນການເບື້ອງຫຼັງສາມສິບວັນທີ່ມີຢູ່.

ການລຶບບັນທຶກຜູ້ໃຊ້ບໍລິການ ແລະ ຊ່ອງຂໍ້ມູນສຸຂະພາບ (ນັບແຕ່ 4 ຕຸລາ 2026): ເມື່ອທຸລະກິດລຶບບັນທຶກຜູ້ໃຊ້ບໍລິການທີ່ບໍ່ມີບັນຊີ, ບັນທຶກຈະຖືກເອົາອອກຈາກລາຍການທີ່ໃຊ້ງານທັນທີ; ຫຼັງຈາກ 30 ວັນ ຊ່ອງຂໍ້ມູນສຸຂະພາບຂອງຜູ້ໃຊ້ບໍລິການ (ກຸ່ມເລືອດ, ອາການແພ້, ພາວະຊຳເຮື້ອ, ຢາ) ກໍຈະຖືກລຶບ/ລ້າງພ້ອມກັບຂໍ້ມູນລະບຸຕົວຕົນ ແລະ ການຕິດຕໍ່. ກົດການເກັບຮັກສາແບບປະຫວັດສຸຂະພາບ, ການວັດແທກ ແລະ ບັນທຶກເຊດຊັນບໍ່ໄດ້ຮັບຜົນກະທົບຈາກບົດບັນຍັດນີ້.

ໄຟລ໌ໃບຮັບເງິນ (ນັບແຕ່ 4 ຕຸລາ 2026): ໄຟລ໌ໃບຮັບເງິນທີ່ບໍ່ໄດ້ເຊື່ອມໂຍງກັບການຊຳລະເງິນໃດ (ບໍ່ມີການເຊື່ອມໂຍງ) ຈະຖືກລຶບອັດຕະໂນມັດຫຼັງຈາກ 7 ວັນ; ໃບຮັບເງິນທີ່ເຊື່ອມໂຍງກັບການຊຳລະເງິນບໍ່ສາມາດຖືກລຶບໂດຍບົດບາດໃດໆ.

ຂໍ້ມູນຕິດຕໍ່ຂອງຜູ້ໃຊ້ບໍລິການໃນໂໝດຊ່ວຍເຫຼືອ (ນັບແຕ່ 4 ຕຸລາ 2026): ໃນເຊດຊັນຊ່ວຍເຫຼືອ (ຊູເປີແອັດມິນ) ຂອງ Corenta, ອີເມວ ແລະ ໂທລະສັບຂອງຜູ້ໃຊ້ບໍລິການບໍ່ຖືກສະແດງໃຫ້ພະນັກງານຊ່ວຍເຫຼືອເຫັນ; ພະນັກງານຊ່ວຍເຫຼືອເຫັນໄດ້ພຽງບົດສະຫຼຸບຕົວຕົນທີ່ຈຳກັດ (ຊື່, ສະຖານະບັນຊີ, ສະຖານະການໃຊ້ງານ, ວັນທີສ້າງ).

ສິດໃນການຂຽນຊ່ອງຂໍ້ມູນສຸຂະພາບ (ນັບແຕ່ 4 ຕຸລາ 2026): ຊ່ອງຂໍ້ມູນສຸຂະພາບຂອງຜູ້ໃຊ້ບໍລິການ (ກຸ່ມເລືອດ, ອາການແພ້, ພາວະຊຳເຮື້ອ, ຢາ) ສາມາດຂຽນໄດ້ໂດຍຜູ້ໃຊ້ບໍລິການເອງ ແລະ ຜູ້ຊ່ຽວຊານທີ່ຖືກມອບໝາຍເທົ່ານັ້ນ; ເຈົ້າຂອງ/ຜູ້ດູແລທຸລະກິດບໍ່ສາມາດຂຽນຊ່ອງເຫຼົ່ານີ້ໄດ້ (ສາມາດແກ້ໄຂບຸກຄົນທີ່ຕິດຕໍ່ໃນກໍລະນີສຸກເສີນ ແລະ ຊ່ອງຂໍ້ມູນລະບຸຕົວຕົນໄດ້).

ການວັດແທກຜະລິດຕະພັນແບບໃຊ້ນາມແຝງ: ເພື່ອປັບປຸງຜະລິດຕະພັນ, ອາດມີການວັດແທກເຫດການການນຳໃຊ້ແບບລວມດ້ວຍຕົວລະບຸແຝງຂອງສູນ ຢູ່ຝັ່ງເຊີບເວີເທົ່ານັ້ນ; ການວັດແທກນີ້ບໍ່ລວມທີ່ຢູ່ IP, ຂໍ້ມູນສຸຂະພາບ ຫຼື ການຕິດຕາມແຫຼ່ງທີ່ມາ/ໂຄສະນາ. ຕົວລະບຸແຝງຂອງສູນມີລັກສະນະເປັນນາມແຝງ (ບໍ່ແມ່ນບໍ່ລະບຸຕົວຕົນ). ຄຸນສົມບັດນີ້ປິດຢູ່ໃນປັດຈຸບັນ.

5.1. ຂັ້ນຕອນ 1 — ການລຶບແບບອ່ອນທັນທີ (Soft-Delete)

ທັນທີທີ່ຜູ້ໃຊ້ຢືນຢັນຄຳຮ້ອງຂໍລຶບບັນຊີຈາກພາຍໃນແອັບ, ລະບົບຈະດຳເນີນການຕໍ່ໄປນີ້ພ້ອມກັນ ແລະ ທັນທີ:

1. ບັນທຶກໂປຣໄຟລ໌ຂອງຜູ້ໃຊ້ຖືກປິດການໃຊ້ງານໂດຍການໃສ່ຄ່າໃນຊ່ອງ deleted_at; ບັນຊີຈະບໍ່ສາມາດເຂົ້າເຖິງ/ເບິ່ງເຫັນໄດ້ສຳລັບການໃຊ້ງານປົກກະຕິອີກ ແລະ ບໍ່ສາມາດໃຊ້ເຂົ້າສູ່ລະບົບໄດ້.
2. ນັດໝາຍທີ່ລໍຖ້າຢູ່ (ທີ່ຍັງບໍ່ທັນເກີດຂຶ້ນ) ຂອງຜູ້ໃຊ້ຖືກຍົກເລີກໂດຍອັດຕະໂນມັດ.
3. ການມອບໝາຍ (ການຈັບຄູ່ຜູ້ໃຊ້ບໍລິການ-ຜູ້ຊ່ຽວຊານ, ການມອບໝາຍໂຄງການ) ທີ່ຜູ້ໃຊ້ມີສ່ວນຮ່ວມໃນຖານະຜູ້ຊ່ຽວຊານ/ແຫຼ່ງ ຖືກເອົາອອກ.
4. ຄວາມຍິນຍອມທັງໝົດຂອງຜູ້ໃຊ້ຖືກຖອນ (ດຳເນີນການໂດຍການໃສ່ຄ່າໃນຊ່ອງ revoked_at ໃນບັນທຶກ consent_logs).

ໃນຂັ້ນຕອນນີ້ ຂໍ້ມູນຍັງບໍ່ຖືກລຶບທາງກາຍະພາບ, ແຕ່ໄດ້ຖືກເຮັດໃຫ້ບໍ່ສາມາດເຂົ້າເຖິງໄດ້ສຳລັບຈຸດປະສົງການປະມວນຜົນ ແລະ ການສະແດງຜົນປົກກະຕິ. ນີ້ປະກອບເປັນຂັ້ນຕອນທຳອິດຂອງຂະບວນການລຶບ ທີ່ມີລັກສະນະເປັນ"ການເຮັດໃຫ້ບໍ່ສາມາດເຂົ້າເຖິງໄດ້" ຕາມຄວາມໝາຍຂອງມາດຕາ 7 ຂອງ KVKK ແລະ ລະບຽບການ.

5.2. ຂັ້ນຕອນ 2 — ການລຶບຖາວອນ (ຫຼັງຈາກ 30 ວັນ)

30 (ສາມສິບ) ວັນຫຼັງຈາກການລຶບແບບອ່ອນ, ວຽກຕາມກຳນົດເວລາ (cron job) ທີ່ເຮັດວຽກໂດຍອັດຕະໂນມັດໃນລະບົບ ຈະດຳເນີນການຕໍ່ໄປນີ້ໃນລັກສະນະທີ່ບໍ່ສາມາດຍ້ອນກັບໄດ້:

1. ບັນທຶກການຢືນຢັນຕົວຕົນ (auth.users) ຂອງຜູ້ໃຊ້ຖືກລຶບຢ່າງຖາວອນ ແລະ ບໍ່ສາມາດຍ້ອນກັບໄດ້.
2. ບັນທຶກຖານຂໍ້ມູນທີ່ເຊື່ອມໂຍງກັບຜູ້ໃຊ້ຖືກດຳເນີນການແຕກຕ່າງກັນຕາມປະເພດ: ບັນທຶກທີ່ບໍ່ມີຄຸນຄ່າທາງທຸລະກິດ/ການພິສູດທີ່ເປັນອິດສະຫຼະ (ເຊັ່ນ ການແຈ້ງເຕືອນ) ຖືກລຶບຖາວອນ (DELETE/cascade); ສ່ວນຂໍ້ມູນສຸຂະພາບ (anamnesis_forms, session_notes, measurements) ແລະ ບັນທຶກທາງຄລີນິກ/ການເງິນ (payments, attendance, consent_logs) ບໍ່ຖືກລຶບ, ແຕ່ຕັດການເຊື່ອມໂຍງກັບບຸກຄົນ — ການເຊື່ອມໂຍງກັບບຸກຄົນຖືກຕັດໃນລະດັບຖານຂໍ້ມູນ, ຊ່ອງຂໍ້ຄວາມອິດສະຫຼະບາງຊ່ອງຖືກລ້າງ, ບັນທຶກຍັງຄົງເປັນບັນທຶກຂອງ tenant ທີ່ຕັດການເຊື່ອມໂຍງກັບບຸກຄົນແລ້ວ ໂດຍຈຳກັດການເຂົ້າເຖິງ (ເນື່ອງຈາກຂໍ້ຄວາມອິດສະຫຼະໃນບັນທຶກເຊດຊັນບໍ່ຖືກແກ້ໄຂ ຈຶ່ງບໍ່ຖືວ່າເປັນຂໍ້ມູນນິລະນາມ) (ເບິ່ງພາກທີ 4 ລຳດັບທີ 2-5, 8, 10 ແລະ ພາກທີ 6.2).
3. ການດຳເນີນການນີ້ຖືກກະຕຸ້ນໂດຍອັດຕະໂນມັດສະເພາະໃນຂະບວນການເບື້ອງຫຼັງທີ່ມີສິດພິເສດ (ປົກປ້ອງດ້ວຍ service-role) ຂອງລະບົບເທົ່ານັ້ນ; ບໍ່ມີຜູ້ໃຊ້ ຫຼື ຜູ້ດູແລທຸລະກິດໃດ ລວມທັງພະນັກງານບໍລິຫານ ທີ່ສາມາດເລີ່ມ, ກະຕຸ້ນໄວ ຫຼື ຢຸດຂະບວນການນີ້ດ້ວຍມືຜ່ານໜ້າຈໍຜະລິດຕະພັນປົກກະຕິ — ນີ້ແມ່ນການອອກແບບດ້ານຄວາມປອດໄພໂດຍເຈດຕະນາ ເພື່ອປ້ອງກັນການລຶບໄວ ຫຼື ຊ້າເກີນໄປໂດຍບັງເອີນ ຫຼື ໂດຍການໃຊ້ໃນທາງທີ່ຜິດ. (ການຮັບປະກັນນີ້ກວມເອົາໜ້າຈໍຜູ້ໃຊ້ ແລະ ໜ້າຈໍການຄຸ້ມຄອງປົກກະຕິຂອງຜະລິດຕະພັນ; ຂະບວນການດຳເນີນງານທາງເຕັກນິກທີ່ອາດມີການເຂົ້າເຖິງຖານຂໍ້ມູນໂດຍກົງໃນລະດັບໂຄງສ້າງພື້ນຖານທີ່ມີສິດພິເສດຂອງລະບົບ ຢູ່ນອກຂອບເຂດຂອງການຮັບປະກັນນີ້ ແລະ ຢູ່ພາຍໃຕ້ການຄວບຄຸມການເຂົ້າເຖິງພາຍໃນແຍກຕ່າງຫາກ.)

ຈຸດປະສົງຂອງຂະບວນການເບື້ອງຫຼັງ 30 ວັນ (ນັບແຕ່ 4 ຕຸລາ 2026): ເນື່ອງຈາກການເຂົ້າເຖິງບັນຊີຖືກຕັດທັນທີດ້ວຍຄຳຮ້ອງຂໍລຶບ, ໄລຍະເວລານີ້ຈຶ່ງບໍ່ໃຫ້ໂອກາດຍົກເລີກ/ຖອນຕົວ; ແຕ່ໃຊ້ເພື່ອໃຫ້ການລຶບບັນທຶກການຢືນຢັນຕົວຕົນ ແລະ ໄຟລ໌ຖາວອນສຳເລັດ ແລະ ເພື່ອພິຈາລະນາການໃຊ້ໃນທາງທີ່ຜິດທີ່ອາດເກີດຂຶ້ນ. ໄລຍະເວລານີ້ເປັນໄລຍະເວລາທີ່ສົມເຫດສົມຜົນ ແລະ ຈຳກັດ ທີ່ສອດຄ່ອງກັບຫຼັກການຄວາມພໍດີຕາມມາດຕາ 5 ຂອງ KVKK. ສາມາດສອບຖາມສະຖານະຂອງຄຳຮ້ອງຂໍລຶບໄດ້ທີ່ hello@corenta.app.

5.3. ຂໍ້ຍົກເວັ້ນ: ຂໍ້ມູນທີ່ມີພັນທະການເກັບຮັກສາຕາມກົດໝາຍ

ຂະບວນການລຶບຖາວອນ 30 ວັນຂ້າງເທິງ ບໍ່ກວມເອົາບັນທຶກທີ່ລະບຸໄວ້ໃນພາກທີ 4, ຕາຕະລາງລຳດັບທີ 6 (ຂໍ້ມູນເມຕາຂອງການສະໝັກໃຊ້/ທຸລະກຳ) ທີ່ມີພັນທະການເກັບຮັກສາຕາມກົດໝາຍພາຍໃຕ້ປະມວນກົດໝາຍການຄ້າຕວກກີ/ກົດໝາຍວ່າດ້ວຍຂັ້ນຕອນອາກອນ. ບັນທຶກເຫຼົ່ານີ້ ເຖິງແມ່ນບັນຊີຈະຖືກລຶບຖາວອນ ກໍຈະຖືກເກັບຮັກສາໄວ້ແຍກຕ່າງຫາກຈົນກວ່າໄລຍະເວລາການເກັບຮັກສາຕາມກົດໝາຍທີ່ກ່ຽວຂ້ອງຈະໝົດ ໂດຍແຍກອອກຈາກຈຸດປະສົງການປະມວນຜົນຂໍ້ມູນສ່ວນບຸກຄົນ ແລະ ດ້ວຍການເຂົ້າເຖິງທີ່ຈຳກັດສະເພາະເພື່ອການປະຕິບັດພັນທະທາງກົດໝາຍເທົ່ານັ້ນ. ເຊັ່ນດຽວກັນ, ບັນທຶກຮ່ອງຮອຍການກວດສອບ (audit_logs) ແລະ ແກນຂັ້ນຕ່ຳຂອງບັນທຶກຄວາມຍິນຍອມເພື່ອຈຸດປະສົງການພິສູດ (ເບິ່ງພາກທີ 4, ລຳດັບທີ 7-8) ກໍອາດສືບຕໍ່ຖືກເກັບໄວ້ນອກໄລຍະເວລາ 30 ວັນນີ້ ເພື່ອຈຸດປະສົງແຍກຕ່າງຫາກ ແລະ ຈຳກັດ ດ້ວຍເຫດຜົນຂອງຜົນປະໂຫຍດອັນຊອບທຳ/ການພິສູດທາງກົດໝາຍ. ໄດ້ລະບຸໄວ້ຢ່າງຊັດເຈນໃນພາກທີ 4 ໝາຍເຫດ 2 ວ່າໄລຍະເວລາທີ່ຢູ່ໃນຂອບເຂດຂໍ້ຍົກເວັ້ນນີ້ ບໍ່ສອດຄ້ອງກັບກົນໄກທາງເຕັກນິກທີ່ນຳໃຊ້ໂດຍອັດຕະໂນມັດໃນລະບົບ.

5.4. ຄຳອະທິບາຍພິເສດກ່ຽວກັບໄຟລ໌ແນບທີ່ເກັບໄວ້ (ສຳຄັນ — ຄວາມໂປ່ງໃສ)

ຕາມຫຼັກການຄວາມໂປ່ງໃສ ຂໍລະບຸຢ່າງຊັດເຈນວ່າ: ໃນລະຫວ່າງການລຶບຖາວອນ ບັນທຶກຖານຂໍ້ມູນ (ໂປຣໄຟລ໌, ນັດໝາຍ, ການມອບໝາຍ, ຄວາມຍິນຍອມ ແລະ ອື່ນໆ) ຖືກລຶບທັງໝົດ ຫຼື (ສຳລັບບັນທຶກສຸຂະພາບ/ຄລີນິກ/ການເງິນ, ເບິ່ງພາກທີ 6.2) ຖືກເຮັດໃຫ້ເປັນນິລະນາມ; ສ່ວນໄຟລ໌ແນບທີ່ເປັນຂອງຜູ້ໃຊ້ ແລະ ເກັບໄວ້ໃນພື້ນທີ່ເກັບຂໍ້ມູນ (Storage) ແຍກຕ່າງຫາກ ຈະຖືກຈັດການດັ່ງນີ້: ຮູບ avatar/ໂປຣໄຟລ໌, ເອກະສານ/ຮູບທີ່ແນບກັບແບບປະຫວັດສຸຂະພາບ ແລະ ຮູບຫຼັກຖານການຊຳລະເງິນ ຖືກລຶບອອກຈາກ Storage ໂດຍອັດຕະໂນມັດ (best-effort) ເປັນສ່ວນໜຶ່ງຂອງຂັ້ນຕອນການລຶບຖາວອນ — ນີ້ແມ່ນພຶດຕິກຳທີ່ກວດສອບແລ້ວ ແລະ ເຮັດວຽກແທ້ໃນລະບົບປັດຈຸບັນ. ຖ້າການລຶບໃນ bucket ໃດໜຶ່ງລົ້ມເຫຼວ ສະຖານະການນີ້ຈະຖືກບັນທຶກໄວ້; ແຕ່ບໍ່ຂັດຂວາງການລ້າງ bucket ອື່ນ ຫຼື ຂັ້ນຕອນການເຮັດໃຫ້ເປັນນິລະນາມ/ການລຶບຖາວອນຂອງບັນຊີ (ການອອກແບບແບບ best-effort).

ຂອບເຂດທີ່ຊື່ສັດ: ປະເພດໄຟລ໌ດຽວທີ່ຢູ່ນອກຂອບເຂດຂອງຂະບວນການອັດຕະໂນມັດນີ້ ແມ່ນເອກະສານຢືນຢັນບັດປະຈຳຕົວ/ປະກາສະນີຍະບັດທີ່ອັບໂຫຼດໃນຂະບວນການລົງທະບຽນຜູ້ຊ່ຽວຊານ/ການລົງທະບຽນແບບ solo (bucket specialist-verification-docs). ເອກະສານເຫຼົ່ານີ້ທາງເຕັກນິກບໍ່ໄດ້ຜູກກັບຜູ້ໃຊ້ ແຕ່ຜູກກັບຂະບວນການຢືນຢັນຂອງ 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 ທັງໝົດ, ສະຖາປັດຕະຍະກຳສອງຂັ້ນຕອນດຽວກັນ (soft-delete → 30 ວັນ → ການລຶບຖາວອນ) ຈະຖືກນຳໃຊ້ກັບຂໍ້ມູນ tenant ຂອງສູນ ແລະ ບັນທຶກຜູ້ໃຊ້ບໍລິການທັງໝົດພາຍໃຕ້ tenant ນີ້. ເນື່ອງຈາກສູນເປັນຜູ້ຄວບຄຸມຂໍ້ມູນຂອງຜູ້ໃຊ້ບໍລິການຂອງຕົນ, ສູນມີພັນທະແຈ້ງໃຫ້ຜູ້ໃຊ້ບໍລິການຊາບພາຍໃນກອບຂອງພັນທະ KVKK ຂອງຕົນກ່ອນຍຸຕິການສະໝັກໃຊ້; ພັນທະນີ້ບໍ່ສາມາດໂອນໃຫ້ Corenta ໄດ້.

5.7. ຄວາມສຳພັນກັບໂໝດຊ່ວຍເຫຼືອຂອງຊູເປີແອັດມິນ (Impersonation)

ຂະບວນການລຶບບັນຊີ ແລະ ການເກັບຮັກສາ ເຮັດວຽກແຍກອອກຈາກກົນໄກການຊ່ວຍເຫຼືອ/impersonation ຂອງ Corenta. ເຊດຊັນ impersonation ມີກຳນົດເວລາ (30 ນາທີ) ແລະ ເປັນແບບອ່ານຢ່າງດຽວໂດຍຄ່າເລີ່ມຕົ້ນ; ການເຂົ້າເຖິງປະເພດຂໍ້ມູນສຸຂະພາບ (ປະຫວັດສຸຂະພາບ, ບັນທຶກເຊດຊັນ, ການວັດແທກ) ຕ້ອງການຂັ້ນຕອນການອະນຸມັດແຍກຕ່າງຫາກ (health_data_enabled) ແລະ ການຂຽນ/ການລຶບໃນຕາຕະລາງເຫຼົ່ານີ້ຜ່ານ impersonation ບໍ່ໄດ້ຮັບອະນຸຍາດໃນທຸກເງື່ອນໄຂ (ໃນນະໂຍບາຍ RLS ບໍ່ມີຂໍ້ຍົກເວັ້ນໃດໆສຳລັບ impersonation). ຄວາມຊັດເຈນ: ຂໍ້ຈຳກັດໃນທີ່ນີ້ກ່ຽວກັບເຊດຊັນ impersonation ທີ່ກະຕຸ້ນໂດຍມະນຸດ ເຊິ່ງພະນັກງານຊ່ວຍເຫຼືອເຂົ້າສູ່ລະບົບ ແລະ ດຳເນີນການດ້ວຍມື; ຂະບວນການ cron ຂອງ service-role ແບບອັດຕະໂນມັດ (ບໍ່ມີການແຊກແຊງຂອງມະນຸດ) ທີ່ອະທິບາຍໃນພາກທີ 5.2 ເປັນຊັ້ນແຍກຕ່າງຫາກຈາກຂໍ້ຈຳກັດນີ້ ແລະ ບໍ່ໄດ້ຮັບຜົນກະທົບຈາກມັນ — ຂໍ້ຈຳກັດ impersonation ບໍ່ຂັດຂວາງກົນໄກການລຶບຖາວອນອັດຕະໂນມັດໃນຂັ້ນຕອນການລຶບບັນຊີ ແລະ ບໍ່ຄວນສັບສົນກັບມັນ. ດັ່ງນັ້ນ ຂະບວນການລຶບບັນຊີ/ການກຳຈັດ ຈຶ່ງດຳເນີນຜ່ານກົນໄກອັດຕະໂນມັດທີ່ກຳນົດໄວ້ໃນນະໂຍບາຍນີ້ເທົ່ານັ້ນ.

6. ວິທີການກຳຈັດ

ຕາມບົດບັນຍັດຂອງມາດຕາ 8 ແລະ ມາດຕາຕໍ່ໆໄປຂອງລະບຽບການ, ວິທີການລຶບ/ທຳລາຍ/ເຮັດໃຫ້ເປັນນິລະນາມທີ່ນຳໃຊ້ຕາມສື່ບັນທຶກ ໄດ້ອະທິບາຍໄວ້ຂ້າງລຸ່ມນີ້.

6.1. ການລຶບ

ແມ່ນການດຳເນີນການເຮັດໃຫ້ຂໍ້ມູນສ່ວນບຸກຄົນບໍ່ສາມາດເຂົ້າເຖິງ ແລະ ນຳມາໃຊ້ຄືນໄດ້ໃນທຸກກໍລະນີສຳລັບຜູ້ໃຊ້ທີ່ກ່ຽວຂ້ອງ (ລວມທັງຜູ້ໃຊ້ແອັບ ແລະ ພະນັກງານທີ່ມີສິດເຂົ້າເຖິງແຜງຜູ້ດູແລ). ໃນ Corenta ວິທີນີ້ຖືກນຳໃຊ້ໃນຂະບວນການ soft-delete ຂັ້ນຕອນ-1: ເຖິງແມ່ນຂໍ້ມູນຈະບໍ່ຖືກເອົາອອກຈາກຖານຂໍ້ມູນທາງກາຍະພາບ, ແຕ່ກໍຖືກເຮັດໃຫ້ບໍ່ສາມາດເຂົ້າເຖິງໄດ້ທັງໝົດຜ່ານສິດການເຂົ້າເຖິງ ແລະ ໜ້າຈໍຕ່າງໆ.

6.2. ການທຳລາຍ (ການລຶບຖາວອນ)

ແມ່ນການດຳເນີນການເຮັດໃຫ້ຂໍ້ມູນສ່ວນບຸກຄົນບໍ່ສາມາດເຂົ້າເຖິງ, ກູ້ຄືນ ແລະ ນຳມາໃຊ້ຄືນໄດ້ໂດຍບໍ່ມີໃຜ ແລະ ໃນທຸກກໍລະນີ. ໃນຂະບວນການລຶບຖາວອນຂັ້ນຕອນ-2 ຂອງ Corenta ຫຼັກການນີ້ຖືກນຳໄປປະຕິບັດດ້ວຍສອງວິທີທາງເຕັກນິກທີ່ແຕກຕ່າງກັນຕາມປະເພດຂໍ້ມູນ:

• ບັນທຶກການຢືນຢັນຕົວຕົນ ແລະ ບັນທຶກທີ່ບໍ່ມີຄຸນຄ່າທາງທຸລະກິດທີ່ເປັນອິດສະຫຼະ: ບັນທຶກການຢືນຢັນຕົວຕົນ (auth.users) ຂອງຜູ້ໃຊ້ຖືກລຶບແບບບໍ່ສາມາດຍ້ອນກັບໄດ້ດ້ວຍ DELETE ໂດຍກົງໃນຂະບວນການອັດຕະໂນມັດທີ່ປົກປ້ອງດ້ວຍ service-role; ບັນທຶກທີ່ກ່ຽວຂ້ອງທີ່ບໍ່ມີຄຸນຄ່າທາງທຸລະກິດ/ການພິສູດດ້ວຍຕົວມັນເອງຫຼັງຈາກບັນຊີຖືກລຶບ (ເຊັ່ນ ການແຈ້ງເຕືອນ, notifications — ເບິ່ງພາກທີ 4 ລຳດັບທີ 10) ຖືກລຶບພ້ອມກັນໃນລະດັບຖານຂໍ້ມູນດ້ວຍ ON DELETE CASCADE.
• ບັນທຶກສຸຂະພາບ, ຄລີນິກ ແລະ ການເງິນ: ສຳລັບ anamnesis_forms, session_notes, measurements, payments, attendance ແລະ consent_logs ຂັ້ນຕອນການລຶບຖາວອນຖືກນຳໃຊ້ຜ່ານການຕັດການເຊື່ອມໂຍງກັບບຸກຄົນ ແລະ ການລ້າງບາງສ່ວນ (ເບິ່ງພາກທີ 6.6) ແທນການ DELETE ບັນທຶກ: ຖັນກະແຈຕ່າງປະເທດທີ່ລະບຸຕົວບຸກຄົນ (client_id, specialist_id, user_id ແລະ ອື່ນໆ) ຖືກຕັ້ງເປັນ NULL ແບບບໍ່ສາມາດຍ້ອນກັບໄດ້ດ້ວຍຂໍ້ຈຳກັດ FK ON DELETE SET NULL; ຖັນເນື້ອໃນທີ່ອາດມີຂໍ້ມູນລະບຸຕົວຕົນທີ່ຊັດເຈນ ຫຼື PII ໃນຂໍ້ຄວາມອິດສະຫຼະ (ຄຳຕອບໃນແບບປະຫວັດສຸຂະພາບ, ໝາຍເຫດຂໍ້ຄວາມອິດສະຫຼະຂອງການວັດແທກ/ການຊຳລະເງິນ, ເລກອ້າງອີງໃບຮັບເງິນ, ທີ່ຢູ່ IP ຂອງບັນທຶກຄວາມຍິນຍອມ) ຖືກລ້າງ ຫຼື ແທນທີ່ດ້ວຍເຄື່ອງໝາຍນິລະນາມໂດຍຟັງຊັນ anonymize_user_relations() (ເອີ້ນໃຊ້ໄດ້ໂດຍ service-role ເທົ່ານັ້ນ, default-deny). ສ່ວນເນື້ອໃນທີ່ເປັນຕົວເລກ ແລະ ທາງປະຫວັດສາດທາງຄລີນິກ/ການເງິນ (ວັນທີ, ຈຳນວນເງິນ, ຄ່າການວັດແທກ, ຍອດເຊດຊັນທີ່ເຫຼືອ, ສະຖານະມາ/ບໍ່ມາ, ເວລາທີ່ໃຫ້/ຖອນຄວາມຍິນຍອມ) ຍັງຄົງຖືກເກັບໄວ້ເປັນບັນທຶກຂອງ tenant ທີ່ຕັດການເຊື່ອມໂຍງກັບບຸກຄົນແລ້ວ ຕາມພັນທະການເກັບບັນທຶກຂອງສູນ ແລະ (ສຳລັບບັນທຶກເຊດຊັນ) ຫຼັກການ append-only; ເນື່ອງຈາກຂໍ້ຄວາມອິດສະຫຼະໃນບັນທຶກເຊດຊັນບໍ່ຖືກແກ້ໄຂ ບັນທຶກເຫຼົ່ານີ້ຈຶ່ງບໍ່ຖືວ່າເປັນຂໍ້ມູນນິລະນາມ ແລະ ຖືກເກັບໄວ້ໂດຍຈຳກັດການເຂົ້າເຖິງ.

ໃນບັນທຶກເຊດຊັນ (session_notes) ຂໍ້ຈຳກັດ append-only ບໍ່ອະນຸຍາດໃຫ້ປ່ຽນແປງເນື້ອໃນ; ມີພຽງຂໍ້ຍົກເວັ້ນແຄບສະເພາະຈຸດປະສົງດຽວສຳລັບການຕັ້ງຖັນເຊື່ອມໂຍງກັບບຸກຄົນ (client_id, specialist_id) ເປັນ NULL — ເນື້ອໃນບັນທຶກເອງບໍ່ຖືກລຶບ ຫຼື ແກ້ໄຂໃນທຸກຂັ້ນຕອນຂອງຂະບວນການນີ້.

ຂອບເຂດ: ບໍ່ມີກົນໄກກວດ/ລ້າງສຳລັບຂໍ້ມູນສ່ວນບຸກຄົນພາຍໃນຂໍ້ຄວາມທີ່ອາດປາກົດໃນຊ່ອງຂໍ້ຄວາມອິດສະຫຼະນອກຈາກຖັນລະບຸຕົວຕົນທີ່ຊັດເຈນ (ເຊັ່ນ ຊື່ທີ່ປາກົດໃນເນື້ອໃນຂອງບັນທຶກເຊດຊັນ). ສະນັ້ນ ບັນທຶກເຫຼົ່ານີ້ຈຶ່ງບໍ່ຖືວ່າເປັນຂໍ້ມູນນິລະນາມ; ຖືກເກັບໄວ້ເປັນຂໍ້ມູນສ່ວນບຸກຄົນໂດຍຈຳກັດການເຂົ້າເຖິງ ແລະ ຈະຖືກກຳຈັດເມື່ອສິ້ນສຸດໄລຍະເວລາ.

ທັງສອງວິທີຂ້າງເທິງ ເນື່ອງຈາກຖືກປົກປ້ອງດ້ວຍ service-role ຈຶ່ງບໍ່ສາມາດກະຕຸ້ນ ຫຼື ຍົກເລີກຜ່ານໜ້າຈໍຜະລິດຕະພັນປົກກະຕິໄດ້.

6.3. ການລຶບອອກຈາກຂໍ້ມູນສຳຮອງ (Backup)

ຂໍ້ມູນສຳຮອງຂອງຖານຂໍ້ມູນ ຖືກຂຽນທັບ/ກຳຈັດໂດຍອັດຕະໂນມັດຫຼັງຈາກໄລຍະເວລາໃດໜຶ່ງ ພາຍໃນກອບຂອງຮອບການສຳຮອງຂໍ້ມູນປົກກະຕິ (rotation). ເຖິງແມ່ນການລຶບຖາວອນຈະມີຜົນທັນທີໃນຖານຂໍ້ມູນຫຼັກ, ຂໍລະບຸຢ່າງຊັດເຈນວ່າ ໃນຂໍ້ມູນສຳຮອງທີ່ສ້າງໄວ້ກ່ອນໜ້ານີ້ ຂໍ້ມູນອາດຍັງຄົງມີຢູ່ທາງເຕັກນິກຈົນກວ່າໄລຍະເວລາການໝູນວຽນຂໍ້ມູນສຳຮອງມາດຕະຖານຂອງຜູ້ໃຫ້ບໍລິການສຳຮອງ (Supabase) ຈະໝົດ. ສະຖານະການນີ້ແມ່ນການປະຕິບັດມາດຕະຖານພາຍໃຕ້ສັນຍາການປະມວນຜົນຂໍ້ມູນ (DPA) ຂອງຜູ້ປະມວນຜົນຂໍ້ມູນຊ່ວງທີ່ກ່ຽວຂ້ອງ (Supabase).

6.4. ໄຟລ໌ແນບໃນພື້ນທີ່ເກັບໄຟລ໌ (Storage)

ໄຟລ໌ທີ່ຜູ້ໃຊ້ອັບໂຫຼດ ເຊັ່ນ ຮູບ avatar, ໃບຮັບເງິນ ແລະ ໄຟລ໌ແນບປະຫວັດສຸຂະພາບ ຖືກເກັບໄວ້ໃນພື້ນທີ່ເກັບຂໍ້ມູນ (Storage) ແຍກຕ່າງຫາກ. ເບິ່ງພາກທີ 5.4 — ສະຖານະປັດຈຸບັນຂອງເນື້ອໃນເຫຼົ່ານີ້ໃນຂະບວນການລຶບບັນຊີ (ການລຶບອັດຕະໂນມັດສຳລັບ avatar/ໄຟລ໌ແນບປະຫວັດສຸຂະພາບ/ໃບຮັບເງິນ, ຂໍ້ຍົກເວັ້ນດຽວສຳລັບ 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. ບົດສະຫຼຸບທີ່ຊື່ສັດກ່ຽວກັບການປະຕິບັດທາງເຕັກນິກໃນປັດຈຸບັນ

ເລື່ອງຕໍ່ໄປນີ້ສະເໜີເປັນບົດສະຫຼຸບທີ່ຊື່ສັດ ແລະ ເປັນຈິງກ່ຽວກັບການປະຕິບັດທາງເຕັກນິກໃນປັດຈຸບັນ:

• ຄຳຮ້ອງຂໍລຶບ (ການລຶບບັນຊີ): ສາມາດຮ້ອງຂໍໄດ້ໂດຍກົງຈາກເມນູການຕັ້ງຄ່າທີ່ກ່ຽວຂ້ອງພາຍໃນແອັບມືຖື; ຄຳຮ້ອງຂໍນີ້ຈະໄດ້ຮັບການຕອບສະໜອງໂດຍອັດຕະໂນມັດດ້ວຍຂະບວນການສອງຂັ້ນຕອນ (soft-delete ທັນທີ → 30 ວັນ → ການລຶບຖາວອນ) ທີ່ອະທິບາຍໃນພາກທີ 5 (ມາດຕາ 11 ຂໍ້ 6).
• ການຂໍຂໍ້ມູນ / ການໂອນຍ້າຍຂໍ້ມູນ: ໄດ້ຮັບການຕອບສະໜອງໂດຍການສະໜອງຂໍ້ມູນຂອງເຈົ້າຂອງຂໍ້ມູນພາຍໃນຂອບເຂດ tenant ຂອງຕົນ ໃນຮູບແບບທີ່ມີໂຄງສ້າງ ແລະ ເຄື່ອງຈັກອ່ານໄດ້ ພາຍໃນເວລາທີ່ສົມເຫດສົມຜົນ (ຟັງຊັນ export_user_data, ຂອບເຂດ tenant ໄດ້ຮັບການກວດສອບແລ້ວ). ກົນໄກການສົ່ງມອບຂອງຂະບວນການນີ້ (ຄຸນລັກສະນະ ເຊັ່ນ ຮູບແບບໄຟລ໌, ວິທີການສົ່ງມອບ, ລິ້ງດາວໂຫຼດທີ່ມີລາຍເຊັນ) ກຳລັງຖືກພັດທະນາຢ່າງຕໍ່ເນື່ອງ; ໃນຂອບເຂດຂອງນະໂຍບາຍນີ້ ບໍ່ມີຄຳໝັ້ນສັນຍາກ່ຽວກັບໄລຍະເວລາການສົ່ງມອບທີ່ແນ່ນອນ ຫຼື ຮູບແບບໄຟລ໌/ການເຂົ້າເຖິງທີ່ສະເພາະ (ມາດຕາ 11 ຂໍ້ 1-2).
• ຂໍ້ມູນກ່ຽວກັບການໂອນໃຫ້ບຸກຄົນທີສາມ (ມາດຕາ 11 ຂໍ້ 4): ຂໍ້ມູນກ່ຽວກັບບຸກຄົນທີສາມ/ຜູ້ປະມວນຜົນຂໍ້ມູນຊ່ວງພາຍໃນປະເທດ/ຕ່າງປະເທດທີ່ໄດ້ຮັບການໂອນຂໍ້ມູນສ່ວນບຸກຄົນ ໄດ້ຮັບການຕອບສະໜອງໃນຕາຕະລາງພາກທີ 11 (ຜູ້ປະມວນຜົນຂໍ້ມູນຊ່ວງ ແລະ ສະຖານທີ່ຂອງຂໍ້ມູນ) ຂອງນະໂຍບາຍນີ້.
• ຄຳຮ້ອງຂໍແກ້ໄຂ (ມາດຕາ 11 ຂໍ້ 5): ທາງເຕັກນິກສາມາດດຳເນີນການດ້ວຍມືຜ່ານແຜງຄວບຄຸມການຄຸ້ມຄອງຂອງສູນ; ບໍ່ມີຂັ້ນຕອນການເຮັດວຽກ "ຄຳຮ້ອງຂໍແກ້ໄຂ" ແບບອັດຕະໂນມັດແຍກຕ່າງຫາກ. ໃນບໍລິບົດຂອງຜະລິດຕະພັນ SaaS ຄຳຮ້ອງຂໍແກ້ໄຂກ່ຽວກັບຂໍ້ມູນຜູ້ໃຊ້ບໍລິການ ຄວນສົ່ງໄປຫາສູນທີ່ກ່ຽວຂ້ອງກ່ອນ; Corenta ໃນຖານະຜູ້ປະມວນຜົນຂໍ້ມູນ ໃຫ້ການສະໜັບສະໜູນທາງເຕັກນິກຕາມຄຳສັ່ງຂອງສູນ.
• ການແຈ້ງແກ່ບຸກຄົນທີສາມ (ມາດຕາ 11 ຂໍ້ 7): ຄຳຮ້ອງຂໍໃຫ້ແຈ້ງການລຶບ/ການແກ້ໄຂແກ່ບຸກຄົນທີສາມທີ່ໄດ້ຮັບການໂອນ ຈະຖືກພິຈາລະນາເມື່ອສົ່ງຜ່ານຊ່ອງທາງທີ່ລະບຸໄວ້ໃນຂັ້ນຕອນການຍື່ນຄຳຮ້ອງ; ປັດຈຸບັນຂະບວນການນີ້ດຳເນີນດ້ວຍມື ບໍ່ແມ່ນແບບອັດຕະໂນມັດ.
• ການຄັດຄ້ານການຕັດສິນໃຈອັດຕະໂນມັດ/ການສ້າງໂປຣໄຟລ໌ (ມາດຕາ 11 ຂໍ້ 8): ໃນລະບົບບໍ່ມີກິດຈະກຳການຕັດສິນໃຈອັດຕະໂນມັດ ຫຼື ການສ້າງໂປຣໄຟລ໌ທີ່ໃຫ້ຜົນເສຍຕໍ່ເຈົ້າຂອງຂໍ້ມູນ ໂດຍການວິເຄາະຂໍ້ມູນທີ່ຖືກປະມວນຜົນດ້ວຍລະບົບອັດຕະໂນມັດເທົ່ານັ້ນ; ສະນັ້ນ ປັດຈຸບັນຈຶ່ງບໍ່ມີຄວາມຈຳເປັນຕ້ອງມີກົນໄກການຄັດຄ້ານແຍກຕ່າງຫາກທີ່ດຳເນີນການແທ້ສຳລັບຂໍ້ນີ້.
• ຄຳຮ້ອງຈະໄດ້ຮັບການດຳເນີນການໃຫ້ສຳເລັດໂດຍບໍ່ເສຍຄ່າ ພາຍໃນ 30 ວັນເປັນຢ່າງຊ້າ ຕາມມາດຕາ 13 ຂອງ KVKK (ຖ້າການດຳເນີນການມີຄ່າໃຊ້ຈ່າຍເພີ່ມເຕີມ, ອາດມີການຮຽກເກັບຄ່າທຳນຽມຕາມອັດຕາທີ່ຄະນະກຳມະການກຳນົດ).

8.3. ຂັ້ນຕອນການຍື່ນຄຳຮ້ອງ

ຄຳຮ້ອງຂໍກ່ຽວກັບສິດຂ້າງເທິງ ສາມາດສົ່ງເຖິງ Corenta ໄດ້:

• ທາງທີ່ຢູ່ອີເມວ hello@corenta.app,
• ຜ່ານໜ້າຈໍການຕັ້ງຄ່າ/ການຊ່ວຍເຫຼືອທີ່ກ່ຽວຂ້ອງພາຍໃນແອັບ,
• ຫຼື ດ້ວຍວິທີອື່ນທີ່ KVKK ກຳນົດ,

ສົ່ງເຖິງ Corenta.

ໝາຍເຫດສຳຄັນກ່ຽວກັບຂໍ້ມູນຜູ້ໃຊ້ບໍລິການ: ຖ້າທ່ານເປັນຜູ້ໃຊ້ບໍລິການຂອງສູນ ແລະ ຕ້ອງການຍື່ນຄຳຮ້ອງຂໍກ່ຽວກັບຂໍ້ມູນຂອງທ່ານ, ທ່ານຕ້ອງຍື່ນຕໍ່ສູນ (ຜູ້ຄວບຄຸມຂໍ້ມູນ) ທີ່ກ່ຽວຂ້ອງກ່ອນ; ເພາະສູນເປັນຜູ້ຕັດສິນສຸດທ້າຍ ແລະ ເປັນຄູ່ກໍລະນີກ່ຽວກັບຂໍ້ມູນຜູ້ໃຊ້ບໍລິການ. Corenta ໃນຖານະຜູ້ປະມວນຜົນຂໍ້ມູນ ສະໜອງເຄື່ອງມືທາງເຕັກນິກທີ່ຈຳເປັນ (ຟັງຊັນການເບິ່ງຂໍ້ມູນ, ການສົ່ງອອກ, ການລຶບ) ຕາມຄຳສັ່ງຂອງສູນ.

9. ບົດບາດ ແລະ ຄວາມຮັບຜິດຊອບ

10. ມາດຕະການຄວາມປອດໄພ (ຕະຫຼອດໄລຍະເວລາການເກັບຮັກສາ)

ຂໍ້ມູນສ່ວນບຸກຄົນຖືກປົກປ້ອງດ້ວຍມາດຕະການທາງເຕັກນິກ ແລະ ທາງການບໍລິຫານຕໍ່ໄປນີ້ຕະຫຼອດໄລຍະເວລາການເກັບຮັກສາ (ມາດຕາ 12 ຂອງ KVKK):

• ໃນສະຖາປັດຕະຍະກຳແບບຫຼາຍຜູ້ເຊົ່າ (multi-tenant) ມີການນຳໃຊ້ຫຼັກການປະຕິເສດໂດຍຄ່າເລີ່ມຕົ້ນ (default-deny) ດ້ວຍການບັງຄັບໃຫ້ມີ tenant_id ໃນທຸກຕາຕະລາງ ແລະ ນະໂຍບາຍຄວາມປອດໄພລະດັບແຖວ (Row Level Security) (37/37 ຕາຕະລາງ, 86 ນະໂຍບາຍ); ການຮົ່ວໄຫຼຂອງຂໍ້ມູນລະຫວ່າງຜູ້ເຊົ່າຖືກສະກັດທາງເຕັກນິກດ້ວຍວິທີນີ້.
• ການເຂົ້າເຖິງຕາຕະລາງທີ່ມີຂໍ້ມູນສຸຂະພາບ ຈຳກັດສະເພາະຜູ້ໃຊ້ບໍລິການທີ່ກ່ຽວຂ້ອງ, ຜູ້ຊ່ຽວຊານທີ່ຖືກມອບໝາຍ ແລະ ຜູ້ດູແລ tenant; ການຄວບຄຸມການເຂົ້າເຖິງຖືກນຳໃຊ້ໃນລະດັບຖານຂໍ້ມູນ (RLS). ບັນທຶກເຊດຊັນບໍ່ສາມາດແກ້ໄຂ/ລຶບໄດ້ຫຼັງຈາກສົ່ງແລ້ວ (append-only); ສຳລັບແບບປະຫວັດສຸຂະພາບ ບໍ່ໄດ້ໃຫ້ສິດລຶບແກ່ຜູ້ໃຊ້ໃດໆ (ລວມທັງຜູ້ດູແລ).
• ໂໝດຊ່ວຍເຫຼືອຂອງຊູເປີແອັດມິນ (impersonation) ມີກຳນົດເວລາ (30 ນາທີ), ເປັນແບບອ່ານຢ່າງດຽວໂດຍຄ່າເລີ່ມຕົ້ນ; ການຂຽນ ແລະ ການເຂົ້າເຖິງຂໍ້ມູນສຸຂະພາບຢູ່ພາຍໃຕ້ຂັ້ນຕອນແຍກຕ່າງຫາກທີ່ຕ້ອງການການອະນຸມັດເພີ່ມເຕີມ; ບໍ່ມີການເປີດສິດຂຽນຕາຕະລາງຂໍ້ມູນສຸຂະພາບໃນທຸກສະຖານະການ impersonation. (ຂໍ້ຈຳກັດນີ້ກ່ຽວກັບເຊດຊັນ impersonation ທີ່ກະຕຸ້ນໂດຍມະນຸດ; ຂະບວນການ 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 ລ້ານລີຣາຕວກກີ) ແລະ 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) ເຂົ້າກັບຂະບວນການປິດ tenant ທີ່ລະບຸໄວ້ໃນພາກທີ 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