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

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

ความต่างนี้ไม่ได้อยู่ที่ฝีมือเขียนโค้ด แต่อยู่ที่การมีกระบวนการ Audit ที่ทำซ้ำได้เป็นประจำ บทความนี้วางจุดตรวจและหลักฐานที่ควรเก็บสำหรับเอเจนซี ฟรีแลนซ์ และทีมพัฒนาเว็บไซต์ ที่ต้องดูแล Privacy Policy ให้ลูกค้าหลายรายพร้อมกัน

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

ทำไมเอเจนซีต้อง Audit Privacy Policy ของลูกค้าเป็นรอบ ไม่ใช่ทำครั้งเดียวตอนส่งมอบ

ทีมพัฒนาเว็บไซต์มักมองว่า Privacy Policy เป็นงานที่ทำเสร็จตอนโปรเจกต์ปิด แต่เว็บไซต์ของลูกค้ายังมีการเปลี่ยนแปลงต่อเนื่องหลังส่งมอบ เช่น ทีมการตลาดของลูกค้าเพิ่ม pixel ติดตามโฆษณาเอง ทีมขายเปลี่ยนระบบ CRM ที่เชื่อมกับฟอร์มติดต่อ หรือมีการเพิ่มปลั๊กอินใหม่โดยไม่แจ้งเอเจนซี ความเปลี่ยนแปลงเหล่านี้เกิดขึ้นได้แม้เอเจนซีไม่ได้เป็นผู้ดูแลเว็บไซต์ต่อแล้ว การ Audit เป็นรอบจึงสำคัญกับเอเจนซีที่รับงาน maintenance ต่อเนื่อง และสำคัญไม่แพ้กันกับฟรีแลนซ์ที่รับงานครั้งเดียวแต่ต้องการปิดความเสี่ยงก่อนส่งมอบให้ครบถ้วน

จุดตรวจที่ 1: ข้อมูลที่เว็บไซต์เก็บจริงตรงกับที่เอกสารระบุหรือไม่

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

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

จุดตรวจที่ 2: ฐานทางกฎหมายและวัตถุประสงค์ยังสอดคล้องกับฟีเจอร์ปัจจุบันหรือไม่

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

จุดตรวจที่ 3: บุคคลที่สามอย่าง Analytics, Ad Pixel และ Plugin ถูกระบุครบหรือไม่

เว็บไซต์ยุคนี้แทบทุกเว็บติดตั้งเครื่องมือวิเคราะห์และปลั๊กอินจากผู้ให้บริการภายนอกหลายราย ผู้ตรวจควรเปิดโค้ดหน้าเว็บและเครื่องมือตรวจสอบ network request เพื่อดูว่ามีสคริปต์จากโดเมนภายนอกใดถูกโหลดอยู่บ้าง แล้วเทียบกับรายชื่อบุคคลที่สามที่ Privacy Policy ระบุไว้ ทีมพัฒนาเว็บไซต์รายหนึ่งพบว่าลูกค้าติดตั้ง live chat widget จากผู้ให้บริการรายใหม่เองหลังส่งมอบงาน โดยไม่แจ้งเอเจนซี widget นี้ส่งข้อมูลการสนทนารวมถึงอีเมลลูกค้าไปเก็บบนเซิร์ฟเวอร์ต่างประเทศ ซึ่งไม่เคยปรากฏในเอกสารที่เอเจนซีเคยทำไว้ตอนส่งมอบเลย

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

จุดตรวจที่ 4: ช่องทางใช้สิทธิ์ของเจ้าของข้อมูลยังใช้งานได้จริงหรือไม่

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

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

จุดตรวจที่ 5: วันที่ปรับปรุงล่าสุดสะท้อนรอบตรวจล่าสุดจริงหรือไม่

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

หลักฐานที่ควรเก็บไว้ทุกครั้งที่ Audit

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

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

นำผลตรวจไปใช้กับสัญญาว่าจ้างและ SOW ของเอเจนซี

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

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

ข้อผิดพลาดที่พบบ่อยเมื่อ Audit Privacy Policy ให้ลูกค้า

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

สรุป

การ Audit Privacy Policy สำหรับเอเจนซีและฟรีแลนซ์ทำเว็บไซต์ ควรเป็นกระบวนการที่ทำซ้ำได้ตามรอบ ไม่ใช่งานที่ทำครั้งเดียวตอนส่งมอบแล้วจบ การตรวจทั้ง 5 จุดที่กล่าวมา พร้อมเก็บหลักฐานเป็นลายลักษณ์อักษรทุกครั้ง ช่วยให้เอเจนซีตอบคำถามลูกค้าได้ทันทีเมื่อมีปัญหาเกิดขึ้นภายหลัง และช่วยลดข้อพิพาทเรื่องขอบเขตความรับผิดชอบระหว่างเอเจนซีกับลูกค้า สำหรับรายการตรวจสอบแบบสั้นที่ใช้ก่อนส่งมอบงานแต่ละครั้ง ดูเพิ่มเติมได้ที่ Checklist Privacy Policy สำหรับ Agency และดูภาพรวมหัวข้ออื่นในหมวด Policies & Notices ได้ที่ คลังความรู้ Policies & Notices

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

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