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

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

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

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

อาการที่พบบ่อยเมื่อระบบ PDPA บนเว็บไซต์สถานศึกษาเริ่มมีปัญหา

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

ปัญหา: Banner แสดงผลแต่สคริปต์ของระบบรับสมัครยังทำงานก่อนกดยินยอม

หลักฐานที่ควรตรวจ: เปิดเครื่องมือตรวจสอบเครือข่าย (Network) ของเบราว์เซอร์ในโหมดไม่ระบุตัวตน โหลดหน้าเว็บรับสมัครแล้วดูว่ามี Request ไปยัง Google Analytics, Facebook Pixel หรือสคริปต์แชทเกิดขึ้นก่อนที่จะมีการโต้ตอบกับ Banner เลยหรือไม่

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

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

ปัญหา: ผู้ปกครองปฏิเสธความยินยอมแต่ระบบอีเมลหรือ LMS ยังส่งข่าวสารต่อ

หลักฐานที่ควรตรวจ: ทดสอบด้วยอีเมลทดสอบ กดปฏิเสธหมวด Marketing บน Cookie Banner แล้วสังเกตว่ายังได้รับอีเมลโปรโมชันหลักสูตรหรือกิจกรรมของสถานศึกษาต่อหรือไม่ภายในสัปดาห์ถัดไป

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

วิธีแก้: แยกสถานะความยินยอมสำหรับการรับอีเมล/SMS การตลาดออกจากการยินยอมใช้ Cookie บนเว็บไซต์อย่างชัดเจนตั้งแต่ในฟอร์มสมัคร แล้วเชื่อมสถานะนี้เข้ากับระบบ CRM หรือระบบส่งอีเมลโดยตรง เพื่อให้เมื่อผู้ปกครองปฏิเสธ ระบบส่งอีเมลหยุดส่งให้อีเมลนั้นจริง ไม่ใช่หยุดเฉพาะการติดตามบนเว็บไซต์

ปัญหา: เว็บไซต์หลายเว็บของสถานศึกษาใช้ Privacy Policy คนละเวอร์ชัน

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

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

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

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

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

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

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

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

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

จะรู้ได้อย่างไรว่าแก้ปัญหาสำเร็จจริง ไม่ใช่แค่ดูเหมือนหายไป

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

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

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

เมื่อใดควรส่งต่อผู้เชี่ยวชาญหรือฝ่ายกฎหมายของสถานศึกษา

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

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

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

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

ข้อผิดพลาดที่พบบ่อยที่ทำให้ปัญหาเกิดซ้ำ

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

สรุป

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

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

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