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

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

คืนก่อนประชุมบอร์ดไตรมาส หัวหน้าทีม Product ของแพลตฟอร์มบริหารจัดการห้องเรียนแห่งหนึ่งเปิดไฟล์ export รายชื่อนักเรียนที่ทีม Customer Success ส่งให้ฝ่ายขายไว้ทำเดโมลูกค้าใหม่ ในไฟล์นั้นมีคอลัมน์ที่เขียนว่า \"หมายเหตุการเรียนรู้พิเศษ\" ระบุว่าเด็กบางคนมีภาวะบกพร่องด้านการอ่านหรือมีโรคประจำตัวที่ครูต้องรู้ ไฟล์นี้ถูกส่งต่อกันในทีมมาหลายเดือนโดยไม่มีใครตั้งคำถามว่าใครควรเห็นข้อมูลนี้บ้าง และผู้ปกครองเคยยินยอมให้ใช้ข้อมูลนี้ไปทำเดโมขายหรือไม่ นั่นคือจุดเริ่มต้นที่ทำให้ทีมตัดสินใจตั้งรอบ Audit PDPA เฉพาะสำหรับข้อมูลนักเรียนและผู้ปกครอง แยกออกจากรอบตรวจสอบข้อมูลผู้ใช้ทั่วไปที่ทีมทำอยู่แล้ว

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

ทำไม EdTech SaaS ต้อง Audit ข้อมูลนักเรียนและผู้ปกครองแยกจากข้อมูลผู้ใช้ทั่วไป

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

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

ขอบเขตข้อมูลที่ต้องตรวจสอบ: นักเรียน ผู้ปกครอง และข้อมูลอ่อนไหว

ก่อนเริ่ม Audit ทีมควรไล่รายการข้อมูลที่ระบบเก็บจริงให้ครบก่อน โดยแบ่งเป็นกลุ่มดังนี้

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

การไล่รายการนี้ควรทำร่วมกันระหว่างทีม Product ที่รู้ว่าฟีเจอร์ไหนเก็บอะไร ทีม Engineering ที่รู้ว่าข้อมูลถูกเก็บไว้ที่ระบบไหน และทีม Privacy ที่ดูแลเรื่องฐานทางกฎหมายของการเก็บแต่ละประเภท

ขั้นตอน Audit พร้อม Evidence ที่ควรเก็บในแต่ละขั้น

ขั้นที่ 1: ตรวจสอบว่าใครให้ความยินยอมจริงในแต่ละบัญชี

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

ขั้นที่ 2: ตรวจสอบการจัดเก็บข้อมูลอ่อนไหวแยกจากข้อมูลทั่วไป

ตรวจว่าข้อมูลสุขภาพหรือความต้องการพิเศษถูกเก็บในตารางหรือฟิลด์เดียวกับข้อมูลทั่วไป เช่น ชื่อและอีเมล หรือมีการแยกระดับการเข้าถึงต่างหาก ระบบที่ดีควรจำกัดสิทธิ์ให้เฉพาะครูประจำชั้นหรือฝ่ายแนะแนวที่จำเป็นต้องรู้จริง ไม่ใช่ทุกคนในทีม Customer Success เข้าถึงได้เหมือนข้อมูลทั่วไป หลักฐานที่ควรเก็บคือรายการสิทธิ์การเข้าถึง (access control list) ของฟิลด์ข้อมูลอ่อนไหว พร้อมวันที่ทบทวนสิทธิ์ล่าสุด

ขั้นที่ 3: ตรวจสอบเส้นทางข้อมูลที่ส่งไปยังผู้ให้บริการภายนอก

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

ขั้นที่ 4: ตรวจสอบนโยบายเก็บรักษาและลบข้อมูลหลังนักเรียนออกหรือจบการศึกษา

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

ขั้นที่ 5: ตรวจสอบช่องทางที่ผู้ปกครองใช้ขอเข้าถึงหรือขอลบข้อมูลบุตรหลาน

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

การขอความยินยอมจากผู้ปกครองและการตรวจสอบอายุผู้เรียน

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

การแชร์ข้อมูลกับผู้ให้บริการภายนอก: LMS ระบบชำระค่าเทอม และเครื่องมือวิเคราะห์

แพลตฟอร์มการศึกษาสาย SaaS มักไม่ได้ทำงานเดี่ยว แต่เชื่อมต่อกับระบบอื่นหลายตัว การ Audit ต้องแยกพิจารณาแต่ละเส้นทางดังตาราง

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

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

การเก็บรักษาและลบข้อมูลหลังนักเรียนออกหรือจบการศึกษา

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

ใครควรเป็นเจ้าของรอบ Audit นี้ในทีมที่ยังไม่มีตำแหน่ง Privacy เต็มเวลา

แพลตฟอร์มการศึกษาสาย SaaS ขนาดเล็กมักไม่มีตำแหน่ง Data Protection Officer เต็มเวลา คนที่เหมาะเป็นเจ้าของรอบ Audit นี้จึงมักเป็น Product Manager ที่มองเห็นภาพรวมของฟีเจอร์ทั้งหมด ร่วมกับตัวแทนจากทีม Engineering ที่รู้ว่าข้อมูลถูกเก็บไว้ที่ไหนจริง และควรมีตัวแทนจากทีม Customer Success หรือฝ่ายที่ติดต่อโรงเรียนโดยตรงเข้าร่วมด้วย เพราะเป็นคนที่รู้ว่าโรงเรียนแต่ละแห่งมีเงื่อนไขการใช้ข้อมูลนักเรียนที่ต่างกันอย่างไร การให้ Engineer เพียงคนเดียวทำ Audit นี้โดยลำพังมักพลาดมุมมองเรื่องความสัมพันธ์สามฝ่ายระหว่างแพลตฟอร์ม โรงเรียน และผู้ปกครอง

ตัวอย่างสถานการณ์ที่ควรตรวจสอบเพิ่มเมื่อลูกค้าเป็นโรงเรียนขนาดใหญ่

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

ข้อผิดพลาดที่พบบ่อยเมื่อทำ Audit PDPA สำหรับธุรกิจการศึกษา

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

สรุป: Audit PDPA สำหรับธุรกิจการศึกษาต้องแยกมองข้อมูลผู้เยาว์เป็นพิเศษ

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

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

ควรตรวจสอบแนวทางล่าสุดเรื่องการประมวลผลข้อมูลของผู้เยาว์และข้อมูลอ่อนไหวจากสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC) อย่างสม่ำเสมอ เนื่องจากเกณฑ์อายุและแนวปฏิบัติย่อยอาจมีการปรับปรุงเป็นระยะ และควรทบทวนผลการ Audit นี้ทุกหกเดือนหรือทุกครั้งที่มีการเปลี่ยนแปลง vendor ภายนอก