องค์กรอาจมีทะเบียนความเสี่ยง เอกสารแสดงการประยุกต์ใช้ หรือ Statement of Applicability: SoA และแผนการจัดการความเสี่ยงที่ครบถ้วน แต่ยังไม่ถือว่ากระบวนการจัดการความเสี่ยงสมบูรณ์ หากมาตรการที่กำหนดไว้ยังไม่ถูกนำไปปฏิบัติจริง
ISO/IEC 27001:2022 ข้อ 8.3 จึงเป็นข้อกำหนดที่เชื่อมโยงการวางแผนด้านความเสี่ยงเข้ากับการดำเนินงานจริงของ ระบบบริหารจัดการความมั่นคงปลอดภัยสำหรับสารสนเทศ หรือ ISMS
ข้อกำหนดนี้มุ่งให้องค์กร
- นำแผนการจัดการความเสี่ยงด้านความมั่นคงปลอดภัยสำหรับสารสนเทศไปปฏิบัติ
- เก็บรักษาสารสนเทศที่เป็นเอกสารเกี่ยวกับผลของการจัดการความเสี่ยง
หัวใจของข้อ 8.3 จึงไม่ใช่เพียงการมีแผน แต่ต้องสามารถแสดงได้ว่าแผนถูกดำเนินการ มีหลักฐานรองรับ และให้ผลต่อความเสี่ยงตามที่องค์กรคาดหวัง
ข้อ 6.1.3 และข้อ 8.3 แตกต่างกันอย่างไร?
ข้อกำหนดทั้งสองเกี่ยวข้องกับการจัดการความเสี่ยง แต่มีหน้าที่ต่างกัน
| ข้อกำหนด | หน้าที่ |
|---|---|
| 6.1.3 | กำหนดกระบวนการ เลือกทางเลือก กำหนดมาตรการ จัดทำ SoA และจัดทำแผนการจัดการความเสี่ยง |
| 8.3 | นำแผนการจัดการความเสี่ยงไปปฏิบัติ และเก็บรักษาผลของการดำเนินการ |
กล่าวอย่างง่ายคือ ข้อ 6.1.3 ตอบว่า “จะจัดการความเสี่ยงอย่างไร” ส่วนข้อ 8.3 ตอบว่า “ได้ดำเนินการตามแผนแล้วหรือไม่ และเกิดผลอย่างไร”
แผนการจัดการความเสี่ยงควรมีข้อมูลอะไร?
ISO/IEC 27001 ไม่ได้กำหนดแบบฟอร์มตายตัว แต่องค์กรควรจัดทำแผนให้สามารถนำไปปฏิบัติ ติดตาม และตรวจสอบย้อนหลังได้
แผนที่ระบุเพียงชื่อมาตรการกับผู้รับผิดชอบอาจยังไม่เพียงพอ เพราะไม่สามารถตอบได้ว่าเมื่อใดงานจึงถือว่าเสร็จ และจะตรวจสอบผลอย่างไร
กำหนดเกณฑ์การเสร็จสมบูรณ์ของแต่ละมาตรการ
องค์กรไม่ควรปิดแผนเพียงเพราะติดตั้งระบบเสร็จหรือออกเอกสารแล้ว แต่ควรกำหนด เกณฑ์การเสร็จสมบูรณ์ หรือ Definition of Done ให้ชัดเจน
ตัวอย่างเช่น มาตรการ “จัดทำระบบสำรองข้อมูล ERP” ไม่ควรถือว่าเสร็จเพียงเพราะตั้งค่าการสำรองข้อมูลแล้ว แต่ควรครอบคลุมถึง
- ระบุระบบและข้อมูลที่อยู่ในขอบเขตการสำรอง
- กำหนดรอบการสำรอง
- เปิดการแจ้งเตือนเมื่อการสำรองล้มเหลว
- ทดสอบการกู้คืน
- ตรวจสอบว่าข้อมูลที่กู้คืนสามารถใช้งานได้
- บันทึกผลและข้อบกพร่อง
- ให้เจ้าของระบบทบทวนผล
ตัวอย่างเกณฑ์การเสร็จสมบูรณ์:
ถือว่ามาตรการเสร็จสมบูรณ์เมื่อการสำรองข้อมูลทำงานตามรอบ การทดสอบกู้คืนสำเร็จ และเจ้าของระบบยืนยันว่าข้อมูลที่กู้คืนสามารถรองรับกระบวนการที่กำหนดได้
แยกการนำไปปฏิบัติออกจากการยืนยันประสิทธิผล
การประยุกต์ใช้ข้อ 8.3 ที่เหมาะสมควรแยกสองประเด็นออกจากกัน
1. การนำไปปฏิบัติ
หมายถึงองค์กรได้ดำเนินกิจกรรมหรือนำมาตรการควบคุมไปใช้แล้ว
ตัวอย่างเช่น
- เปิดใช้งานการยืนยันตัวตนหลายปัจจัย
- ติดตั้งระบบสำรองข้อมูล
- เปิดบันทึกเหตุการณ์
- กำหนดบัญชีผู้ใช้รายบุคคล
- ประกาศใช้นโยบาย
- จัดอบรมผู้ใช้งาน
2. การยืนยันประสิทธิผล
หมายถึงมาตรการทำงานตามวัตถุประสงค์และช่วยจัดการความเสี่ยงได้จริง
ตัวอย่างเช่น
- บัญชีที่อยู่ในขอบเขตเปิดใช้การยืนยันตัวตนหลายปัจจัยครบถ้วน
- สามารถกู้คืนข้อมูลได้จริง
- ไม่มีบัญชีร่วมในระบบสำคัญ
- บันทึกเหตุการณ์มีข้อมูลเพียงพอสำหรับตรวจสอบย้อนหลัง
- มีหลักฐานการทบทวนบันทึกเหตุการณ์ตามรอบ
- สิทธิ์การเข้าถึงสอดคล้องกับหน้าที่ที่ได้รับอนุมัติ
ดังนั้น สถานะ “ดำเนินการเสร็จแล้ว” ไม่ควรถูกใช้แทน “ยืนยันประสิทธิผลแล้ว” โดยอัตโนมัติ
กำหนดเกณฑ์การยอมรับผลของมาตรการควบคุม
ก่อนเริ่มดำเนินการ องค์กรควรกำหนดว่าต้องมีผลลัพธ์หรือหลักฐานใด จึงจะถือว่ามาตรการควบคุมได้รับการดำเนินการครบถ้วน
| มาตรการควบคุม | เกณฑ์การยอมรับผลตัวอย่าง |
|---|---|
| การยืนยันตัวตนหลายปัจจัย | บัญชีในขอบเขตเปิดใช้งานครบและผ่านการทดสอบ |
| การสำรองข้อมูล | การสำรองสำเร็จตามรอบและการทดสอบกู้คืนผ่าน |
| การทบทวนสิทธิ์ | เจ้าของข้อมูลทบทวนครบและแก้ไขสิทธิ์ที่ไม่เหมาะสมแล้ว |
| การบันทึกเหตุการณ์ | ระบบบันทึกข้อมูลที่กำหนดและมีหลักฐานการทบทวน |
| การแบ่งแยกเครือข่าย | ผลการทดสอบยืนยันว่าการเชื่อมต่อที่ไม่ได้รับอนุญาตถูกปิดกั้น |
| การแก้ไขช่องโหว่ | ช่องโหว่ได้รับการแก้ไข หรือมีข้อยกเว้นที่อนุมัติและกำหนดวันทบทวน |
เกณฑ์เหล่านี้ไม่ใช่ข้อกำหนดตายตัวของ ISO/IEC 27001 แต่ช่วยให้องค์กรควบคุมการปิดแผนได้อย่างมีเหตุผล
สร้างความเชื่อมโยงที่ตรวจสอบย้อนกลับได้
องค์กรควรสามารถติดตามความเชื่อมโยงตั้งแต่ความเสี่ยงไปจนถึงผลการดำเนินการได้
รหัสความเสี่ยง → การตัดสินใจจัดการความเสี่ยง → มาตรการควบคุม → SoA → แผนดำเนินการ → หลักฐานการนำไปปฏิบัติ → ผลการทวนสอบ → ความเสี่ยงที่เหลืออยู่ → การตัดสินใจของผู้เป็นเจ้าของความเสี่ยง
ตัวอย่าง:
| จุดเชื่อมโยง | ตัวอย่าง |
|---|---|
| รหัสความเสี่ยง | R-ERP-004 |
| ความเสี่ยง | ระบบ ERP ไม่พร้อมใช้เมื่อเซิร์ฟเวอร์หลักขัดข้อง |
| ทางเลือกในการจัดการ | ลดความเสี่ยง |
| มาตรการควบคุม | สำรองข้อมูลและทดสอบการกู้คืน |
| SoA | อ้างอิงมาตรการควบคุมที่เกี่ยวข้อง |
| การดำเนินการ | ติดตั้งระบบสำรองและกำหนดรอบการทดสอบ |
| หลักฐาน | รายงานการสำรองและผลการทดสอบกู้คืน |
| ผลการทวนสอบ | กู้คืนข้อมูลได้ภายในระยะเวลาที่กำหนด |
| ความเสี่ยงที่เหลืออยู่ | ลดจากระดับสูงเป็นปานกลาง |
| การตัดสินใจ | ผู้เป็นเจ้าของความเสี่ยงยอมรับและกำหนดรอบทบทวน |
ความเชื่อมโยงลักษณะนี้ช่วยให้องค์กรแสดงได้ว่าแต่ละมาตรการเกิดจากความเสี่ยงหรือข้อกำหนดใด และมีผลลัพธ์จริงอย่างไร
ชุดหลักฐานสำหรับข้อ 8.3
การมีแผนเพียงฉบับเดียวไม่เพียงพอ ชุดหลักฐานที่เหมาะสมอาจประกอบด้วย
- แผนการจัดการความเสี่ยงที่ได้รับอนุมัติ
ระบุขอบเขต ผู้รับผิดชอบ กำหนดเวลา และมาตรการ - บันทึกการเปลี่ยนแปลงหรือบันทึกโครงการ
เช่น หมายเลขคำขอเปลี่ยนแปลง หมายเลขโครงการ หรือใบสั่งงาน - หลักฐานการกำหนดค่าระบบ
เช่น รายงานค่าระบบ การส่งออกค่ากำหนด หรือภาพหน้าจอที่ตรวจสอบแหล่งที่มาได้ - ผลการทดสอบ
เช่น ผลการทดสอบกู้คืน ทดสอบสิทธิ์ ทดสอบการสลับระบบ หรือทดสอบการเชื่อมต่อ - บันทึกผลการปฏิบัติงาน
เช่น รายงานการสำรอง บันทึกการทบทวนสิทธิ์ หรือรายงานการติดตามระบบ - บันทึกข้อยกเว้นและประเด็นปัญหา
แสดงงานค้าง การเบี่ยงเบนจากแผน หรือข้อจำกัดที่ต้องติดตาม - บันทึกผลการทวนสอบ
แสดงผลการตรวจสอบว่ามาตรการทำงานตามวัตถุประสงค์ - ผลการประเมินความเสี่ยงที่เหลืออยู่
แสดงระดับความเสี่ยงหลังดำเนินมาตรการ - ผลการตัดสินใจของผู้เป็นเจ้าของความเสี่ยง
เช่น การยอมรับผล การยอมรับความเสี่ยงที่เหลืออยู่ หรือคำสั่งให้เพิ่มมาตรการ
ผู้รับผิดชอบแต่ละบทบาทต่างกันอย่างไร?
ผู้รับผิดชอบการดำเนินการ
เป็นผู้ดำเนินกิจกรรมเฉพาะในแผน เช่น
- ติดตั้งระบบ
- ปรับค่าระบบ
- จัดทำขั้นตอน
- ดำเนินการทดสอบ
- จัดอบรม
ผู้รับผิดชอบมาตรการควบคุม
เป็นผู้ดูแลให้มาตรการควบคุมได้รับการดำเนินการ รักษาไว้ ติดตาม และทบทวนตามที่กำหนด
ผู้เป็นเจ้าของความเสี่ยง
เป็นผู้มีอำนาจและความรับผิดชอบในการตัดสินใจเกี่ยวกับความเสี่ยง เช่น
- อนุมัติแผน
- ติดตามความคืบหน้า
- พิจารณาผลของมาตรการ
- ยอมรับความเสี่ยงที่เหลืออยู่
- กำหนดให้มีมาตรการเพิ่มเติม
ตัวอย่างเช่น
- ทีมโครงสร้างพื้นฐานติดตั้งระบบสำรอง
- ฝ่ายปฏิบัติการ IT รับผิดชอบมาตรการสำรองและกู้คืน
- เจ้าของกระบวนการ ERP เป็นผู้เป็นเจ้าของความเสี่ยง
บุคคลทั้งสามบทบาทอาจเป็นคนละคนกัน
ตัวอย่างการนำแผนการจัดการความเสี่ยงไปปฏิบัติ
ตัวอย่างที่ 1 ระบบ ERP ไม่พร้อมใช้
ความเสี่ยง
เซิร์ฟเวอร์หลักขัดข้องและไม่มีผลการทดสอบกู้คืนล่าสุด อาจทำให้ระบบ ERP ไม่พร้อมใช้ ส่งผลให้ไม่สามารถยืนยันสินค้าและจัดทำเอกสารการจัดส่งได้ตามกำหนด
ผลต่อสารสนเทศ
ความพร้อมใช้ — Availability
ทางเลือกในการจัดการ
ลดความเสี่ยง
แผนการดำเนินการ
- กำหนดขอบเขตระบบและข้อมูลที่ต้องสำรอง
- จัดทำรอบการสำรองข้อมูล
- เปิดการแจ้งเตือนเมื่อการสำรองไม่สำเร็จ
- จัดทำขั้นตอนการกู้คืน
- ทดสอบการกู้คืน
- บันทึกระยะเวลาและข้อบกพร่อง
- กำหนดรอบการทดสอบครั้งถัดไป
เกณฑ์การยอมรับผล
- การสำรองข้อมูลสำเร็จตามรอบ
- การทดสอบกู้คืนผ่าน
- ข้อมูลที่กู้คืนสามารถใช้งานได้
- ข้อบกพร่องสำคัญได้รับการแก้ไข
- เจ้าของระบบทบทวนผลแล้ว
หลักฐาน
- รายงานค่าการสำรอง
- ประวัติงานสำรอง
- รายงานการทดสอบกู้คืน
- บันทึกเหตุการณ์
- บันทึกการทบทวนของเจ้าของระบบ
ตัวอย่างที่ 2 ผลตรวจสอบคุณภาพถูกแก้ไขโดยระบุผู้ดำเนินการไม่ได้
ความเสี่ยง
การใช้บัญชีร่วมและไม่มีประวัติการเปลี่ยนแปลงที่เพียงพอ อาจทำให้ข้อมูลผลตรวจถูกแก้ไขโดยไม่สามารถระบุผู้ดำเนินการ ส่งผลต่อความถูกต้องครบถ้วนของสารสนเทศ
ผลต่อสารสนเทศ
ความถูกต้องครบถ้วน — Integrity
มาตรการที่กำหนด
- ยกเลิกบัญชีร่วม
- ใช้บัญชีรายบุคคล
- จำกัดสิทธิ์การแก้ไข
- เปิดบันทึกประวัติการเปลี่ยนแปลง
- กำหนดการทบทวนบันทึก
- กำหนดการอนุมัติการแก้ไขข้อมูลสำคัญ
เกณฑ์การยอมรับผล
- ไม่มีบัญชีร่วมในระบบที่อยู่ในขอบเขต
- ผู้ใช้แต่ละรายสามารถระบุตัวตนได้
- บันทึกประวัติแสดงผู้ดำเนินการ เวลา ค่าเดิม และค่าใหม่
- มีหลักฐานการทบทวนตามรอบ
- การทดสอบสิทธิ์เป็นไปตามผลที่คาดหวัง
ตัวอย่างที่ 3 สิทธิ์เข้าถึงสูตรการผลิตไม่สอดคล้องกับหน้าที่
ความเสี่ยง
บุคลากรที่เปลี่ยนตำแหน่งยังคงเข้าถึงสูตรการผลิตได้ ทำให้มีความเสี่ยงต่อการเปิดเผยสารสนเทศที่ต้องรักษาความลับ
ผลต่อสารสนเทศ
ความลับ — Confidentiality
มาตรการที่กำหนด
- ระบุเจ้าของข้อมูล
- กำหนดสิทธิ์ตามบทบาท
- เชื่อมกระบวนการเปลี่ยนตำแหน่งกับการปรับสิทธิ์
- ทบทวนสิทธิ์ตามรอบ
- ยกเลิกสิทธิ์ที่ไม่มีความจำเป็น
- ติดตามการเข้าถึงข้อมูลสำคัญ
เกณฑ์การยอมรับผล
- สิทธิ์ตรงกับบทบาทที่อนุมัติ
- ผู้ใช้ที่เปลี่ยนหน้าที่ได้รับการปรับสิทธิ์แล้ว
- รายการผิดปกติจากการทบทวนสิทธิ์ได้รับการแก้ไขครบ
- เจ้าของข้อมูลอนุมัติผลการทบทวน
จัดการมาตรการที่ล่าช้าหรือทำไม่ได้ตามแผน
หากมาตรการล่าช้า งบประมาณไม่พร้อม หรือระบบไม่รองรับ องค์กรไม่ควรปล่อยสถานะ “อยู่ระหว่างดำเนินการ” ค้างไว้อย่างไม่มีกำหนด
ควรดำเนินการดังนี้
- ระบุสาเหตุของความล่าช้า
- ประเมินผลต่อระดับความเสี่ยง
- พิจารณามาตรการชั่วคราวหรือมาตรการทดแทน
- กำหนดวันเป้าหมายใหม่
- ขออนุมัติจากผู้มีอำนาจ
- แจ้งผู้เป็นเจ้าของความเสี่ยง
- บันทึกข้อยกเว้นและวันหมดอายุ
- ทบทวนว่าความเสี่ยงยังอยู่ในระดับที่ยอมรับได้หรือไม่
ตัวอย่างเช่น หากระบบเดิมยังไม่รองรับการยืนยันตัวตนหลายปัจจัย องค์กรอาจกำหนดมาตรการชั่วคราว ได้แก่
- จำกัดการเข้าถึงผ่านเครือข่ายที่กำหนด
- จำกัดจำนวนบัญชีผู้ใช้
- เพิ่มการติดตามบันทึกเหตุการณ์
- ทบทวนสิทธิ์ให้ถี่ขึ้น
- กำหนดวันยกเลิกข้อยกเว้น
- ขออนุมัติจากผู้เป็นเจ้าของความเสี่ยง
มาตรการชั่วคราวต้องได้รับการติดตามและไม่ควรกลายเป็นข้อยกเว้นถาวรโดยไม่มีการทบทวน
สถานะของแผนการจัดการความเสี่ยง
| สถานะ | ความหมาย |
|---|---|
| ยังไม่เริ่มดำเนินการ | ยังไม่มีการเริ่มกิจกรรมตามแผน |
| อยู่ระหว่างดำเนินการ | กำลังดำเนินกิจกรรม |
| ดำเนินการแล้วและรอการทวนสอบ | งานเสร็จ แต่ยังไม่ได้ตรวจสอบผล |
| ดำเนินการเสร็จแล้ว | กิจกรรมครบและมีหลักฐาน |
| ยืนยันประสิทธิผลแล้ว | ตรวจสอบแล้วว่ามาตรการให้ผลตามวัตถุประสงค์ |
| เกินกำหนด | ไม่เสร็จภายในวันที่เป้าหมาย |
| เลื่อนการดำเนินการโดยได้รับอนุมัติ | เลื่อนโดยมีเหตุผลและผู้มีอำนาจอนุมัติ |
| ข้อยกเว้นได้รับการอนุมัติ | มีการอนุมัติข้อยกเว้นและกำหนดวันทบทวน |
| ปิดแผนแล้ว | ตรวจสอบผล ประเมินความเสี่ยงที่เหลืออยู่ และบันทึกการตัดสินใจแล้ว |
ควรแยกสถานะ “ดำเนินการเสร็จแล้ว” ออกจาก “ยืนยันประสิทธิผลแล้ว” ให้ชัดเจน
การประเมินความเสี่ยงที่เหลืออยู่
หลังนำมาตรการไปปฏิบัติ องค์กรควรประเมินความเสี่ยงที่เหลืออยู่โดยใช้เกณฑ์ขององค์กร
ตัวอย่าง:
| รายการ | ก่อนจัดการ | หลังจัดการ |
|---|---|---|
| โอกาสเกิด | 4 | 2 |
| ผลกระทบ | 5 | 5 |
| ระดับความเสี่ยง | 20 | 10 |
ในกรณีนี้ มาตรการอาจช่วยลดโอกาสเกิด แต่หากเหตุการณ์เกิดขึ้น ผลกระทบต่อธุรกิจยังคงสูง จึงไม่ควรลดทั้งโอกาสเกิดและผลกระทบโดยอัตโนมัติ
หากความเสี่ยงที่เหลืออยู่ยังเกินเกณฑ์ องค์กรควร
- เพิ่มมาตรการ
- เปลี่ยนทางเลือกในการจัดการ
- ปรับกำหนดเวลา
- ยกระดับการตัดสินใจ
- ขอการยอมรับความเสี่ยงตามอำนาจที่กำหนด
ตัวชี้วัดที่ช่วยติดตามข้อ 8.3
แม้ข้อ 8.3 ไม่ได้กำหนดตัวชี้วัดตายตัว แต่องค์กรสามารถใช้ตัวชี้วัดเพื่อติดตามประสิทธิผลของการดำเนินงาน เช่น
- ร้อยละของแผนที่เสร็จภายในกำหนด
- จำนวนแผนที่เกินกำหนด
- จำนวนมาตรการที่รอการทวนสอบ
- ร้อยละของมาตรการที่มีหลักฐานครบถ้วน
- จำนวนข้อยกเว้นที่หมดอายุ
- จำนวนมาตรการที่ไม่ให้ผลตามวัตถุประสงค์
- ระยะเวลาเฉลี่ยในการปิดแผน
- จำนวนความเสี่ยงที่ยังเกินเกณฑ์หลังจัดการ
- จำนวนแผนที่ยังไม่ได้รับการทบทวนจากผู้เป็นเจ้าของความเสี่ยง
ตัวชี้วัดเหล่านี้ช่วยให้ผู้บริหารเห็นปัญหาด้านทรัพยากร ความล่าช้า การนำไปใช้ และประสิทธิผลของมาตรการ
Checklist ก่อนปิดแผนการจัดการความเสี่ยง ?
ก่อนเปลี่ยนสถานะเป็น “ปิดแผนแล้ว” ควรตรวจสอบว่า
- เชื่อมโยงกับรหัสความเสี่ยงที่ถูกต้อง
- ทางเลือกในการจัดการได้รับการอนุมัติ
- มาตรการสอดคล้องกับ SoA เมื่อเกี่ยวข้อง
- กิจกรรมครบตามแผน
- เกณฑ์การยอมรับผลผ่านครบ
- มีหลักฐานตรวจสอบย้อนหลังได้
- มีการทวนสอบผลของมาตรการ
- ข้อบกพร่องที่พบได้รับการจัดการ
- ประเมินความเสี่ยงที่เหลืออยู่แล้ว
- ผู้เป็นเจ้าของความเสี่ยงทบทวนผลแล้ว
- ปรับปรุงทะเบียนความเสี่ยงแล้ว
- กำหนดวันติดตามหรือวันทบทวนครั้งต่อไปแล้ว
ข้อผิดพลาดที่พบบ่อย ?
มีแผนแต่ไม่มีหลักฐานการดำเนินการ
แผนที่ได้รับอนุมัติไม่แสดงว่ามาตรการถูกนำไปปฏิบัติจริง
ใช้ภาพหน้าจอเพียงอย่างเดียว
ภาพหน้าจออาจแสดงค่าระบบ ณ ช่วงเวลาหนึ่ง แต่ไม่เสมอไปว่าจะพิสูจน์ว่ามาตรการทำงานอย่างต่อเนื่องหรือมีประสิทธิผล
ปิดงานทันทีหลังติดตั้ง
ควรมีการทวนสอบก่อนปิดแผน
ไม่มีเกณฑ์การยอมรับผล
ทำให้แต่ละฝ่ายเข้าใจคำว่า “เสร็จ” ไม่ตรงกัน
ไม่มีผู้เป็นเจ้าของความเสี่ยงร่วมตัดสินใจ
ผู้ติดตั้งมาตรการไม่ควรยอมรับความเสี่ยงทางธุรกิจแทนผู้เป็นเจ้าของความเสี่ยงโดยอัตโนมัติ
เปลี่ยนวันที่เป้าหมายโดยไม่มีการอนุมัติ
แผนที่ล่าช้าต้องมีเหตุผล การประเมินผลกระทบ และการอนุมัติ
เชื่อมโยงกับ Annex A ฉบับเก่า
หากองค์กรใช้ ISO/IEC 27001:2022 ต้องทบทวนหมายเลขและโครงสร้างมาตรการให้ตรงกับฉบับปี 2022
เลือกมาตรการทุกข้อใน Annex A โดยอัตโนมัติ
องค์กรต้องกำหนดมาตรการจากความเสี่ยงก่อน แล้วใช้ Annex A เป็นรายการอ้างอิงเพื่อตรวจสอบความครบถ้วน
ISO/IEC 27001 ข้อ 8.3 กำหนดให้องค์กรนำแผนการจัดการความเสี่ยงด้านความมั่นคงปลอดภัยสำหรับสารสนเทศไปปฏิบัติ และเก็บรักษาสารสนเทศที่เป็นเอกสารเกี่ยวกับผลของการจัดการความเสี่ยง
การประยุกต์ใช้ในระดับมืออาชีพควรแสดงให้เห็นว่า
- ความเสี่ยงใดได้รับการจัดการ
- เลือกทางเลือกใด
- ใช้มาตรการควบคุมอะไร
- ใครเป็นผู้รับผิดชอบการดำเนินการ ผู้รับผิดชอบมาตรการ และผู้เป็นเจ้าของความเสี่ยง
- กำหนดเกณฑ์การเสร็จสมบูรณ์และเกณฑ์การยอมรับผลไว้อย่างไร
- มีหลักฐานใดแสดงการนำไปปฏิบัติ
- ใครเป็นผู้ทวนสอบผล
- มาตรการมีประสิทธิผลหรือไม่
- ความเสี่ยงที่เหลืออยู่เปลี่ยนแปลงอย่างไร
- งานล่าช้าและข้อยกเว้นได้รับการควบคุมหรือไม่
- ผู้เป็นเจ้าของความเสี่ยงยอมรับผลหรือกำหนดให้มีมาตรการเพิ่มเติมหรือไม่
หัวใจของข้อ 8.3 จึงไม่ใช่เพียงคำว่า “ดำเนินการแล้ว” แต่ต้องตอบได้ว่า
ดำเนินการอย่างไร มีหลักฐานอะไร มาตรการทำงานตามที่ตั้งใจหรือไม่ และความเสี่ยงลดลงจริงหรือไม่
อยากให้แผนจัดการความเสี่ยงของคุณแสดงหลักฐานได้จริงตอนตรวจ?
Equal Assurance (Thailand) Ltd. ให้บริการฝึกอบรมและตรวจประเมินระบบ ISO/IEC 27001 โดยผู้ตรวจประเมินที่มีประสบการณ์จริง
บทความที่เกี่ยวข้อง: ISO/IEC 27001 ข้อ 6.1.3 การจัดการความเสี่ยง และ SoA · ISO/IEC 27001 ข้อ 8.2 ประเมินความเสี่ยงเมื่อใด · ISO/IEC 27001 ข้อ 6.1.2 การประเมินความเสี่ยง · คลังบทความทั้งหมด
ISO/IEC 27001:2022 Annex A — หมวดการควบคุมมีไว้ให้หาเจอ ไม่ได้มีไว้ให้ไล่ให้ครบ
ISO/IEC 27001 ข้อ 7.1 ทรัพยากรสำหรับระบบการจัดการความมั่นคงปลอดภัยสารสนเทศ
ISO/IEC 27001:2022 ข้อ 4.4 และ 6.1.1 ระบบการจัดการและความเสี่ยงระดับระบบ ตีความข้อกำหนด
ISO/IEC 27001 ข้อ 4.2 ความต้องการและความคาดหวังของผู้มีส่วนได้ส่วนเสีย
ISO/IEC 27001:2022 ข้อ 10.1 การปรับปรุงอย่างต่อเนื่อง พิสูจน์อย่างไรว่าระบบดีขึ้นจริง
ISO/IEC 27001 ข้อ 6.3 การวางแผนการเปลี่ยนแปลง: ตีความข้อกำหนดและตัวอย่างในบริบทไทย