Consent Logs คืออะไร? คู่มือสำหรับโรงเรียน มหาวิทยาลัย และธุรกิจการศึกษา

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

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

Consent Log คืออะไร และทำไมสถานศึกษาต้องมี

Consent Log คือบันทึกหลักฐานของการให้หรือไม่ให้ความยินยอม ประกอบด้วยข้อมูลอย่างน้อยคือ Consent ID เวลาที่เกิดขึ้น เวอร์ชันของ Privacy Policy และ Cookie Banner ที่ผู้ใช้เห็น ณ ตอนนั้น หมวดที่เลือกหรือปฏิเสธ และช่องทางที่เกิดการให้ความยินยอม

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

ข้อมูลนักเรียนหรือผู้เยาว์ กับความยินยอมของผู้ปกครอง

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

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

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

จุดที่ต้องเก็บ Consent Log ในเว็บไซต์สถานศึกษา

แบบฟอร์มรับสมัคร (Admissions Form)

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

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

คุกกี้บนเว็บไซต์และพอร์ทัลนักเรียน

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

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

ระบบ LMS และวิดีโอการเรียน

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

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

โครงสร้างของ Consent Log ที่ควรมี

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

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

ทีมไอทีของโรงเรียนกับทีม Privacy โดยเฉพาะ: ต่างกันอย่างไร

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

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

ตัวอย่างสถานการณ์ที่พบบ่อยในสถานศึกษา

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

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

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

เมื่อไหร่ควรพิจารณาขอความยินยอมใหม่ (Re-consent)

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

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

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

คำถามที่พบบ่อย

Consent Log คืออะไรกันแน่ และต่างจาก Cookie Banner อย่างไร Cookie Banner คือหน้าจอที่ให้ผู้ใช้เลือก Accept, Reject หรือ Customize ส่วน Consent Log คือบันทึกหลักฐานของการเลือกนั้น เช่น เวลาที่กด หมวดที่เลือก และเวอร์ชัน Policy ที่ผู้ใช้เห็น

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

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

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

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

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

• กำหนดโครงสร้างข้อมูลของ Consent Log ให้มี Consent ID, Timestamp, เวอร์ชัน Policy, เวอร์ชัน Banner, หมวดที่เลือก และช่องทางที่เกิดการให้ความยินยอม
• แยกแบบฟอร์มรับสมัครที่มีผู้ปกครองเป็นผู้กรอกแทนผู้เยาว์ ออกจากแบบฟอร์มที่ผู้เรียนกรอกเองได้ แล้วบันทึกสถานะผู้ให้ความยินยอมแยกกัน
• สำรวจว่าเว็บไซต์หลัก พอร์ทัลนักเรียน และ LMS อยู่คนละโดเมนหรือซับโดเมนหรือไม่ แล้ววาง Consent Log ให้ครอบคลุมทุกจุด
• ตรวจคุกกี้และสคริปต์บนพอร์ทัลนักเรียนว่าจัดหมวด Necessary, Functional, Analytics และ Marketing ถูกต้องตามลักษณะการใช้งานจริง
• มอบหมาย Owner ของ Consent Log ให้ชัดเจน แม้ทีมไอทีของสถานศึกษาจะมีคนจำกัดและต้องดูแลหลายระบบพร้อมกัน
• กำหนดระยะเก็บ Consent Log เป็นลายลักษณ์อักษร และวางวิธีส่งออกข้อมูลเมื่อผู้ปกครองหรือนักเรียนที่บรรลุนิติภาวะร้องขอตรวจสอบ
• ทบทวน Consent Log ทุกครั้งที่มีการเพิ่มระบบใหม่ เช่น ระบบแชทสนับสนุนผู้ปกครองหรือแพลตฟอร์มเรียนออนไลน์เพิ่มเติม
• วางแผนโอนย้ายหรือสำรอง Consent Log ทุกครั้งก่อนเปลี่ยนผู้ให้บริการระบบที่เกี่ยวข้องกับข้อมูลนักเรียนหรือผู้ปกครอง เช่น ระบบรับสมัครหรือแอปแจ้งเตือน

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

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

สรุป

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

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

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