วิธี Audit WordPress PDPA ของเอเจนซีและฟรีแลนซ์ทำเว็บไซต์ พร้อม Evidence ที่ควรเก็บ

การ Audit WordPress PDPA สำหรับเอเจนซีคือการตรวจย้อนหลังว่า Privacy Tools ที่ WordPress core มีให้ถูกตั้งค่าและทดสอบจริงหรือไม่ ไม่ใช่แค่การติดตั้งปลั๊กอินคุกกี้ ต้องตรวจหน้า Privacy Policy ผลการทดสอบ Export/Erasure การจัดการข้อมูลคอมเมนต์กับ Akismet และคุกกี้ระบบอย่าง wp-settings ทุกจุดควรมีหลักฐานเป็นเอกสารหรือภาพหน้าจอแนบไว้ เพื่อให้ตอบคำถามลูกค้าย้อนหลังได้โดยไม่ต้องเดา

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

สถานการณ์แบบนี้เกิดขึ้นซ้ำในหลายเอเจนซีเพราะการ Audit WordPress PDPA มักถูกมองว่าเป็นงานเสริมที่ทำหลังส่งมอบ ทั้งที่จริงแล้วควรเป็นขั้นตอนที่ทำสม่ำเสมอทุกหกเดือน โดยเฉพาะกับเว็บไซต์ที่มีการติดตั้งปลั๊กอินใหม่หรือเปลี่ยนธีมระหว่างทาง เพราะทุกการเปลี่ยนแปลงอาจกระทบกลไก Privacy ที่ WordPress core มีให้อยู่แล้วโดยไม่มีใครสังเกต

ทำไมการ Audit ต้องแยกจากการติดตั้งครั้งแรก

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

ขั้นตอนที่ 1: ตรวจสถานะหน้า Privacy Policy ผ่านเมนู Settings

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

ขั้นตอนที่ 2: รัน Policy Guide เทียบกับปลั๊กอินที่ติดตั้งอยู่จริง

เครื่องมือ Policy Guide ของ WordPress core จะสแกนปลั๊กอินที่ติดตั้งอยู่แล้วแนะนำหัวข้อที่ควรมีในนโยบายความเป็นส่วนตัว ผู้ตรวจสอบควรเปิดเครื่องมือนี้แล้วเทียบกับเนื้อหาในหน้า Privacy Policy จริงทีละบรรทัด หากพบว่ามีปลั๊กอินใหม่ที่ Policy Guide แนะนำให้เขียนถึงแต่ในหน้านโยบายยังไม่มี นั่นคือช่องว่างที่ต้องแก้ไขก่อนปิดรอบ Audit

ขั้นตอนที่ 3: ทดสอบคำขอ Export ข้อมูลส่วนบุคคลซ้ำ

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

ขั้นตอนที่ 4: ทดสอบคำขอ Erasure และบันทึกผลเป็นภาพหน้าจอ

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

ขั้นตอนที่ 5: ตรวจข้อมูลคอมเมนต์และการเชื่อมต่อ Akismet

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

ขั้นตอนที่ 6: ตรวจคุกกี้ที่ core สร้างเองด้วย DevTools

เปิด DevTools ของเบราว์เซอร์แล้วดูรายชื่อคุกกี้ที่เกิดขึ้นจริงเมื่อมีการล็อกอินเข้าระบบหลังบ้าน คุกกี้อย่าง wordpress_logged_in และ wp-settings เป็นของ core ที่ทำงานเพื่อจดจำสถานะผู้ดูแลระบบ ไม่ใช่คุกกี้ tracking การตลาด แต่ยังควรระบุไว้ในหน้านโยบายเพื่อความครบถ้วน ผู้ตรวจสอบควรบันทึกชื่อคุกกี้ที่พบจริงในรอบ Audit นั้นไว้ เพราะบางปลั๊กอินอาจเพิ่มคุกกี้ใหม่โดยไม่แจ้งในเอกสาร

ขั้นตอนที่ 7: ตรวจ Site Health หาคำเตือนด้าน Privacy ที่ค้างอยู่

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

ขั้นตอนที่ 8: ตรวจสิทธิ์การเข้าถึงของทีมเอเจนซีเอง

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

ตารางสรุปจุดตรวจและ Evidence ที่ควรเก็บในแต่ละรอบ Audit

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

วิธีจัดเก็บ Evidence ให้ตรวจสอบย้อนกลับได้จริง

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

จัดรอบ Audit ให้เข้ากับจังหวะงานของเอเจนซีขนาดเล็ก

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

ข้อควรระวังเมื่อดูแลเว็บลูกค้าหลายเว็บบนสภาพแวดล้อม Staging

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

ผูกรอบ Audit เข้ากับสัญญาบำรุงรักษาเว็บไซต์ต่อเนื่อง

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

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

ข้อผิดพลาดที่พบบ่อยเมื่อ Audit WordPress PDPA

• ตรวจแค่ว่าปลั๊กอินคุกกี้ยังทำงานอยู่ โดยไม่แตะ Privacy Tools ของ core เลย
• ไม่ทดสอบ Export/Erasure ซ้ำหลังจากอัปเดตปลั๊กอินหรือเปลี่ยนธีม
• เก็บภาพหน้าจอ Evidence โดยไม่ระบุวันที่หรือชื่อผู้ตรวจ
• ลืมเช็ก Site Health ทั้งที่เป็นจุดที่เห็นคำเตือนด้าน Privacy ได้เร็วที่สุด
• ใช้ผลการ Audit ครั้งเก่าซ้ำโดยไม่ได้ตรวจสถานะปัจจุบันของเว็บไซต์จริง

ข้อควรระวังเมื่อสื่อสารผลการ Audit กับลูกค้า

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

สรุป: Audit ที่มี Evidence คือสิ่งที่ตอบคำถามลูกค้าได้ทันเวลา

เหตุการณ์แบบคืนที่ทีมพัฒนาต้องรีบไล่ตรวจเมนู Settings เพื่อหาคำตอบให้ลูกค้าจะไม่เกิดซ้ำ ถ้าเอเจนซีจัดรอบ Audit WordPress PDPA อย่างสม่ำเสมอและเก็บ Evidence ไว้เป็นระบบตั้งแต่แรก ดูขั้นตอนการวางระบบตั้งแต่ต้นเพิ่มเติมได้ที่ คู่มือวางระบบ WordPress PDPA แบบเป็นขั้นตอน และภาพรวมทั้งคลัสเตอร์ที่ คู่มือ WordPress PDPA สำหรับเอเจนซี หรือสำรวจหมวดอื่นที่เกี่ยวข้องได้ที่ ศูนย์ความรู้ Platforms & Integrations

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

อ้างอิงจาก WordPress Developer Resources หมวด Privacy ซึ่งอธิบายกลไก Privacy Tools ของ core อย่างเป็นทางการ ผู้ตรวจสอบควรกลับไปอ่านเอกสารต้นทางซ้ำทุกรอบ Audit เพราะรายละเอียดของฟีเจอร์ Export/Erasure และ Site Health อาจมีการปรับปรุงเพิ่มเติมตามเวอร์ชันใหม่ของ WordPress