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

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

บ่ายวันศุกร์ก่อนสิ้นเดือน ทีม Growth ของเอเจนซี่แห่งหนึ่งได้รับอีเมลจากลูกค้า SaaS สตาร์ทอัพรายหนึ่งว่าจะไม่ต่อสัญญา Retainer หลังครบกำหนดอีก 30 วัน คนที่ตอบอีเมลกลับไปคือ Account Manager ซึ่งพยายามหาคำตอบว่าฐานข้อมูลลีดที่เก็บผ่านแคมเปญโฆษณา พิกเซลติดตามผลบนเว็บของลูกค้า และไฟล์ Audience ที่อัปโหลดไว้ในระบบโฆษณาต้องทำอย่างไรต่อ คำถามนี้ไม่มีคำตอบสำเร็จรูปในหัวทีม เพราะสัญญาที่เซ็นกันไว้ตอนเริ่มงานพูดถึงแค่ค่าบริการและ Deliverable ไม่ได้ระบุขั้นตอนคืนหรือลบข้อมูลเมื่อเลิกจ้างไว้เลย

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

ทำไม PDPA สำหรับ Agency ต้องมองผ่านมุม Processor ไม่ใช่ Controller

เมื่อทีม Growth หรือ Media Buying ของเอเจนซี่นำอีเมลลูกค้าไปสร้าง Custom Audience บนแพลตฟอร์มโฆษณา หรือฝังพิกเซลติดตามพฤติกรรมบนเว็บของลูกค้า SaaS เอเจนซี่กำลังประมวลผลข้อมูลส่วนบุคคลตามคำสั่งของลูกค้า ไม่ได้ตัดสินใจเองว่าจะเก็บข้อมูลอะไรหรือใช้เพื่อวัตถุประสงค์ใด บทบาทนี้ทำให้เอเจนซี่เป็น Processor และลูกค้า SaaS เป็น Controller ตามโครงสร้างของ PDPA ความแตกต่างสำคัญคือ Processor ต้องทำตามคำสั่งของ Controller เท่านั้น จะนำข้อมูลไปใช้ต่อยอดเอง เช่น เอาลีดของลูกค้ารายหนึ่งไปทำ Lookalike ให้ลูกค้าอีกรายไม่ได้ และต้องมีมาตรการความปลอดภัยของข้อมูลในระดับที่ตกลงกันไว้เป็นลายลักษณ์อักษร

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

DPA กับลูกค้าควรระบุอะไรบ้าง

สัญญาประมวลผลข้อมูล หรือ Data Processing Agreement เป็นเอกสารที่แยกออกมาจากสัญญาบริการหลัก หรืออาจแนบเป็นภาคผนวกก็ได้ สิ่งที่ควรมีในเอกสารนี้สำหรับเอเจนซี่ที่รับงานลูกค้า SaaS มีดังนี้

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

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

Sub-processor ที่เอเจนซี่ใช้ต้องแจ้งลูกค้าหรือไม่

เอเจนซี่แทบทุกแห่งไม่ได้ประมวลผลข้อมูลด้วยระบบของตัวเองล้วน ๆ มักพึ่งเครื่องมือภายนอก เช่น แพลตฟอร์ม Marketing Automation เครื่องมือ Tracking พิกเซลของบุคคลที่สาม หรือระบบ CDP ที่ใช้เก็บ Audience รวมศูนย์ เครื่องมือเหล่านี้ในทางกฎหมายถือเป็น Sub-processor เพราะเข้าถึงหรือประมวลผลข้อมูลของลูกค้าลูกค้าอีกทอดหนึ่ง

หลักปฏิบัติที่ควรทำคือทำรายการ Sub-processor ที่ใช้งานจริงทั้งหมดแนบไว้ใน DPA หรือเป็นเอกสารอ้างอิงที่อัปเดตได้ และเมื่อจะเพิ่มเครื่องมือใหม่เข้ามาระหว่างสัญญา ควรแจ้งลูกค้าล่วงหน้าตามช่องทางที่ตกลงกันไว้ เช่น อีเมลแจ้งเปลี่ยนแปลง 15-30 วันก่อนเริ่มใช้งานจริง จุดที่เอเจนซี่จำนวนมากพลาดคือทีม Media Buying เปลี่ยนเครื่องมือ Tracking หรือเพิ่มปลั๊กอินใหม่โดยไม่ได้แจ้งฝ่ายที่ดูแลสัญญา ทำให้รายการ Sub-processor ที่ลูกค้าเห็นกับที่ใช้งานจริงไม่ตรงกัน หากเกิดปัญหาการรั่วไหลของข้อมูลผ่านเครื่องมือที่ไม่เคยแจ้งลูกค้ามาก่อน จุดนี้มักเป็นประเด็นแรกที่ลูกค้าหยิบยกขึ้นมาถามเมื่อสอบสวนเหตุ

เมื่อสัญญาสิ้นสุด ข้อมูลของลูกค้าต้องทำอย่างไร

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

1. รวบรวมรายการข้อมูลของลูกค้ารายนั้นที่กระจายอยู่ในระบบต่าง ๆ เช่น บัญชีโฆษณา เครื่องมือ Automation ไฟล์ที่แชร์ผ่าน Cloud Storage และกล่องข้อความภายในทีม
2. สอบถามลูกค้าว่าต้องการให้คืนไฟล์ต้นฉบับ หรือให้ลบทิ้งเลยโดยไม่ต้องส่งคืน เพราะทั้งสองทางมีขั้นตอนต่างกัน
3. ลบสิทธิ์การเข้าถึงบัญชีโฆษณา บัญชี Automation และระบบที่เกี่ยวข้องของทีมงานที่เคยดูแลลูกค้ารายนี้
4. ลบไฟล์ Audience ที่อัปโหลดไว้ในแพลตฟอร์มโฆษณา และตรวจว่าระบบภายนอกลบข้อมูลออกจริงตามรอบเวลาที่แพลตฟอร์มนั้นกำหนดไว้
5. บันทึกหลักฐานการลบไว้ เช่น Screenshot วันที่ลบ อีเมลยืนยันจากระบบ หรือ Log การลบสิทธิ์ เพื่อใช้ยืนยันย้อนหลังหากลูกค้าสอบถามในภายหลัง

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

ความรับผิดอยู่ตรงไหน เมื่อเกิดปัญหาระหว่างเอเจนซี่กับลูกค้า

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

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

สิ่งที่ต้องทบทวนซ้ำตอนเข้าปี 2026

เอเจนซี่ที่ทำ DPA ไว้ตั้งแต่ปีก่อน ๆ ควรกลับไปเปิดอ่านอีกครั้งโดยเทียบกับสิ่งที่สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล หรือ PDPC เผยแพร่ล่าสุด เพราะแนวปฏิบัติและตัวอย่างกรณีศึกษาที่ PDPC ออกมาเพิ่มเติมมักละเอียดกว่าตอนที่ธุรกิจเขียน DPA ครั้งแรก จุดที่ควรเช็กซ้ำมีสามเรื่องหลัก หนึ่งคือรายชื่อ Sub-processor ในเอกสารตรงกับเครื่องมือที่ทีมงานใช้จริงในปัจจุบันหรือไม่ เพราะทีม Media Buying มักเปลี่ยนเครื่องมือบ่อยกว่าที่ฝ่ายสัญญารับรู้ สองคือขั้นตอนคืน-ลบข้อมูลที่เขียนไว้ยังใช้งานได้จริงหรือไม่ เพราะระบบที่ใช้อาจเปลี่ยนไปแล้ว และสามคือมีลูกค้ารายไหนที่สัญญาใกล้ครบกำหนดในไตรมาสนี้บ้าง เพื่อเตรียมขั้นตอนปิดงานล่วงหน้าแทนที่จะรอให้ถึงวันสุดท้ายแล้วค่อยคิด

สำหรับเอเจนซี่ที่รับงานลูกค้ากลุ่ม SaaS และเทคโนโลยีโดยเฉพาะ ควรระวังเพิ่มอีกจุดหนึ่งคือข้อมูลที่ได้จาก Product Analytics หรือ In-app Tracking ที่ลูกค้าส่งต่อมาให้ทำ Remarketing เพราะข้อมูลกลุ่มนี้มักละเอียดกว่าอีเมลหรือเบอร์โทรทั่วไป เช่น พฤติกรรมการใช้ฟีเจอร์ในระบบ ซึ่งอาจสะท้อนข้อมูลเชิงพฤติกรรมที่ละเอียดอ่อนกว่าที่คิด การทบทวนแนวปฏิบัตินี้ควรทำเป็นรอบสม่ำเสมอ ไม่ใช่ทำครั้งเดียวแล้วปล่อยผ่าน

ข้อผิดพลาดที่พบบ่อยในเอเจนซี่ที่รับงานลูกค้า SaaS

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

สรุปสิ่งที่เอเจนซี่ควรทำต่อ

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

แหล่งข้อมูลอ้างอิงและวิธีตรวจสอบ

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