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

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

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

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

ทำไมเอเจนซีต้องมีเช็กลิสต์แยกจากของลูกค้า

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

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

ในทางปฏิบัติ เช็กลิสต์นี้ควรถูกฝังเข้าไปในขั้นตอนมาตรฐานของทีม เช่น เป็นหนึ่งในรายการที่ต้องติ๊กถูกก่อนขึ้นระบบจริง (go-live) เหมือนกับการตรวจสอบความเร็วเว็บไซต์หรือความเข้ากันได้กับมือถือ เมื่อทำเป็นกิจวัตรแล้ว เวลาที่ใช้ตรวจแต่ละโปรเจกต์จะสั้นลงเรื่อยๆ เพราะทีมงานคุ้นชินกับจุดที่ต้องดู และสามารถแยกแยะได้เร็วว่าเว็บไซต์แต่ละแบบมีความเสี่ยงต่างกันตรงไหน เช่น เว็บที่มีระบบสมาชิกและเก็บประวัติการสั่งซื้อ ย่อมมีจุดต้องตรวจมากกว่าเว็บแนะนำบริษัทที่มีแค่ฟอร์มติดต่อเดียว

เช็กลิสต์ก่อนส่งมอบเว็บไซต์ให้ลูกค้าใช้งานจริง

แบ่งเป็น 5 กลุ่มตามลำดับที่ควรตรวจ:

1. ฐานทางกฎหมายของการเก็บข้อมูลแต่ละจุด

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

2. กลไกขอความยินยอมที่ใช้งานได้จริง

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

3. ช่องทางให้เจ้าของข้อมูลใช้สิทธิ

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

4. ขั้นตอนแจ้งเหตุละเมิดข้อมูล

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

5. บทลงโทษและความเสี่ยงที่ต้องสื่อสารกับลูกค้า

• อธิบายให้ลูกค้าเข้าใจว่าความไม่ครบถ้วนของฟอร์มหรือคุกกี้แบนเนอร์อาจนำไปสู่ข้อร้องเรียนและการตรวจสอบจาก PDPC
• ไม่ควรสื่อสารว่าการทำตามเช็กลิสต์นี้ทำให้ธุรกิจ \"ปลอดภัย 100%\" แต่ควรบอกตรงๆ ว่านี่คือการลดความเสี่ยงและสร้างหลักฐานปฏิบัติตามกฎหมายเท่าที่ทำได้ในขั้นตอนพัฒนาเว็บไซต์

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

ข้อผิดพลาดที่พบบ่อยเมื่อเอเจนซีทำเช็กลิสต์ PDPA

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

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

สรุป: เช็กลิสต์ต้องเป็นกิจวัตร ไม่ใช่งานทำครั้งเดียว

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

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

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