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

Agency จำนวนมากที่รับดูแล Campaign การตลาดให้ลูกค้ากลุ่ม SaaS เก็บ Audience List, ข้อมูลจาก Pixel Tracking และ Lead List ของลูกค้าไว้ในระบบของตัวเองเป็นปกติ แต่หลายทีมไม่เคยมีสัญญาที่ระบุชัดว่า Agency ทำหน้าที่เป็นผู้ประมวลผลข้อมูล (Data Processor) ตามคำสั่งของลูกค้าซึ่งเป็นผู้ควบคุมข้อมูล (Data Controller) ไม่ใช่เจ้าของข้อมูลเอง ปัญหานี้ไม่โผล่ออกมาให้เห็นในสถานการณ์ปกติ จนกว่าจะเกิดเหตุข้อมูลรั่วไหลจากระบบโฆษณาที่ Agency ใช้งาน หรือสัญญากับลูกค้าจบลงแล้วไม่มีใครตอบได้ว่าข้อมูล Audience ที่เคยอัปโหลดไว้ในแพลตฟอร์มโฆษณาถูกลบไปแล้วจริงหรือไม่ การ Audit ที่ตรงจุดจึงต้องเจาะไปที่ตัวสัญญาและกระบวนการจริงเบื้องหลัง ไม่ใช่แค่ตรวจว่า Agency มี Privacy Policy ของตัวเองสวยงามครบถ้วน

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

เรื่องที่ 1: ตรวจความครบถ้วนของ DPA กับลูกค้าแต่ละราย

จุดเริ่มต้นของ Audit คือไล่ดูสัญญากับลูกค้าแต่ละรายว่ามี Data Processing Agreement (DPA) แนบอยู่จริงหรือไม่ และเนื้อหาระบุครบหรือไม่ว่า Agency ประมวลผลข้อมูลประเภทใดบ้าง เพื่อวัตถุประสงค์อะไร ตามคำสั่งของลูกค้าเท่านั้น ไม่ใช่ตามดุลยพินิจของ Agency เอง Agency หลายรายเซ็นสัญญาบริการทั่วไปที่พูดถึงขอบเขตงานและค่าบริการอย่างละเอียด แต่ไม่มีภาคผนวกเรื่องข้อมูลส่วนบุคคลเลย เพราะทีมขายที่ปิดดีลไม่รู้ว่าต้องขอเอกสารนี้เพิ่ม และทีม Legal ของทั้งสองฝ่ายไม่เคยถูกดึงเข้ามาคุยเรื่องนี้ตั้งแต่ต้น

วิธีตรวจที่ทำได้จริงคือสร้างตารางรายชื่อลูกค้าทั้งหมดที่ Agency ดูแลอยู่ พร้อมคอลัมน์ระบุว่ามี DPA หรือไม่ ลงนามเมื่อใด และครอบคลุมประเภทข้อมูลอะไรบ้าง เช่น Audience List, ข้อมูลจาก Pixel, หรือ Lead Form ทีม Account Management ควรร่วมทบทวนตารางนี้กับผู้รับผิดชอบด้าน Privacy อย่างน้อยทุกหกเดือน และทุกครั้งที่ปิดดีลลูกค้าใหม่ ต้องได้ DPA ที่ลงนามก่อนเริ่มรับข้อมูลจริง ไม่ใช่ลงนามย้อนหลังหลัง Campaign เริ่มไปแล้ว

เรื่องที่ 2: ตรวจทะเบียน Sub-processor และการเปิดเผยต่อลูกค้า

Agency แทบทุกรายใช้เครื่องมือภายนอกเพิ่มเติมนอกเหนือจากแพลตฟอร์มโฆษณาหลัก เช่น เครื่องมือ Marketing Automation, ระบบเก็บ Lead กลาง หรือ Vendor วิเคราะห์ข้อมูลที่ Agency จ้างต่อ เครื่องมือเหล่านี้ล้วนเป็น Sub-processor ที่ได้รับข้อมูลของลูกค้าไปประมวลผลต่ออีกทอดหนึ่ง จุดที่ Agency พลาดบ่อยคือเพิ่มเครื่องมือใหม่เข้ามาในกระบวนการทำงานโดยไม่เคยแจ้งลูกค้า และไม่เคยปรับปรุงทะเบียน Sub-processor ให้ตรงกับความเป็นจริง เพราะทีม Operations เป็นคนตัดสินใจเลือกเครื่องมือเอง โดยไม่รู้ว่าต้องแจ้งฝ่าย Legal หรือลูกค้าก่อน

การ Audit ต้องตรวจว่าทะเบียน Sub-processor ที่แนบในสัญญาหรือแจ้งลูกค้าไว้ตรงกับเครื่องมือที่ทีมใช้งานจริงหรือไม่ และตรวจว่ามีกระบวนการแจ้งลูกค้าล่วงหน้าก่อนเพิ่ม Sub-processor รายใหม่หรือไม่ เช่น แจ้งผ่านอีเมลพร้อมระยะเวลาให้ลูกค้าคัดค้านได้ก่อนเริ่มใช้งานจริง หากลูกค้าไม่เคยได้รับแจ้งเลยว่า Agency ส่งข้อมูล Audience ของตนไปให้ Vendor วิเคราะห์ข้อมูลภายนอก นี่คือช่องว่างที่ต้องแก้ก่อนเรื่องอื่น

เรื่องที่ 3: ตรวจกระบวนการจัดการข้อมูลเมื่อสัญญาสิ้นสุด

สิ่งที่ Agency ส่วนใหญ่ไม่เคยเตรียมไว้ล่วงหน้าคือขั้นตอนตอนสัญญากับลูกค้าจบลง ไม่ว่าจะเป็นการยกเลิกกลางคันหรือครบสัญญาตามกำหนด คำถามที่ต้องตอบได้คือ ข้อมูล Audience List, Pixel Data และ Lead List ของลูกค้าที่อยู่ในระบบของ Agency และใน Sub-processor ต่าง ๆ จะถูกลบหรือคืนให้ลูกค้าภายในกรอบเวลาเท่าใด และมีหลักฐานยืนยันการลบจริงหรือไม่ Agency จำนวนมากปล่อยให้ Audience ที่เคยอัปโหลดไว้ในแพลตฟอร์มโฆษณายังคงอยู่ในระบบต่อไปหลังเลิกจ้าง เพราะไม่มีใครมีหน้าที่ไปลบออกโดยเฉพาะ

การ Audit ต้องตรวจว่าสัญญาระบุกรอบเวลาการลบหรือคืนข้อมูลหลังสิ้นสุดสัญญาไว้ชัดเจนหรือไม่ เช่น สามสิบวันหลังสัญญาสิ้นสุด และต้องตรวจว่าทีม Operations มี Checklist ปิดงานลูกค้าที่รวมขั้นตอนลบ Audience ออกจากแพลตฟอร์มโฆษณา ลบไฟล์ Lead List จากระบบเก็บข้อมูลกลาง และแจ้ง Sub-processor ให้ลบข้อมูลตามด้วยหรือไม่ ควรเก็บภาพหน้าจอหรือรายงานยืนยันการลบไว้เป็นหลักฐาน แทนที่จะบอกลูกค้าด้วยปากเปล่าว่าลบแล้ว

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

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

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

สิ่งที่ DPA ที่ดีควรระบุไว้อย่างละเอียด ไม่ใช่แค่มีชื่อเอกสารว่า DPA

Agency บางรายมีเอกสารชื่อ Data Processing Agreement แนบไว้จริง แต่เนื้อหาข้างในเป็นแค่ประโยคกว้าง ๆ หนึ่งย่อหน้าว่า Agency จะรักษาความลับของข้อมูลลูกค้า ซึ่งไม่เพียงพอสำหรับการพิสูจน์บทบาทผู้ประมวลผลข้อมูลเมื่อถูกตรวจสอบจริง สิ่งที่ควรมีอย่างละเอียดคือรายการประเภทข้อมูลที่ Agency จะได้รับ วัตถุประสงค์ที่จำกัดเฉพาะงานตามสัญญา ระยะเวลาที่ Agency จะเก็บข้อมูลไว้ระหว่างสัญญา มาตรการรักษาความปลอดภัยขั้นต่ำที่ Agency ต้องมี เช่น การเข้ารหัสไฟล์ Lead List และการจำกัดสิทธิ์เข้าถึงเฉพาะทีมที่ดูแล Campaign นั้นจริง

อีกส่วนที่มักถูกมองข้ามคือสิทธิ์ของลูกค้าในการขอตรวจสอบ Agency เป็นระยะ เช่น ขอดูทะเบียน Sub-processor หรือขอรายงานสรุปมาตรการความปลอดภัยปีละครั้ง Agency ที่ยอมให้สิทธิ์นี้ไว้ล่วงหน้าในสัญญามักตอบคำถามลูกค้าองค์กรได้เร็วกว่า และไม่ต้องมาเจรจาเรื่องขอบเขตการตรวจสอบกันใหม่ทุกครั้งที่ลูกค้าต้องการหลักฐาน โดยเฉพาะลูกค้า SaaS ที่ขาย Enterprise Plan ซึ่งลูกค้าปลายทางของเขาเองมักขอ Certification ด้าน Privacy ย้อนไปถึง Vendor ทุกรายในห่วงโซ่ รวมถึง Agency ที่ดูแล Campaign ด้วย

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

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

ตัวอย่าง: Agency ที่มี DPA ครบแต่ไม่เคยลบข้อมูลหลังจบสัญญา

Agency ด้าน Performance Marketing รายหนึ่งดูแลลูกค้า SaaS ด้าน HR Software มาสามปี มี DPA ที่ลงนามครบถ้วนตั้งแต่วันแรก แต่เมื่อลูกค้ายกเลิกสัญญาแล้วเปลี่ยนไปใช้ Agency เจ้าอื่น ทีมภายในไม่มีใครรับผิดชอบไปลบ Audience List ที่เคยอัปโหลดไว้ในแพลตฟอร์มโฆษณาออก เพราะ Checklist ปิดงานลูกค้าที่ใช้อยู่พูดถึงแค่การส่งมอบรายงานผลงานย้อนหลังและปิดใบแจ้งหนี้ ไม่เคยพูดถึงการลบข้อมูล เก้าเดือนต่อมาลูกค้ารายนี้ทำ Audit เพื่อขอ Certification ด้าน Privacy จากลูกค้าปลายทางของตัวเอง แล้วพบว่า Audience ของพนักงานตนเองยังคงอยู่ในระบบของ Agency เดิม ทั้งที่สัญญาระบุไว้ว่าต้องลบภายในสามสิบวัน เหตุการณ์นี้ทำให้ลูกค้าต้องเสียเวลาชี้แจงกับลูกค้าปลายทางของตัวเองเพิ่มเติม ทั้งที่ DPA ต้นทางเขียนไว้ถูกต้องทุกอย่าง เพราะกระบวนการปฏิบัติจริงไม่เคยเชื่อมกับสิ่งที่สัญญาระบุไว้

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

ใน Agency ขนาดเล็กที่ยังไม่มีตำแหน่ง Privacy โดยเฉพาะ วิธีที่ทำได้จริงคือให้ Account Director ร่วมกับหัวหน้าทีม Operations ไล่สี่เรื่องข้างต้นทุกหกเดือน แล้วนำผลไปให้ที่ปรึกษากฎหมายภายนอกตรวจทานเฉพาะจุดที่ไม่มั่นใจ เมื่อ Agency โตขึ้นจนมีทีมกฎหมายหรือ Compliance ของตัวเอง บทบาทของ Audit ควรเปลี่ยนมาเป็นการประสานงานเชิงระบบ ดึงข้อมูลจากทีมขายเรื่องสัญญาลูกค้าใหม่ ทีม Operations เรื่อง Sub-processor ที่ใช้งานจริง และทีม Account Management เรื่องสถานะสัญญาที่กำลังจะสิ้นสุด แล้วรวบรวมเป็นรายงาน Audit ที่มีวันที่และผู้รับผิดชอบชัดเจนทุกรอบ

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

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

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

• เซ็นสัญญาบริการทั่วไปโดยไม่มีภาคผนวก DPA แนบเรื่องข้อมูลส่วนบุคคลเลย
• เพิ่มเครื่องมือหรือ Vendor ใหม่เข้ามาในงานโดยไม่แจ้งลูกค้าและไม่ปรับทะเบียน Sub-processor
• ไม่มี Checklist ปิดงานลูกค้าที่รวมขั้นตอนลบ Audience หรือ Lead List ออกจากระบบ
• ไม่เคยตกลงล่วงหน้าว่าฝ่ายใดต้องแจ้งอีกฝ่ายภายในกี่ชั่วโมงเมื่อพบเหตุข้อมูลรั่วไหล

สรุป

การ Audit PDPA สำหรับ Agency ที่ดูแลข้อมูลลูกค้า SaaS ต้องมองข้ามหน้าเอกสารสัญญาไปตรวจว่ากระบวนการจริงเบื้องหลังทำตามที่สัญญาเขียนไว้หรือไม่ ทั้ง DPA ทะเบียน Sub-processor การจัดการข้อมูลเมื่อสัญญาสิ้นสุด และขอบเขตความรับผิดเมื่อเกิดเหตุ Agency ที่ทำ Audit แบบนี้เป็นรอบสม่ำเสมอจะไม่ต้องเจอสถานการณ์ที่ลูกค้าองค์กรตรวจพบภายหลังว่าข้อมูลของตนยังค้างอยู่ในระบบที่ไม่ควรอยู่แล้ว ดูภาพรวมหัวข้ออื่นในหมวด Business, Industry and SEO เพิ่มเติมได้ที่ คลังความรู้ Business, Industry and SEO

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

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