ข้อปฏิบัติสำหรับการประเมินผลกระทบความเสี่ยงข้อมูลส่วนบุคคล

https://www.facebook.com/monsaks

ความเสี่ยง คือ สถานการณ์ที่อธิบายเหตุการณ์ที่กำลังเกิดขึ้น (หรืออาจเกิดขึ้น) พร้อมทั้งผลที่จะตามมา และปัจจัยที่ใช้ประเมินระดับความเสี่ยงก็คือความรุนแรง (ของผลกระทบ) และความน่าจะเป็นที่จะเกิดขึ้น ในขณะที่การบริหารความเสี่ยง คือ การวางแผนกิจกรรมเพื่อที่จะกำหนดทิศทางและควบคุมองค์กรในการตอบสนองต่อความเสี่ยงนั้น ๆ (ลดความรุนแรง และ/หรือ ลดความน่าจะเป็น)

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

ข้อปฏิบัติฯ นี้เรียบเรียงขึ้นโดยอาศัยพื้นฐานข้อมูลจาก Guidelines on Data Protection Impact Assessment (DPIA) and determining whether processing is “likely to result in a high risk”[1] ซึ่งเป็นเอกสารแนะนำแนวทางการปฏิบัติ (Guidelines) ที่จัดทำโดยคณะทำงานคุ้มครองข้อมูลส่วนบุคคลของสหภาพยุโรป (Working Party จัดตั้งตามมาตรา 29 ใน GDPR)  เอกสารแนวทางการปฏิบัติของสหภาพยุโรปดังกล่าวให้คำแนะนำในการประเมินว่าการประมวลผลนั้นๆ ส่งผลให้เกิดความเสี่ยงสูงหรือไม่ อีกทั้งยังให้คำแนะนำและหลักการเพื่อให้ได้มาซึ่งเอกสารการประเมินผลกระทบความเสี่ยง (Data Protection Impact Assessment: DPIA)

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

มนต์ศักดิ์  โซ่เจริญธรรม
เมษายน 2563

[1] (ปรับปรุงและประกาศใช้ล่าสุด 4 ตุลาคม 2017) และเห็นชอบโดยคณะกรรมการคุ้มครองข้อมูลส่วนบุคคลของสหภาพยุโรป (European Data Protection Board (EDPB))

รูปสรุปขั้นตอนและหลักการพื้นฐานในการทำ DPIA

ต่อไปนี้จะสรุปประเด็นเป็นข้อ ๆ เพื่อให้เข้าใจได้ง่าย

1 การทำ DPIA สามารถทำได้ทั้งแบบเจาะจงไปที่การประมวลผลเฉพาะหนึ่ง ๆ เป็นครั้ง ๆ ไป หรือ ทำเพื่อให้ครอบคลุมการประมวลผลประเภทเดียวกัน เช่น CCTV รักษาความปลอดภัยในที่สาธารณะแล้วนำไปใช้อ้างอิงได้หลายสถานที่หลายโครงการที่มีลักษณะการประมวลผลแบบเดียวกัน

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

2 กรณี DPIA เกี่ยวข้องกับหลาย data controllers แต่ละ data controller ก็ต้องเปิดเผยความต้องการคนตนให้ทุกคนทราบ เพื่อให้สามารถจัดทำ DPIA ได้ ทั้งนี้สามารถพิจารณาตามความเหมาะสมหากเกี่ยวเนื่องกับความลับทางธุรกิจ

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

4 ต้องพึงระลึกไว้ด้วยว่า บางครั้งเมื่อประเมินโดยพิจารณาจากเทคโนโลยีปัจจุบัน อาจจะพบว่าความเสี่ยงต่ำและไม่ต้องจัดทำ DPIA แต่เมื่อเทคโนโลยีเปลี่ยนแปลง แม้จะเป็นการใช้งานเดิมก็อาจจะต้องทำทวนและจัดทำ DPIA ใหม่

5 กรณีก้ำกึ่งไม่แน่ใจว่า DPIA จำเป็นหรือไม่ ให้ดำเนินการทำไปก่อน

6 ตัวอย่าง 3 เกณฑ์ที่ใช้พิจารณาว่าจะต้อง DPIA มีดังนี้

6.1 การประมวลผลที่เป็นระบบและกระทบคนจำนวนมาก มีการประมวลผลโดยอัตโนมัติ และผลการตัดสินใจจากระบบมีผลทางกฎหมายต่อบุคคล
6.2 การประมวลผลข้อมูลอ่อนไหว (sensitive) ในปริมาณมากหรือต่อบุคคลจำนวนมาก หรือ ข้อมูลส่วนบุคคลที่เกี่ยวกับประวัติอาชญากรรม
6.3การติดตามตรวจการอย่างเป็นระบบในพื้นที่เปิดสาธารณะที่มีการเก็บและประมาณข้อมูลปริมาณมาก หรือ เกี่ยวเนื่องกับบุคคลจำนวนมาก

7 นอกจากกรณี 3 ข้างต้นซึ่งระบุชัดเจนตรง ๆ แล้ว ยังมีประเด็นของความเสี่ยงแฝง (inherent risk) ด้วย คือมิได้แสดงความเสี่ยงชัดเจนแต่เป็นลักษณะมีโอกาสหรือแนวโน้ม (สะท้อนคำว่า “likely to result in a high risk”) โดยการพิจารณาความเสี่ยงแฝงให้พิจารณาลักษณะการประมวลผลตาม 9 เกณฑ์ ดังนี้

7.1 มีการให้คะแนนหรือประเมิน (รวมถึงการจำแนกหรือทำนาย) ข้อมูลส่วนบุคคล จากมุมมองต่าง ๆ เช่น พฤติกรรมการทำงาน สถานะภาพทางเศรษฐกิจ สุขภาพ ความชอบ ความสนใจ พฤติกรรมส่วนตัว ตำแหน่ง หรือการเคลื่อนที่เดินทาง
7.2 มีการตัดสินใจแบบอัตโนมัติ ที่ส่งผลทางกฎหมาย (หรือคล้ายคลึง) ต่อ data subject เช่น ผลการตัดสินใจอาจนำไปสู่การยกเว้น การแบ่งแยกกลุ่ม/ประเภทบุคคล (discrimination) อย่างไม่เป็นธรรม
7.3 การตรวจตราอย่างเป็นระบบ (systematic monitoring) เป็นการประมวลผลที่ใช้เพื่อ สังเกต ตรวจตรา หรือควบคุม data subject รวมถึงข้อมูลที่รวบรวมจากเครือข่ายสื่อสาร หรือ การตรวจตราพื้นที่สาธารณะ สาเหตุที่ประเด็นนี้สำคัญเนื่องจาก data subject อาจไม่รู้ตัวว่ากำลังถูกใครติดตามและบันทึกข้อมูลหรือไม่ อย่างไร ยิ่งไปกว่านั้น อาจทำให้ data subject มิอาจจะหลีกเลี่ยงการประมวลผลดังกล่าวได้เมื่อตนเข้าในพื้นที่สาธารณะนั้น
7.4 มีการประมวลผลข้อมูลอ่อนไหว หรือมีความเป็นส่วนตัวสูง
7.5 การประมวลผลข้อมูลปริมาณมาก (GDPR ไม่ได้ระบุว่าขนาดไหนจึงเรียกว่ามาก) โดยเกณฑ์คร่าว ๆ ที่ใช้ประเมินว่าเป็น large scale หรือไม่ มี 4 ข้อด้านล่าง

7.5.1 จำนวน data subject ไม่ว่าจะระบุเป็นจำนวนตรงๆ หรือ เป็นสัดส่วนของประชากร
7.5.2 ปริมาณข้อมูล (จำนวน record) หรือความหลากหลาย (จำนวน field)
7.5.3 ระยะเวลาดำเนินการ
7.5.4 ขอบเขตทางภูมิศาสตร์ เช่น ระดับเมือง หรือ หลายพื้นที่เล็ก ๆ กระจายกัน

8 การจับคู่ข้อมูล (data matching) หรือ การหลวมรวมข้อมูล (data merging) หมายถึง การประมวลผลที่เกิดกับข้อมูลตั้งแต่ 2 แหล่งมารวมกัน (อาจจะมาจากต่าง data controllers กัน) ซึ่งอาจก่อให้เกิดผลกระทบในลักษณะทวีคูณเทียบกับเมื่อประมวลผลแยกกัน

9 การประมวลผลข้อมูลที่เกี่ยวข้องกับ data subject ที่ถือว่าเปราะบาง เช่น ผู้เยาว์ ลูกจ้าง ผู้มีอาการทางจิต คนเร่ร่อน คนชรา หรือ ผู้ป่วย เช่นนี้ เรียกว่าการประมวลผลนั้นมีแนวโน้มที่จะมีความเสี่ยงสูง เนื่องจากอาจเกิดความไม่สมดุลระหว่าง data subject กับ data controller เนื่องจาก data subject อาจไม่ทราบ หรือ ไม่สามารถปฏิเสธการประมวลผลเหล่านี้ เนื่องจากตนยังไม่สมบูรณ์ (หรือมีความบกพร่อง) ทางกาย ทางจิตใจ หรือทางนิติภาวะ

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

11 เมื่อการประมวลผลนั้นจำกัด data subject จากการได้รับสิทธิประโยชน์ หรือบริการบางอย่าง เช่น ธนาคารประมวลผลข้อมูลประวัติเครดิตในการตัดสินใจว่าจะให้ลูกค้ากู้ยืมหรือไม่

ตารางแสดงตัวอย่างการประเมินว่าการประมวลผลใดต้องทำ DPIA หรือไม่ โดยระบุเกณฑ์ว่าตรงกับข้อใดบ้าง

ในทางกลับกัน หลังจากการประเมินตามตารางข้างต้นแล้ว data controller อาจพบว่าแม้จะตรงเกณฑ์ที่กำหนดแต่ก็อาจจะไม่จำเป็นต้องทำ DPIA ก็ได้  ในกรณีนี้ data controller ควรทำเอกสารชี้แจงเหตุผลไว้เป็นลายลักษณ์อักษร พร้อมทั้งแนบความเห็นของ DPO (Data Protection Officer) ไว้ด้วย

นอกจากนี้ data controller ยังต้องทำการบันทึกรายการประมวลผลที่เกิดขึ้นด้วย ซึ่งรวมถึงจุดประสงค์ รูปแบบลักษณะการประมวลผล และผู้รับข้อมูล และหากเป็นไปได้ เตรียมคำอธิบายทางเทคนิคและคำอธิบายมาตรการทางด้านความปลอดภัย (securities) ด้วย พร้อมทั้งประเมินความเสี่ยง (ถึงแม้ว่าสุดท้ายแล้วจะตัดสินใจไม่จัดทำ DPIA)

data controller ต้องมีการแต่งตั้งที่ปรึกษา (ที่ได้รับการยอมรับจากหน่วยงานรับผิดชอบ) และประกาศให้สาธารณะทราบ และควรสื่อสารรายการประมวลผลที่ต้องทำ DPIA ต่อ คณะกรรมการคุ้มครองข้อมูลส่วนบุคคลสหภาพยุโรป หรือ EDPB กรณี GDPR (Article 35(4) (เทียบได้กับคณะกรรมการคุ้มครองข้อมูลส่วนบุคคลของไทย)

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

12 เมื่อใดไม่ต้องทำ DPIA

• เมื่อประเมินแล้วพบว่าน่าจะมีความเสี่ยงต่ำ (not likely to result in a high risk)
• มี DPIA ที่คล้ายคลึงกันได้ถูกจัดทำไว้แล้ว (สามารถนำมาใช้โดยไม่ต้องจัดทำซ้ำ)
• ได้รับการตรวจสอบจากหน่วยงานรับผิดชอบและได้รับการอนุมัติให้ดำเนินการก่อนพฤษภาคม 2018 (ปีที่ GDPR ประกาศบังคับใช้)\
• มีฐานกฎหมายรองรับ ได้แก่ Article 6 (c) ประมวลผลเนื่องจากจำเป็นต้องทำตามกฎหมายกำหนดอำนาจหน้าที่ให้ทำ หรือ Article 6 (e) ทำเพื่อประโยชน์สาธารณะ ทั้งนี้ใน 2 กรณีนี้ มักมีกฎหมายควบคุมการดำเนินการอยู่แล้ว และ DPIA อาจได้ถูกจัดทำไปแล้วในเชิงภาพรวมในระหว่างที่ร่างกฎหมายควบคุมนั้น ๆ อย่างไรก็ตามหน่วยงานรับผิดชอบอาจเห็นควรให้ทำ DPIA อีกเป็นการเฉพาะก็ได้ (อ้างจาก Article 35 (10))
• อยู่ในรายการประมวลผล ที่ไม่จำเป็นต้องทำ DPIA ซึ่งกำหนดและประกาศโดยหน่วยงานผู้รับผิดชอบ (เทียบได้กับ สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคลของไทย) ทั้งนี้สามารถกำหนดเงื่อนไขประกอบต่าง ๆ ให้ผู้ปฎิบัติตรวจสอบได้ด้วยว่าการประมวลผลดังกล่าว ตกหรือตรงกับรายการประมวลผลที่ประกาศหรือไม่ ซึ่งหน่วยงานรับผิดชอบจะต้องรายงาน EPDB ด้วย อ้างอิงตาม Article 35 (5)
•  

13 การประมวลผลที่มีอยู่ก่อนแล้วแต่พบว่าการประมวลนั้นมีความเสี่ยง หรือ พบว่ามีการเปลี่ยนบางอย่าง เช่น ลักษณะพื้นฐาน (nature) ขอบเขต บริบท หรือวัตถุประสงค์ การประมวลผล เช่นนี้ต้องจัดทำ DPIA

14 DPIA ไม่จำเป็นสำหรับการประมวลผลที่ได้รับการตรวจสอบแล้วโดยหน่วยงานรับผิดชอบ และการประมวลผลนั้นยังไม่มีการเปลี่ยนแปลงใด ๆ เพิ่มเติม

15 ในทางกลับกัน ต้องทำ DPIA ถ้ามีการเปลี่ยนแปลงใด ๆ เช่น ขอบเขต วัตถุประสงค์ รายการข้อมูลส่วนบุคคลที่เก็บรวบรวม มีการเปลี่ยนแปลงข้อมูลเกี่ยวกับตัว data controller และผู้รับข้อมูล ระยะเวลาการเก็บรักษาข้อมูล มาตรการทางเทคนิคและเชิงการจัดการ ซึ่งการเปลี่ยนแปลงเหล่านี้เกิดขึ้นหลังจากการตรวจประเมินโดยหน่วยงานหรือเจ้าหน้าที่รับผิดชอบ และเปลี่ยนแปลงเหล่านี้มีโอกาสสร้างความเสี่ยงสูงขึ้น เช่น ในกรณีมีการนำเทคโนโลยีใหม่มาใช้ หรือวัตถุประสงค์การประมวลผลเปลี่ยน หรืออาจจะมาจาก บริบททางสังคมคมหรือเชิงองค์กรเปลี่ยน เช่น การเริ่มใช้การประมวลผลและตัดสินใจอัตโนมัติ หรือมีกลุ่ม data subjects กลุ่มใหม่ (เช่น เด็ก) เข้ามาเกี่ยวข้องเพิ่มเติม (และ/หรืออาจมีการแบ่งแยกการให้บริการ แบ่งชนชั้น)

ในทางตรงข้าม การเปลี่ยนแปลงบางอย่างอาจทำให้ความเสี่ยงลดลงก็เป็นได้ เช่น ลักษณะรูปแบบการประมวลผลที่นำเอาเทคโนโลยีประมวลผลอัตโนมัติออกไป หรือ ทำให้การตรวจตรา (monitoring) ไม่เป็นการทำด้วยระบบ (systematic) อีกต่อไป ซึ่งก็หมายความว่า DPIA ก็ไม่จำเป็นอีกต่อไป เช่นนี้ หากเดิมยังไม่ได้ทำ DPIA แล้วต่อมามีการเปลี่ยนแปลง แต่การเปลี่ยนแปลงนั้น ทำให้ความเสี่ยงลดลง ดังนั้น จึงไม่ต้องจัดทำ DPIA

แนวทางการดำเนินการที่ดีคือ DPIA ควรจะได้รับการทบทวนและประเมินใหม่อย่างสม่ำเสมอ

16 ควรทำ DPIA เมื่อไหร่

คำตอบ เร็วที่สุดก่อนการออกแบบและพัฒนาระบบ

การทบทวนและปรับปรุง DPIA ตลอดระยะเวลาการพัฒนาระบบ ก็ยิ่งทำให้ผลการพัฒนาระบบนั้น มั่นใจได้มากขึ้นว่าจะเป็นไปตามที่กฎหมายกำหนด

• จำเป็นต้องกลับมาทบทวนซ้ำในแต่ละขั้นตอนของ DPIA ด้วย เนื่องจากระหว่างการพัฒนาระบบอาจเกิดการเปลี่ยนแปลงมาตรการทางเทคนิคและบริบทขององค์กร อาจมีผลกระทบต่อความเสี่ยงให้เปลี่ยนแปลงไป
• ไม่ควรใช้ข้ออ้างที่ว่า DPIA ต้องทำก่อนเกิดการประมวลผลข้อมูลมาใช้ผัดผ่อนการทำ DPIA ไปจนใกล้ ๆ จะเริ่มทำการประมวลผล เน้นว่าการทำ DPIA เป็นกระบวนการที่ทำต่อเนื่อง (continual process) ไม่ใช่ทำครั้งเดียวจบ (one-time process)

17 ใครต้องเป็นผู้จัดทำ DPIA

คำตอบ data controller ร่วมกันกับ DPO และ data processor  ส่วนผู้ที่ลงมือจัดทำ DPIA จริง ๆ จะเป็นคนใน หรือ นอกองค์กรก็ได้  อย่างไรก็ตามผู้รับผิดชอบยังคงเป็น data controller

data controller ต้องปรึกษา DPO ด้วย และตัดสินใจจากตัวเลือกต่าง ๆ ที่แนะนำโดย DPO (ตาม Article 35 (2) ระบุให้ระบุไว้ในเอกสาร DPIA ด้วยว่าเลือกตัวเลือกใด พร้อมเหตุผลการเลือก (Article 39 (1) (c)) 

หมายเหตุ ข้อปฏิบัติเพิ่มเติมดูได้จาก  Guidelines on Data Protection Officer 16/EN WP 243.

18 data controller ต้องทำการสำรวจความคิดเห็นของ data subject ด้วย

• การได้มาเพียงความยินยอมให้เก็บรวบรวมข้อมูล (consent) ไม่ใช่การสำรวจความเห็น
• เนื่องจากการประมวลผล ยังไม่เกิดขึ้นจริง จึงเป็นเพียงการสำรวจความเห็นของผู้ที่คาดว่าจะเป็น data subject (prospect data subject)
• หากการตัดสินของ data controller ไม่ตรงกับความเห็นของ data subject จะต้องมีการเขียนอธิบายเหตุผลไว้ด้วยว่าเหตุใดจึงตัดสินทำ หรือ ไม่ทำอะไร
• หาก data controller ตัดสินใจไม่ดำเนินการสำรวจความเห็นของ data subject ก็จะต้องทำการบันทึกเหตุผลเป็นเอกสารไว้ด้วย เช่น ถ้าทำอาจทำให้เกิดความลับทางธุรกิจรั่วไหล แผนธุรกิจ หรือเป็นเรื่องไม่เหมาะสม หรือ ปฏิบัติไม่ได้เนื่องด้วยข้อจำกัดอย่างอื่น

•  

19 ควรจะทำเอกสารที่ระบุบทบาท ความรับผิดชอบ ที่เกี่ยวพันกับนโยบายภายใน กระบวนการ และกฎระเบียบต่าง ๆ

• ระบุทีมงานที่มีหน้าที่เตรียมข้อมูลและเนื้อหาสำหรับการทำ DPIA และทีมงานนี้ควรเข้าไปมีส่วนร่วมในการตรวจสอบความถูกต้องของ DPIA เมื่อจัดทำเสร็จด้วย
• ควรจะมีการระบุให้ขอคำแนะนำจากที่ปรึกษาอิสระที่มาจากสายอาชีพต่างๆ (กฎหมาย เทคโนโลยีสารสนเทศ ความมั่นคงปลอดภัย สังคมศาสตร์ จริยธรรม ฯลฯ)
• บทบาทและความรับผิดชอบของ data processors จะต้องกำหนดเป็นสัญญาตกลงชัดเจน และ การจัดทำ DPIA ต้องได้รับความร่วมมือจาก data processor ด้วย ทั้งนี้ให้พิจารณาธรรมชาติการประมวลผลและข้อมูลที่มีให้ data processor สำหรับไปประเมินความเสี่ยง (Article 28(3) (f))

20 Chief Information Security Officer (CISO) (ถ้ามีการแต่งตั้ง) ให้ร่วมมือกับ DPO ในการช่วยสนับสนุนข้อมูลให้ controller จัดทำ DPIA สำหรับการประมวลผลที่มีความจำเพาะ และควรช่วยอำนวยความสะดวกให้แก่ผู้มีส่วนได้เสียในเรื่องกระบวนการจัดทำ ช่วยประเมินคุณภาพของการประเมินความเสี่ยง และประเมินด้วยว่าความเสี่ยงอยู่ในระดับที่ยอมรับได้ ตลอดจนสร้างองค์ความรู้ในบริบทที่เกี่ยวข้องกับ data controller

หมายเหตุ CISO และ/หรือ (ฝ่าย IT) ควรจะให้ความช่วยเหลือ data controller และยังสามารถช่วยดำเนินการ DPIA ในบางหัวข้อด้วย โดยเฉพาะที่เกี่ยวกับ security

21 รายการหัวข้อที่ควรปรากฎใน DPIA

• คำอธิบายการประมวลผลที่คาดการณ์และจุดประสงค์การประมวลผล
• การประเมินความจำเป็น และความสมเหตุผลในการประมวลผล
• การประเมินระดับความเสี่ยง ที่มีต่อสิทธิและเสรีภาพของ data subject มีแง่มุมไหนอะไรบ้าง
• มาตรการที่ใช้ (ลดความเสี่ยง) ต้องแสดงให้เห็นว่า
  • จะลดความเสี่ยงได้อย่างไร
  • แสดงให้เห็นว่าสอดคล้องกับกฎหมายคุ้มครองข้อมูลส่วนบุคคลอย่างไร ข้อไหน

รูปอธิบายกระบวนการจัดทำ DPIA (ลักษณะเป็นวัฏจักร)

22 การปฏิบัติตามข้อปฏิบัติ/จรรยาบรรณองค์กร (code of conduct) ของ data controller และ data processor อย่างสอดคล้องกันกับกฎหมายคุ้มครองข้อมูลส่วนบุคคล (Article 40 แนะนำให้หน่วยงานรับผิดชอบส่งเสริมให้เอกชน/รัฐ ดำเนินการจัดทำ/ปรับปรุง จรรยาบรรณ)

23 สามารถนำเอาหลักฐานการปฏิบัติตามข้อปฏิบัติ/จรรยาบรรณองค์กร (code of conduct) ของ data controller และ data processor มาใช้เป็นหลักฐานยืนยันได้ว่ามีการดำเนินการเพื่อให้เป็นไปตามกฎหมายแล้ว (เนื่องจากมีการใส่ลงในข้อปฏิบัติ/จรรยาบรรณองค์กร) ทั้งนี้ภายใต้สมมติฐานว่าจรรยาบรรณองค์กร ได้ถูกกปรับให้สอดคล้องกฎหมายคุ้มครองข้อมูลส่วนบุคคลไว้ก่อนแล้ว

• ข้อปฏิบัติ/จรรยาบรรณ ควรต้องแสดงให้เห็นว่ามาตรการที่เพียงพอและเหมาะสมได้ถูกคัดเลือกและนำมาใช้
• ควรมีการออกใบรับรอง ตราประทับ และเครื่องหมาย (ออกโดย controller และ processor ตาม Article (42)) เพื่อจุดประสงค์ในการสาธิตให้เห็นว่าสอดคล้องตาม GDPR นอกจากนี้ควรนำประเด็นนโยบายหรือกฎเกณฑ์การให้ความคุ้มครองข้อมูลส่วนบุคคลภายในองค์กร (Binding Corporate Rule (BCR)) เข้ามาพิจารณาด้วย
•  

หมายเหตุ ใน GDPR Article 40 ยังระบุให้หน่วยงานที่มีอำนาจหน้าที่เรื่องกฎหมายคุ้มครองข้อมูลส่วนบุคคล ดำเนินการส่งเสริมให้เอกชน/รัฐ ทำการจัดทำ/ปรับปรุง จรรยาบรรณ ของตนให้สอดคล้องกับกฎหมายคุ้มครองฯ ด้วย

24 GDPR เพียงแค่จัดเตรียมหลักการแนวคิดเบื้องต้นเรื่อง DPIA ให้เท่านั้น เมื่อ data controller (ไม่ว่ารายเล็กหรือใหญ่) ไปจัดทำ DPIA ก็จะสามารถจัดทำโดยใส่รายละเอียดและออกแบบให้เหมาะกับการประมวลผลของตน (แปลว่า DPIA ออกแบบให้ scale ได้)

Recital 90 (คำอธิบายขยายความข้อที่ 90) ของ GDPR ระบุองค์ประกอบของ DPIA ไว้จำนวนหนึ่ง ซึ่งซ้ำกับที่ระบุไว้ใน ISO 31000 (risk management) ที่กำหนดมาตรฐานองค์ประกอบของการบริหารจัดการความเสี่ยง (ทั่ว ๆ ไป ไม่ได้เน้นไปที่ข้อมูลส่วนบุคคล) ไว้ 

DPIA ในส่วนชอง Risk management แบ่งเป็น 3 ขั้นตอนคือ

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

หมายเหตุ สังเกตว่า GDPR เป็นเครื่องมือสำหรับบริหารจัดการความเสี่ยง โดยพิจารณาสิทธิ เสรีภาพของ data subject เป็นที่ตั้ง  ดังนั้น GDPR จึงให้ความสำคัญกับมุมมองต่าง ๆ ของ data subject (เช่น มุมมองความมั่นคงปลอดภัยทางสังคม) ในขณะที่ risk management ในสายงานอื่น (เช่น information security) จะเน้นไปที่ความเสี่ยงที่เกิดกับองค์กรเป็นตัวตั้ง

25 จำเป็นต้องเผยแพร่เอกสาร DPIA หรือไม่ ?

คำตอบ ไม่จำเป็น เนื่องจากกฎหมายฯ ไม่ได้กำหนดว่าให้ data controller ต้องเผยแพร่ DPIA

แต่หากจะเผยแพร่ ก็เป็นสิทธิของ data controller และจะเลือกเผยแพร่ทั้งหมด หรือบางส่วนก็ได้ เช่น อาจจะเลือกเผยแพร่ให้กลุ่ม data subjects ที่ได้รับผลกระทบจากการประมวลผลนั้น ๆ ก็ได้ หรือกรณีองค์กรรัฐเลือกเผยแพร่ DPIA เพื่อแสดงความโปร่งใสความน่าเชื่อถือ

การเผยแพร่เอกสาร DPIA นั้นจะช่วยสร้างความน่าเชื่อถือ โดยอาจเผยแพร่เฉพาะเอกสารสรุปก็ได้ ส่วนเอกสารฉบับเต็มนั้น ควรส่งให้กับหน่วยงานรับผิดชอบเพื่อขอความเห็นชอบ หรือ เมื่อได้รับการร้องขอจาก DPA (Data Protection Authorities เทียบได้กับ สคส.ของไทย)

นอกจากนี้ ในกรณีที่ DPIA แสดงให้เห็นว่ามีความเสี่ยงที่ไม่อาจบริหารจัดการได้ data controller จะต้องร้องขอความเห็นจาก DPA ก่อนทำการประมวลผลข้อมูล

26 เมื่อใดจึงควรต้องขอความเห็นจากหน่วยงานผู้รับผิดชอบ ?

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

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

• ทำการเข้ารหัส (encrypt) ข้อมูลทั้งหมดในฮาร์ดดิสค์
• การบริหารจัดการและให้มีกุญแจสำหรับไขเข้าออกห้องทำงานหรือห้องคอมพิวเตอร์
• การตรวจจับการเข้าถึง (access control) ผ่านระบบ
• การสำรองข้อมูลที่มั่นคงปลอดภัย

ทั้งนี้ให้นำปัจจัยด้านเทคโนโลยีในปัจจุบัน และต้นทุนมาร่วมพิจารณาด้วย ตลอดจนหลักปฏิบัติ ที่เกี่ยวข้องจาก EDPB และหน่วยงานรับผิดชอบ

สำหรับกรณีตัวอย่างเรื่อง laptop หาก data controller จัดการความเสี่ยงจนอยู่ในระดับที่ต่ำได้ ก็ไม่มีความจำเป็นต้องหารือกับหน่วยงานรับผิดชอบ สามารถดำเนินการต่อได้เลยหลังจากทำ DPIA เสร็จสิ้น

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

27 สรุป DPIA เป็นแนวทางที่เป็นประโยชน์สำหรับ data controller ที่จะช่วยให้การพัฒนาระบบประมวลผลข้อมูลที่มีความเสี่ยงสูงเป็นไปตาม GDPR

การประมวลผลบางประเภท DPIA ตัวเลือก แต่ในบางประเภท DPIA เป็นสิ่งที่ต้องดำเนินการ

GDPR ได้กำหนดความต้องการพื้นฐานของ DPIA ที่ดีไว้ แต่รูปแบบดังกล่าวยืดหยุ่นพอให้ DPIA นั้นสามารถปรับขนาดได้ (ตามประเภทการประมวลผล ปริมาณข้อมูลและขนาดกิจการ) และสามารถอยู่ในรูปแบบหลายรูปแบบ

data controller ควรจะมองว่าการทำ DPIA เป็นกิจกรรมที่เป็นประโยชน์ช่วยให้สามารถดำเนินการให้เป็นไปตามข้อกำหนดของกฎหมาย อีกทั้งยังมีผลดี คือ จะเสริมความเชื่อมั่นและความไว้ใจของ data subject และ data controllers รายอื่น

หากวางแผนว่าจะทำการประมวลผลที่มีความเสี่ยงสูง data controller สามารถเลือกวิธีการ (ตัวอย่างให้ไว้ใน ภาคผนวก 1) ที่ตอบเกณฑ์ที่ระบุไว้ในภาคหนวก 2 หรือระบุและดำเนินการจัดทำ DPIA อย่างเป็นระบบ เช่น

• ถูกบูรณาการเข้าไปในกระบวนการออกแบบ การพัฒนา การเปลี่ยนแปลง การทบทวนความเสี่ยงและการปฏิบัติการ โดยให้สอดคล้องกับกระบวนการภายใน บริบท และวัฒนธรรม
• ดึงการมีส่วนร่วมของฝ่ายต่าง ๆ ที่สนใจพร้อมระบุบทบาทความรับผิดชอบ (controller, DPO, data subjects (หรือตัวแทน), ภาคธุรกิจ, การบริการทางเทคนิค, ผู้ประมวลผล, เจ้าหน้าที่ความมั่นคงปลอดภัยข้อมูล, ฯลฯ)
• จัดเตรียม รายงาน DPIA ให้กับหน่วยงานรับปิดชอบ เมื่อได้รับการร้องขอ
• หารือแนวทางการดำเนินการกับหน่วยงานรับผิดชอบเมื่อพบว่าไม่สามารถกำหนดมาตรการที่เพียงพอต่อการบรรเทาความเสี่ยงได้
• ทบทวน DPIA เป็นระยะ ๆ และการประเมินผลที่ถูกประเมินโดย DPIA และอย่างน้อยเมื่อเกิดการเปลี่ยนแปลงความเสี่ยงที่เคยถกประเมินไว้

จัดทำผลการตัดสินไว้เป็นลายลักษณ์อักษรภาคผนวก 1
ตัวอย่าง DPIA Framework ของยุโรป (EU DPIA Framework)

GDPR มิได้บังคับกระบวนการที่ใช้ในการทำ DPIA โดยอนุญาตให้ data controller สามารถกำหนดกรอบการทำงานขึ้นมาเองได้ เพียงแต่ขอให้สอดคล้องตามหลักปฏิบัติที่อธิบายไว้ใน Article 35(7) (ดูรายละเอียดของ Article 35(7) ได้ใน ภาคผนวก 2 เกณฑ์สำหรับ DPIA)

สำหรับกรอบการทำงานที่มีการเผยแพร่ไว้แล้ว โดย สำนักงานคุ้มครองข้อมูลส่วนบุคคลของสหภาพยุโรป และโดยกลุ่มอุตสาหกรรมเฉพาะ ได้ถูกรวบรวมบางส่วนไว้ดังนี้

ตัวอย่างของ EU generic frameworks:

• The Standard Data Protection Model A concept for inspection and consultation on the basis of unified protection goals
  https://www.huntonprivacyblog.com/wp-content/uploads/sites/28/2017/04/SDM-Methodology_V1_EN1.pdf
• PRIVACY IMPACT ASSESSMENT (PIA) Methodology (how to carry out a PIA)
  https://www.cnil.fr/sites/default/files/typo/document/CNIL-PIA-1-Methodology.pdf
• Conducting privacy impact assessments code of practice
  https://iapp.org/media/pdf/resource_center/ICO_pia-code-of-practice.pdf
• Privacy Impact Assessment Handbook Version 2.0
  http://www.rogerclarke.com/DV/ICO-2007-V2.pdf

ตัวอย่างของ EU sector-specific frameworks:

• Privacy and Data Protection Impact Assessment Framework for RFID Applications32.
  http://ec.europa.eu/justice/data-protection/article-29/documentation/opinion-recommendation/files/2011/wp180_annex_en.pdf
• Data Protection Impact Assessment Template for Smart Grid and Smart Metering systems
  http://ec.europa.eu/energy/sites/ener/files
  /documents/2014_dpia_smart_grids_forces.pdf
• ISO/IEC 29134: 2017 Information technology — Security techniques — Guidelines for privacy impact assessment.

ภาคผนวก 2
เกณฑ์สำหรับ DPIA

1. มีการอธิบายกระบวนการประมวลผลอย่างเป็นระบบ (ระบุใน Article 35(7) (a)) โดยมีหัวข้อต่อไปนี้
   1. อธิบายธรรมชาติ ขอบเขต บริบท และจุดประสงค์ ของการประมวลผล (GDPR Recital 90)
   2. รายการข้อมูลส่วนบุคคล ผู้รับ และระยะเวลาซึ่งข้อมูลส่วนบุคคลนั้นจะถูกจัดเก็บและบันทึกไว้
   3. คำอธิบายฟังก์ชั่นการทำงานที่เกี่ยวกับประมวลผลข้อมูล เพื่อให้ทราบว่าประมวลผลอย่างไร
   4. สินทรัพย์และเครื่องมือต่าง ๆ ที่เกี่ยวข้องและนำมาใช้กับการประมวลผลข้อมูลส่วนบุคคล (hardware, software, เครือข่าย, บุคลากร, เอกสาร และช่องทางการส่งเอกสาร)
   5. การปฏิบัติตามกฎหมายฯ พร้อมระบุหัวข้อในจรรยาบรรณธุรกิจ ที่สอดคล้องกัน (กำหนดไว้ใน Article 35(8))
2. มีการประเมินความจำเป็นและความเหมาะสม (Article 35(7)(b))
   1. วางมาตรการลดความเสี่ยงล่วงหน้า โดยนำ Article 35(7)(d) และ Recital 90 มาพิจารณาร่วมด้วย
      1. ระบุจุดประสงค์ที่ชัดเจนและมีเหตุผลประกอบ (Article 5(1)(b))
      2. ระบุฐานกฎหมายที่ใช้ในการประมวลผล (เลือกที่เหมาะสมตามที่ระบุใน Article 6)
      3. รายการข้อมูลที่จำเป็นต้องใช้ประมวลผล Article 5(1)(c)
      4. ระยะเวลาที่จัดเก็บข้อมูลไว้ Article 5(1)(e)
   2. มาตรการที่ให้การดูแลสิทธิของ data subject
      1. ให้ข้อมูลแก่ data subject ทราบ (ตามที่ระบุใน Articles 12, 13 and 14)
      2. สิทธิในการเข้าถึงข้อมูลและสิทธิเกี่ยวกับการถ่ายโอนข้อมูลให้ผู้บริการรายอื่น (กรณี data subject ต้องการเปลี่ยนผู้ให้บริการ) (Articles 15 and 20)
      3. สิทธิในการขอให้แก้ไขข้อมูลและให้ลบข้อมูล (Articles 16, 17 and 19)
      4. สิทธิในการคัดค้านและจำกัดการประมวลผล (Article 18, 19 and 21)
      5. ลักษณะความสัมพันธ์ระหว่างdata controller กับ data processor (Article 28)
      6. การระวังป้องกันข้อมูลกรณีมีการถ่ายโอนข้ามประเทศ (ปฏิบัติตาม Chapter 5 Transfers of personal data to third countries or international organizations ซึ่งประกอบด้วย Article 44-50)
      7. การปรึกษาหารือ (prior consultation) กับหน่วยงานรับผิดชอบ (Article 36)

3. ความเสี่ยงต่อสิทธิและเสรีภาพของ data subject ได้รับการใส่ใจและจัดการ Article 35 (7)(c)
   1. ต้นต่อของความเสี่ยงถูกนำมาพิจารณา
   2. ผลกระทบต่อสิทธิและเสรีภาพของ data subjects ได้รับการชี้จำเพาะแยกเป็นประเด็น ๆ สำหรับเหตุการณ์ต่าง ๆ เช่น การเข้าถึงข้อมูลโดยมิชอบด้วยกฎหมาย การแก้ไขข้อมูลโดยไม่รับอนุญาต และการสูญหายของข้อมูล
   3. การคุกคามที่อาจนำไปสู่การเข้าถึงข้อมูลโดยมิชอบด้วยกฎหมายและการแก้ไขข้อมูลโดยไม่รับอนุญาต
   4. มีการประเมินโอกาสที่จะเกิดเหตุและระดับความรุนแรง (Recital 90)
   5. กำหนดมาตรการรองรับความเสี่ยงต่าง ๆ ที่ได้วิเคราะห์ไว้ (Article 35(7)(d) and Recital 90)
4. การมีส่วนร่วมของฝ่ายต่างๆ ที่เกี่ยวข้อง
   1. มีการรับคำปรึกษาจาก Data Protection Officer (Article 35(2))
   2. รับฟังความคิดเห็นจาก data subject (หรือตัวแทน)  Article 35(9)

https://www.facebook.com/monsaks