วิธีวางระบบ PDPA สำหรับธุรกิจการศึกษา สำหรับเอเจนซีและฟรีแลนซ์ทำเว็บไซต์แบบเป็นขั้นตอน

บ่ายวันศุกร์ก่อนส่งมอบงาน ทีมเอเจนซีหกคนนั่งประชุมด่วน เพราะลูกค้าเจ้าของสถาบันกวดวิชาที่มีนักเรียนอายุต่ำกว่า 18 ปีมากกว่า 3,000 คน ถามคำถามเดียวที่ทีมตอบไม่ได้ทันที เว็บไซต์ลงทะเบียนเรียนที่กำลังจะขึ้นระบบจริงในสัปดาห์หน้าเก็บข้อมูลผู้ปกครองไว้ตรงไหน แล้วถ้ามีผู้ปกครองคนหนึ่งขอให้ลบข้อมูลลูกออกจากระบบ ทีมพัฒนาต้องกดปุ่มไหน โปรเจกต์แมเนเจอร์เปิดสเปกงานย้อนดูแล้วพบว่าไม่มีข้อไหนพูดถึงเรื่องนี้เลย มีแต่ Requirement ด้านฟีเจอร์กับดีไซน์ล้วน ๆ นี่คือจุดที่เอเจนซีจำนวนไม่น้อยพลาด เพราะมองว่า PDPA เป็นเรื่องของลูกค้าที่ต้องไปจัดการเอง ทั้งที่ตัวเว็บไซต์และระบบหลังบ้านที่เอเจนซีสร้างขึ้นนั่นแหละคือจุดที่ข้อมูลนักเรียนไหลเข้าออกจริง หลังจากประชุมวันนั้น ทีมงานตัดสินใจสร้างเช็กลิสต์วางระบบ PDPA เป็นมาตรฐานที่ใช้ซ้ำได้กับลูกค้าสายการศึกษาทุกเจ้า แทนที่จะแก้ปัญหาเฉพาะหน้าไปทีละโปรเจกต์แบบไม่มีแบบแผน

ทำไมเอเจนซีต้องวางระบบ PDPA สำหรับธุรกิจการศึกษาให้ลูกค้า

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

ขั้นตอนที่ 1-3 สำรวจข้อมูลนักเรียนที่ระบบของลูกค้าเก็บจริง

1. ทำ Data Mapping ทุกฟอร์มบนเว็บไซต์และแอปที่เก็บข้อมูลนักเรียน ตั้งแต่ฟอร์มสมัครเรียน ฟอร์มติดต่อ ไปจนถึง Cookie ที่ใช้ยิงโฆษณาไปยังผู้ปกครอง เพราะทีมพัฒนาเดิมมักลืมนับ Cookie และ Pixel ของแพลตฟอร์มโฆษณาว่าเป็นการเก็บข้อมูลเช่นกัน หลักฐานที่ควรเก็บคือไฟล์ Data Map ที่ระบุแหล่งที่มา ฟิลด์ข้อมูล และปลายทางจัดเก็บของแต่ละฟอร์ม ขั้นตอนนี้มักใช้เวลาหนึ่งถึงสองสัปดาห์สำหรับเว็บไซต์ขนาดกลาง เพราะต้องไล่ดูทุกหน้าจริง ไม่ใช่แค่เดาจากเมนูนำทาง
2. แยกประเภทข้อมูลเป็นสามกลุ่ม คือข้อมูลติดต่อทั่วไป ข้อมูลที่ใช้ยืนยันตัวตนผู้ปกครอง และข้อมูลที่เข้าข่ายอ่อนไหวเช่นข้อมูลสุขภาพหรือความต้องการพิเศษของนักเรียน เพื่อกำหนดระดับการเข้าถึงที่ต่างกันในขั้นตอนถัดไป การแยกกลุ่มนี้ควรทำเป็นตารางง่าย ๆ ที่ทั้งทีมพัฒนาและลูกค้าเข้าใจตรงกัน ไม่ใช่เก็บไว้ในหัวของคนใดคนหนึ่งในทีม
3. ตรวจสอบว่าระบบหลังบ้านที่เอเจนซีเขียนโค้ดให้มีช่องทางส่งออกหรือลบข้อมูลรายบุคคลได้จริงหรือไม่ ถ้าไม่มี ต้องเสนอเป็น Feature เพิ่มในสัญญาโครงการ ไม่ใช่ปล่อยให้ลูกค้าไปนั่งลบข้อมูลใน Database เอง ซึ่งเสี่ยงต่อการลบผิดตารางหรือลบไม่ครบทุกจุดที่ข้อมูลถูกคัดลอกไปเก็บสำรอง

ขั้นตอนที่ 4-6 วางระบบขอความยินยอมผู้ปกครองและแชร์ข้อมูลกับ Vendor

1. ออกแบบฟอร์มความยินยอมที่ระบุชัดว่าใครเป็นผู้ให้ความยินยอมแทนผู้เยาว์ พร้อมช่องยืนยันความสัมพันธ์กับนักเรียน เช่น อัปโหลดสำเนาบัตรผู้ปกครองหรือใช้ระบบยืนยันอีเมลคู่กับเบอร์โทร วิธีนี้ช่วยลดกรณีมีคนแอบใช้ข้อมูลของผู้ปกครองปลอมสมัครแทน และยังช่วยให้สถาบันมีหลักฐานยืนยันตัวตนผู้ปกครองไว้ใช้ในกรณีที่ต้องติดต่อเรื่องฉุกเฉินของนักเรียนในภายหลังด้วย
2. เขียน Privacy Policy เวอร์ชันเฉพาะสำหรับผู้ปกครอง แยกจากเงื่อนไขการใช้งานทั่วไป ระบุให้ชัดว่าเก็บข้อมูลอะไร ใช้ทำอะไร แชร์ให้ใครบ้าง เช่น ระบบ LMS ของบุคคลที่สาม หรือผู้ให้บริการรับชำระค่าเทอม และต้องมีสัญญาประมวลผลข้อมูล หรือข้อตกลงคุ้มครองข้อมูลกับ Vendor เหล่านั้นแนบท้ายเป็นเอกสารเก็บไว้ ไม่ใช่แค่คำสัญญาปากเปล่าจากฝ่ายขายของ Vendor เอเจนซีควรขอสำเนาสัญญาเหล่านี้เก็บไว้เป็นส่วนหนึ่งของเอกสารส่งมอบโครงการด้วย เพื่อให้ลูกค้าเรียกดูได้ทันทีหากมีคำถามจากผู้ปกครอง
3. ตั้งค่าระบบ Cookie Consent ให้แยกหมวดโฆษณาออกจากหมวดจำเป็นต่อการใช้งานเว็บไซต์อย่างชัดเจน เพราะเว็บไซต์การศึกษาที่มีผู้เยาว์เข้าชมจำนวนมากมักถูกตรวจสอบเรื่องการติดตามพฤติกรรมเพื่อยิงโฆษณาเข้มงวดกว่าธุรกิจทั่วไป และควรปิดการติดตามโฆษณาแบบ Personalized ไว้เป็นค่าเริ่มต้นสำหรับผู้ใช้ที่ยังไม่ได้ยืนยันว่าเป็นผู้ปกครองหรือผู้ใหญ่

ขั้นตอนที่ 7 เก็บ Evidence และกำหนดระยะเวลาการเก็บข้อมูลหลังนักเรียนจบหรือลาออก

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

ข้อผิดพลาดที่พบบ่อยเมื่อเอเจนซีวางระบบ PDPA ให้ลูกค้าสายการศึกษา

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

สรุปเช็กลิสต์ก่อนส่งมอบระบบ PDPA ให้ลูกค้า

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

วิธีคุยกับลูกค้าเรื่อง PDPA โดยไม่ทำให้โปรเจกต์ดูซับซ้อนเกินจำเป็น

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

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

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