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

การ Audit PDPA สำหรับ SME สาย SaaS ไม่ต้องเริ่มจากนโยบายหนา ๆ แบบองค์กรใหญ่ แต่ควรเริ่มจากไล่ดูว่าโปรดักต์เก็บข้อมูลอะไรบ้างในแต่ละจุด (signup, in-app tracking, billing, support ticket) แล้วจับคู่กับฐานทางกฎหมายที่ใช้ได้จริง เก็บหลักฐานเป็นสเปรดชีตหรือ เอกสารสั้น ๆ ที่คนคนเดียวในทีมดูแลต่อได้ และกำหนดรอบตรวจซ้ำทุกหกเดือนแทนการทำครั้งเดียวจบ เพื่อให้ทันกับฟีเจอร์ใหม่ที่ทีมโปรดักต์ปล่อยออกมาเรื่อย ๆ

บ่ายวันศุกร์ก่อนปิดสปรินต์ Nan หัวหน้าทีม Growth ของสตาร์ทอัพ SaaS ขนาด 12 คน เปิดสเปรดชีตลูกค้าเพื่อเตรียมส่งอีเมลแจ้งฟีเจอร์ใหม่ แล้วสะดุดกับคอลัมน์หนึ่งที่เก็บเบอร์โทร ของผู้ใช้ทดลองใช้งานฟรีไว้ตั้งแต่ปีที่แล้ว ไม่มีใครจำได้ว่าเก็บไว้ทำไม ทีม Engineering ก็ไม่แน่ใจว่า field นี้ยังถูกดึงไปใช้ที่ไหนในระบบบ้าง และไม่มีใครในบริษัทเคยตรวจสอบเรื่องนี้อย่างจริงจัง มาก่อนเลยตั้งแต่เปิดตัวโปรดักต์ ในบริษัทที่ไม่มีตำแหน่ง DPO เต็มเวลา เหตุการณ์แบบนี้เกิดขึ้นบ่อยกว่าที่คิด และเป็นเหตุผลว่าทำไม SME สาย SaaS ถึงต้องมีรอบ Audit PDPA ของตัวเอง แม้จะไม่มีทีมกฎหมายประจำก็ตาม

ทำไม SME สาย SaaS ต้อง Audit PDPA เป็นระยะ ไม่ใช่ทำครั้งเดียวจบ

โปรดักต์ SaaS มีลักษณะที่ต่างจากเว็บไซต์ทั่วไปตรงที่ฟีเจอร์เปลี่ยนแทบทุกสปรินต์ ทีม Engineering เพิ่ม tracking event ใหม่ ทีม Growth ต่อปลั๊กอินวิเคราะห์พฤติกรรมตัวใหม่ ทีม Product เปิด beta feature ที่ขอสิทธิ์เข้าถึงข้อมูลเพิ่มโดยไม่ได้ผ่านการตรวจสอบเรื่องข้อมูลส่วนบุคคลก่อน สิ่งที่เคยถูกตรวจแล้วว่าไม่มีปัญหาตอนเปิดตัวโปรดักต์ อาจไม่เป็นจริงอีกต่อไปหลังผ่านไปหกเดือน SME ที่ไม่มีคนดูแลเรื่องนี้เต็มเวลาจึงต้องอาศัยรอบ Audit ที่ทำได้จริงด้วยทรัพยากรจำกัด ไม่ใช่กระบวนการตรวจสอบระดับองค์กรใหญ่ที่ต้องใช้ทีมกฎหมายหลายคน เป้าหมายของการ Audit แบบ SME คือการรู้ตัวก่อนว่าระบบเก็บอะไรอยู่ ใครเข้าถึงได้ และมีเหตุผลรองรับหรือไม่ ไม่ใช่การทำเอกสารให้ดูสวยงาม

ขอบเขตการ Audit: ข้อมูลอะไรบ้างที่ SaaS ระดับ SME เก็บอยู่จริง

ก่อนเริ่ม Audit ต้องกำหนดขอบเขตให้ชัดว่าจะตรวจจุดไหนบ้าง เพราะโปรดักต์ SaaS มักเก็บข้อมูลกระจายอยู่หลายระบบ ไม่ได้อยู่ในฐานข้อมูลเดียว จุดที่ควรอยู่ในขอบเขตการ Audit ทุกครั้งมีดังนี้

• ข้อมูลตอนสมัครสมาชิก (signup) เช่น อีเมล ชื่อบริษัท ตำแหน่งงาน และข้อมูลที่ใช้ยืนยันตัวตนผ่าน OAuth
• ข้อมูลพฤติกรรมการใช้งานในระบบ (in-app tracking) ที่เก็บผ่านเครื่องมือวิเคราะห์อย่าง Mixpanel หรือ Amplitude
• ข้อมูลการเรียกเก็บเงิน (billing) ที่เชื่อมกับผู้ให้บริการชำระเงินภายนอก
• ข้อมูลในตั๋วซัพพอร์ต (support ticket) ที่ลูกค้าอาจแนบภาพหน้าจอหรือรายละเอียดที่มีข้อมูลส่วนบุคคลปนอยู่
• ข้อมูล log ระบบและ error tracking ที่บางครั้งบันทึกอีเมลหรือ user ID ของลูกค้าไว้โดยไม่ตั้งใจ

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

ขั้นตอน Audit ทีละขั้น สำหรับทีมที่ไม่มี DPO เต็มเวลา

1. ทำรายการ data flow ของแต่ละจุดที่เก็บข้อมูล — ไล่ตามขอบเขตด้านบนทีละจุด แล้วบันทึกลงสเปรดชีตว่าเก็บฟิลด์อะไร เก็บที่ไหน (ฐานข้อมูลหลัก, เครื่องมือวิเคราะห์, บริการชำระเงิน) และใครในทีมเข้าถึงได้บ้าง ขั้นนี้ใช้เวลามากที่สุดแต่เป็นฐานของทุกขั้นถัดไป
2. จับคู่แต่ละฟิลด์กับฐานทางกฎหมายที่ใช้ได้จริง — ข้อมูลบางอย่างใช้ฐานสัญญาได้ (เช่นอีเมลที่ใช้ส่งใบแจ้งหนี้) บางอย่างต้องขอความยินยอมแยก (เช่นการส่งอีเมลการตลาด) หากพบฟิลด์ที่ไม่มีฐานรองรับชัดเจน ให้ทำเครื่องหมายไว้เป็นจุดที่ต้องแก้ไข
3. ตรวจสิทธิ์เข้าถึงข้อมูลภายในทีม — ทีมเล็กมักให้สิทธิ์แอดมินเต็มระบบกับทุกคน เพราะสะดวก แต่ควรจำกัดว่าใครจำเป็นต้องเห็นข้อมูลลูกค้าดิบจริง ๆ เช่น ทีมซัพพอร์ตกับทีม Engineering ที่ดูแลระบบ ไม่จำเป็นต้องให้สิทธิ์เดียวกันกับทุกคนในบริษัท
4. ตรวจผู้ให้บริการภายนอกที่ประมวลผลข้อมูลแทน — เครื่องมือวิเคราะห์ ผู้ให้บริการชำระเงิน และระบบอีเมล ล้วนเป็นผู้ประมวลผลข้อมูลแทนบริษัท ควรมีรายชื่อผู้ให้บริการเหล่านี้พร้อมลิงก์ไปยังข้อตกลงการใช้งานหรือ DPA (Data Processing Agreement) ของแต่ละเจ้า
5. ทดสอบคำขอสิทธิ์ของเจ้าของข้อมูลจริงหนึ่งครั้ง — ลองส่งคำขอลบบัญชีทดสอบของตัวเองผ่านช่องทางที่ลูกค้าจริงใช้ แล้วดูว่าใช้เวลานานแค่ไหน ข้อมูลถูกลบออกจากระบบไหนบ้าง และมีระบบไหนที่ข้อมูลยังตกค้างอยู่
6. บันทึกผลและตั้งรอบตรวจครั้งถัดไป — สรุปสิ่งที่พบ สิ่งที่แก้แล้ว และสิ่งที่ยังต้องแก้ ลงเอกสารเดียวที่คนถัดไปในทีมอ่านต่อได้ พร้อมกำหนดวันที่จะ Audit รอบถัดไปไว้ล่วงหน้า

Evidence ที่ควรเก็บในแต่ละขั้นของการ Audit

จุดที่ทีม Product และ Engineering ของ SaaS มักมองข้าม

ฟีเจอร์ export ข้อมูลที่ทีม Product เพิ่มให้ลูกค้าองค์กรดาวน์โหลดรายงานเป็นไฟล์ CSV มักไม่ถูกนำเข้ามาอยู่ในขอบเขตการ Audit เลย ทั้งที่ไฟล์ export เหล่านี้อาจพ่วงข้อมูลผู้ใช้ปลายทางของลูกค้าองค์กรไปด้วย ไม่ใช่แค่ข้อมูลของบัญชีที่กดดาวน์โหลด อีกจุดที่มักถูกลืมคือ environment ทดสอบ (staging) ที่บางทีมยังคงใช้ข้อมูลลูกค้าจริงชุดเต็มในการทดสอบฟีเจอร์ใหม่ แทนที่จะใช้ข้อมูลจำลอง ซึ่งทำให้ขอบเขตความเสี่ยงขยายออกไปเกินระบบโปรดักชันโดยไม่มีใครสังเกต นอกจากนี้ third-party SDK ที่ฝังไว้ในแอปมือถือหรือหน้าเว็บ เช่น เครื่องมือวัดประสิทธิภาพหรือเครื่องมือแชทสด บางตัวส่งข้อมูลอุปกรณ์และพฤติกรรม ของผู้ใช้ไปยังเซิร์ฟเวอร์ของผู้ให้บริการโดยอัตโนมัติ ทีมเล็กที่ติดตั้งครั้งเดียวแล้วไม่เคยกลับมาตรวจซ้ำ จะไม่รู้ว่า SDK เวอร์ชันใหม่เก็บข้อมูลเพิ่มขึ้นจากตอนติดตั้งครั้งแรกหรือไม่

SME กับองค์กรใหญ่ทำ Audit PDPA ต่างกันตรงไหน

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

อีกความต่างที่สำคัญคือองค์กรใหญ่มักมีงบประมาณจ้างที่ปรึกษาภายนอกมาช่วยตรวจสอบ ขณะที่ SME ส่วนใหญ่ต้องทำเองด้วยเครื่องมือฟรี อย่างสเปรดชีตและปฏิทินตั้งเตือน วิธีที่ได้ผลคือกำหนดให้การ Audit เป็นส่วนหนึ่งของ ritual ทีมที่ทำอยู่แล้ว เช่น ผูกรอบตรวจเข้ากับรอบวางแผนไตรมาส ที่ทีม Product ทำอยู่แล้ว แทนที่จะสร้างกระบวนการใหม่แยกต่างหากที่ไม่มีใครจำได้ว่าต้องทำเมื่อไร

ตัวอย่างจริง: SaaS 12 คน ใช้เวลากี่ชั่วโมงในการ Audit รอบแรก

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

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

ข้อผิดพลาดที่พบบ่อยเมื่อ SME สาย SaaS ทำ Audit PDPA

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

สรุป: Audit ที่ทำได้จริงสำคัญกว่าเอกสารที่สมบูรณ์แบบ

SME สาย SaaS ไม่จำเป็นต้องมีกระบวนการ Audit ที่ซับซ้อนเท่าองค์กรใหญ่ สิ่งที่ต้องมีคือรายการ data flow ที่อัปเดตอยู่เสมอ รอบตรวจสิทธิ์เข้าถึงที่ทำจริง และการทดสอบคำขอสิทธิ์ของเจ้าของข้อมูลอย่างน้อยปีละครั้ง เอกสารไม่จำเป็นต้องยาวหรือใช้ศัพท์กฎหมายเยอะ ขอแค่เป็นสิ่งที่คนถัดไปในทีมหยิบขึ้นมาอ่านแล้วเข้าใจและทำต่อได้ ดูภาพรวมการทำ PDPA แบบ SME เพิ่มเติมได้ที่ คู่มือ PDPA สำหรับ SME สาย SaaS ฉบับเต็ม และหากยังไม่เคยเริ่มวางระบบมาก่อน แนะนำให้เริ่มจาก ขั้นตอนวิธีทำ PDPA สำหรับ SME สาย SaaS ก่อนเข้าสู่รอบ Audit นี้ ดูหมวดหมู่อื่นเพิ่มเติมได้ที่ ศูนย์ความรู้ธุรกิจและอุตสาหกรรม

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

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