เช็กลิสต์ Privacy Risk Assessment สำหรับเว็บไซต์ธุรกิจทั่วไปและ SME: ต้องตรวจอะไรบ้างก่อนเปิดใช้งาน

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

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

ขั้นตอนที่ 1 — สำรวจว่าเว็บไซต์เก็บข้อมูลอะไรบ้างก่อนเปิดใช้งานฟีเจอร์ใหม่

ก่อนเปิดฟีเจอร์ใหม่ ให้ทีมไล่ดูทุกจุดที่เว็บไซต์เก็บข้อมูลจากผู้ใช้ ไม่ใช่แค่ฟอร์มที่มองเห็น แต่รวมถึง Cookie, Local Storage, ปุ่มแชท, ระบบตะกร้าสินค้า และวิดเจ็ตของบุคคลที่สามที่ฝังไว้ในหน้าเว็บ

จุดที่ทีมเล็กมักมองข้าม

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

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

ขั้นตอนที่ 2 — ตรวจ Script และปลั๊กอินที่ทำงานก่อนผู้ใช้กดยินยอม

ปัญหาที่พบบ่อยที่สุดคือสคริปต์ติดตามผล เช่น Analytics หรือ Pixel โฆษณา ทำงานทันทีที่หน้าเว็บโหลด โดยไม่รอให้ผู้ใช้กดยินยอมบน Cookie Banner ก่อน ทีมควรทดสอบด้วยการเปิดเว็บไซต์ในโหมดไม่ระบุตัวตน แล้วดูใน Network Tab ของเบราว์เซอร์ว่ามีการยิง Request ออกไปยังผู้ให้บริการภายนอกก่อนกดปุ่มใดๆ หรือไม่

trusty ช่วยสแกนหน้าเว็บสาธารณะและแสดงรายการสคริปต์หรือ Cookie ที่ตรวจพบว่าทำงานก่อนมีการโต้ตอบได้ในระดับหนึ่ง แต่การสแกนอัตโนมัติมองเห็นเฉพาะสิ่งที่ปรากฏบนหน้าเว็บสาธารณะ ไม่เห็นสิ่งที่เกิดขึ้นหลังบ้าน เช่น การส่งข้อมูลจาก Server ไปยังระบบ CRM ทีมยังต้องตรวจการตั้งค่า Tag Manager และปลั๊กอินด้วยตนเองประกอบกัน

วิธีทดสอบแบบไม่ต้องพึ่งเครื่องมือพิเศษ

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

ขั้นตอนที่ 3 — จับคู่ความเสี่ยงกับระดับความอ่อนไหวของข้อมูล

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

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

ขั้นตอนที่ 4 — ตรวจ Privacy Policy และช่องทางใช้สิทธิของเจ้าของข้อมูล

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

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

trusty ช่วยร่าง Privacy Policy เบื้องต้นจากผลสแกนและข้อมูลที่ทีมกรอกเพิ่มเอง แต่ธุรกิจที่มีกิจกรรมข้อมูลซับซ้อนหรือมีข้อมูลอ่อนไหวควรให้ผู้เชี่ยวชาญตรวจร่างก่อนเผยแพร่จริง

ขั้นตอนที่ 5 — กำหนดเจ้าของงานและรอบทบทวนก่อนเปิดใช้งานจริง

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

ทีมควรกำหนดรอบทบทวนที่ชัดเจน เช่น ทุกครั้งที่เพิ่มฟีเจอร์ใหม่ หรืออย่างน้อยทุกหกเดือน พร้อมระบุว่าใครมีหน้าที่ตรวจ Cookie Inventory ใครตรวจ Policy และใครเป็นผู้อนุมัติก่อนเปิดใช้งานจริง

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

Privacy Risk Assessment ต่างจาก PDPA Readiness Scan อย่างไร

Privacy Risk Assessment เป็นกระบวนการที่ทีมภายในไล่ตรวจข้อมูล ความเสี่ยง และ Policy ด้วยตนเองอย่างเป็นระบบ ส่วน PDPA Readiness Scan ของ trusty เป็นการตรวจเบื้องต้นด้วยเครื่องมืออัตโนมัติที่มองเห็นเฉพาะสิ่งที่ปรากฏบนหน้าเว็บสาธารณะ ทั้งสองส่วนใช้ประกอบกันได้ แต่ไม่ทดแทนกัน

SME ขนาดเล็กจำเป็นต้องทำ Privacy Risk Assessment ทุกครั้งที่แก้เว็บไซต์หรือไม่

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

ถ้าพบข้อมูลอ่อนไหวระหว่างตรวจ ควรทำอย่างไรก่อน

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

เครื่องมืออัตโนมัติอย่าง trusty ช่วยแทนการทำ Privacy Risk Assessment ได้ทั้งหมดหรือไม่

ไม่ได้ เครื่องมือช่วยตรวจ Banner, Policy ที่เผยแพร่ และพฤติกรรมสคริปต์บนหน้าเว็บสาธารณะได้ในระดับหนึ่ง แต่ไม่เห็นข้อมูลหลังบ้าน สัญญากับผู้ให้บริการภายนอก หรือกระบวนการภายในทีม ซึ่งเป็นส่วนสำคัญของการประเมินความเสี่ยงที่ต้องใช้คนตรวจร่วมด้วย

เช็กลิสต์ปฏิบัติ

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

ข้อผิดพลาดที่พบบ่อย

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

สรุป

Privacy Risk Assessment สำหรับ SME ไม่จำเป็นต้องซับซ้อนเท่าองค์กรใหญ่ แต่ต้องครอบคลุมทั้งข้อมูลที่เก็บ พฤติกรรมสคริปต์ Policy และเจ้าของงาน การไล่ตรวจ 5 ขั้นตอนนี้ก่อนเปิดใช้งานฟีเจอร์ใหม่ช่วยลดความเสี่ยงพื้นฐานที่ตรวจพบได้ แต่เมื่อพบข้อมูลอ่อนไหวหรือความเสี่ยงสูง ควรส่งต่อผู้เชี่ยวชาญด้านกฎหมายหรือ Data Protection พิจารณาเพิ่มเติมเสมอ

อ่านต่อ วิธี Audit Privacy Risk Assessment พร้อม Evidence ที่ควรเก็บ เพื่อดูขั้นตอนตรวจเชิงลึกกว่านี้ หรือดูภาพรวมทั้งหมวดที่ Rights, Incidents & Risk

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

• NIST Privacy Framework
• สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC)