วิธี Audit Privacy Notice ขององค์กรการเงิน ประกัน และธุรกิจที่มีความเสี่ยงสูง พร้อม Evidence ที่ควรเก็บ

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

บทความนี้วางขั้นตอน Audit Privacy Notice แบบเป็นรอบตรวจประจำสำหรับองค์กรการเงิน ประกัน และธุรกิจที่มีความเสี่ยงสูง ครอบคลุมตั้งแต่การตรวจความตรงกันระหว่างเอกสารกับระบบจริง ฐานทางกฎหมาย ระยะเวลาเก็บข้อมูล ไปจนถึงช่องทางใช้สิทธิ์ของเจ้าของข้อมูล พร้อมตัวอย่าง Evidence ที่ทีม Compliance ควรเก็บไว้แต่ละรอบ

การ Audit Privacy Notice ขององค์กรการเงินและธุรกิจความเสี่ยงสูง คือการตรวจว่าเนื้อหาที่เผยแพร่ยังตรงกับข้อมูลที่ระบบเก็บจริง ฐานทางกฎหมายของแต่ละวัตถุประสงค์ยังใช้ได้ถูกต้อง ระยะเวลาเก็บข้อมูลตรงกับ retention policy จริง และช่องทางใช้สิทธิ์ของเจ้าของข้อมูลยังทำงานได้ตามที่เอกสารระบุ องค์กรที่ทำเป็นรอบตรวจประจำอย่างน้อยทุก 6 เดือน พร้อมเก็บ Evidence เป็นชุด แนวทางนี้เป็นหลักปฏิบัติเพื่อตรวจสอบและเก็บหลักฐาน ไม่ใช่การยืนยันว่าองค์กรผ่านข้อกำหนดทางกฎหมายทุกกรณี ควรตรวจสอบภาระหน้าที่ตาม PDPA กับที่ปรึกษากฎหมายโดยตรง

ทำไมองค์กรความเสี่ยงสูงต้องเลือกรอบตรวจประจำ ไม่ใช่ตรวจเมื่อมีเหตุ

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

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

ขั้นตอนที่ 1: ตรวจความตรงกันระหว่างเอกสารกับข้อมูลที่ระบบเก็บจริง

เริ่มจากขอรายการ database schema หรือ data flow diagram ล่าสุดจากทีม Engineering แล้วเทียบทีละบรรทัดกับหมวดข้อมูลที่ Privacy Notice ระบุไว้ บริษัทประกันภัยแห่งหนึ่งพบระหว่างรอบตรวจว่าระบบ underwriting ใหม่เก็บข้อมูลประวัติการเคลมจากบริษัทประกันคู่แข่งผ่านการเชื่อมต่อ API กับหน่วยงานกลาง แต่ Privacy Notice เดิมพูดถึงแค่ข้อมูลที่ลูกค้ากรอกเองในใบสมัครเท่านั้น ความไม่ตรงกันแบบนี้จับได้เฉพาะเมื่อมีคนอ่าน data flow จริง ไม่ใช่แค่อ่านเอกสารที่เขียนไว้

จุดที่มักตรวจไม่ครบ: ข้อมูลจากบุคคลที่สาม

องค์กรการเงินจำนวนมากรับข้อมูลจากแหล่งอื่นนอกเหนือจากที่ลูกค้ากรอกเอง เช่น ข้อมูลเครดิตจากบริษัทข้อมูลเครดิตแห่งชาติ หรือข้อมูลจากพันธมิตรทางธุรกิจที่ส่งต่อ lead มาให้ การ Audit ต้องตรวจว่า Privacy Notice ระบุแหล่งที่มาของข้อมูลบุคคลที่สามเหล่านี้ครบถ้วนหรือไม่ เพราะเป็นจุดที่ทีม Product มักลืมแจ้งทีม Legal เมื่อเริ่มความร่วมมือใหม่กับพันธมิตร

ขั้นตอนที่ 2: ตรวจฐานทางกฎหมายของแต่ละวัตถุประสงค์ว่ายังใช้ได้ถูกต้อง

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

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

ขั้นตอนที่ 3: ตรวจระยะเวลาเก็บข้อมูลเทียบกับ retention policy จริง

องค์กรการเงินมักมีข้อกำหนดด้าน retention ที่ซับซ้อนกว่าธุรกิจทั่วไป เพราะบางประเภทข้อมูลต้องเก็บไว้นานตามข้อกำหนดด้านการเงินหรือประกันภัย ขณะที่บางประเภทควรลบเร็วกว่านั้นตามหลักการเก็บข้อมูลเท่าที่จำเป็น การ Audit ต้องขอรายงาน retention job จากทีม Data Engineering มาเทียบกับตัวเลขที่ระบุใน Privacy Notice ทีละประเภทข้อมูล ไม่ใช่ดูภาพรวมเพียงตัวเลขเดียว

บริษัทหลักทรัพย์แห่งหนึ่งพบระหว่างการ Audit ว่าข้อมูลการสมัครบัญชีที่ถูกปฏิเสธ (ลูกค้าที่สมัครแต่ไม่ผ่านการอนุมัติ) ถูกเก็บไว้โดยไม่มี retention job ลบออกเลย ทั้งที่ Privacy Notice ระบุว่าข้อมูลกลุ่มนี้จะถูกลบภายใน 2 ปี เพราะทีมที่สร้างระบบเดิมตั้ง job ลบไว้เฉพาะบัญชีที่อนุมัติสำเร็จเท่านั้น ลืมครอบคลุมกรณีสมัครไม่ผ่าน

ขั้นตอนที่ 4: ตรวจช่องทางใช้สิทธิ์ของเจ้าของข้อมูลว่าทำงานได้จริง

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

ขั้นตอนที่ 5: ตรวจการเชื่อมโยงกับพันธมิตรและผู้ประมวลผลข้อมูลภายนอก

องค์กรการเงินและประกันมักส่งข้อมูลลูกค้าต่อไปยังผู้ประมวลผลภายนอก เช่น บริษัทที่รับจ้างพิมพ์และจัดส่งเอกสารกรมธรรม์ บริษัทวิเคราะห์ความเสี่ยงด้านเครดิต หรือผู้ให้บริการ cloud storage ที่เก็บเอกสารสแกนของลูกค้า การ Audit ต้องขอรายชื่อผู้ประมวลผลภายนอกทั้งหมดที่ทีม Procurement หรือ IT เซ็นสัญญาไว้ในรอบปีที่ผ่านมา แล้วเทียบว่าตรงกับรายชื่อที่ระบุใน Privacy Notice หรือไม่ ธนาคารแห่งหนึ่งพบระหว่างการ Audit ว่ามีการเปลี่ยนผู้ให้บริการ cloud storage จากเจ้าเดิมไปเจ้าใหม่เมื่อหกเดือนก่อน แต่ Privacy Notice ยังระบุชื่อผู้ให้บริการเดิมอยู่ เพราะทีม IT ที่เปลี่ยนสัญญาไม่ทราบว่าต้องแจ้งทีม Legal ให้ปรับเอกสารตามไปด้วย

นอกจากรายชื่อผู้ประมวลผล ทีม Compliance ควรตรวจด้วยว่าสัญญาการประมวลผลข้อมูล (Data Processing Agreement) กับผู้ให้บริการแต่ละรายยังมีผลบังคับใช้และครอบคลุมขอบเขตข้อมูลที่ส่งต่อจริงในปัจจุบัน ไม่ใช่แค่ขอบเขตที่เคยตกลงกันตอนเริ่มสัญญาซึ่งอาจแคบกว่าการใช้งานจริงที่ขยายออกไปตามเวลา

ขั้นตอนที่ 6: ตรวจกรณีการโอนข้อมูลข้ามพรมแดนหากมี

บริษัทประกันหรือสถาบันการเงินที่เป็นเครือข่ายข้ามประเทศ หรือใช้ผู้ให้บริการ cloud ที่มีศูนย์ข้อมูลอยู่ต่างประเทศ ต้องตรวจว่า Privacy Notice ระบุกรณีการโอนข้อมูลออกนอกประเทศไว้ชัดเจนหรือไม่ รวมถึงมาตรการคุ้มครองข้อมูลที่ใช้ในการโอนแต่ละครั้ง ทีม Compliance ควรขอแผนผัง data residency จากทีม Infrastructure เพื่อยืนยันว่าข้อมูลลูกค้าถูกประมวลผลหรือสำรองข้อมูลอยู่ที่ใดบ้าง แล้วเทียบกับสิ่งที่เอกสารเปิดเผยไว้ บริษัทประกันแห่งหนึ่งพบว่าระบบสำรองข้อมูลภัยพิบัติ (disaster recovery) ตั้งอยู่ที่ศูนย์ข้อมูลต่างประเทศ ซึ่งไม่เคยถูกกล่าวถึงในเอกสารเลย ทั้งที่ข้อมูลสำเนาลูกค้าทั้งหมดถูกเก็บไว้ที่นั่นด้วยเช่นกัน

Evidence ที่ทีม Compliance ควรเก็บไว้ทุกรอบ

ทีม Compliance ควรเก็บรายงานเปรียบเทียบ data schema กับเนื้อหา Privacy Notice ของแต่ละรอบตรวจ พร้อมวันที่และชื่อผู้ตรวจ เก็บตารางฐานทางกฎหมายที่ทบทวนแล้วในแต่ละรอบ เก็บผลเทียบตัวเลข retention job กับตัวเลขในเอกสาร และเก็บบันทึกผลการทดสอบช่องทางใช้สิทธิ์ พร้อมระยะเวลาตอบสนองจริงเทียบกับที่สัญญาไว้ หลักฐานชุดนี้ไม่ได้มีไว้ยืนยันว่าองค์กรทำถูกต้องตามกฎหมายทุกข้อ แต่แสดงว่าองค์กรมีกระบวนการตรวจสอบเชิงรุกอย่างสม่ำเสมอ ซึ่งเป็นแนวปฏิบัติที่ดีสำหรับธุรกิจความเสี่ยงสูงที่ต้องพร้อมตอบผู้ตรวจสอบภายนอกได้ตลอดเวลา

ความสัมพันธ์กับบทความอื่นในชุดความรู้เดียวกัน

บทความนี้เน้นขั้นตอน Audit สำหรับองค์กรการเงินและธุรกิจความเสี่ยงสูงโดยเฉพาะ หากต้องการรายการตรวจสอบก่อนเผยแพร่หรือปรับปรุง Privacy Notice ดูได้ที่ Checklist Privacy Notice สำหรับองค์กรการเงินและธุรกิจความเสี่ยงสูง และหากองค์กรของท่านมี Cookie Policy ที่ต้องตรวจสอบคู่กันด้วย ดูแนวทางได้ที่ วิธี Audit Cookie Policy สำหรับองค์กรการเงินและธุรกิจความเสี่ยงสูง

ข้อผิดพลาดที่พบบ่อยระหว่างการ Audit

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

สรุป

การ Audit Privacy Notice ขององค์กรการเงิน ประกัน และธุรกิจความเสี่ยงสูง ต้องครอบคลุมสี่ชั้นพร้อมกัน คือความตรงกันระหว่างเอกสารกับระบบจริง ฐานทางกฎหมายของแต่ละวัตถุประสงค์ ระยะเวลาเก็บข้อมูลเทียบกับ retention job จริง และช่องทางใช้สิทธิ์ที่ทำงานได้จริง องค์กรที่เลือกตั้งรอบตรวจประจำแทนการตรวจเฉพาะเมื่อมีเหตุ จะมี Evidence สะสมเป็นประวัติที่พร้อมตอบผู้ตรวจสอบภายนอกได้ทันที ดูภาพรวมหัวข้ออื่นในหมวด Policies & Notices เพิ่มเติมได้ที่ คลังความรู้ Policies & Notices

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

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