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

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

ขั้นตอนที่ 1: กำหนดจุดกระตุ้นที่ต้องประเมินทุกครั้ง

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

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

ขั้นตอนที่ 2: สร้างแบบฟอร์มประเมินความเสี่ยงมาตรฐาน

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

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

ขั้นตอนที่ 3: ให้คะแนนโอกาสเกิดและผลกระทบ

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

ขั้นตอนที่ 4: ผูกผลประเมินเข้ากับขั้นตอนตรวจสอบก่อนปล่อยงาน

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

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

ขั้นตอนที่ 5: มอบหมายเจ้าของงานและกำหนดกรอบเวลาแก้ไข

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

ขั้นตอนที่ 6: บันทึกผลลงในทะเบียนความเสี่ยงกลาง

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

ขั้นตอนที่ 7: ทบทวนทะเบียนความเสี่ยงเป็นรอบ

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

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

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

ขั้นตอนที่ 8: ฝึกทีมโปรดักต์ให้ประเมินความเสี่ยงเบื้องต้นได้เอง

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

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

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

ขั้นตอนที่ 9: เตรียมแนวทางสื่อสารผลประเมินให้ผู้บริหารเข้าใจง่าย

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

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

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

trusty ช่วยสนับสนุนกระบวนการนี้ได้ที่จุดใดบ้าง

ผลจาก PDPA Readiness Scan และ Website Trust Scan สามารถใช้เป็นข้อมูลประกอบในขั้นตอนที่ 2 และ 3 ได้ เช่น ใช้ตรวจว่าสคริปต์ของบุคคลที่สามที่กำลังจะเชื่อมต่อมีพฤติกรรมอย่างไรบนหน้าเว็บทดสอบ แต่ผลสแกนไม่สามารถกรอกแบบฟอร์มประเมินหรือให้คะแนนความเสี่ยงแทนทีมได้ เพราะข้อมูลบริบทของกิจกรรม เช่น วัตถุประสงค์การใช้ข้อมูล ยังต้องมาจากทีมโปรดักต์โดยตรง

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

ต้องใช้ซอฟต์แวร์เฉพาะทางในการวางระบบ Privacy Risk Assessment หรือไม่

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

ควรผูกการประเมินเข้ากับขั้นตอนไหนของการพัฒนาฟีเจอร์

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

ถ้าทีมเล็กมากไม่มีคนรับผิดชอบด้านความเป็นส่วนตัวโดยตรงควรทำอย่างไร

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

ผลสแกนของ trusty ใช้แทนขั้นตอนที่ 2 และ 3 ได้เลยหรือไม่

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

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

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

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

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

สรุป

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

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

• NIST Privacy Framework