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

ในการตรวจสอบเว็บไซต์ SaaS ไทยที่เปิดให้บริการลูกค้าองค์กรมากกว่าสามสิบรายในช่วงปีที่ผ่านมา จุดที่พบซ้ำบ่อยที่สุดไม่ใช่การไม่มี Privacy Policy แต่เป็นการมีเอกสารสวยงามครบถ้วน ในขณะที่ระบบจริงเบื้องหลังไม่ได้ทำตามที่เอกสารเขียนไว้เลย ทีม Legal เขียนว่า "ผู้ใช้สามารถขอลบข้อมูลได้ภายในสามสิบวัน" แต่ไม่มีใครในทีม Engineering รู้ว่าต้องลบข้อมูลจากตารางไหนบ้าง หรือเอกสารเขียนว่า "ขอความยินยอมก่อนเก็บข้อมูล Analytics" แต่ปุ่มปฏิเสธในป้าย Cookie Banner กดแล้วไม่มีผลอะไรกับ Script ที่รันอยู่จริง ช่องว่างแบบนี้เกิดขึ้นเพราะทีมส่วนใหญ่ตรวจแค่ตัวเอกสาร ไม่เคยตรวจว่าเว็บไซต์ปฏิบัติตาม PDPA จริงหรือไม่ในทางเทคนิค การ Audit ที่ดีจึงต้องเจาะไปที่ระบบเบื้องหลัง ไม่ใช่แค่อ่านทวนข้อความในหน้า Privacy Policy

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

เรื่องที่ 1: ตรวจฐานทางกฎหมายของการประมวลผลข้อมูลแต่ละจุดบนเว็บไซต์

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

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

เรื่องที่ 2: ตรวจกลไกขอความยินยอมที่ใช้งานจริง ไม่ใช่แค่ข้อความในเอกสาร

จุดที่ผู้ตรวจสอบหรือลูกค้าองค์กรมักทดสอบเองคือกดปุ่มปฏิเสธใน Cookie Banner แล้วเปิด Network Tab ดูว่า Script ของ Analytics หรือ Advertising ยังยิง Request ออกไปอยู่หรือไม่ SaaS หลายรายเขียนโค้ด Cookie Banner ให้ซ่อน Banner หลังกดปฏิเสธ แต่ลืมผูก Logic ให้ Script จริง ๆ หยุดทำงานตาม เพราะทีม Front-end กับทีมที่ดูแลเอกสารเป็นคนละกลุ่มและไม่เคยทดสอบร่วมกัน การ Audit ต้องรวมการทดสอบจริงบนเว็บไซต์ ไม่ใช่แค่ตรวจว่ามี Cookie Banner ปรากฏอยู่

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

เรื่องที่ 3: ตรวจช่องทางให้ผู้ใช้ใช้สิทธิ์เจ้าของข้อมูลจริง

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

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

เรื่องที่ 4: ตรวจความพร้อมของกระบวนการแจ้งเหตุละเมิดข้อมูล

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

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

เครื่องมือและวิธีติดตามผลระหว่างสองรอบ Audit

ทีม SaaS หลายแห่งมีปัญหาว่าทำ Audit เสร็จแล้วรายงานถูกเก็บไว้ในไฟล์เดียวแล้วไม่มีใครเปิดดูอีกจนกว่าจะถึงรอบถัดไป วิธีที่ช่วยได้จริงคือแปลงรายการที่พบว่าต้องแก้ไขจากการ Audit แต่ละครั้งให้เป็น Ticket ในระบบที่ทีม Engineering ใช้งานประจำอยู่แล้ว เช่น Jira หรือ Linear แล้วติดป้ายเฉพาะให้แยกออกจาก Backlog ทั่วไป เพื่อให้ทีมเห็นว่ายังมีงานด้าน Privacy ค้างอยู่กี่รายการและใครเป็นเจ้าของแต่ละงาน แทนที่จะรอให้ครบหกเดือนแล้วมาพบว่าเรื่องเดิมยังไม่ถูกแก้

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

ตัวอย่าง: SaaS ที่ Audit เอกสารแต่ไม่เคย Audit ระบบจริง

ทีมผลิตภัณฑ์ HR Tech รายหนึ่งผ่านการตรวจสอบ Privacy Policy จากทีม Legal ทุกปีอย่างสม่ำเสมอ เอกสารเขียนไว้ครบทุกหมวดตามที่กฎหมายกำหนด แต่เมื่อมีลูกค้าองค์กรรายใหญ่ขอทดสอบสิทธิ์ลบข้อมูลจริงก่อนเซ็นสัญญา ทีม Engineering ใช้เวลาเกือบสองสัปดาห์เพื่อหาว่าข้อมูลพนักงานคนหนึ่งกระจายอยู่ในกี่ระบบ เพราะไม่เคยมีแผนผังการไหลของข้อมูลที่อัปเดตตามระบบจริง ลูกค้าองค์กรรายนั้นตัดสินใจเลื่อนการเซ็นสัญญาออกไปเพราะไม่มั่นใจว่าทีมจะตอบสนองคำขอลบข้อมูลของพนักงานตนเองได้ทันตามกรอบเวลาที่ต้องการ เหตุการณ์นี้เกิดขึ้นทั้งที่เอกสาร Privacy Policy ผ่านการตรวจทุกปี เพราะการ Audit ที่ผ่านมาไม่เคยแตะระบบจริงเลยสักครั้ง

ใครควรเป็นเจ้าของการ Audit นี้ในทีม SaaS

ในทีมสตาร์ทอัพขนาดเล็กที่ยังไม่มีตำแหน่ง Privacy โดยเฉพาะ วิธีที่ทำได้จริงคือให้ Engineering Lead กับ Product Manager ร่วมกันไล่สี่เรื่องข้างต้นทุกหกเดือน แล้วนำผลไปให้ที่ปรึกษากฎหมายภายนอกตรวจทานเฉพาะจุดที่ไม่มั่นใจ เมื่อทีมโตขึ้นจนมีคนดูแล Privacy โดยตรง บทบาทของ Audit ควรเปลี่ยนมาเป็นการประสานงานเชิงระบบ ดึงข้อมูลจากทีม Engineering เรื่องฟีเจอร์ใหม่ ทีมขายเรื่องข้อกำหนดจากลูกค้าองค์กร และทีม Support เรื่องคำขอใช้สิทธิ์ที่เข้ามาจริง แล้วรวบรวมเป็นรายงาน Audit ที่มีวันที่และผู้รับผิดชอบชัดเจนทุกรอบ

Evidence ที่ควรเก็บไว้จากการ Audit แต่ละรอบ

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

ข้อผิดพลาดที่พบบ่อยเมื่อ Audit เฉพาะเอกสารไม่ใช่ระบบจริง

• ตรวจแค่ว่า Privacy Policy มีข้อความครบทุกหมวด โดยไม่เคยทดสอบว่าปุ่มปฏิเสธ Cookie มีผลกับ Script จริงหรือไม่
• เขียนฐานทางกฎหมายไว้กว้าง ๆ ครั้งเดียว แล้วไม่เคยทบทวนเมื่อมีฟีเจอร์ใหม่ที่เก็บข้อมูลเพิ่ม
• ไม่มีเอกสารภายในระบุว่าคำขอใช้สิทธิ์แต่ละประเภทต้องไปลบหรือแก้ข้อมูลจากระบบใดบ้าง
• ไม่เคยซ้อมกระบวนการแจ้งเหตุละเมิดข้อมูล จนต้องเสียเวลาตัดสินใจตอนเกิดเหตุจริง

สรุป

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

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

รายละเอียดเรื่องฐานทางกฎหมาย สิทธิ์เจ้าของข้อมูล และหน้าที่แจ้งเหตุละเมิดตามกฎหมาย ควรตรวจสอบเทียบกับแนวปฏิบัติของ สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC) โดยตรง บทความนี้เป็นแนวทางเชิงปฏิบัติสำหรับทีม Product, Engineering, Growth และ Privacy Team ไม่ใช่การตีความข้อกำหนดทางกฎหมายแทนหน่วยงานกำกับดูแล