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

การ Audit PDPA ของเอเจนซีทำเว็บไซต์ควรทำเป็นรอบ ไม่ใช่ทำครั้งเดียวตอนเริ่มโครงการ จุดที่ต้องตรวจซ้ำคือสัญญาประมวลผลข้อมูล (DPA) ของลูกค้าที่ยังทำงานอยู่ว่าครบถ้วนหรือไม่ รายชื่อ Sub-processor ตรงกับที่แจ้งลูกค้าไว้จริงหรือไม่ บัญชีแอดมินของโปรเจกต์ที่ปิดไปแล้วถูกปิดสิทธิ์จริงหรือยังค้างอยู่ หลักฐานการลบหรือคืนข้อมูลเมื่อจบสัญญามีครบหรือไม่ และบันทึกการทักท้วงคำสั่งลูกค้าที่มีความเสี่ยงยังเก็บอยู่หรือถูกลืมไป การ Audit สม่ำเสมอช่วยจับจุดที่หลุดจากระบบตั้งแต่เนิ่น ๆ แต่ไม่ได้แปลว่าทีมจะไม่มีช่องโหว่เหลืออยู่เลยหลังตรวจเสร็จ

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

ทำไมเอเจนซีทำเว็บไซต์ต้อง Audit ระบบ PDPA เป็นระยะ ไม่ใช่ทำครั้งเดียว

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

จุดที่ 1: ตรวจสอบสัญญาประมวลผลข้อมูล (DPA) ของลูกค้าที่ยังทำงานอยู่

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

จุดที่ 2: ตรวจสอบรายชื่อ Sub-processor ว่าตรงกับที่แจ้งลูกค้าไว้จริงหรือไม่

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

จุดที่ 3: ตรวจสอบบัญชีแอดมินและสิทธิ์เข้าถึงของโปรเจกต์ที่ปิดไปแล้ว

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

จุดที่ 4: ตรวจสอบหลักฐานการลบหรือคืนข้อมูลเมื่อจบสัญญา

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

จุดที่ 5: ตรวจสอบบันทึกการทักท้วงคำสั่งลูกค้าที่มีความเสี่ยง

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

ความถี่และวิธีจัดทำรอบ Audit ให้เป็นนิสัยของทีม

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

ข้อผิดพลาดที่พบบ่อยเมื่อ Audit ระบบ PDPA ของเอเจนซี

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

สรุปการ Audit PDPA สำหรับเอเจนซีทำเว็บไซต์

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

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

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