วิธีวางระบบ PDPA สำหรับ Agency สำหรับเอเจนซีและฟรีแลนซ์ทำเว็บไซต์แบบเป็นขั้นตอน

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

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

ทำไมเอเจนซีทำเว็บไซต์ถึงเป็น "ผู้ประมวลผลข้อมูล" ไม่ใช่เจ้าของข้อมูล

เมื่อรับงานสร้างเว็บไซต์ ระบบฟอร์มติดต่อ ระบบสมัครสมาชิก หรือเชื่อมต่อ CRM ให้ลูกค้า สิ่งที่เกิดขึ้นคือทีมงานเข้าไปสัมผัสข้อมูลส่วนบุคคลของลูกค้าปลายทางที่เป็นเจ้าของข้อมูลจริง เช่น ชื่อ เบอร์โทร อีเมล ที่อยู่จัดส่ง หรือพฤติกรรมการใช้งานผ่านเครื่องมือ Tracking ที่ติดตั้งไว้ ในความสัมพันธ์นี้ ลูกค้าที่ว่าจ้างเอเจนซีคือผู้ควบคุมข้อมูล (Data Controller) เพราะเป็นผู้ตัดสินใจว่าจะเก็บข้อมูลอะไร เก็บไปเพื่ออะไร และเก็บนานแค่ไหน ส่วนเอเจนซีหรือฟรีแลนซ์ที่ทำตามคำสั่งของลูกค้าเพื่อสร้างและดูแลระบบนั้น คือผู้ประมวลผลข้อมูล (Data Processor) ความแตกต่างนี้สำคัญเพราะภาระหน้าที่ตามกฎหมายของทั้งสองฝ่ายไม่เท่ากัน ผู้ควบคุมข้อมูลต้องรับผิดชอบเรื่องฐานทางกฎหมายในการเก็บข้อมูล การแจ้งสิทธิเจ้าของข้อมูล และการตอบสนองคำขอใช้สิทธิ ส่วนผู้ประมวลผลข้อมูลอย่างเอเจนซีมีหน้าที่หลักคือทำตามคำสั่งลูกค้าเท่านั้น ห้ามนำข้อมูลไปใช้นอกขอบเขตที่ตกลงกัน และต้องมีมาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสมกับข้อมูลที่ตนถืออยู่ ปัญหาที่พบบ่อยคือเอเจนซีจำนวนมากไม่เคยตกลงเรื่องนี้เป็นลายลักษณ์อักษรกับลูกค้าเลย ทำงานกันด้วยความไว้ใจปากเปล่า จนกระทั่งเกิดปัญหาแล้วถึงพบว่าไม่มีเอกสารใดยืนยันว่าใครต้องรับผิดชอบส่วนไหน

ขั้นตอนที่ 1: ทำสัญญาประมวลผลข้อมูล (DPA) กับลูกค้าให้ชัดเจนตั้งแต่ต้นโครงการ

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

ขั้นตอนที่ 2: จัดทำรายชื่อ Sub-processor และเปิดเผยให้ลูกค้ารู้ล่วงหน้า

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

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

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

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

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

ขั้นตอนที่ 5: ทำเช็คลิสต์ภายในทีมและตรวจซ้ำทุกโครงการใหม่

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

ข้อผิดพลาดที่พบบ่อยของเอเจนซีทำเว็บไซต์เรื่อง PDPA

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

สรุประบบ PDPA สำหรับเอเจนซีทำเว็บไซต์

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

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

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