PDPA สำหรับ Agency คืออะไร? คู่มือสำหรับเอเจนซีและฟรีแลนซ์ทำเว็บไซต์

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

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

เอเจนซีเป็น Data Processor ให้ลูกค้าหลายรายพร้อมกัน ความเสี่ยงจากการบริหารหลายสัญญา

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

Sub-processor ที่ใช้ร่วมกันหลายโปรเจกต์ ต้องแจ้งลูกค้าทุกรายหรือไม่

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

สิทธิ์เข้าถึงของทีมงานและฟรีแลนซ์ภายนอกที่เข้าออกโปรเจกต์บ่อย

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

Template และข้อมูลตัวอย่างที่หลงเหลือข้ามโปรเจกต์

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

DPA ที่ควรใช้เป็นมาตรฐานกับลูกค้าทุกราย

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

เมื่อเกิดเหตุการณ์ผิดปกติในระบบที่ดูแลอยู่หลายโปรเจกต์พร้อมกัน

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

ใบเสนอราคาและสัญญาที่ต้องระบุขอบเขต PDPA ตั้งแต่ขั้นตอนขายงาน

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

การนำไปใช้จริงร่วมกับระบบอื่น

เอเจนซีที่รับงานลูกค้าในอุตสาหกรรมต่างกันควรทำความเข้าใจเงื่อนไขเฉพาะของแต่ละกลุ่มลูกค้าด้วย ดูแนวทางสำหรับลูกค้ากลุ่ม SaaS ได้ที่ คู่มือ PDPA สำหรับ Agency ที่ดูแลลูกค้า SaaS และแนวทางสำหรับลูกค้ากลุ่มการเงินที่มีความเสี่ยงสูงกว่าได้ที่ คู่มือ PDPA สำหรับ Agency ที่ดูแลลูกค้าองค์กรการเงิน

หากต้องการตรวจสอบว่าเว็บไซต์ที่เอเจนซีดูแลตั้งค่าความเป็นส่วนตัวครบถ้วนหรือยัง ลองใช้ เครื่องมือตรวจสอบเว็บไซต์ฟรีของ trusty

การส่งมอบโปรเจกต์และสิ้นสุดสัญญา ข้อมูลของลูกค้าปลายทางไปอยู่ที่ไหนต่อ

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

คำถามที่พบบ่อย

เอเจนซีต้องแจ้งลูกค้าทุกรายเมื่อเปลี่ยน Sub-processor ที่ใช้ร่วมกันหลายโปรเจกต์หรือไม่

ต้องแจ้ง เพราะแต่ละสัญญาเป็นความสัมพันธ์แยกกันตามกฎหมาย แม้ Sub-processor จะเป็นเจ้าเดียวกันในหลายโปรเจกต์ก็ตาม

Template ที่ใช้ซ้ำหลายโปรเจกต์ควรจัดการข้อมูลตัวอย่างอย่างไร

ควรล้างข้อมูลตัวอย่างให้เป็น Data สมมติล้วน ๆ ก่อนบันทึกเป็น Template มาตรฐาน และห้ามใช้ Backup ที่มีข้อมูลจริงของลูกค้ารายหนึ่งไปเป็นฐานของโปรเจกต์อื่น

ฟรีแลนซ์ที่พ้นจากโปรเจกต์แล้วควรถูกตัดสิทธิ์เข้าถึงเมื่อไหร่

ควรตัดสิทธิ์ทันทีที่พ้นจากโปรเจกต์ ครอบคลุมทุกระบบที่เข้าถึงได้ ไม่ใช่แค่ปิดอีเมลบริษัท และควรมี Checklist Offboarding ที่ระบุระบบทั้งหมดไว้ล่วงหน้า

DPA ที่เอเจนซีใช้กับลูกค้าทุกรายควรมีอะไรบ้าง

ควรระบุขอบเขตการประมวลผล รายชื่อ Sub-processor ระยะเวลาเก็บและลบข้อมูล ขั้นตอนแจ้งเหตุการณ์ผิดปกติ และสิทธิ์เข้าถึงของทีมงานที่ดูแลโปรเจกต์นั้น

เหตุการณ์ผิดปกติที่เกิดกับ Sub-processor เดียว กระทบลูกค้าหลายรายพร้อมกันได้หรือไม่

ได้ หากช่องโหว่เกิดที่ Sub-processor หรือ Template ที่ใช้ร่วมกันหลายโปรเจกต์ เอเจนซีจึงควรมีเอกสาร Mapping ระหว่าง Sub-processor กับรายชื่อโปรเจกต์ที่ใช้งานอยู่เตรียมไว้ล่วงหน้า

เช็กลิสต์ปฏิบัติ

• ทำตาราง Requirement สรุปเงื่อนไขเฉพาะของแต่ละลูกค้าไว้ในที่เดียวสำหรับทีมตรวจสอบก่อนแก้ไข
• เก็บรายชื่อ Sub-processor มาตรฐานเป็นเอกสารกลาง และแจ้งลูกค้าทุกรายเมื่อมีการเปลี่ยนแปลง
• ทำ Checklist Offboarding ที่ตัดสิทธิ์เข้าถึงทุกระบบทันทีที่บุคคลพ้นจากโปรเจกต์
• ล้างข้อมูลตัวอย่างให้เป็น Data สมมติก่อนบันทึกเป็น Template สำหรับใช้ซ้ำ
• ใช้ DPA มาตรฐานเดียวกันกับลูกค้าทุกราย ปรับเฉพาะเงื่อนไขที่จำเป็นต้องต่างกัน
• ทำเอกสาร Mapping ระหว่าง Sub-processor กับโปรเจกต์ที่ใช้งานอยู่ และอัปเดตให้ตรงความเป็นจริง

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

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

สรุป

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

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

• สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC)
• พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562