ตัวอย่างและ Template PDPA สำหรับเว็บไซต์องค์กรการเงินและธุรกิจความเสี่ยงสูง

ทีมกฎหมายขององค์กรประกันภัยแห่งหนึ่งได้รับมอบหมายให้จัดทำเอกสารประกอบการตรวจสอบภายในภายในสองสัปดาห์ แต่พบว่าไม่มีบันทึกกิจกรรมประมวลผลข้อมูล (Record of Processing Activities) สำหรับหน้าเว็บไซต์ที่เก็บข้อมูลลูกค้าเลยแม้แต่ฉบับเดียว ทีมงานต้องเริ่มจากศูนย์โดยไล่สัมภาษณ์ทีมที่ดูแลแต่ละหน้าเว็บทีละคน ซึ่งใช้เวลานานกว่าที่ควรเพราะไม่มี Template มาตรฐานให้เริ่มต้น บทความนี้รวบรวมตัวอย่าง Template ที่ทีมองค์กร ฝ่ายกฎหมาย Privacy Security และ Compliance นำไปปรับใช้ได้ทันที พร้อมคำอธิบายว่าแต่ละส่วนต้องปรับให้ตรงกับองค์กรจริงตรงไหน

Template ทุกชุดในบทความนี้เป็นโครงร่างเริ่มต้นสำหรับใช้ภายในองค์กร ไม่ใช่เอกสารทางกฎหมายสำเร็จรูปที่ใช้แทนการตรวจสอบจากทีมกฎหมายหรือ DPO ได้

เทมเพลตบันทึกกิจกรรมประมวลผลข้อมูล KYC บนเว็บไซต์

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

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

เทมเพลตข้อตกลงการประมวลผลข้อมูลระหว่างแผนก

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

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

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

เทมเพลตแบบฟอร์มขออนุมัติจาก DPO ก่อนเปิดฟีเจอร์ใหม่

เมื่อทีม Product ต้องการเปิดฟีเจอร์ใหม่บนเว็บไซต์ที่เก็บข้อมูลเพิ่มเติม ควรมีแบบฟอร์มมาตรฐานที่ส่งให้ DPO พิจารณาก่อน Deploy จริง โครงร่างแบบฟอร์มควรมีหัวข้อดังนี้

1. ชื่อฟีเจอร์และวัตถุประสงค์ทางธุรกิจ
2. ประเภทข้อมูลใหม่ที่จะเก็บเพิ่มเติมจากเดิม
3. ระบบปลายทางที่ข้อมูลจะถูกส่งไปจัดเก็บหรือประมวลผล
4. ทีมที่จะมีสิทธิ์เข้าถึงข้อมูลใหม่นี้
5. ผลกระทบต่อ Privacy Notice ปัจจุบัน ต้องแก้ไขหรือไม่
6. วันที่คาดว่าจะ Deploy และวันที่ส่งขออนุมัติ

แบบฟอร์มนี้ควรมีสถานะอนุมัติ/ไม่อนุมัติ/ขอข้อมูลเพิ่มเติมที่ชัดเจน และเก็บประวัติการอนุมัติไว้เป็นส่วนหนึ่งของ Audit Trail ขององค์กร

ตัวอย่างข้อความ Privacy Notice สำหรับฟอร์มเปิดบัญชีออนไลน์

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

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

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

เทมเพลตโครงสร้าง Audit Trail Log สำหรับระบบเว็บไซต์

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

เทมเพลตสรุปข้อมูลสำหรับการรายงานภายในและกำกับดูแล

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

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

วิธีปรับ Template ให้เหมาะกับโครงสร้างองค์กรจริง

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

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

ทีมที่ต้องการตรวจสอบความพร้อมเบื้องต้นก่อนกรอก Template สามารถเริ่มจาก Website Trust Scan เพื่อดูว่าหน้าใดของเว็บไซต์มีการเก็บข้อมูลผ่านฟอร์มหรือ Script ที่ควรนำมาบันทึกในตาราง และหากต้องการรายการข้อผิดพลาดที่พบบ่อยเพื่อตรวจทานก่อนใช้ Template ควรอ่านคู่กับ 10 ข้อผิดพลาดเรื่อง PDPA บนเว็บไซต์องค์กรการเงิน และดูภาพรวมของหมวดนี้เพิ่มเติมได้ที่ Privacy Fundamentals

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

• กรอกบันทึกกิจกรรมประมวลผลข้อมูล KYC ให้ครบทุกหน้าที่เก็บข้อมูลลูกค้า
• ให้เจ้าของหน้าเว็บไซต์แต่ละหน้ายืนยันความถูกต้องของข้อมูลใน Template
• จัดทำข้อตกลงระหว่างแผนกก่อนอนุญาตให้ส่งข้อมูลลูกค้าข้ามแผนก
• ใช้แบบฟอร์มขออนุมัติจาก DPO ก่อนเปิดฟีเจอร์ที่เก็บข้อมูลใหม่ทุกครั้ง
• ผูก Audit Trail กับเวอร์ชันของ Privacy Notice ที่ใช้งาน ณ ขณะนั้น
• กำหนดแหล่งข้อมูลกลางสำหรับรวบรวมข้อมูลรายงานกำกับดูแล

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

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

สรุป

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

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

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