การออกแบบระบบธุรกิจให้สอดคล้องกับข้อกำหนดด้านการคุ้มครองข้อมูลส่วนบุคคล

พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (2019) ใช้บังคับกับองค์กรที่เก็บรวบรวม ใช้ หรือเปิดเผยข้อมูลส่วนบุคคลของบุคคลในประเทศไทย กฎหมายแยกผู้ควบคุมข้อมูลส่วนบุคคล ซึ่งเป็นผู้ตัดสินใจว่าจะประมวลผลข้อมูลเพื่ออะไรและอย่างไร ออกจากผู้ประมวลผลข้อมูลส่วนบุคคล ซึ่งประมวลผลในนามของผู้ควบคุม โดยมีคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC) เป็นผู้กำกับดูแล กฎหมายกำหนดฐานทางกฎหมายในการประมวลผล สิทธิของเจ้าของข้อมูลส่วนบุคคล หน้าที่ด้านความมั่นคงปลอดภัย หน้าที่ในการจัดทำบันทึก และข้อกำหนดเรื่องการแจ้งเหตุละเมิดข้อมูล

คู่มือนี้จัดทำขึ้นเพื่อให้ข้อมูลเท่านั้น และไม่ใช่คำแนะนำทางกฎหมาย กฎหมาย กฎหมายลำดับรอง และแนวปฏิบัติของ PDPC มีการเปลี่ยนแปลงตามเวลา เจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคลหรือที่ปรึกษากฎหมายขององค์กรควรยืนยันว่ากฎหมายใช้กับองค์กรของคุณอย่างไร เนื้อหาต่อไปนี้เป็นมุมมองด้านวิศวกรรม กล่าวคือ เมื่อกฎหมายกำหนดให้องค์กรต้องทำสิ่งใดได้ คู่มือนี้จะอธิบายว่าระบบต้องมีอะไรบ้างเพื่อทำสิ่งนั้น

เมื่อใช้ความยินยอมเป็นฐานทางกฎหมาย ระบบต้องแสดงได้ว่าบุคคลใดให้ความยินยอมต่อการใช้งานใด ด้วยถ้อยคำใด ณ เวลาใด และด้วยวิธีใด จัดเก็บบันทึกความยินยอมพร้อมตัวระบุเจ้าของข้อมูลส่วนบุคคล วัตถุประสงค์ เวอร์ชันของประกาศหรือข้อความขอความยินยอมที่บุคคลนั้นเห็น เวลาที่ให้ความยินยอม ช่องทาง (ฟอร์มบนเว็บ แอป เอกสารกระดาษที่สแกน การโทร) และหลักฐานประกอบ เช่น รหัสฟอร์ม เก็บข้อความขอความยินยอมไว้ทุกเวอร์ชัน เพราะบันทึกที่อ้างถึงข้อความซึ่งถูกเขียนใหม่ไปแล้วไม่สามารถพิสูจน์สิ่งใดได้

การถอนความยินยอมต้องทำได้ง่ายเท่ากับการให้ความยินยอม และต้องมีผลในทุกระบบที่ใช้ความยินยอมนั้น ออกแบบความยินยอมเป็นสถานะกลางที่ระบบปลายทาง (แพลตฟอร์มการตลาด ระบบส่งจดหมายข่าว Pipeline การวิเคราะห์) ตรวจสอบ ณ เวลาที่ใช้งาน แทนการคัดลอกค่าสถานะครั้งเดียวแล้วลืม จดหมายข่าวบนเว็บไซต์ของเราเองเป็นตัวอย่างเล็ก ๆ ของรูปแบบนี้ คือ ยืนยันการสมัครสองขั้นตอนทางอีเมล มีลิงก์ยกเลิกการรับในทุกฉบับ และตรวจสอบรายชื่อระงับการส่งก่อนส่งทุกครั้ง

ความยินยอมไม่ใช่ฐานที่เหมาะสมสำหรับทุกกรณี การประมวลผลข้อมูลพนักงานเพื่อจ่ายเงินเดือน หรือข้อมูลลูกค้าเพื่อส่งมอบสินค้าที่ซื้อ อาศัยฐานสัญญาหรือหน้าที่ตามกฎหมาย การขอความยินยอมในกรณีเหล่านั้นจะก่อให้เกิดสิทธิในการถอนความยินยอมที่องค์กรไม่สามารถปฏิบัติตามได้ เมื่อเลือกฐานทางกฎหมายได้ถูกต้อง บันทึกความยินยอมจะมีจำนวนน้อยลงและมีความหมายมากขึ้น

กฎหมายกำหนดให้มีมาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสม ในแง่ของระบบ เริ่มจากหลักการให้สิทธิ์น้อยที่สุด (Least Privilege) คือการควบคุมสิทธิ์ตามบทบาท ซึ่งแต่ละบทบาทเห็นเฉพาะฟิลด์ที่งานของตนต้องใช้เท่านั้น รูปแบบ Owner/Admin/Member/Viewer เป็นรากฐานที่ดีสำหรับเวิร์กสเปซ แต่แอปพลิเคชันธุรกิจมักต้องการบทบาทที่ละเอียดกว่า เช่น พนักงานคลังสินค้าเห็นที่อยู่จัดส่งแต่ไม่เห็นเลขประจำตัวประชาชน และเจ้าหน้าที่ฝ่ายบริการเห็นเลขบัตรสี่หลักสุดท้ายแต่ไม่เห็นเลขเต็ม การปิดบังข้อมูลระดับฟิลด์ที่ทำในชั้น API เพื่อไม่ให้ไคลเอนต์ใดหลีกเลี่ยงได้ คุ้มค่ากับความพยายามสำหรับฟิลด์ข้อมูลส่วนบุคคลและข้อมูลอ่อนไหว

หลักการใช้ข้อมูลเท่าที่จำเป็นใช้ทั้งตอนเก็บรวบรวมและในทุกสำเนา เก็บเฉพาะฟิลด์ที่วัตถุประสงค์นั้นต้องใช้ ไม่คัดลอกข้อมูลส่วนบุคคลจาก Production ไปยังสภาพแวดล้อมทดสอบและพัฒนา แต่ให้สร้างหรือทำข้อมูลทดสอบให้เป็นข้อมูลนิรนามแทน จำกัดการส่งออกและการดาวน์โหลดข้อมูลจำนวนมากไว้เฉพาะบทบาทที่จำเป็น และบันทึกทุกครั้ง การยืนยันตัวตนที่รัดกุมช่วยปกป้องทั้งหมดนี้ ได้แก่ การลงชื่อเข้าใช้ครั้งเดียว (SSO) ผ่านผู้ให้บริการยืนยันตัวตนขององค์กร การยืนยันตัวตนแบบสองขั้นตอน (2FA) Passkey ในกรณีที่รองรับ และการหมดเวลาของเซสชันที่เหมาะสมกับความอ่อนไหวของข้อมูล

ผู้ประมวลผลข้อมูลส่วนบุคคลที่องค์กรใช้บริการ (โฮสติ้ง อีเมล การวิเคราะห์ บริการ AI) ต้องมีสัญญาที่ผูกพันให้ปฏิบัติตามมาตรฐานเดียวกัน และสถาปัตยกรรมควรแสดงให้ชัดเจนว่าข้อมูลส่วนบุคคลใดไหลไปยังผู้ประมวลผลแต่ละราย

ข้อมูลส่วนบุคคลเก็บไว้ได้เพียงเท่าที่วัตถุประสงค์ต้องการ หรือตามที่กฎหมายกำหนด ให้แปลงหลักการนี้เป็นตารางระยะเวลาการเก็บรักษาตามประเภทข้อมูล พร้อมระยะเวลาและเหตุผลทางกฎหมายหรือทางธุรกิจ เช่น เอกสารทางบัญชีเก็บตามระยะเวลาที่กฎหมายภาษีกำหนด ข้อมูลผู้สมัครงานเก็บตามระยะเวลาที่กำหนดหลังการตัดสินใจ บัญชีลูกค้าที่ไม่มีการใช้งานลบหลังจากไม่มีการใช้งานตามระยะเวลาที่กำหนด และบันทึกการสนทนากับฝ่ายบริการลบหลังระยะเวลาที่กำหนด จากนั้นจึงทำให้ตารางนี้ทำงานโดยอัตโนมัติ นโยบายการเก็บรักษาที่ต้องรอให้มีคนรันสคริปต์ปีละครั้งไม่ถือเป็นมาตรการควบคุม

กำหนดว่าการลบทำงานอย่างไรในทางเทคนิค การลบแบบ Soft Delete ทำให้ข้อมูลมองไม่เห็นแต่ยังคงอยู่ ซึ่งยอมรับได้เพียงเป็นช่วงผ่อนผันสั้น ๆ ก่อนการลบถาวรหรือการทำให้เป็นข้อมูลนิรนาม การทำให้เป็นข้อมูลนิรนาม (Anonymization) คือการลบหรือแปลงตัวระบุแบบย้อนกลับไม่ได้โดยยังคงข้อมูลสถิติไว้ ทำให้องค์กรเก็บประวัติทางธุรกิจได้โดยไม่ต้องเก็บข้อมูลตัวบุคคล ข้อมูลสำรองต้องได้รับการจัดการแบบเดียวกัน กล่าวคือ กำหนดอายุการเก็บ ยืนยันว่ามีการเข้ารหัส และตรวจสอบให้แน่ใจว่าข้อมูลที่กู้คืนจะถูกลบตามรายการลบที่เกิดขึ้นหลังจากสำรองข้อมูลนั้น

เจ้าของข้อมูลส่วนบุคคลสามารถขอทราบว่าองค์กรมีข้อมูลใดเกี่ยวกับตน ขอสำเนาและขอแก้ไข ขอให้ลบ คัดค้านหรือขอให้ระงับการประมวลผล และถอนความยินยอม โดยผู้ควบคุมข้อมูลส่วนบุคคลต้องดำเนินการภายในระยะเวลาที่กฎหมายและกฎหมายลำดับรองกำหนด ข้อกำหนดของระบบคือ ต้องมีวิธีให้พนักงานที่ผ่านการอบรมดำเนินการตามคำขอเหล่านี้ได้โดยไม่ต้องพึ่งทีมวิศวกร ได้แก่ ค้นหาทุกระเบียนของบุคคลหนึ่งในทุกโมดูล ส่งออกข้อมูลส่วนบุคคลในรูปแบบที่อ่านได้ แก้ไขฟิลด์พร้อมบันทึกการตรวจสอบ และลบหรือทำให้เป็นข้อมูลนิรนามโดยเป็นไปตามกฎการเก็บรักษาที่ต้องปฏิบัติตาม (ใบแจ้งหนี้ไม่สามารถลบได้เพียงเพราะลูกค้าขอให้ลบ แต่สามารถเก็บไว้โดยบันทึกฐานทางกฎหมายประกอบ)

จัดทำบันทึกคำขอ: ใครเป็นผู้ขอ เมื่อใด ยืนยันตัวตนอย่างไร ดำเนินการอะไร และเสร็จสิ้นเมื่อใด บันทึกนี้ทั้งแสดงการปฏิบัติตามกฎหมาย และชี้ให้เห็นว่ากระบวนการใดล่าช้า

บันทึกการตรวจสอบ (Audit Log) บันทึกว่าใครทำอะไรกับข้อมูลใดและเมื่อใด ได้แก่ การลงชื่อเข้าใช้ การเปลี่ยนสิทธิ์ การเปิดดูและส่งออกข้อมูลส่วนบุคคล การแก้ไขและการลบ และการเปลี่ยนแปลงการตั้งค่า แอปพลิเคชันควรเขียนบันทึกนี้ ณ จุดที่เกิดการกระทำ จัดเก็บแยกจากข้อมูลธุรกิจโดยจำกัดสิทธิ์การเขียน และเก็บรักษาตามระยะเวลาที่กำหนดไว้อย่างรอบคอบ บันทึกที่อยู่ในฐานข้อมูลเดียวกันและมีผู้ดูแลระบบชุดเดียวกัน ไม่สามารถป้องกันการกระทำของบุคคลภายในได้

ทำให้บันทึกมีประโยชน์ ไม่ใช่เพียงแค่มีอยู่ กล่าวคือ ค้นหาได้ตามบุคคลและตามระเบียน ได้รับการทบทวนตามกำหนดเวลา และมีการแจ้งเตือนเมื่อพบรูปแบบผิดปกติ เช่น การส่งออกข้อมูลจำนวนมาก หรือการเข้าถึงนอกเวลาทำงาน บันทึกการตรวจสอบเองก็มีข้อมูลส่วนบุคคล และต้องอยู่ในตารางระยะเวลาการเก็บรักษาด้วย

กฎหมายกำหนดให้ผู้ควบคุมข้อมูลส่วนบุคคลแจ้งเหตุละเมิดข้อมูลส่วนบุคคลต่อ PDPC โดยไม่ชักช้า และภายใน 72 ชั่วโมงนับแต่ทราบเหตุเท่าที่จะสามารถกระทำได้ เว้นแต่การละเมิดนั้นไม่มีความเสี่ยงที่จะมีผลกระทบต่อสิทธิและเสรีภาพของบุคคล และหากมีความเสี่ยงสูง ต้องแจ้งเจ้าของข้อมูลส่วนบุคคลที่ได้รับผลกระทบด้วย 72 ชั่วโมงผ่านไปอย่างรวดเร็ว ความพร้อมในด้านระบบคือการตรวจจับ ซึ่งหมายถึงการบันทึกและการมอนิเตอร์ที่จะเผยให้เห็นการเข้าถึงโดยไม่ได้รับอนุญาต ควบคู่กับความสามารถในการระบุได้อย่างรวดเร็วว่าข้อมูลใดได้รับผลกระทบ ของบุคคลใด และในช่วงเวลาใด

ความพร้อมในด้านองค์กรคือกระบวนการรับมือเหตุการณ์ที่เป็นลายลักษณ์อักษร ได้แก่ ใครได้รับแจ้งเป็นคนแรก ใครประเมินความเสี่ยง ใครร่างหนังสือแจ้ง ใครสื่อสารกับลูกค้า และแม่แบบที่เตรียมไว้ล่วงหน้าในทุกภาษาที่องค์กรใช้ทำงาน จัดการซ้อมแผนบนโต๊ะ (Tabletop Exercise) เป็นประจำทุกปีด้วยสถานการณ์ที่สมจริง เพื่อไม่ให้การใช้คู่มือปฏิบัติงานครั้งแรกเกิดขึ้นในระหว่างเหตุละเมิดจริง