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

ทีม SaaS จำนวนมากเชื่อว่าเมื่อเลือกผู้ให้บริการรับชำระเงินที่ผ่านมาตรฐาน PCI-DSS อย่าง Stripe หรือ Omise มาติดตั้งที่หน้า checkout แล้ว เรื่องข้อมูลส่วนบุคคลของลูกค้าตรงจุดนั้นก็ถือว่าจบไปพร้อมกัน ความเชื่อนี้ผิดตั้งแต่ต้น เพราะ PCI-DSS เป็นมาตรฐานความปลอดภัยเฉพาะข้อมูลบัตรเครดิตที่ผู้ให้บริการรับชำระเงินต้องปฏิบัติตาม ไม่ได้ครอบคลุมชื่อ อีเมล เบอร์โทร ที่อยู่จัดส่งใบเสร็จ หรือประวัติการสมัครทดลองใช้งานที่ระบบของทีม SaaS เองเก็บไว้คู่ขนานกัน เมื่อหน้า checkout ของผลิตภัณฑ์ทำหน้าที่เหมือนร้านค้าออนไลน์ที่ขายแพ็กเกจสมัครสมาชิกโดยตรง ทีม Product, Engineering, Growth และ Privacy ต้องแยกสองเรื่องนี้ออกจากกันให้ชัด แล้ววางระบบ PDPA สำหรับข้อมูลธุรกรรมที่เกิดขึ้นทั้งหมดเอง

PDPA สำหรับ E-commerce ของธุรกิจ SaaS ที่ขายสมัครใช้งานผ่านหน้า checkout ของตัวเอง ไม่ใช่เรื่องเดียวกับการผ่านมาตรฐาน PCI-DSS ของผู้ให้บริการรับชำระเงิน เพราะ PCI-DSS คุ้มครองเฉพาะข้อมูลบัตร ส่วน PDPA ครอบคลุมข้อมูลส่วนบุคคลทั้งหมดที่เก็บระหว่างขั้นตอนสมัครและชำระเงิน ทีมต้องลดข้อมูลที่เก็บให้เหลือเท่าที่จำเป็น กำหนดระยะเวลาเก็บข้อมูลบัญชีทดลองที่ไม่ต่ออายุ และแยกความยินยอมรับข่าวสารการตลาดออกจากขั้นตอนสมัครใช้งานให้ชัดเจน

ทำไม PCI-DSS ถึงไม่ใช่คำตอบของ PDPA

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

ขั้นตอนที่ 1 ลดข้อมูลที่เก็บที่หน้า checkout ให้เหลือเท่าที่จำเป็นจริง

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

ขั้นตอนที่ 2 แยกขอบเขตข้อมูลบัตรกับข้อมูลส่วนบุคคลอื่นให้ชัด

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

ขั้นตอนที่ 3 กำหนดระยะเวลาเก็บข้อมูลบัญชีทดลองที่ไม่ต่ออายุ

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

ขั้นตอนที่ 4 จัดการข้อมูลของผู้สมัครทดลองใช้แบบไม่ผูกบัตร

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

ขั้นตอนที่ 5 แยกความยินยอมรับข่าวสารการตลาดออกจากการสมัครใช้งาน

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

ขั้นตอนที่ 6 ผูกรอบตรวจสอบ checkout เข้ากับรอบพัฒนาฟีเจอร์ใหม่

เมื่อทีม Growth ทดลอง A/B test หน้าสมัครใช้งานบ่อยครั้ง ฟิลด์ข้อมูลที่เก็บอาจเปลี่ยนแปลงได้ตลอดเวลาโดยไม่มีใครแจ้งทีม Privacy ล่วงหน้า แนวทางที่ป้องกันปัญหานี้คือกำหนดว่าการเปลี่ยนแปลงฟอร์ม checkout หรือหน้าสมัครใช้งานทุกครั้งต้องผ่านการตรวจสอบสั้น ๆ ว่ามีการเพิ่มฟิลด์ข้อมูลส่วนบุคคลใหม่หรือไม่ ก่อนขึ้น production เหมือนขั้นตอนตรวจสอบความปลอดภัยที่ทีม Security ทำเป็นประจำ

ตัวอย่าง: ฟอร์มสมัครทดลองใช้ที่เพิ่มฟิลด์โดยไม่ตั้งใจ

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

ข้อผิดพลาดที่พบบ่อยเมื่อ SaaS วางระบบ PDPA สำหรับ checkout

• เข้าใจว่าผ่าน PCI-DSS แล้วเท่ากับข้อมูลส่วนบุคคลที่หน้า checkout ปลอดภัยตาม PDPA ไปด้วย
• เก็บฟิลด์ข้อมูลเสริมเพื่อการตลาดไว้ในฟอร์มสมัครใช้งานโดยบังคับกรอกตั้งแต่ต้น
• ปล่อยให้บัญชีทดลองที่ไม่ต่ออายุค้างอยู่ในระบบถาวรโดยไม่มีกำหนดลบ
• ใช้ช่องติ๊กเดียวรวมการยอมรับเงื่อนไขบริการกับการรับข่าวสารการตลาดไว้ด้วยกัน
• เปลี่ยนฟิลด์ในฟอร์ม checkout ระหว่างทำ A/B test โดยไม่แจ้งทีม Privacy ก่อน launch

สรุป

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

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

ขอบเขตของกฎหมายคุ้มครองข้อมูลส่วนบุคคลที่ใช้กับข้อมูลลูกค้าและธุรกรรมออนไลน์ ควรตรวจสอบกับประกาศและแนวปฏิบัติของ สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC) โดยตรง ส่วนข้อกำหนดเรื่องความปลอดภัยของข้อมูลบัตรเครดิตเป็นคนละมาตรฐานที่ต้องตรวจสอบแยกจากผู้ให้บริการรับชำระเงินของตัวเอง คู่มือนี้เป็นแนวทางเชิงปฏิบัติสำหรับทีม Product, Engineering, Growth และ Privacy ไม่ใช่การตีความข้อกำหนดทางกฎหมายแทนหน่วยงานกำกับดูแล ดูภาพรวมหัวข้ออื่นในหมวด Business, Industry & SEO เพิ่มเติมได้ที่ คลังความรู้ Business, Industry & SEO