อัปเดต PDPA สำหรับ Agency ปี 2026: สิ่งที่ร้านค้าออนไลน์และ E-commerceต้องทบทวน

ปี 2026 สิ่งที่ agency ดูแลข้อมูลลูกค้า e-commerce ต้องทบทวนคือ DPA ฉบับปัจจุบันยังระบุขอบเขตการประมวลผล การเปิดเผย sub-processor และขั้นตอนคืน/ลบข้อมูลเมื่อจบสัญญาไว้ชัดเจนหรือไม่ เพราะ agency ทำหน้าที่เป็น data processor ให้ลูกค้าซึ่งเป็น controller ไม่ใช่เจ้าของข้อมูลเอง เส้นแบ่งความรับผิดจึงขึ้นกับว่าปัญหาเกิดจากคำสั่งของลูกค้าหรือจากระบบของ agency เอง การตรวจทบทวนนี้ควรทำเป็นรอบทุกไตรมาสไม่ใช่ทำครั้งเดียวตอนเซ็นสัญญา

ทีม Account ของเอเจนซี่แห่งหนึ่งกำลังเตรียมเอกสารต่อสัญญารายไตรมาสกับลูกค้าที่เป็นร้านค้าออนไลน์รายหนึ่ง สองวันก่อนวันนัดเซ็น ฝ่ายกฎหมายของลูกค้าส่งอีเมลกลับมาถามสามข้อ: DPA ฉบับที่เซ็นไว้เมื่อสองปีก่อนยังครอบคลุมเครื่องมือ ad-tech ที่ agency เพิ่งเปลี่ยนไปใช้หรือไม่ ถ้าสัญญาจบกลางปีข้อมูลลูกค้าในระบบ Ads Manager กับ CRM ของ agency จะถูกจัดการอย่างไร และถ้าเกิดข้อมูลรั่วจากระบบของ agency ใครเป็นผู้รับผิดตามกฎหมาย ทีม Account ตอบไม่ได้ทันที เพราะ DPA ฉบับเดิมเขียนกว้างเกินไปและไม่มีใครในทีมตรวจทบทวนมันมาตั้งแต่วันเซ็นสัญญาครั้งแรก สถานการณ์แบบนี้กำลังเกิดขึ้นซ้ำในหลายเอเจนซี่ที่รับงานลูกค้า e-commerce เพราะสัญญาที่เขียนไว้แต่เดิมมักไม่ทันการเปลี่ยนแปลงของเครื่องมือและความคาดหวังด้าน PDPA ที่ลูกค้าเองก็ถูกกดดันจากลูกค้าปลายทางมากขึ้นทุกปี

อัปเดต 2026: อะไรเปลี่ยนไปสำหรับ Agency ที่ดูแลข้อมูลลูกค้า E-commerce

สิ่งที่เปลี่ยนไม่ใช่ตัวบทกฎหมาย PDPA เอง แต่คือระดับความเข้มงวดที่ลูกค้า e-commerce เรียกร้องจาก agency ที่ตนว่าจ้าง ร้านค้าออนไลน์จำนวนมากเริ่มมีทีมกฎหมายหรือที่ปรึกษาภายนอกตรวจสอบคู่สัญญาทุกฉบับก่อนต่ออายุ โดยเฉพาะสัญญากับ agency ที่เข้าถึงฐานข้อมูลลูกค้า รายการสั่งซื้อ หรือ pixel ติดตามพฤติกรรมบนหน้าเว็บ สิ่งที่ agency ควรตรวจทบทวนตอนนี้มีสามเรื่องหลัก คือขอบเขตของ DPA ที่เซ็นไว้ยังตรงกับเครื่องมือและ vendor ที่ใช้งานจริงหรือไม่ ขั้นตอนคืน/ลบข้อมูลเมื่อจบสัญญามีการทดสอบจริงหรือยังเป็นแค่ข้อความในสัญญา และทีมงานภายในเข้าใจตรงกันหรือไม่ว่าตัวเองกำลังทำหน้าที่เป็น data processor ไม่ใช่เจ้าของข้อมูล การตรวจทบทวนแบบนี้ควรทำทุกสามเดือน ไม่ใช่รอให้ลูกค้าถามก่อนแล้วค่อยไปหาคำตอบ

Agency คือ Data Processor ไม่ใช่ Controller — ทำไมต้องแยกให้ชัด

เวลาพูดถึง PDPA ส่วนใหญ่คนจะนึกถึงเว็บไซต์ที่เก็บข้อมูลลูกค้าตัวเองโดยตรง ซึ่งเว็บไซต์นั้นคือ controller ที่ตัดสินใจว่าจะเก็บข้อมูลอะไรและเอาไปใช้ทำอะไร แต่ agency ที่รับงานดูแล ads หรือ performance marketing ให้ร้านค้าออนไลน์ ส่วนใหญ่ไม่ได้เป็น controller ของข้อมูลลูกค้าปลายทาง agency เป็นผู้ประมวลผลข้อมูล (processor) ตามคำสั่งของลูกค้าซึ่งเป็น controller ตัวจริง เช่น เมื่อลูกค้าส่งไฟล์รายชื่อลูกค้าเดิมมาให้ agency อัปโหลดเป็น custom audience บน Facebook หรือ Google Ads agency ไม่มีสิทธิ์ตัดสินใจเองว่าจะเอาไปใช้ทำอะไรนอกเหนือคำสั่งของลูกค้า ความแตกต่างนี้สำคัญเพราะภาระหน้าที่ตามกฎหมายของ processor กับ controller ไม่เหมือนกัน controller ต้องมีฐานทางกฎหมายในการเก็บข้อมูลตั้งแต่ต้น ส่วน processor ต้องประมวลผลตามคำสั่งเป็นลายลักษณ์อักษรของ controller เท่านั้น และต้องมีมาตรการรักษาความปลอดภัยของข้อมูลที่ตนครอบครองอยู่

DPA กับลูกค้า E-commerce ต้องระบุอะไรบ้าง

Data Processing Agreement หรือ DPA คือเอกสารที่แยกออกจากสัญญาว่าจ้างงานทั่วไป และควรระบุรายละเอียดเฉพาะเรื่องการประมวลผลข้อมูล สิ่งที่ DPA กับลูกค้า e-commerce ควรครอบคลุมอย่างน้อยคือ ขอบเขตและวัตถุประสงค์ของการประมวลผล เช่น ใช้รายชื่อลูกค้าเพื่อทำ custom audience เท่านั้น ไม่ใช่เพื่อวัตถุประสงค์อื่น ประเภทข้อมูลที่ agency จะเข้าถึง เช่น อีเมล เบอร์โทร หรือประวัติการสั่งซื้อ ระยะเวลาที่ agency เก็บสำเนาข้อมูลไว้ในระบบของตัวเอง มาตรการความปลอดภัยขั้นต่ำที่ agency ต้องมี เช่น การจำกัดสิทธิ์เข้าถึงเฉพาะทีมที่ดูแลบัญชีนั้นจริง และช่องทางแจ้งเหตุเมื่อเกิดเหตุการณ์ผิดปกติกับข้อมูล หลายเอเจนซี่ยังใช้ DPA แบบ template เดียวกับลูกค้าทุกราย ทั้งที่ลูกค้าแต่ละรายมีข้อมูลอ่อนไหวต่างระดับกัน เช่น ร้านค้าที่ขายสินค้าสุขภาพย่อมมีข้อมูลที่ต้องระวังมากกว่าร้านขายเสื้อผ้าทั่วไป การใช้ DPA แบบเดียวกันหมดจึงเป็นความเสี่ยงที่ควรทบทวนก่อนต่อสัญญาแต่ละครั้ง

เปิดเผย Sub-processor: เมื่อ Agency เองก็ใช้เครื่องมือของเจ้าอื่น

อีกจุดที่ agency มักมองข้ามคือตัว agency เองก็มี sub-processor อีกทอดหนึ่ง เช่น ใช้เครื่องมือ automation ของ vendor ต่างประเทศในการจัดการโฆษณา ใช้แพลตฟอร์ม CRM กลางที่โฮสต์อยู่บน cloud ของบริษัทอื่น หรือจ้าง freelance เพิ่มเติมมาช่วยดูแลบัญชีในช่วงเปิดตัวแคมเปญใหญ่ ทุกครั้งที่ข้อมูลของลูกค้าถูกส่งต่อไปยังมือที่สามแบบนี้ ถือว่า agency กำลังใช้ sub-processor และตาม DPA ที่ดีควรมีข้อกำหนดให้ agency ต้องแจ้งลูกค้าก่อนเพิ่ม sub-processor รายใหม่ ไม่ใช่แค่แจ้งย้อนหลังตอนลูกค้าถามเอง แนวทางที่ใช้ได้จริงคือทำรายการ sub-processor เป็นเอกสารแนบท้าย DPA และอัปเดตทุกครั้งที่เปลี่ยนเครื่องมือหรือ vendor พร้อมเก็บหลักฐานว่าลูกค้ารับทราบหรือไม่คัดค้านภายในระยะเวลาที่ตกลงกันไว้ วิธีนี้ช่วยให้ agency ไม่ต้องมานั่งไล่ย้อนหลังว่าเคยแจ้งลูกค้ารายไหนไปแล้วบ้างเมื่อเกิดข้อพิพาท

เมื่อสัญญาจบ: คืนหรือลบข้อมูลลูกค้า E-commerce อย่างไรให้พิสูจน์ได้

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

เส้นแบ่งความรับผิด: Controller กับ Processor ใครรับผิดชอบอะไร

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

ข้อผิดพลาดที่พบบ่อยของ Agency ที่ดูแลข้อมูล E-commerce

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

สรุป: สิ่งที่ต้องทบทวนก่อนต่อสัญญาปี 2026

สำหรับ agency ที่ดูแลลูกค้าในกลุ่มร้านค้าออนไลน์และ e-commerce สิ่งที่ควรทำก่อนต่อสัญญารอบนี้คือดึง DPA ฉบับปัจจุบันมาอ่านใหม่ทั้งฉบับ เทียบกับเครื่องมือและ vendor ที่ใช้งานจริงตอนนี้ว่าตรงกันหรือไม่ ปรับรายการ sub-processor ให้เป็นปัจจุบันและแจ้งลูกค้าอย่างน้อยหนึ่งครั้งต่อปี และทดสอบขั้นตอนคืน/ลบข้อมูลกับลูกค้าอย่างน้อยหนึ่งรายให้แน่ใจว่าทำได้จริงไม่ใช่แค่เขียนไว้ในสัญญา งานนี้ไม่ใช่เรื่องที่ทำครั้งเดียวจบ แต่เป็นรอบตรวจสอบที่ควรผูกเข้ากับรอบต่อสัญญาทุกไตรมาสหรืออย่างน้อยทุกครั้งที่ agency เปลี่ยนเครื่องมือหลักที่ใช้ประมวลผลข้อมูลลูกค้า

ดูภาพรวมของหมวดธุรกิจและอุตสาหกรรมได้ที่ หมวด Business, Industry & SEO และดูขั้นตอนตรวจสอบแบบเป็นระบบเพิ่มเติมได้ที่ วิธีทำ PDPA สำหรับ Agency ที่ดูแลลูกค้า E-commerce หรือใช้เป็นแนวทางตรวจรอบถัดไปที่ คู่มือตรวจสอบ PDPA สำหรับ Agency กลุ่ม E-commerce

ข้อควรระวังเพิ่มเติมสำหรับทีมที่ดูแลหลายลูกค้าพร้อมกัน

เอเจนซี่ที่ดูแลลูกค้า e-commerce หลายรายพร้อมกันมักมีความเสี่ยงเพิ่มเติมคือข้อมูลของลูกค้าคนละรายถูกเก็บปนกันในระบบเดียว เช่น ใช้ spreadsheet กลางไฟล์เดียวไล่ทุกบัญชี หรือใช้บัญชี ad account เดียวสลับดูแลหลายลูกค้า วิธีที่ปลอดภัยกว่าคือแยกพื้นที่จัดเก็บข้อมูลของลูกค้าแต่ละรายออกจากกันอย่างชัดเจน กำหนดสิทธิ์เข้าถึงเฉพาะทีมที่ดูแลบัญชีนั้นจริง และตั้งชื่อไฟล์ให้ตรวจสอบย้อนหลังได้ง่ายว่าไฟล์ไหนเป็นของลูกค้ารายใด เมื่อถึงเวลาต้องคืนหรือลบข้อมูลของลูกค้ารายหนึ่ง จะได้ไม่กระทบข้อมูลของลูกค้ารายอื่นที่ยังใช้งานอยู่

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

ทบทวนหลักการ data processor และแนวทางการทำสัญญาประมวลผลข้อมูลอย่างเป็นทางการได้จากสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC) ที่ pdpc.or.th ซึ่งเผยแพร่แนวปฏิบัติและประกาศที่เกี่ยวข้องกับผู้ประมวลผลข้อมูลส่วนบุคคลไว้เป็นระยะ ควรกลับไปตรวจสอบทุกสามเดือนเนื่องจากแนวปฏิบัติของหน่วยงานอาจมีการปรับปรุงเพิ่มเติม