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

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

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

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

ทำไมลูกค้าองค์กรการเงินและประกันตรวจเอเจนซี่ต่างจากลูกค้าทั่วไป

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

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

ขั้นที่ 1: ร่างสัญญา Data Processing Agreement ที่ระบุขอบเขตชัดเจน

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

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

ขั้นที่ 2: จัดทำรายชื่อ Sub-processor ที่พร้อมเปิดเผยได้ทุกเมื่อ

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

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

ขั้นที่ 3: วางกระบวนการแจ้งเหตุละเมิดข้อมูลให้ตอบสนองเร็วพอ

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

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

ขั้นที่ 4: วางแผนคืนหรือลบข้อมูลเมื่อสัญญาสิ้นสุดพร้อมหลักฐาน

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

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

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

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

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

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

ข้อผิดพลาดที่พบบ่อยเมื่อวางระบบ

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

สรุป

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

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

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