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

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

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

ทำไมเรื่องนี้ต้องเป็นหน้าที่ของทีมพัฒนา ไม่ใช่รอลูกค้าสั่ง

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

ขั้นตอนที่ 1: สำรวจและจัดหมวดข้อมูลที่ระบบเก็บจริง

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

ขั้นตอนที่ 2: ออกแบบฟอร์มเช็กเอาต์ให้เก็บเฉพาะข้อมูลที่จำเป็น

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

ขั้นตอนที่ 3: แยกขอบเขต PDPA ออกจากมาตรฐาน PCI-DSS อย่างชัดเจน

ทีมพัฒนาจำนวนไม่น้อยเข้าใจผิดว่าการต่อ payment gateway ที่ผ่านมาตรฐาน PCI-DSS แล้วเท่ากับทำ PDPA ครบไปด้วย ทั้งที่สองมาตรฐานนี้ดูแลคนละเรื่องกัน ขั้นตอนนี้คือการตรวจสอบให้แน่ใจว่าข้อมูลบัตรเครดิต/เดบิตของลูกค้าไม่ถูกเก็บไว้ในฐานข้อมูลของร้านเองเลย แต่ส่งผ่าน gateway ที่มีใบรับรองแยกต่างหาก ส่วนข้อมูลอื่นทั้งหมดของลูกค้า เช่น ชื่อ ที่อยู่ ประวัติการสั่งซื้อ ยังอยู่ในขอบเขตของ PDPA ที่ทีมต้องดูแลเอง

ตารางเทียบขอบเขตความรับผิดชอบ

ขั้นตอนที่ 4: ออกแบบช่องยินยอมรับข่าวสารการตลาดแยกจากการยืนยันคำสั่งซื้อ

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

ขั้นตอนที่ 5: กำหนดรอบเก็บและลบข้อมูลสำหรับคำสั่งซื้อที่สำเร็จและที่ถูกยกเลิก

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

ขั้นตอนที่ 6: ตรวจสอบผู้ให้บริการภายนอกที่เข้าถึงข้อมูลลูกค้า

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

ข้อมูลสมาชิกสะสมและพฤติกรรมการซื้อ: จุดที่มักถูกมองข้ามหลังขึ้นระบบไปแล้ว

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

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

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

ข้อผิดพลาดที่พบบ่อยเมื่อวางระบบ PDPA ให้ลูกค้าอีคอมเมิร์ซ

ข้อผิดพลาดแรกคือใส่ฟิลด์ข้อมูลตามเทมเพลตสำเร็จรูปโดยไม่ตัดส่วนที่ไม่จำเป็นออกเลย เพราะคิดว่ามีไว้ก่อนอาจมีประโยชน์ภายหลัง ข้อผิดพลาดที่สองคือเข้าใจผิดว่าต่อ payment gateway ที่ผ่าน PCI-DSS แล้วคือทำ PDPA เสร็จสมบูรณ์ ทั้งที่เป็นคนละขอบเขตกัน ข้อผิดพลาดที่สามคือออกแบบช่องยินยอมรับข่าวสารให้ติ๊กไว้ล่วงหน้าเพื่อเพิ่มยอดสมาชิกอีเมล ซึ่งขัดกับหลักการขอความยินยอมที่แท้จริง และข้อผิดพลาดสุดท้ายคือไม่มีเอกสารสรุปการเก็บข้อมูลส่งมอบให้ลูกค้าเลย ทำให้เมื่อถูกฝ่ายกฎหมายของลูกค้าถามในนาทีสุดท้าย ทีมพัฒนาตอบไม่ได้และต้องเลื่อนวันขึ้นระบบออกไปเหมือนกรณีที่ยกมาต้นบทความ

สรุปขั้นตอนวางระบบ PDPA สำหรับ E-commerce

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

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

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