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

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

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

ทำไม Agency มักเป็น "ผู้ประมวลผล" ไม่ใช่ "ผู้ควบคุม"

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

เช็กลิสต์ก่อนเปิดใช้งานเว็บไซต์ให้ลูกค้า

1. มีข้อตกลงประมวลผลข้อมูล (Data Processing Agreement) กับลูกค้าเป็นลายลักษณ์อักษร ไม่ใช่แค่คุยปากเปล่าหรือฝังอยู่ในอีเมลกระจัดกระจาย
2. DPA ระบุขอบเขตชัดว่าเอเจนซีเก็บข้อมูลอะไรบ้าง เก็บไว้ที่ไหน เข้าถึงได้ใครบ้างในทีม
3. รายชื่อเครื่องมือ/ผู้ให้บริการภายนอกที่แตะข้อมูลลูกค้า (โฮสติ้ง อีเมลมาร์เกตติ้ง แชทบอท เครื่องมือวิเคราะห์) ถูกเปิดเผยให้ลูกค้ารับทราบครบทุกตัว
4. มีขั้นตอนแจ้งเตือนลูกค้าก่อนเพิ่มหรือเปลี่ยนผู้ให้บริการภายนอกรายใหม่ระหว่างโครงการ
5. มีแผนที่เขียนไว้ล่วงหน้าว่าเมื่อจบสัญญาจะคืนหรือลบข้อมูลลูกค้าอย่างไร ภายในกี่วัน
6. มีวิธีเก็บหลักฐานการลบข้อมูล เช่น log การลบ หรือใบยืนยันจากผู้ให้บริการโฮสติ้ง
7. สัญญาระบุขอบเขตความรับผิดชัดเจนว่ากรณีข้อมูลรั่วไหลจากระบบของเอเจนซีเอง กับกรณีลูกค้าสั่งให้ทำสิ่งที่ผิดกฎหมายตั้งแต่ต้น แยกความรับผิดชอบกันอย่างไร
8. มีขั้นตอนแจ้งเหตุละเมิดข้อมูลให้ลูกค้าทราบภายในกรอบเวลาที่ตกลงกัน ไม่ปล่อยให้ลูกค้ารู้ทีหลังจากช่องทางอื่น
9. ทีมงานที่เข้าถึงข้อมูลลูกค้าได้รับการอบรมพื้นฐานเรื่องการจัดการข้อมูลส่วนบุคคล ไม่ใช่แค่ผู้บริหารที่รู้เรื่องนี้คนเดียว

สิ่งที่ต้องระบุใน DPA กับลูกค้า

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

การเปิดเผย Sub-processor เมื่อ Agency ใช้เครื่องมือของบุคคลที่สาม

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

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

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

ขอบเขตความรับผิดเมื่อเกิดเหตุข้อมูลรั่วไหล

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

ข้อผิดพลาดที่พบบ่อย

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

สรุป

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

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

อ้างอิงแนวปฏิบัติจากสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC) ที่ pdpc.or.th เป็นหลัก ทีมที่ต้องการรายละเอียดเชิงปฏิบัติเพิ่มเติมสามารถอ่านคู่มือขั้นตอนทำ PDPA สำหรับ Agency แบบ How-to และแนวทางตรวจสอบแบบ Audit เพิ่มเติมได้ที่ คู่มือขั้นตอน PDPA สำหรับ Agency และ แนวทางตรวจสอบ PDPA สำหรับ Agency รวมถึงหมวดความรู้ธุรกิจและ SEO ภาพรวมที่ ศูนย์ความรู้ธุรกิจ อุตสาหกรรม และ SEO ควรทบทวนแนวปฏิบัติซ้ำทุก 6 เดือนตามความเสี่ยงด้านความทันสมัยของหัวข้อนี้