SEC // 01
ขั้นออกแบบ: เก็บเท่าที่จำเป็น
PDPA ให้เก็บข้อมูลเท่าที่จำเป็นตามวัตถุประสงค์ (มาตรา 22) ก่อนเพิ่มฟิลด์ใดในฐานข้อมูล ให้ถามว่า "ใช้ทำอะไร ถ้าไม่มีระบบทำงานได้ไหม"
- ไม่ขอวันเกิดเต็ม ถ้าแค่ต้องเช็กว่าอายุเกิน 20 ปี
- ไม่เก็บเลขบัตรประชาชน ถ้าไม่มีกฎหมายหรือธุรกรรมที่ต้องใช้
- แยกตารางข้อมูลอ่อนไหวออกจากข้อมูลทั่วไป และเข้ารหัสระดับฟิลด์
SEC // 02
ทำแผนที่ข้อมูลคู่กับสถาปัตยกรรม
วาดว่าข้อมูลส่วนบุคคลไหลผ่านบริการใดบ้าง รวมถึงบริการภายนอก เช่น ระบบส่งอีเมล analytics ระบบชำระเงิน คลาวด์ region ไหน แผนผังนี้ใช้ทำ RoPA เขียน Privacy Notice และประเมินการส่งข้อมูลไปต่างประเทศได้พร้อมกัน
SEC // 03
สิทธิ์การเข้าถึงและ Audit Trail
ประกาศมาตรการรักษาความมั่นคงปลอดภัยฯ ปี 2565 คาดหวังให้มีอย่างน้อย
- การควบคุมการเข้าถึงข้อมูลตามหน้าที่ (Role-Based Access)
- การบริหารสิทธิ์ผู้ใช้ เพิ่ม/ถอนสิทธิ์เมื่อคนเข้า-ออก
- การบันทึกว่าใครเข้าถึง แก้ไข หรือลบข้อมูลใดเมื่อไร
- การสร้างความตระหนักรู้ให้พนักงาน
แอดมินหลังบ้านไม่ควรเห็นข้อมูลทุกฟิลด์โดยอัตโนมัติ ใช้การปิดบังบางส่วน (masking) เช่น แสดงเบอร์โทรเฉพาะ 4 ตัวท้าย
SEC // 04
ออกแบบปุ่ม "ลบ" และ "ส่งออก" ไว้ตั้งแต่แรก
ผู้ใช้มีสิทธิ์ขอลบและขอรับข้อมูลของตน ระบบที่ไม่เคยคิดเรื่องนี้จะลบยากมากเพราะข้อมูลกระจายอยู่หลายตาราง หลาย backup
- ใช้ soft delete แล้วตามด้วยงานลบจริงตามรอบ
- กำหนดว่าข้อมูลใดต้องเก็บต่อตามกฎหมาย เช่น เอกสารบัญชีภาษี แล้วแยกเก็บ
- มีฟังก์ชันส่งออกข้อมูลของผู้ใช้เป็นไฟล์อ่านได้ทั่วไป (JSON/CSV)
SEC // 05
ก่อนขึ้น Production
- Privacy Notice ตรงกับสิ่งที่ระบบทำจริง
- ข้อมูลทดสอบไม่ใช่ข้อมูลจริงของลูกค้า
- ปิด debug log ที่พิมพ์ข้อมูลส่วนบุคคลหรือ token ออกมา
- มีแผนรับมือเหตุข้อมูลรั่วและรู้ว่าใครต้องแจ้ง สคส. ภายใน 72 ชั่วโมง
Q&A // FAQ
คำถามที่พบบ่อย
>ใช้ข้อมูลจริงทดสอบระบบได้ไหม
ไม่ควร เพราะเป็นการใช้ข้อมูลนอกวัตถุประสงค์ที่แจ้งไว้ และสภาพแวดล้อมทดสอบมักป้องกันอ่อนกว่า ให้ใช้ข้อมูลสังเคราะห์หรือข้อมูลที่ทำให้ระบุตัวไม่ได้แล้ว
STATUTE_REF // กฎหมายที่อ้างอิง
- §พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 มาตรา 22, 23, 33, 37, 39
- §ประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล เรื่อง มาตรการรักษาความมั่นคงปลอดภัยของผู้ควบคุมข้อมูลส่วนบุคคล พ.ศ. 2565
ข้อมูล ณ วันที่ 11 ตุลาคม 2569
ตรวจสอบตัวบทและประกาศล่าสุดได้ที่
เนื้อหานี้เป็นข้อมูลทั่วไปเพื่อการศึกษา ไม่ใช่คำแนะนำทางกฎหมายสำหรับกรณีของคุณ กฎหมายและประกาศลำดับรองอาจเปลี่ยนแปลง โปรดตรวจสอบฉบับล่าสุด
ต่อยอดบน Lawslaneให้ทนายตรวจระบบก่อนเปิดตัวทนายด้านเทคโนโลยีบน Lawslane ช่วยร่าง Terms, Privacy Notice, สัญญาจ้างพัฒนา และ DPAADVISORY // LAWSLANE
เรื่องของคุณซับซ้อนหรือมีความเสี่ยงทางกฎหมาย? ให้ทนายความที่ผ่านการยืนยันตัวตนบน Lawslane ช่วยดูให้
ปรึกษาทนายบน Lawslaneอ่านต่อ
สร้างระบบBUILD-02มาตรฐานความปลอดภัยขั้นต่ำตาม PDPA: รหัสผ่าน การเข้ารหัส สิทธิ์แอดมิน และ log ที่ระบบต้องมี
PDPA มาตรา 37 บังคับให้มีมาตรการรักษาความปลอดภัยที่เหมาะสม ถ้าข้อมูลรั่วเพราะเก็บรหัสผ่านแบบอ่านออก หรือเปิดฐานข้อมูลสู่สาธารณะ จะถูกมองว่าละเลยหน้าที่ บทความนี้แปลงกฎหมายเป็นสิ่งที่ทีม Dev ทำได้จริง
อ่าน 3 นาที
สร้างระบบBUILD-03เก็บข้อมูลผู้ใช้ได้นานแค่ไหน: ออกแบบ Retention Policy และระบบลบข้อมูลให้ถูกกฎหมาย
PDPA ไม่ได้กำหนดจำนวนปีตายตัว แต่ให้เก็บเท่าที่จำเป็นตามวัตถุประสงค์ ขณะที่กฎหมายอื่นบังคับให้เก็บบางอย่างไว้ เช่น เอกสารบัญชีและข้อมูลจราจรคอมพิวเตอร์ ต้องจับคู่ให้ถูกแล้วตั้งรอบลบอัตโนมัติ
อ่าน 3 นาที
PDPAPDPA-03ข้อมูลรั่ว ต้องทำอะไรภายใน 72 ชั่วโมง: ขั้นตอนแจ้งเหตุละเมิดข้อมูลส่วนบุคคล
เมื่อเกิดเหตุข้อมูลรั่ว องค์กรต้องแจ้ง สคส. โดยไม่ชักช้าภายใน 72 ชั่วโมงนับแต่ทราบเหตุ และแจ้งเจ้าของข้อมูลหากมีความเสี่ยงสูง พร้อมเช็กลิสต์รับมือ
อ่าน 4 นาที