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

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

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

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

ขอบเขตข้อมูลที่ต้องสำรวจในเว็บไซต์ลูกค้าแต่ละเว็บ

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

เว็บไซต์อสังหาริมทรัพย์ที่มีฟอร์มจองชมโครงการเชื่อมเข้า CRM ภายนอก

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

Staging Server ที่ยังมีฐานข้อมูลลูกค้าจริงค้างอยู่หลังโปรเจกต์ปิดงาน

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

ไฟล์ Export รายชื่อลูกค้าที่ถูกส่งผ่านอีเมลให้ทีมการตลาดของลูกค้าเป็นประจำ

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

ขั้นตอน Audit ข้อมูลส่วนบุคคลบนเว็บไซต์ลูกค้าแบบทำซ้ำได้ทุกไตรมาส

1. รวบรวมรายชื่อเว็บไซต์ลูกค้าที่ดูแลอยู่ทั้งหมดในปัจจุบัน พร้อมระบุสถานะแต่ละเว็บว่าใช้งานจริง อยู่ระหว่างพัฒนา หรือเก็บไว้เฉย ๆ หลังปิดโปรเจกต์ เพราะเว็บที่ถูกลืมมักเป็นจุดเสี่ยงที่สุด
2. ไล่ตรวจทุกฟอร์มและจุดรับข้อมูลบนแต่ละเว็บไซต์ด้วยตัวเอง โดยกรอกข้อมูลทดสอบจริงแล้วดูว่าปลายทางรับข้อมูลไปเก็บที่ไหน ไม่ใช่อ่านจากเอกสารเก่าที่อาจไม่ตรงกับโค้ดปัจจุบัน
3. ตรวจรายชื่อเครื่องมือและบริการภายนอกที่แต่ละเว็บไซต์เชื่อมต่ออยู่จริง เช่น CRM ระบบอีเมล วิดเจ็ตแชท ระบบชำระเงิน และปลั๊กอินวิเคราะห์เว็บไซต์ แล้วบันทึกว่าแต่ละรายรับข้อมูลประเภทใดไปบ้าง
4. ตรวจ Cookie และสคริปต์ติดตามที่ทำงานจริงบนหน้าเว็บผ่าน Developer Tools ของเบราว์เซอร์ เพราะสคริปต์ที่ทีมการตลาดเพิ่มเองผ่าน Tag Manager มักไม่ถูกบันทึกไว้ในเอกสารของทีมพัฒนา
5. ตรวจ Staging และ Dev environment ของทุกโปรเจกต์ว่ามีข้อมูลลูกค้าจริงค้างอยู่หรือไม่ และหากมี ใครบ้างที่ยังเข้าถึงได้ในตอนนี้
6. ตรวจสิทธิ์การเข้าถึงฐานข้อมูลและไฟล์ export ของแต่ละเว็บไซต์ ว่าจำกัดเฉพาะคนที่ยังทำงานกับโปรเจกต์นั้นจริง ไม่ใช่รวมถึงพนักงานที่ลาออกไปแล้วหรือฟรีแลนซ์ที่จบงานไปนานแล้ว
7. ตรวจว่า Backup เก่าของแต่ละเว็บไซต์ถูกเก็บไว้นานแค่ไหน และมีกำหนดลบหรือย้ายไปที่จัดเก็บที่ปลอดภัยกว่าหรือไม่ เพราะไฟล์ backup มักถูกลืมไว้ในโฟลเดอร์แชร์ของทีมเป็นปี

Evidence ที่ควรเก็บไว้ทุกรอบตรวจ

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

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

การทำ Data Flow Mapping เพิ่มเติมจากรายการเก็บข้อมูล

รายการข้อมูลที่เว็บไซต์เก็บอย่างเดียวยังไม่พอสำหรับเอเจนซีที่ดูแลหลายโปรเจกต์พร้อมกัน เพราะคำถามที่ลูกค้ามักถามต่อคือข้อมูลนั้นไหลต่อไปที่ไหนหลังถูกเก็บ การทำ Data Flow Mapping คือการวาดเส้นทางว่าข้อมูลแต่ละประเภทเดินทางจากฟอร์มบนหน้าเว็บไปสู่ระบบไหนบ้าง เช่น ฟอร์มสมัครสมาชิกอาจส่งข้อมูลไปสามทางพร้อมกัน คือบันทึกลงฐานข้อมูลของเว็บไซต์เอง ส่งต่อไปยัง CRM ผ่าน API และซิงก์เข้า Mailchimp เพื่อส่งอีเมลต้อนรับอัตโนมัติ แต่ละปลายทางมีผู้ให้บริการโฮสต์ข้อมูลอยู่คนละราย ซึ่งหมายความว่าข้อมูลชุดเดียวกันอาจอยู่ในมือผู้ให้บริการภายนอกสามเจ้าพร้อมกันโดยไม่มีใครสรุปภาพนี้ไว้เป็นลายลักษณ์อักษร

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

ใครในทีมเอเจนซีควรเป็นเจ้าของกระบวนการนี้

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

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

เชื่อมโยงกับบทความอื่นในคลัสเตอร์ข้อมูลส่วนบุคคลบนเว็บไซต์สำหรับเอเจนซี

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

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

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

สรุป

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

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

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