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

เอเจนซี่ที่รับงาน Growth Marketing ให้ลูกค้า SaaS ต้องเซ็น Data Processing Agreement กับลูกค้าทุกรายจริงหรือ คำถามนี้เกิดขึ้นบ่อยในทีม Growth ที่เพิ่งเริ่มดูแลลูกค้ากลุ่มซอฟต์แวร์ เพราะงานประจำวันคือดึงรายชื่อผู้ใช้ที่สมัคร Trial มาสร้าง Custom Audience บน Facebook และ Google Ads หรือดึง Event การใช้งานในแอปมาต่อกับระบบ Marketing Automation คำตอบคือต้องทำ และไม่ใช่แค่เรื่องเอกสารทางกฎหมาย เพราะทุกครั้งที่ดึงอีเมลหรือพฤติกรรมผู้ใช้จากระบบของลูกค้ามาประมวลผล เอเจนซี่กำลังทำหน้าที่เป็นผู้ประมวลผลข้อมูลแทนเจ้าของข้อมูลจริงคือลูกค้า SaaS นั้นเอง

บทความนี้ไล่ทีละขั้นตอนที่ทีม Product, Engineering, Growth และ Privacy ของเอเจนซี่ต้องวางจริงเพื่อให้ความสัมพันธ์กับลูกค้า SaaS เป็นไปตาม PDPA อย่างเป็นระบบ ไม่ใช่แค่แนบข้อความในสัญญาแล้วจบ

Agency ที่ดูแล Growth หรือ Performance Marketing ให้ลูกค้า SaaS ต้องเริ่มจากยอมรับบทบาทตัวเองว่าเป็นผู้ประมวลผลข้อมูลแทนลูกค้า ไม่ใช่เจ้าของข้อมูล จากนั้นทำ Data Processing Agreement ที่ระบุขอบเขตการใช้ข้อมูลชัดเจน เปิดเผย Sub-processor ที่ตัวเองใช้งาน วางกระบวนการคืนหรือลบข้อมูลเมื่อสัญญาสิ้นสุด และแบ่งเส้นความรับผิดชอบกับลูกค้าไว้ล่วงหน้าก่อนเกิดปัญหา

ทำไม Agency ต้องมองตัวเองเป็นผู้ประมวลผลข้อมูล ไม่ใช่เจ้าของข้อมูล

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

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

ขั้นตอนที่ 1: สำรวจว่างานส่วนไหนของ Agency คือการประมวลผลข้อมูลแทนลูกค้า

ก่อนร่างเอกสารใด ๆ ทีมต้องไล่ดูงานจริงที่ทำให้ลูกค้า SaaS แต่ละรายว่าจุดไหนบ้างที่แตะข้อมูลผู้ใช้ปลายทาง เช่น การรับไฟล์อีเมลผู้สมัคร Trial มาอัปโหลดเป็น Custom Audience การเชื่อมต่อ API ดึง Event การใช้งานฟีเจอร์ในแอปมาวิเคราะห์ Funnel หรือการเข้าถึงระบบ CRM ของลูกค้าโดยตรงเพื่อดูรายชื่อลีดที่ยังไม่ปิดการขาย แต่ละจุดควรบันทึกไว้ว่าใช้ข้อมูลประเภทใด เก็บไว้ที่ระบบไหนของเอเจนซี่เอง และมีคนในทีมกี่คนที่เข้าถึงได้

ทีม Engineering ควรเป็นผู้ช่วยตรวจสอบส่วนนี้ร่วมกับ Privacy Team เพราะบางครั้งสคริปต์หรือ Pixel ที่ทีม Growth ติดตั้งเองดึงข้อมูลมากกว่าที่ตกลงกันไว้ในตอนแรก เช่น Pixel ที่ตั้งค่าแบบ Advanced Matching อาจส่งอีเมลผู้ใช้แบบไม่เข้ารหัสไปให้แพลตฟอร์มโฆษณาโดยทีมไม่รู้ตัว หลักฐานที่ควรเก็บไว้คือรายการจุดประมวลผลข้อมูลนี้ในรูปแบบเอกสารที่ปรับปรุงทุกครั้งที่มีการเปลี่ยนเครื่องมือหรือเพิ่มฟีเจอร์ใหม่

ขั้นตอนที่ 2: ร่าง Data Processing Agreement กับลูกค้าแต่ละราย

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

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

ขั้นตอนที่ 3: เปิดเผย Sub-processor ที่ Agency ใช้งานอยู่จริง

งาน Growth Marketing แทบไม่มีเอเจนซี่รายไหนทำเองทั้งหมดโดยไม่พึ่งเครื่องมือภายนอก เช่น แพลตฟอร์มโฆษณา ระบบ Marketing Automation หรือเครื่องมือวิเคราะห์ข้อมูลแบบ Third-party ทุกเครื่องมือเหล่านี้ที่มีสิทธิ์เข้าถึงหรือเก็บข้อมูลผู้ใช้ปลายทางของลูกค้าถือเป็น Sub-processor และตาม PDPA เอเจนซี่ต้องเปิดเผยรายชื่อ Sub-processor เหล่านี้ให้ลูกค้าทราบ ไม่ใช่แอบใช้งานเงียบ ๆ โดยไม่แจ้ง

ทีมควรทำรายการ Sub-processor เป็นเอกสารแนบท้าย DPA ระบุชื่อผู้ให้บริการ วัตถุประสงค์ที่ใช้งาน และประเทศที่เซิร์ฟเวอร์ตั้งอยู่หากมีการส่งข้อมูลออกนอกประเทศ เมื่อจะเพิ่มเครื่องมือใหม่เข้ามาในกระบวนการทำงาน เช่น เปลี่ยนไปใช้ระบบ Marketing Automation ตัวใหม่ที่มีฟีเจอร์ AI วิเคราะห์พฤติกรรม ควรแจ้งลูกค้าล่วงหน้าตามระยะเวลาที่ระบุใน DPA และเปิดช่องให้ลูกค้าคัดค้านได้หากไม่เห็นด้วย เพราะสุดท้ายแล้วลูกค้าคือผู้รับผิดชอบต่อผู้ใช้ปลายทางของตัวเองในฐานะผู้ควบคุมข้อมูล

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

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

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

ขั้นตอนที่ 5: แบ่งเส้นความรับผิดชอบไว้ล่วงหน้าก่อนเกิดปัญหา

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

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

ขั้นตอนที่ 6: ตรวจสอบคำสั่งของลูกค้าก่อนลงมือทำทุกครั้ง

บางครั้งลูกค้า SaaS ที่เร่งผลลัพธ์ Growth อาจขอให้เอเจนซี่ทำสิ่งที่เสี่ยงต่อการฝ่าฝืน PDPA โดยไม่ตั้งใจ เช่น ขอให้อัปโหลดฐานข้อมูลผู้ใช้ทั้งหมดรวมถึงคนที่ยกเลิกการใช้งานไปแล้วเพื่อทำ Win-back Campaign โดยไม่เคยขอความยินยอมสำหรับการตลาดไว้ก่อน ทีม Growth ควรมีขั้นตอนตรวจสอบก่อนดำเนินการว่าคำสั่งนั้นมีฐานทางกฎหมายรองรับหรือไม่ และหากไม่แน่ใจควรสอบถามกลับไปยังลูกค้าเป็นลายลักษณ์อักษรก่อนเริ่มงาน เพราะการทำตามคำสั่งที่ไม่ชอบด้วยกฎหมายโดยไม่ทักท้วงเลยอาจทำให้เอเจนซี่ถูกมองว่ามีส่วนร่วมในความผิดด้วยเช่นกัน

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

ข้อผิดพลาดที่พบบ่อยเมื่อ Agency ดูแลข้อมูลลูกค้า SaaS

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

สรุป

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

ทีมที่ต้องการแนวทางตรวจสอบระบบที่วางไว้แล้วอย่างสม่ำเสมอ สามารถอ่านเพิ่มเติมได้ที่ วิธี Audit PDPA สำหรับ Agency ลูกค้า SaaS และดูรายการตรวจก่อนรับงานลูกค้าใหม่ได้ที่ เช็กลิสต์ PDPA สำหรับ Agency ลูกค้า SaaS

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

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