trusty — Website Trust Platform
Business, Industry & SEO

เช็กลิสต์ PDPA สำหรับ E-commerce สำหรับเอเจนซีและฟรีแลนซ์ทำเว็บไซต์: ต้องตรวจอะไรบ้างก่อนเปิดใช้งาน

เว็บอีคอมเมิร์ซที่ทีมพัฒนาส่งมอบให้ลูกค้า มักมีจุดเสี่ยง PDPA ซ่อนอยู่ในฟอร์มเช็กเอาต์และการจัดเก็บข้อมูล เช็กลิสต์นี้รวมสิ่งที่ต้องตรวจก่อนกดเปิดใช้งานจริง

📅 เผยแพร่ 26 กรกฎาคม 2569อัปเดตล่าสุด 26 กรกฎาคม 2569✍️ เขียนโดย trusty Editorial Team⏱ อ่าน 8 นาที
Three diverse business professionals collaborating indoors, focusing on teamwork.
ภาพโดย Mikhail Nilov จาก Pexels

💬 สรุปสั้น ๆ

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

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

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

ทำไมเอเจนซีต้องดูแลจุดนี้เอง ไม่ใช่รอลูกค้าสั่ง

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

เช็กก่อนส่งมอบ: ฟอร์มเช็กเอาต์และข้อมูลชำระเงิน

  • ฟอร์มเช็กเอาต์เก็บเฉพาะฟิลด์ที่จำเป็นต่อการจัดส่งและออกใบกำกับภาษี เช่น ชื่อ ที่อยู่ เบอร์โทร อีเมล ไม่มีช่องเลขบัตรประชาชนหรือวันเกิดที่ไม่ได้ใช้งานจริง
  • ข้อมูลบัตรเครดิต/เดบิตไม่ถูกเก็บไว้ในฐานข้อมูลของร้านเองโดยตรง แต่ส่งผ่าน payment gateway ที่มีใบรับรอง PCI-DSS แยกต่างหาก
  • ทีมพัฒนาไม่เข้าใจผิดว่าการใช้ gateway ที่ผ่าน PCI-DSS แล้วเท่ากับร้านทำ PDPA ครบถ้วนไปด้วย เพราะสองมาตรฐานนี้ดูแลคนละเรื่อง — PCI-DSS ดูแลความปลอดภัยของข้อมูลบัตร ส่วน PDPA ดูแลการเก็บ ใช้ เปิดเผยข้อมูลส่วนบุคคลของลูกค้าทั้งระบบ
  • มีการเข้ารหัสข้อมูลระหว่างส่ง (HTTPS/TLS) ทุกหน้าที่มีการกรอกข้อมูลส่วนบุคคล ไม่เฉพาะหน้าชำระเงิน
  • สิทธิ์เข้าถึงฐานข้อมูลคำสั่งซื้อจำกัดเฉพาะทีมที่จำเป็นต้องใช้งานจริง ไม่ใช่ทุกคนในทีมพัฒนาเข้าถึงได้หมด

ตารางเทียบสั้น ๆ: PDPA กับ PCI-DSS ต่างกันตรงไหน

ประเด็นPDPAPCI-DSS
ขอบเขตข้อมูลข้อมูลส่วนบุคคลของลูกค้าทั้งระบบ เช่น ชื่อ ที่อยู่ พฤติกรรมการซื้อเฉพาะข้อมูลบัตรชำระเงิน เช่น หมายเลขบัตรและวันหมดอายุ
สถานะกฎหมายไทยที่บังคับใช้กับผู้ควบคุมข้อมูลทุกรายมาตรฐานที่กำหนดโดยเครือข่ายบัตรชำระเงิน ไม่ใช่กฎหมาย
ผู้รับผิดชอบหลักร้านค้าในฐานะผู้ควบคุมข้อมูลร้านค้าและ payment gateway ร่วมกันตามขอบเขตที่ตกลงไว้ในสัญญา

เช็กก่อนส่งมอบ: ที่อยู่จัดส่งและคำสั่งซื้อที่ยกเลิก

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

เช็กก่อนส่งมอบ: ความยินยอมรับข่าวสารการตลาด

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

ข้อมูลลูกค้าประจำและประวัติการสั่งซื้อสะสม: จุดต่างจากเว็บทั่วไป

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

พร้อมตรวจสอบความน่าเชื่อถือของเว็บไซต์คุณหรือยัง?

ทดลองใช้งาน trusty ฟรี ไม่ต้องใช้บัตรเครดิต เริ่มสแกนได้ทันที

ทดลองใช้งานระบบฟรี

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

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

เช็กก่อนส่งมอบ: เอกสารส่งมอบให้ลูกค้า

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

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

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

สรุปเช็กลิสต์ก่อนเปิดใช้งาน

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

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

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

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

ถ้าลูกค้าไม่ได้ร้องขอเรื่อง PDPA เอเจนซีต้องทำเช็กลิสต์นี้เองไหม

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

PCI-DSS กับ PDPA ต่างกันตรงไหนสำหรับเว็บอีคอมเมิร์ซ

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

guest checkout ต้องขอความยินยอมแบบเดียวกับสมาชิกไหม

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

ควรเก็บข้อมูลคำสั่งซื้อที่ถูกยกเลิกไว้นานแค่ไหน

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

อ่านต่อในหัวข้อเดียวกัน

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

พร้อมตรวจสอบความน่าเชื่อถือของเว็บไซต์คุณหรือยัง?

ทดลองใช้งาน trusty ฟรี ไม่ต้องใช้บัตรเครดิต เริ่มสแกนได้ทันที