10 ข้อผิดพลาดเรื่อง PDPA สำหรับเว็บไซต์ ที่โรงเรียน มหาวิทยาลัย และธุรกิจการศึกษาควรหลีกเลี่ยง

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

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

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

ข้อผิดพลาดเกี่ยวกับข้อมูลผู้เยาว์และความยินยอมของผู้ปกครอง

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

1. ให้ฟอร์มรับสมัครขอความยินยอมจากนักเรียนโดยตรง

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

2. ไม่แยกข้อมูลผู้เยาว์ออกจากข้อมูลผู้ใหญ่ในระบบเดียวกัน

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

3. เก็บสำเนาบัตรประชาชนหรือสูติบัตรไว้บนเซิร์ฟเวอร์ที่ทีมการตลาดเข้าถึงได้

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

ข้อผิดพลาดเกี่ยวกับ Cookie และสคริปต์ติดตามบนเว็บไซต์สถานศึกษา

เว็บไซต์สถานศึกษาจำนวนมากติดตั้ง Google Analytics, Facebook Pixel หรือสคริปต์แชทสำหรับฝ่ายรับสมัครเพื่อวัดผลแคมเปญโฆษณา แต่การตั้งค่าฝั่ง Consent มักตามหลังการตลาดหลายก้าว

4. สคริปต์ติดตามทำงานทันทีที่เปิดหน้าเว็บ ก่อนมีการกดยินยอม

เมื่อตรวจสอบ Network Request ของเว็บไซต์รับสมัครหลายแห่งจะพบว่า Facebook Pixel หรือ Google Ads Conversion Tracking ยิง Request ออกไปทันทีที่หน้าเว็บโหลดเสร็จ ก่อนที่ผู้ปกครองจะเห็น Cookie Banner ด้วยซ้ำ เพราะสคริปต์ถูกฝังในส่วนหัวของเว็บไซต์โดยตรงแทนที่จะรอสถานะความยินยอมจาก Consent Management Platform

5. ปุ่ม "ปฏิเสธทั้งหมด" ไม่ได้บล็อกสคริปต์จริง

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

6. ใช้ Cookie หมวด Necessary ครอบคลุมสคริปต์การตลาดของฝ่ายรับสมัคร

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

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

ข้อผิดพลาดในการเชื่อมข้อมูลระหว่างเว็บไซต์หลัก ระบบทะเบียน และ LMS

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

7. Privacy Policy ฉบับเดียวใช้ครอบคลุมทุกระบบ ทั้งที่เก็บข้อมูลคนละชุด

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

8. ข้อมูลนักเรียนที่ลาออกหรือไม่ผ่านการคัดเลือกยังคงอยู่ในระบบไม่มีกำหนด

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

9. ครูหรือเจ้าหน้าที่ที่ไม่เกี่ยวข้องเข้าถึงข้อมูลผู้ปกครองในระบบทะเบียนได้ทั้งหมด

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

10. เปลี่ยนผู้ให้บริการเว็บไซต์หรือ LMS โดยไม่ตรวจสอบว่าข้อมูลเดิมถูกโอนหรือทำลายอย่างไร

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

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

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

เช็กลิสต์ปฏิบัติ

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

ข้อผิดพลาดที่พบบ่อย

• ให้นักเรียนที่ยังเป็นผู้เยาว์กดยอมรับเงื่อนไขในฟอร์มรับสมัครด้วยตัวเองโดยไม่มีขั้นตอนสำหรับผู้ปกครอง
• ปล่อยให้สคริปต์ติดตามของฝ่ายการตลาดทำงานก่อนผู้ปกครองกดยินยอมบน Cookie Banner
• จัดสคริปต์การตลาดของฝ่ายรับสมัครไว้ในหมวด Necessary ทำให้ผู้ปกครองปฏิเสธไม่ได้
• ใช้ Privacy Policy ฉบับเดียวครอบคลุมเว็บไซต์หลัก ระบบรับสมัคร และ LMS ทั้งที่เก็บข้อมูลคนละชุด
• ไม่มีกระบวนการลบข้อมูลผู้สมัครที่ไม่ผ่านการคัดเลือกหรือลาออกไปแล้วหลายปี

สรุป

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

แหล่งข้อมูลอ้างอิง

• สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC)