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

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

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

Audit ข้อมูลส่วนบุคคลต่างจากการตรวจเอกสารกฎหมายอย่างไร

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

ขั้นตอนที่ 1: ไล่รายการฟิลด์ข้อมูลที่เว็บไซต์เก็บจริง

เริ่มจากไล่ทุกฟอร์มบนเว็บไซต์และแอปพลิเคชัน ตั้งแต่หน้าสมัครสมาชิก หน้าตั้งค่าโปรไฟล์ หน้าชำระเงิน ไปจนถึงฟอร์มติดต่อฝ่ายขาย แล้วบันทึกว่าแต่ละฟอร์มเก็บฟิลด์อะไรบ้าง เช่น ชื่อ อีเมล เบอร์โทร ตำแหน่งงาน ชื่อบริษัท หมายเลขบัตรที่ถูกส่งผ่าน Payment Gateway หรือไฟล์ที่ผู้ใช้อัปโหลด เช่น เอกสารยืนยันตัวตนในฟีเจอร์ KYC อย่าลืมฟิลด์ที่เก็บโดยไม่ผ่านฟอร์มโดยตรง เช่น IP Address ที่ระบบ Log อัตโนมัติ หรือ Device Fingerprint ที่ SDK ฝั่ง Mobile เก็บไว้ ทีม Engineering มักรู้ฟิลด์เหล่านี้ดีที่สุด เพราะเป็นคนออกแบบ Schema ฐานข้อมูล ควรให้ทีมนี้ Export รายชื่อคอลัมน์จากตารางหลักที่เกี่ยวกับผู้ใช้มาเทียบกับรายการที่ทีม Privacy คิดว่ามี ความต่างระหว่างสองรายการนี้มักเผยข้อมูลที่ถูกลืมไปแล้ว

ขั้นตอนที่ 2: ตรวจสอบคุกกี้และ Tracking Identifier

เปิดเว็บไซต์จริงด้วยเครื่องมือตรวจคุกกี้ในเบราว์เซอร์ แล้วไล่ดูว่ามีคุกกี้อะไรถูกตั้งค่าไว้บ้างในแต่ละหน้า ทั้งคุกกี้ที่จำเป็นต่อการทำงานของระบบ คุกกี้วิเคราะห์พฤติกรรม และคุกกี้โฆษณาที่อาจติดมาจาก Pixel ของแพลตฟอร์มโฆษณา นอกจากคุกกี้แล้วให้ตรวจ Local Storage และ Session Storage ด้วย เพราะเครื่องมือ Analytics และ Feature Flag บางตัวเก็บ Identifier ไว้ในที่เหล่านี้แทนคุกกี้ทั่วไป แล้วบันทึกไว้ว่าแต่ละตัวมีอายุการเก็บนานแค่ไหน ถูกตั้งโดยผู้ให้บริการรายใด และเก็บข้อมูลอะไรจริง ๆ เช่น User ID ภายในระบบ หรือค่า Anonymous ที่สุ่มขึ้นมา รายการนี้ควรทำซ้ำทุกครั้งที่ทีม Growth เพิ่มเครื่องมือการตลาดใหม่ เพราะสคริปต์บุคคลที่สามมักฝังคุกกี้เพิ่มโดยไม่มีใครในทีม Privacy รับรู้ล่วงหน้า

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

SaaS ทั่วไปพึ่งพาผู้ให้บริการภายนอกจำนวนมาก ตั้งแต่ Cloud Hosting, Email Delivery, Customer Support Widget, Analytics, Payment Gateway ไปจนถึงบริการ AI ที่ใช้ประมวลผลข้อความจากผู้ใช้ ขั้นตอนนี้คือการไล่รายชื่อผู้ให้บริการทั้งหมดที่รับข้อมูลผู้ใช้จริง ไม่ใช่แค่รายชื่อที่ทีมจัดซื้อจำไว้ วิธีที่ได้ผลคือให้ทีม Engineering ไล่ดู API Key และ Webhook ที่ระบบเรียกออกไปจริงในโค้ด เทียบกับใบแจ้งหนี้ที่ทีมการเงินจ่ายให้ผู้ให้บริการแต่ละราย สองแหล่งนี้มักไม่ตรงกันเสมอ เพราะมีบริการทดลองใช้ฟรีที่ยังเชื่อมต่ออยู่แต่ไม่มีใบแจ้งหนี้ สำหรับแต่ละรายที่พบ ให้บันทึกว่าส่งข้อมูลประเภทใดไปให้ ผู้ให้บริการนั้นตั้งอยู่ประเทศใด และมีข้อตกลงประมวลผลข้อมูลระหว่างกันหรือไม่

ขั้นตอนที่ 4: ตรวจสอบระยะเวลาการเก็บรักษาข้อมูล

หลังจากรู้แล้วว่าเก็บข้อมูลอะไรและส่งไปให้ใคร ขั้นตอนถัดไปคือตรวจว่าข้อมูลแต่ละประเภทถูกเก็บไว้นานแค่ไหนก่อนถูกลบหรือทำให้ไม่ระบุตัวตน หลาย SaaS ตั้งค่าเริ่มต้นให้เก็บข้อมูล Log ไว้ตลอดไปโดยไม่มีใครตั้งใจ เพราะไม่มีใครกำหนด Retention Policy ไว้ตั้งแต่แรก ให้ไล่ตรวจฐานข้อมูลหลัก ระบบ Log, ระบบสำรองข้อมูล และกล่องข้อความสนับสนุนลูกค้า ว่าแต่ละที่มีการลบข้อมูลอัตโนมัติหรือไม่ และถ้าลูกค้ายกเลิกบัญชี ข้อมูลของลูกค้ารายนั้นถูกลบออกจากระบบทั้งหมดจริงหรือเก็บค้างไว้ในระบบสำรอง เพราะบางทีมลบข้อมูลจากฐานข้อมูลหลักแล้ว แต่ลืมว่าข้อมูลเดียวกันยังอยู่ในระบบ Analytics หรือระบบ Backup ที่แยกต่างหาก

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

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

ตัวอย่าง: SaaS ที่พบข้อมูลซ่อนอยู่ตอนทำ Audit รอบแรก

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

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

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

ข้อผิดพลาดที่พบบ่อยเมื่อ Audit ข้อมูลส่วนบุคคลบนเว็บไซต์

• ไล่ตรวจเฉพาะฟอร์มหลักบนเว็บไซต์ แต่ลืมตรวจ Local Storage และ SDK ฝั่ง Mobile ที่เก็บข้อมูลแยกต่างหาก
• ใช้รายชื่อผู้ให้บริการภายนอกจากความจำหรือสัญญาเก่า แทนที่จะไล่ดู API Key ที่ระบบเรียกออกไปจริง
• ไม่มีใครกำหนด Retention Policy ที่ชัดเจน ทำให้ข้อมูล Log ถูกเก็บไว้ตลอดไปโดยไม่ตั้งใจ
• ลบข้อมูลลูกค้าออกจากฐานข้อมูลหลักแล้ว แต่ลืมว่าข้อมูลเดียวกันยังค้างอยู่ในระบบ Backup หรือ Analytics
• ไม่ทบทวนสิทธิ์การเข้าถึงข้อมูลของพนักงานที่ลาออกไปแล้ว ทำให้บัญชียังเปิดค้างอยู่

สรุป

การ Audit ข้อมูลส่วนบุคคลบนเว็บไซต์ SaaS คือการทำแผนที่ข้อมูลจริงที่มีอยู่ ไม่ใช่การตรวจเอกสารกฎหมาย และควรทำเป็นรอบสม่ำเสมอ ไม่ใช่ทำครั้งเดียวตอนเปิดตัวบริษัท ห้าขั้นตอนหลักคือไล่ฟิลด์ข้อมูล ตรวจคุกกี้และ Tracking Identifier ตรวจเส้นทางข้อมูลไปยังผู้ให้บริการภายนอก ตรวจระยะเวลาการเก็บรักษา และตรวจการควบคุมสิทธิ์เข้าถึงภายในทีม ทีมที่ทำเรื่องนี้เป็นนิสัยจะไม่ต้องตกใจเมื่อลูกค้าองค์กรถามคำถามเจาะลึก และมีวัตถุดิบพร้อมให้ทีม Legal ใช้ทบทวนเอกสารกฎหมายได้ทันที ดูภาพรวมของหมวด Privacy Fundamentals เพิ่มเติมได้ที่ คลังความรู้ Privacy Fundamentals และดูเช็กลิสต์ก่อนเปิดใช้งานฟีเจอร์ใหม่ได้ที่ เช็กลิสต์ข้อมูลส่วนบุคคลบนเว็บไซต์ SaaS

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

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