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

ทีมไอทีของมหาวิทยาลัยแห่งหนึ่งติด Cookie Banner และเผยแพร่ Privacy Policy บนเว็บไซต์รับสมัครมาเกือบสองปีแล้ว แต่เมื่อฝ่ายกฎหมายถามหาหลักฐานว่าระบบทำงานตรงตามที่ประกาศไว้จริงหรือไม่ กลับไม่มีใครเก็บบันทึกอะไรไว้เลย นี่คือช่องว่างที่ Audit เข้ามาช่วยปิด — การตรวจย้อนกลับว่าสิ่งที่ประกาศไว้กับสิ่งที่เว็บไซต์ทำจริงตรงกันหรือไม่ และมีหลักฐานยืนยันเพียงพอหรือเปล่า

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

Audit ต่างจากการตรวจ Compliance ทั่วไปอย่างไร

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

4 ขั้นตอนของการ Audit

ขั้นที่ 1 — สำรวจขอบเขต (Scope)

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

ขั้นที่ 2 — เก็บหลักฐาน (Evidence Collection)

ขั้นนี้คือแกนหลักของ Audit ทีมงานควรเก็บภาพหน้าจอ Privacy Policy ฉบับที่ใช้งานอยู่ บันทึกผล Network Request ที่แสดงว่าสคริปต์วิเคราะห์หรือโฆษณาทำงานก่อนหรือหลังผู้ใช้กดยินยอม และทดสอบ Cookie Banner ในสถานการณ์ต่าง ๆ เช่น กด Reject All แล้วโหลดหน้าเว็บใหม่ หรือเปิดในเซสชันใหม่โดยไม่มี Preference เดิม

ขั้นที่ 3 — ทดสอบสถานการณ์จริง (Testing)

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

ขั้นที่ 4 — สรุปและรายงาน (Reporting)

สรุปผลตามรูปแบบ Finding → Evidence → Why It Matters → Priority → Recommended Fix → Owner → Limitation เพื่อให้ผู้บริหารเห็นภาพว่าอะไรเป็นความเสี่ยงจริง อะไรเป็นเพียงข้อสังเกตทางเทคนิค และใครควรเป็นผู้รับผิดชอบแก้ไข

Evidence ที่ควรเก็บแยกตามประเภท

เครื่องมือที่ช่วยทดสอบระหว่าง Audit

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

สำหรับเว็บไซต์ที่ใช้ Google Tag Manager ควรใช้ตัวช่วยตรวจสอบ Tag ปัจจุบันของ Google เพื่อดูว่า Default Consent State ถูกตั้งค่าไว้ก่อนที่ Tag จะทำงานหรือไม่ และ Tag แต่ละตัวถูก Map กับหมวด Consent ที่ตรงกับ Cookie Banner จริงหรือไม่ ทั้งหมดนี้เป็นการทดสอบเชิงเทคนิคที่ทีมไอทีทำได้เอง แต่การตีความว่าผลที่พบมีนัยทางกฎหมายอย่างไรยังคงต้องส่งต่อให้ฝ่ายกฎหมายพิจารณาอยู่ดี

Audit หลังบ้านที่ Automated Scan มองไม่เห็น

trusty มีข้อจำกัดในการ Audit เว็บไซต์สถานศึกษาหรือไม่ คำตอบคือมีข้อจำกัดจริง PDPA Readiness Scan ของ trusty (Capability Status A) ตรวจ Policy ที่เผยแพร่ พฤติกรรม Banner และ Tracking ฝั่งไคลเอนต์ได้ดี แต่ไม่เห็นข้อมูลที่เก็บผ่านฟอร์มกระดาษ ระบบทะเบียนหลังบ้าน สัญญากับ Vendor หรือการเข้าถึงข้อมูลของเจ้าหน้าที่ภายใน ส่วนเหล่านี้ต้องให้ทีมงานภายในตรวจเพิ่มด้วยการสัมภาษณ์เจ้าของระบบและตรวจเอกสารจริง

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

Audit เว็บไซต์มหาวิทยาลัยที่มีหลายคณะหรือหลายโดเมน

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

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

รูปแบบปัญหาที่พบบ่อยระหว่าง Audit

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

• ฝ่ายการตลาดหรือฝ่ายรับสมัครเพิ่ม Tag วัดผลโฆษณาเองผ่าน Google Tag Manager โดยฝ่ายไอทีไม่ทราบ
• ปลั๊กอินหรือธีมของเว็บไซต์ฝัง Script ติดตามมาโดยอัตโนมัติตั้งแต่ติดตั้ง โดยไม่มีใครตรวจสอบตอนเปิดใช้งานครั้งแรก
• Banner แสดงผลให้ผู้ใช้เห็น แต่ Pixel ของแพลตฟอร์มโฆษณายิงไปแล้วตั้งแต่โหลดหน้าเว็บ ก่อนผู้ใช้กดปุ่มใด ๆ
• ผู้ใช้กด Reject All แล้ว แต่ Tag บางตัวยังคงทำงานเพราะไม่ได้ผูกกับ Consent State จริง
• ทีมเปลี่ยนธีมเว็บไซต์ใหม่แล้ว Script ที่เคยตั้งค่าการบล็อกตาม Consent หายไปโดยไม่มีใครสังเกต
• อัปเดตปลั๊กอินเวอร์ชันใหม่แล้วเพิ่มคุกกี้ชนิดใหม่เข้ามาโดยไม่มีการแจ้งในรายการคุกกี้เดิม

เมื่อพบรูปแบบเหล่านี้ระหว่าง Audit ควรบันทึกเป็น Finding แยกรายการ พร้อมระบุว่าเป็นข้อสังเกตที่ต้องตรวจยืนยันเพิ่มเติม (Needs Manual Review) หรือเป็นสิ่งที่ยืนยันได้แล้วจาก Evidence ที่เก็บมา (Confirmed)

จัดลำดับความสำคัญของ Finding หลัง Audit

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

ใครควรเป็นเจ้าของกระบวนการ Audit

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

เมื่อพบ Critical Finding ระหว่าง Audit ควรทำอย่างไร

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

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

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

• กำหนดขอบเขตเว็บไซต์และระบบย่อยทั้งหมดที่จะ Audit ในรอบนี้
• เก็บภาพหน้าจอ Privacy Policy และ Cookie Banner ฉบับปัจจุบันพร้อมวันที่
• ทดสอบปุ่ม Reject All และบันทึกผล Network Request ก่อน-หลังกด
• ทดสอบ Journey จริงของผู้ปกครอง นักศึกษา และผู้เข้าชมทั่วไปอย่างน้อยคนละหนึ่งรอบ
• ทำรายการ Vendor ภายนอกพร้อมวัตถุประสงค์การใช้ข้อมูล
• สรุปผลตามรูปแบบ Finding, Evidence, Priority, Fix และ Owner
• กำหนดรอบ Audit ครั้งถัดไปและผู้รับผิดชอบให้ชัดเจนก่อนปิดรายงาน

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

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

สรุป

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

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

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