PDPA • ฐานกฎหมาย • ความปลอดภัยข้อมูลสำหรับโรงเรียน

PDPA สำหรับโรงเรียน: เริ่มอย่างไรให้ปลอดภัยและใช้งานได้จริง

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

🧾 ครอบคลุม Lawful Basis / Notice / Consent
🔐 ดูแล Access / Security / Audit Log
🏫 ออกแบบตาม บริบทโรงเรียนไทย

เหตุใดสถานศึกษาจึงต้องปฏิบัติตาม PDPA?

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

โรงเรียน

กำหนดวัตถุประสงค์ให้ชัด

ระบุว่าเก็บข้อมูลใด เพื่ออะไร ใช้ฐานกฎหมายใด ใครเข้าถึงได้ เก็บไว้นานเท่าใด และส่งต่อให้ใครบ้าง

ผู้ให้บริการ

กำหนดบทบาทในสัญญา

หากผู้ให้บริการประมวลผลข้อมูลแทนโรงเรียน ควรมีข้อตกลงที่กำหนดขอบเขต คำสั่ง มาตรการรักษาความปลอดภัย และการคืนหรือลบข้อมูลเมื่อสิ้นสุดบริการ

เจ้าของข้อมูล

สื่อสารอย่างโปร่งใส

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

ข้อมูลส่วนบุคคลอะไรบ้างที่ไหลเวียนในโรงเรียน

โรงเรียนควรทำ Data Inventory หรือ Data Map เพื่อให้ทราบว่าข้อมูลมาจากไหน อยู่ที่ใด ใครใช้ ส่งให้ใคร และลบเมื่อใด ทั้งเอกสารกระดาษและระบบดิจิทัล

นักเรียนและผู้ปกครอง

ข้อมูลหลักที่พบบ่อย

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

ข้อมูลที่อาจถูกมองข้าม

  • ข้อมูลครู เจ้าหน้าที่ ผู้สมัครงาน และคู่ค้า
  • ข้อมูลผู้มาติดต่อจากระบบ Visitor Management
  • ภาพจากกล้องวงจรปิดและบันทึกการเข้า–ออก
  • ข้อมูลที่ผู้รับจ้าง Cloud หรือผู้ดูแลระบบเข้าถึงได้
หลักสำคัญ: เก็บข้อมูลเท่าที่จำเป็นต่อวัตถุประสงค์ (Data Minimisation) และใช้ข้อมูลตามวัตถุประสงค์ที่กำหนดและแจ้งไว้ (Purpose Limitation) ทั้งสองหลักเกี่ยวข้องกัน แต่ไม่ใช่ความหมายเดียวกัน

PDPA ไม่ได้หมายความว่าต้องขอ Consent ทุกเรื่อง

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

ตัวอย่างฐานกฎหมาย

หน้าที่ตามกฎหมายหรือภารกิจสาธารณะ

อาจเกี่ยวข้องกับการจัดการศึกษา การจัดทำทะเบียน การรายงานข้อมูล หรือภารกิจของสถานศึกษาของรัฐ ทั้งนี้ต้องพิจารณากฎหมายและอำนาจหน้าที่ที่เกี่ยวข้องเป็นรายกิจกรรม

ตัวอย่างฐานกฎหมาย

สัญญาหรือประโยชน์โดยชอบ

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

เมื่อจำเป็น

ความยินยอม

ต้องขออย่างชัดเจน แยกจากข้อความอื่น เข้าใจง่าย ถอนความยินยอมได้ และการถอนควรทำได้ง่ายพอ ๆ กับการให้ความยินยอม

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

ข้อมูลผู้เยาว์และ Face Recognition ต้องระมัดระวังเป็นพิเศษ

เด็กและผู้เยาว์

ตรวจเงื่อนไขมาตรา 20 เมื่อใช้ Consent

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

ข้อมูลชีวภาพ

ภาพถ่ายทั่วไปไม่เท่ากับข้อมูลจำลองใบหน้า

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

ก่อนใช้ Face Recognition: ควรประเมินวัตถุประสงค์ ความจำเป็น ทางเลือกที่กระทบสิทธิน้อยกว่า ฐานกฎหมายตามมาตรา 26 ระยะเวลาเก็บ Template การเข้ารหัส การจำกัดสิทธิ์เข้าถึง ขั้นตอนลบข้อมูล และผลกระทบต่อเด็ก การประเมินผลกระทบด้านการคุ้มครองข้อมูล (DPIA) เป็นแนวปฏิบัติที่เหมาะสมสำหรับการประมวลผลที่มีความเสี่ยงสูง

9 ประเด็นเบื้องต้นที่ผู้บริหารโรงเรียนควรตรวจสอบ

รายการนี้เป็น Checklist เพื่อช่วยมองภาพรวม ไม่ใช่ข้อสรุปทางกฎหมายเฉพาะกรณี และไม่ใช้แทนการตรวจสอบกิจกรรมประมวลผลของแต่ละโรงเรียน

01

ผู้รับผิดชอบและ DPO

กำหนดเจ้าของงานภายในให้ชัด และประเมินว่าเข้าเงื่อนไขต้องจัดให้มี DPO ตามกฎหมายหรือไม่ ไม่ใช่ทุกโรงเรียนต้องแต่งตั้งโดยอัตโนมัติ

02

Data Map และ ROPA

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

03

วัตถุประสงค์และฐานกฎหมาย

แยกแต่ละกิจกรรม เช่น รับสมัคร เรียนการสอน เช็กชื่อ กล้องวงจรปิด ประชาสัมพันธ์ และการตลาด ก่อนเลือกฐานกฎหมาย

04

Privacy Notice และ Consent

แจ้งรายละเอียดให้ครบ ชัดเจน และเหมาะกับผู้อ่าน หากต้องใช้ Consent ต้องจัดเก็บหลักฐานและรองรับการถอน

05

สิทธิของเจ้าของข้อมูล

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

06

ความมั่นคงปลอดภัย

ใช้มาตรการตามความเสี่ยง เช่น MFA การแยกสิทธิ์ การเข้ารหัส การสำรองข้อมูล Patch Management Logging และการอบรมบุคลากร

07

Retention และการทำลาย

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

08

ผู้ให้บริการภายนอก

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

09

เหตุละเมิดข้อมูล

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

ขั้นตอนนำไปใช้จริงในโรงเรียน

อย่าเริ่มจากการทำแบบฟอร์ม Consent เพียงชุดเดียว ให้เริ่มจากกิจกรรมและเส้นทางของข้อมูลจริง

Step-by-step

โฟลว์ตัวอย่างสำหรับแต่ละกิจกรรม

  1. ระบุกิจกรรม: เช่น รับสมัคร เช็กชื่อรายคาบ กล้องวงจรปิด Face Recognition หรือเผยแพร่ภาพกิจกรรม
  2. ระบุข้อมูลและวัตถุประสงค์: เก็บอะไร จากใคร เพราะเหตุใด และจำเป็นทั้งหมดหรือไม่
  3. เลือกฐานกฎหมาย: พิจารณามาตรา 24 และหากเป็นข้อมูลอ่อนไหวให้พิจารณามาตรา 26 เพิ่มเติม
  4. จัดทำ Notice และ Consent เมื่อจำเป็น: แยกวัตถุประสงค์ให้ชัด ใช้ภาษาที่ผู้ปกครองและนักเรียนเข้าใจได้
  5. กำหนดสิทธิ์และความปลอดภัย: ใครดู แก้ไข ส่งออก หรือลบข้อมูลได้ พร้อมเก็บ Log ที่จำเป็น
  6. กำหนด Retention: ระยะเวลาเก็บ วิธีลบ และการดำเนินการเมื่อย้ายโรงเรียน จบการศึกษา หรือสิ้นสุดสัญญา
  7. เตรียมรับคำขอและเหตุละเมิด: กำหนดผู้รับผิดชอบ ช่องทางติดต่อ ขั้นตอนประเมิน และหลักฐานการดำเนินการ
  8. ทบทวนสม่ำเสมอ: เมื่อเปลี่ยนระบบ ผู้ให้บริการ วัตถุประสงค์ หรือประเภทข้อมูล ต้องประเมินและปรับเอกสารอีกครั้ง

เชื่อมการคุ้มครองข้อมูลเข้ากับ Student Identity / Smart School

ระบบที่ดีควรช่วยบังคับใช้นโยบายของโรงเรียนได้จริง ไม่ใช่เก็บเอกสารไว้แยกจากระบบ

Identity & Preference

ผูกสถานะกับบุคคลและวัตถุประสงค์

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

Access & Audit

ให้แต่ละบทบาทเห็นเท่าที่จำเป็น

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

แหล่งอ้างอิงและอ่านเพิ่มเติม

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

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