ข้อมูลของคนคนเดียวอยู่ในกี่ระบบ: ทำแผนที่ข้อมูลรายบุคคลก่อนคำขอเข้าถึงข้อมูลฉบับแรกจะมาถึง

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

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

กฎใหม่เกี่ยวกับคำขอเข้าถึงข้อมูลว่าด้วยอะไร และเราอ่านถึงไหน

พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA) ให้เจ้าของข้อมูลมีสิทธิขอเข้าถึงและขอรับสำเนาข้อมูลส่วนบุคคลของตน สิทธินี้ไม่ใช่เรื่องใหม่ สิ่งที่เปลี่ยนตามรายงานของสำนักงานกฎหมายหลายแห่งคือ คณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC) ออกประกาศในเดือนกรกฎาคม 2026 กำหนดรายละเอียดวิธีปฏิบัติ เช่น ช่องทางรับคำขอ การตรวจสอบตัวตน กรอบเวลาการตอบ ค่าธรรมเนียม เหตุที่ปฏิเสธได้ และการเก็บบันทึกคำขอ (ดูตัวอย่างรายงานได้ที่ บทความของ Tilleke & Gibbins)

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

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

ข้อมูลของคนคนเดียว กระจายอยู่ตรงไหนบ้าง

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

• ระบบหลักที่ใช้งานจริง เช่น ระบบสมาชิก ระบบขาย ระบบบัญชี ซึ่งมักมีเจ้าของระบบชัดเจนและค้นข้อมูลได้

• บริการของผู้ให้บริการภายนอก เช่น เครื่องมือส่งอีเมล ระบบรับเรื่องลูกค้า เครื่องมือวิเคราะห์พฤติกรรมผู้ใช้ ข้อมูลอยู่ในระบบของเขา แต่ธุรกิจของคุณเป็นผู้เลือกส่งข้อมูลเข้าไป

• ไฟล์ที่คนในทีมถือเอง สเปรดชีตรายชื่อลูกค้า ไฟล์ที่ export ไว้ทำรายงาน ไฟล์แนบในอีเมล ซึ่งอยู่นอกการควบคุมของระบบทั้งหมด

• สำเนาและข้อมูลสำรอง ฐานข้อมูลในสภาพแวดล้อมทดสอบ และ backup ของระบบเหล่านั้น เรื่องนี้เราเขียนแยกไว้ในบทความเรื่องข้อมูลจริงกับสภาพแวดล้อมทดสอบ

• log และข้อมูลจราจร ที่มีรหัสผู้ใช้ ที่อยู่ IP หรือค่าที่ระบุตัวบุคคลได้โดยตรงหรือทางอ้อม เรื่องการแยกตารางจับคู่รหัสกับตัวบุคคลไว้ในที่ที่สิทธิ์เข้มกว่า เราเขียนไว้ในบทความเรื่องการเก็บ log

บางที่ในรายการนี้ ทีมไอทีรู้อยู่แล้ว บางที่รู้อยู่ที่คนอื่น เช่น ฝ่ายการตลาดที่สมัครเครื่องมือใหม่ด้วยบัตรเครดิตของแผนก ปัญหาไม่ได้อยู่ที่ใครทำผิด แต่อยู่ที่ไม่มีใครถือรายการทั้งหมดไว้ในที่เดียว

แผนที่ข้อมูลรายบุคคลคืออะไร

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

สำหรับแต่ละระบบหรือแหล่งข้อมูล เราบันทึกอย่างน้อยห้าเรื่อง

• ชื่อระบบ และคนที่เป็นเจ้าของระบบ

• ประเภทข้อมูลส่วนบุคคลที่เก็บอยู่ในนั้น

• ใช้ตัวระบุอะไรในการค้นหา เช่น อีเมล เบอร์โทร รหัสลูกค้า

• ดึงข้อมูลของคนคนหนึ่งออกมาได้อย่างไร และออกมาในรูปแบบไหน

• ข้อมูลนั้นถูกส่งต่อไปที่ใครหรือระบบไหนต่อ

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

ปัญหาที่ซ่อนอยู่คือไม่มีตัวระบุกลาง

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

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

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

ระบบแบบไหนที่ค้นและส่งออกรายบุคคลได้

เมื่อเราไล่ถามว่าแต่ละระบบ ค้นข้อมูลรายบุคคลได้ไหม คำตอบแบ่งเป็นสามกลุ่มกว้าง ๆ

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

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

ผู้ให้บริการภายนอกในแผนที่ของคุณ

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

สิ่งที่ทีมไอทีทำได้คือ ถามผู้ให้บริการสามเรื่องก่อนเซ็นสัญญาหรือก่อนต่ออายุ ว่าส่งออกข้อมูลรายบุคคลได้ไหม ได้ในรูปแบบอะไร และเมื่อสัญญาสิ้นสุดแล้วข้อมูลอยู่ที่ใคร เราเขียนแนวคิดทำนองนี้ไว้ในบทความเรื่องเงื่อนไขใน TOR และเรื่องผู้ให้บริการที่อาจหายไปในปีที่สามอยู่ในบทความเรื่องความเสี่ยงที่ vendor จะหายไป

เมื่อผลการค้นมีข้อมูลของคนอื่นปนมาด้วย

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

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

ข้อจำกัดที่ต้องบอกตรง ๆ

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

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

ข้อโต้แย้งที่ได้ยินบ่อย

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

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

จะเริ่มตรงไหน

1. ไล่รายการระบบที่เก็บข้อมูลส่วนบุคคล รวมบริการภายนอก ไฟล์ที่คนถือเอง และสำเนาในสภาพแวดล้อมทดสอบ ถามแต่ละแผนกว่าใช้เครื่องมืออะไรอยู่ อย่าถามแค่ทีมไอที

2. ระบุเจ้าของของแต่ละแหล่ง เป็นรายชื่อคน ไม่ใช่ชื่อแผนก

3. ทดลองค้นข้อมูลของคนหนึ่งคนในทุกระบบ ใช้บุคคลสมมติหรือเจ้าหน้าที่ที่ยินยอม แล้วจับเวลาและจดว่าติดตรงไหน

4. เขียนวิธีค้นและส่งออกของแต่ละระบบ ให้คนที่ไม่เคยทำมาก่อนทำตามได้ และเก็บ query หรือสคริปต์ไว้ในที่ที่ทีมเข้าถึงได้

5. ส่งแผนที่ให้ผู้รับผิดชอบด้านข้อมูลส่วนบุคคลตรวจ พร้อมรายการช่องว่างที่ยังปิดไม่ได้ และกำหนดวันทบทวนซ้ำ

สรุป

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

หากต้องการคุยรายละเอียดของโครงการ ติดต่อเราได้ที่ 088-983-9386 หรืออีเมล [email protected] สำนักงานของเราอยู่ที่บางกะปิ กรุงเทพฯ สำหรับองค์กรที่ยังอยู่ระหว่างร่างขอบเขตงาน เรายินดีนัดคุยเพื่อทำความเข้าใจโจทย์ก่อน โดยยังไม่ต้องมีเอกสารครบ และหากคุยแล้วพบว่าโจทย์ยังไม่ถึงเวลาต้องพัฒนาระบบใหม่ เราจะบอกตรง ๆ เพราะการเริ่มโครงการผิดจังหวะ มีต้นทุนสูงกว่าการรออีกหนึ่งไตรมาส