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

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

เช็กลิสต์นี้รวมสิ่งที่ทีมองค์กร ฝ่ายกฎหมาย Privacy Security และ Compliance ของเอเจนซี่ต้องตรวจให้ครบก่อนเปิดใช้งานระบบทำงานร่วมกับลูกค้ากลุ่มการเงิน ประกัน หรือธุรกิจความเสี่ยงสูง ไม่ใช่แค่ก่อนเซ็นสัญญาเท่านั้น

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

1. มี Data Processing Agreement ที่ระบุขอบเขตชัดเจนกับลูกค้าแล้วหรือยัง

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

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

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

2. เปิดเผยรายชื่อ Sub-processor ที่เอเจนซี่ใช้งานจริงครบถ้วนหรือยัง

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

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

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

3. วางกระบวนการลบหรือคืนข้อมูลเมื่อจบสัญญาไว้ล่วงหน้าหรือยัง

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

ในทางปฏิบัติ ทีมควรกำหนดกรอบเวลาให้ชัดเจนเป็นตัวเลข เช่น ต้องคืนข้อมูลหรือลบข้อมูลภายในกี่วันทำการหลังวันสิ้นสุดสัญญา และต้องลบสำเนาสำรอง (backup) ที่อาจกระจายอยู่หลายระบบภายในกรอบเวลาเดียวกัน ไม่ใช่ลบเฉพาะฐานข้อมูลหลักแล้วปล่อยให้สำเนาสำรองค้างอยู่ตามรอบ retention เดิมของระบบ Backup เอกสารยืนยันการลบควรระบุวันที่ลบจริง วิธีการลบ และผู้รับผิดชอบลงนามยืนยัน เพื่อให้ลูกค้าใช้เป็นหลักฐานประกอบการตรวจสอบภายในของตัวเองได้ต่อ

4. กำหนดสิทธิ์เข้าถึงข้อมูลตามบทบาทหน้าที่จริงแล้วหรือยัง

ก่อนเปิดใช้งานระบบ ทีมควรกำหนดให้ชัดว่าใครในเอเจนซี่มีสิทธิ์เข้าถึงข้อมูลของลูกค้ารายนี้ได้บ้าง โดยอิงจากบทบาทหน้าที่จริงในงาน ไม่ใช่เปิดสิทธิ์ให้ทั้งทีมเข้าถึงได้เพราะสะดวกกว่า เช่น จำกัดให้เฉพาะทีม Media Buying และ Data Analyst ที่ทำงานกับบัญชีนี้โดยตรงเท่านั้นที่เข้าถึงไฟล์ Segment ได้ ส่วนทีม Creative ที่ไม่จำเป็นต้องเห็นข้อมูลระบุตัวตนควรได้รับเฉพาะข้อมูลสรุปที่ไม่ระบุตัวบุคคล

5. ตกลงขั้นตอนแจ้งเหตุเมื่อข้อมูลรั่วไหลไว้ล่วงหน้ากับลูกค้าแล้วหรือยัง

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

เส้นแบ่งความรับผิดระหว่างผู้ควบคุมข้อมูลกับผู้ประมวลผลข้อมูลอยู่ตรงไหน

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

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

ข้อผิดพลาดที่พบบ่อยก่อนเปิดใช้งานระบบกับลูกค้ากลุ่มนี้

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

สรุป

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

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

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