ความปลอดภัยและข้อมูล
PDPA และความเป็นส่วนตัวของข้อมูลลูกบ้าน: เช็กลิสต์ก่อนนำงานนิติบุคคลขึ้นระบบ
ความเป็นส่วนตัวไม่ได้จบที่ checkbox ยินยอม ต้องรู้ว่าเก็บข้อมูลอะไร เพื่ออะไร ใครเข้าถึง ส่งให้ใคร เก็บนานเท่าไร และจะตอบคำขอของเจ้าของข้อมูลอย่างไร
นิติบุคคลและผู้บริหารโครงการทำงานกับข้อมูลที่เชื่อมโยงถึงบุคคลได้แทบทุกวัน ตั้งแต่รายชื่อและห้อง รูปป้ายพัสดุ ผู้มาติดต่อ งานซ่อม ภาพสลิป ไปจนถึงรายละเอียดเหตุฉุกเฉิน การนำงานเหล่านี้ขึ้นระบบช่วยให้กำหนดสิทธิ์และติดตามประวัติได้ดีขึ้น แต่ไม่ได้ทำให้องค์กรปฏิบัติตาม PDPA โดยอัตโนมัติ
บทความนี้เป็นกรอบคำถามเชิงปฏิบัติสำหรับการทำ Workshop และออกแบบระบบ ไม่ใช่คำปรึกษากฎหมาย ฐานการประมวลผล หน้าที่แจ้ง การโอนข้อมูล และระยะเก็บรักษาต้องพิจารณาจากกิจกรรม สัญญา และข้อเท็จจริงของแต่ละองค์กรร่วมกับผู้เชี่ยวชาญที่เหมาะสม
1. ระบุบทบาทของแต่ละฝ่ายจากกิจกรรมจริง
โดยทั่วไป ผู้บริหารโครงการหรือนิติบุคคลเป็นฝ่ายกำหนดวัตถุประสงค์และวิธีใช้ข้อมูลในงานอาคาร ส่วนผู้ให้บริการระบบอาจประมวลผลตามคำสั่งในบางกิจกรรม และกำหนดวัตถุประสงค์เองในบางเรื่อง เช่น บัญชีแพลตฟอร์ม ความปลอดภัย หรือการเรียกเก็บค่าบริการ อย่างไรก็ตาม บทบาทต้องพิจารณาเป็นรายกิจกรรมและเขียนให้ตรงกับสัญญา
- ใครตัดสินใจว่าจะเก็บข้อมูลประเภทนี้หรือไม่
- ใครกำหนดผู้ที่เข้าถึงและระยะเวลาเก็บ
- ผู้ให้บริการใดรับข้อมูลต่อและเพื่อวัตถุประสงค์อะไร
- ใครเป็นผู้รับคำขอหรือเหตุละเมิดข้อมูลจากลูกบ้าน
- ข้อตกลงประมวลผลข้อมูลและคำสั่งของผู้ควบคุมอยู่ที่ใด
2. ทำ Data Inventory ตาม Workflow ไม่ใช่ตามชื่อฐานข้อมูล
ให้เดินตาม lifecycle ของข้อมูลตั้งแต่เก็บ ใช้ เปิดเผย จัดเก็บสำรอง จนถึงลบหรือทำให้ไม่สามารถเชื่อมโยงถึงบุคคลได้ วิธีนี้จะเห็นสำเนาที่อยู่นอกระบบหลัก เช่น โทรศัพท์ของเจ้าหน้าที่ กลุ่มแชต ไฟล์ export อีเมล และกระดาษหน้าป้อม
เก็บจากไหน
ลูกบ้าน เจ้าหน้าที่ LINE แบบฟอร์ม ไฟล์นำเข้า กล้อง หรือผู้ให้บริการภายนอก
ใช้เพื่ออะไร
ระบุวัตถุประสงค์ที่เฉพาะพอให้ผู้ใช้เข้าใจ ไม่ใช้คำกว้างว่า “เพื่อพัฒนาบริการ” เพียงอย่างเดียว
ใครเห็นได้
แยกตาม role อาคาร ห้อง และความจำเป็นต่อหน้าที่ รวมถึงสิทธิ์ export และเปิดไฟล์
ส่งไปที่ใด
ตรวจ LINE, hosting, storage, OCR, payment, support และผู้รับข้อมูลในหรือต่างประเทศ
จบ lifecycle อย่างไร
กำหนด retention, archive, deletion, backup expiry และหลักฐานการดำเนินการ
3. ลดข้อมูลตั้งแต่แบบฟอร์มและภาพถ่าย
การจำกัดข้อมูลตั้งแต่ต้นลดทั้งภาระทางกฎหมายและผลกระทบเมื่อเกิดเหตุ แบบฟอร์มควรถามเฉพาะสิ่งที่ใช้ตัดสินใจหรือปฏิบัติงานจริง ส่วนช่องหมายเหตุอิสระควรมีคำแนะนำไม่ให้กรอกข้อมูลละเอียดอ่อนเกินจำเป็น
- ภาพพัสดุควรโฟกัสข้อมูลที่ใช้จับคู่และหลีกเลี่ยงบุคคลหรือบริเวณรอบข้างที่ไม่เกี่ยวข้อง
- บันทึกผู้มาติดต่อควรกำหนดชุดข้อมูลและอายุข้อมูลตามวัตถุประสงค์ด้านการเข้าออก
- รายละเอียดงานซ่อมอาจเปิดเผยพฤติกรรมหรือสภาพภายในห้อง จึงควรจำกัดผู้เห็นและข้อความที่ส่งออก
- เหตุฉุกเฉินอาจมีข้อมูลสุขภาพหรือความปลอดภัย ควรส่งการแจ้งเตือนขั้นต่ำและให้ผู้มีสิทธิ์เปิดรายละเอียดในระบบ
- ไฟล์ export ต้องมีเจ้าของ เหตุผล อายุการใช้งาน และวิธีทำลาย ไม่ถือว่าปลอดภัยเพียงเพราะออกจากระบบแล้ว
4. ทำ Privacy Notice ให้ตรงกับสิ่งที่ระบบทำจริง
Privacy Notice ควรอธิบายประเภทข้อมูล วัตถุประสงค์ ฐานการประมวลผล ผู้รับข้อมูล การโอน ระยะเก็บรักษา สิทธิ และช่องทางติดต่อด้วยภาษาที่ผู้ใช้เข้าใจได้ การเพิ่มฟังก์ชันใหม่ เช่น OCR, Payment หรือ Emergency ควรทำให้เกิดการทบทวน notice และสัญญาที่เกี่ยวข้อง
ความยินยอมไม่ใช่คำตอบเริ่มต้นสำหรับทุกกิจกรรม และ checkbox ไม่ทดแทนการมีฐานที่เหมาะสม หากใช้ความยินยอมจริง ต้องอธิบายทางเลือกและผลของการถอนอย่างเป็นธรรม จึงควรให้ฝ่ายกฎหมายหรือ DPO พิจารณาจากกรณีใช้งานจริง
5. บังคับสิทธิ์ที่ Server และตรวจทุกเส้นทางของข้อมูล
การซ่อนปุ่มในหน้าจอไม่เพียงพอ API สำหรับ list, detail, action, export, image และ download ต้องตรวจสิทธิ์และ tenant scope ด้วยกฎเดียวกัน รหัสอาคารหรือห้องจาก URL และ request body ควรถูกถือว่าไม่น่าเชื่อถือจนกว่า server จะตรวจความสัมพันธ์สำเร็จ
- กำหนด role matrix ทั้งการดู สร้าง แก้ อนุมัติ export และลบ
- ยกเลิก session เดิมเมื่อปิดบัญชี เปลี่ยนสิทธิ์ หรือเปลี่ยน credential ที่เกี่ยวข้อง
- เก็บไฟล์สำคัญแบบ private และให้ application ตรวจสิทธิ์ก่อน stream
- บันทึก actor, เวลา, action และ resource สำหรับการดำเนินการที่สำคัญ
- ทดสอบข้ามอาคาร ข้ามห้อง และ URL ที่เดา ID ได้เป็นส่วนหนึ่งของ UAT ด้านสิทธิ์
6. Retention ต้องจบด้วยการลบจริง ไม่ใช่เพียงเปลี่ยนสถานะ
แต่ละข้อมูลมีเหตุผลและอายุไม่เท่ากัน รูปพัสดุ ผู้มาติดต่อ หลักฐานการเงิน งานซ่อม และ audit อาจต้องใช้ตารางคนละชุด การย้ายรายการเข้า archive หรือซ่อนจากหน้าจอไม่เท่ากับการลบ
ตาราง retention ควรระบุเจ้าของ policy จุดเริ่มนับ เงื่อนไข hold วิธีลบจากระบบหลักและสำเนาสำรอง และหลักฐานว่ากระบวนการทำงานได้จริง พร้อมทดสอบ restore เพื่อให้ทราบว่าข้อมูลที่ควรถูกลบจะกลับมาจาก backup หรือไม่และจัดการอย่างไร
7. เตรียมขั้นตอนสิทธิของเจ้าของข้อมูลและเหตุผิดปกติก่อนเปิดใช้
ทีมต้องรู้ว่าจะรับคำขอผ่านช่องทางใด ตรวจตัวตนอย่างไร ค้นข้อมูลจากระบบและผู้ให้บริการใด ใครอนุมัติ และบันทึกการตอบอย่างไร เช่นเดียวกับเหตุข้อมูลผิดสิทธิ์หรือไฟล์ถูกส่งผิดห้อง ต้องมีช่องทางรายงาน การจำกัดผลกระทบ การเก็บหลักฐาน และ escalation ที่กำหนดเจ้าของไว้ล่วงหน้า
เช็กลิสต์สำหรับ Privacy & Security Workshop
- มี data inventory และ data flow ที่รวมระบบนอกแพลตฟอร์มหรือยัง
- ทุก field และไฟล์มีวัตถุประสงค์ เจ้าของ และระยะเก็บหรือไม่
- Privacy Notice, Terms, DPA และรายชื่อผู้ให้บริการตรงกับการทำงานจริงหรือไม่
- Role matrix ครอบคลุม detail, export, image, download และ action สำคัญหรือไม่
- มีขั้นตอนเปลี่ยน/ยกเลิกสิทธิ์และทดสอบ session เก่าหรือไม่
- มีเจ้าของคำขอข้อมูล เหตุผิดปกติ retention และการลบหรือไม่
- ได้ทดสอบ tenant isolation, upload, backup/restore และ provider failure บน environment แยกหรือไม่
- คำกล่าวอ้างบนเว็บไซต์และเอกสารขายตรงกับหลักฐานที่ตรวจสอบได้หรือไม่
แหล่งอ้างอิงทางการ
ใช้เอกสารต้นทางเหล่านี้ประกอบการทำ Workshop และตรวจสอบข้อกำหนดที่เป็นปัจจุบันกับผู้เชี่ยวชาญขององค์กร
- พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 — รัฐสภา (เปิดในแท็บใหม่)
- หลักสูตรการจัดการข้อมูลและการคุ้มครองข้อมูลส่วนบุคคลสำหรับประชาชน — GPPC / สคส. (เปิดในแท็บใหม่)
- การดำเนินงานตามคำขอใช้สิทธิของเจ้าของข้อมูลส่วนบุคคล — GPPC / สคส. (เปิดในแท็บใหม่)
หมายเหตุด้านบรรณาธิการ: เรียบเรียงโดยทีม Nitis เพื่อใช้เป็นกรอบออกแบบ workflow ไม่ใช่คำปรึกษากฎหมาย และยังไม่มีผู้ทบทวนทางกฎหมายที่ระบุชื่อ ควรให้ที่ปรึกษากฎหมายหรือ DPO ตรวจตามข้อเท็จจริงขององค์กรก่อนนำไปใช้
สรุป
การคุ้มครองข้อมูลลูกบ้านเริ่มจากการทำให้วัตถุประสงค์ ข้อมูล สิทธิ์ ผู้รับ และอายุข้อมูลมองเห็นได้ตลอด workflow เทคโนโลยีที่ออกแบบดีช่วยบังคับกติกาและสร้างหลักฐาน แต่ความรับผิดชอบยังต้องเชื่อมกับ policy สัญญา การอบรม และผู้มีอำนาจตัดสินใจขององค์กรเสมอ