วิธี Audit PDPA สำหรับ E-commerce ของธุรกิจ SaaS สตาร์ทอัพ และบริษัทเทคโนโลยี พร้อม Evidence ที่ควรเก็บ

บ่ายวันหนึ่งก่อนปิดรอบระดมทุน Series A ทีม Finance ของ SaaS สตาร์ทอัพรายหนึ่งที่ขายแพ็กเกจ Add-on และอุปกรณ์เสริมผ่านหน้า Checkout ของตัวเอง เปิดฐานข้อมูลลูกค้าขึ้นมาเตรียมตอบคำถามนักลงทุนเรื่อง Data Governance แล้วพบว่าตารางคำสั่งซื้อเก็บเลขบัตรเครดิตบางส่วนไว้เป็น Plain Text ในฟิลด์ Note ที่ทีม Support ใช้จดบันทึกเวลาโทรช่วยลูกค้า ทั้งที่ระบบชำระเงินหลักผ่าน Payment Gateway ที่ได้มาตรฐานอยู่แล้ว ปัญหาไม่ได้อยู่ที่ Gateway แต่อยู่ที่กระบวนการภายในที่ไม่มีใครเคย Audit มาก่อนว่าทีม Support เก็บอะไรไว้บ้างนอกระบบหลัก เหตุการณ์แบบนี้ไม่ใช่เรื่องแปลก เพราะทีม SaaS ส่วนใหญ่มองว่าเลือก Payment Gateway ที่น่าเชื่อถือแล้วก็เพียงพอ โดยไม่เคยไล่ตรวจว่าข้อมูลลูกค้าไหลไปที่ไหนบ้างนอกเหนือจากจุดชำระเงินหลัก

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

เรื่องที่ 1: ตรวจว่าหน้า Checkout เก็บข้อมูลเกินความจำเป็นหรือไม่

ทีม Product มักเพิ่มฟิลด์ในหน้า Checkout ทีละนิดตามคำขอของทีมขายหรือทีม Growth เช่น เพิ่มช่องกรอกตำแหน่งงาน เพิ่มช่องเบอร์โทรสำรอง หรือเพิ่มช่องวันเกิดเพื่อใช้ส่งโปรโมชันวันเกิดในอนาคต โดยไม่มีใครตั้งคำถามว่าฟิลด์เหล่านี้จำเป็นต่อการทำรายการซื้อขายจริงหรือไม่ การ Audit ต้องไล่ทีละฟิลด์ในฟอร์ม Checkout แล้วถามว่าถ้าตัดฟิลด์นี้ออก การทำรายการซื้อยังสำเร็จได้หรือไม่ ถ้าคำตอบคือได้ ฟิลด์นั้นควรย้ายไปเป็นข้อมูลเสริมที่กรอกทีหลังในหน้าโปรไฟล์แทน ไม่ใช่บังคับกรอกตั้งแต่ขั้นตอนจ่ายเงิน

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

เรื่องที่ 2: แยก PDPA กับ PCI-DSS ให้ชัดในการตรวจข้อมูลการชำระเงิน

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

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

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

ที่อยู่จัดส่งเป็นข้อมูลที่ SaaS หลายรายเก็บไว้ถาวรโดยไม่เคยกำหนดรอบลบ ทั้งที่คำสั่งซื้อเสร็จสมบูรณ์และสินค้าถูกส่งไปแล้วนานหลายปี การ Audit ต้องตรวจว่ามีนโยบายกำหนดระยะเวลาเก็บที่อยู่จัดส่งไว้ชัดเจนหรือไม่ เช่น เก็บไว้ตามระยะเวลาที่กฎหมายภาษีหรือกฎหมายบัญชีกำหนด แล้วหลังจากนั้นควรมีกระบวนการลบหรือทำให้ข้อมูลไม่สามารถระบุตัวบุคคลได้ อีกจุดที่มักถูกมองข้ามคือคำสั่งซื้อที่ลูกค้ากรอกที่อยู่และข้อมูลบัตรไว้แล้วแต่ไม่กดยืนยันจนสุดท้าย หรือที่เรียกว่า Abandoned Cart ข้อมูลชุดนี้มักถูกเก็บไว้ในระบบ Analytics หรือ Marketing Automation เพื่อใช้ยิงอีเมลตามตื้อ โดยไม่มีใครกำหนดว่าจะเก็บไว้นานแค่ไหนก่อนต้องลบทิ้ง

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

เรื่องที่ 4: ตรวจว่าความยินยอมด้านการตลาดแยกออกจากการซื้อสินค้าจริงหรือไม่

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

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

ตัวอย่าง: ระบบ Checkout ที่เอกสารเขียนถูกแต่ของจริงไม่ตรง

ทีมผลิตภัณฑ์ SaaS ด้าน HR รายหนึ่งเปิดขายคอร์สอบรมออนไลน์เป็นสินค้าเสริมผ่านหน้า Checkout ของตัวเอง เอกสาร Privacy Policy เขียนไว้ชัดเจนว่าการสมัครรับข่าวสารเป็นทางเลือกแยกจากการซื้อสินค้า แต่เมื่อทีม Privacy ทดสอบซื้อจริงกลับพบว่าช่องรับข่าวสารถูกติ๊กไว้ล่วงหน้าโดยอัตโนมัติ และไม่มีทางยกเลิกจากหน้า Checkout ได้เลยนอกจากต้องกดลิงก์ยกเลิกในอีเมลฉบับแรกที่ได้รับ เหตุการณ์นี้เกิดจากทีม Front-end ที่พัฒนาฟีเจอร์นี้ไม่เคยเห็นเอกสาร Privacy Policy ฉบับล่าสุดเลย เพราะทีม Legal อัปเดตเอกสารแยกต่างหากโดยไม่ได้แจ้งทีมพัฒนาให้ปรับโค้ดตาม ลูกค้าองค์กรรายหนึ่งที่กำลังพิจารณาซื้อแพ็กเกจระดับองค์กรตั้งข้อสังเกตเรื่องนี้ระหว่างการตรวจสอบก่อนเซ็นสัญญา และขอให้แก้ไขก่อนจึงจะดำเนินการต่อ

Evidence ที่ควรเก็บไว้จากการ Audit แต่ละรอบ

เพื่อให้ตอบคำถามลูกค้าองค์กรหรือผู้ตรวจสอบได้เร็ว ทีมควรเก็บรายการฟิลด์ข้อมูลทั้งหมดที่ฟอร์ม Checkout เก็บไว้พร้อมเหตุผลความจำเป็นของแต่ละฟิลด์ บันทึกผลตรวจว่าข้อมูลบัตรชำระเงินไม่ได้ถูกเก็บไว้นอกระบบ Gateway ที่ผ่านมาตรฐาน PCI-DSS บันทึกรอบลบข้อมูลที่อยู่จัดส่งและ Abandoned Cart พร้อมวันที่ดำเนินการ และ Log การให้หรือถอนความยินยอมด้านการตลาดที่แยกจากการยืนยันคำสั่งซื้อของผู้ใช้แต่ละราย ดูขั้นตอนตรวจก่อนเปิดใช้งานฟีเจอร์ Checkout ใหม่ได้ที่ เช็กลิสต์ PDPA สำหรับ E-commerce ของ SaaS และดูขั้นตอนวางระบบทั้งหมดตั้งแต่ต้นได้ที่ วิธีทำ PDPA สำหรับ E-commerce ของ SaaS

ข้อผิดพลาดที่พบบ่อยระหว่าง Audit หน้า Checkout

• เข้าใจว่าผ่านมาตรฐาน PCI-DSS ของ Payment Gateway แล้วเท่ากับข้อมูลส่วนบุคคลอื่นปลอดภัยตาม PDPA ไปด้วย
• ปล่อยให้ทีม Support Export ประวัติการสั่งซื้อเป็นไฟล์ Excel โดยไม่ควบคุมสิทธิ์เข้าถึงไฟล์นั้น
• ไม่มีรอบลบข้อมูล Abandoned Cart ที่ไม่มีการโต้ตอบต่อเนื่องหลายปี
• ติ๊กช่องรับข่าวสารการตลาดไว้ล่วงหน้าโดยอัตโนมัติในหน้า Checkout

สรุป

การ Audit PDPA สำหรับ E-commerce ของ SaaS ที่ได้ผลจริงต้องมองข้ามการมี Payment Gateway ที่น่าเชื่อถือไปตรวจว่าข้อมูลลูกค้าไหลไปที่ไหนบ้างนอกจุดชำระเงินหลัก ทั้งฟิลด์ที่เก็บเกินจำเป็นในหน้า Checkout ขอบเขตระหว่าง PDPA กับ PCI-DSS รอบลบข้อมูลที่อยู่จัดส่งและ Abandoned Cart และการแยกความยินยอมการตลาดออกจากการซื้อ ทีมที่ทำ Audit แบบนี้เป็นรอบสม่ำเสมอจะลดโอกาสที่ลูกค้าองค์กรจะพบช่องว่างเองระหว่างตรวจสอบก่อนเซ็นสัญญา ดูภาพรวมหัวข้ออื่นในหมวด Business, Industry & SEO เพิ่มเติมได้ที่ คลังความรู้ Business, Industry & SEO

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

รายละเอียดเรื่องฐานทางกฎหมายและขอบเขตข้อมูลส่วนบุคคลที่ธุรกิจ E-commerce ต้องดูแล ควรตรวจสอบเทียบกับแนวปฏิบัติของ สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC) โดยตรง ส่วนข้อกำหนดเรื่องความปลอดภัยของข้อมูลบัตรชำระเงินเป็นมาตรฐาน PCI-DSS ซึ่งเป็นคนละกรอบกับ PDPA และควรตรวจสอบแยกกับผู้ให้บริการ Payment Gateway ของธุรกิจ บทความนี้เป็นแนวทางเชิงปฏิบัติสำหรับทีม Product, Engineering, Growth และ Privacy Team ไม่ใช่การตีความข้อกำหนดทางกฎหมายแทนหน่วยงานกำกับดูแล