ISO/IEC 27001 ข้อ 6.1.3 การจัดการความเสี่ยงด้านความมั่นคงปลอดภัยสำหรับสารสนเทศ และการจัดทำ SoA

ISO/IEC 27001:2022 เป็นมาตรฐานข้อกำหนดสำหรับการจัดทำ นำไปปฏิบัติ รักษาไว้ และปรับปรุงระบบบริหารจัดการความมั่นคงปลอดภัยสำหรับสารสนเทศ หรือ ISMS โดยใช้กระบวนการที่อิงความเสี่ยงและปรับให้เหมาะสมกับบริบทขององค์กร

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

การจัดการความเสี่ยงด้านความมั่นคงปลอดภัยสำหรับสารสนเทศคืออะไร ?

คำว่า Information security risk treatment /การจัดการความเสี่ยงด้านความมั่นคงปลอดภัยสำหรับสารสนเทศ

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

ISO/IEC 27001 ข้อ 6.1.3 กำหนดให้องค์กรทำอะไร ?

สาระของข้อ 6.1.3 สามารถเรียงลำดับได้ดังนี้

1. เลือกทางเลือกในการจัดการความเสี่ยง
2. กำหนดมาตรการควบคุมทั้งหมดที่จำเป็น
3. เปรียบเทียบมาตรการควบคุมกับภาคผนวก A
4. จัดทำเอกสารแสดงการประยุกต์ใช้ หรือ SoA
5. จัดทำแผนการจัดการความเสี่ยง
6. ขออนุมัติแผนและการยอมรับความเสี่ยงที่เหลืออยู่จากผู้เป็นเจ้าของความเสี่ยง

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

1. เลือกทางเลือกในการจัดการความเสี่ยง

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

ลดหรือปรับเปลี่ยนความเสี่ยง

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

ตัวอย่างเช่น การทดสอบการกู้คืนข้อมูล การจำกัดสิทธิ์การเข้าถึง หรือการกำหนดการตรวจทานโดยผู้มีอำนาจ

หลีกเลี่ยงความเสี่ยง

องค์กรยุติหรือเปลี่ยนแปลงกิจกรรมที่เป็นต้นเหตุของความเสี่ยง

ตัวอย่างเช่น ยกเลิกการใช้งานระบบที่ไม่สามารถรักษาความมั่นคงปลอดภัยได้ตามความต้องการขององค์กร

แบ่งปันความเสี่ยง

องค์กรแบ่งความรับผิดชอบหรือผลกระทบบางส่วนกับบุคคลภายนอก เช่น ผู้ให้บริการหรือบริษัทประกันภัย

อย่างไรก็ตาม การทำสัญญากับผู้ให้บริการไม่ได้ทำให้องค์กรหมดความรับผิดชอบในการกำกับดูแลความเสี่ยง

ยอมรับความเสี่ยง

องค์กรตัดสินใจยอมรับความเสี่ยงตามเกณฑ์ที่กำหนด โดยต้องมีผู้มีอำนาจหรือผู้เป็นเจ้าของความเสี่ยงให้การยอมรับอย่างเหมาะสม

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

2. กำหนดมาตรการควบคุมทั้งหมดที่จำเป็น

หลังจากเลือกทางเลือกในการจัดการความเสี่ยงแล้ว องค์กรต้องกำหนด มาตรการควบคุมทั้งหมดที่จำเป็น เพื่อดำเนินการตามทางเลือกนั้น

มาตรการควบคุมอาจเป็นได้ทั้ง

• นโยบายหรือกฎระเบียบ
• การกำหนดบทบาทและความรับผิดชอบ
• กระบวนการอนุมัติและทบทวน
• การฝึกอบรมและสร้างความตระหนัก
• มาตรการด้านบุคลากร
• มาตรการทางกายภาพ
• มาตรการทางเทคโนโลยี
• การติดตาม ตรวจวัด และทบทวนผล

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

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

3. เปรียบเทียบมาตรการควบคุมกับภาคผนวก A

เมื่อองค์กรกำหนดมาตรการควบคุมที่จำเป็นแล้ว ต้องนำมาตรการเหล่านั้นไปเปรียบเทียบกับมาตรการควบคุมใน ISO/IEC 27001:2022 ภาคผนวก A วัตถุประสงค์ของการเปรียบเทียบคือ ตรวจสอบว่าไม่มีมาตรการควบคุมที่จำเป็นถูกละเว้นหรือมองข้าม

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

การใช้ภาคผนวก A ที่ถูกต้อง

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

การใช้ภาคผนวก A ที่ไม่ถูกต้อง

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

แนวทางของ กลุ่มแนวปฏิบัติด้านการตรวจประเมิน ISO/IEC 27001 (ISO/IEC 27001 Auditing Practices Group: APG) ระบุว่าการเปรียบเทียบกับภาคผนวก A เป็นการตรวจสอบคุณภาพของกระบวนการจัดการความเสี่ยง เพื่อช่วยลดโอกาสที่มาตรการจำเป็นจะถูกละเว้น

4. จัดทำเอกสารแสดงการประยุกต์ใช้ หรือ SoA

Statement of Applicability: SoA /เอกสารแสดงการประยุกต์ใช้

สามารถคงคำย่อ SoA ไว้ในบทความและเอกสารระบบ เพื่อให้สื่อสารตรงกับคำศัพท์สากล

SoA เป็นเอกสารสำคัญที่แสดงความสัมพันธ์ระหว่าง

• ความเสี่ยงที่องค์กรระบุ
• ทางเลือกในการจัดการความเสี่ยง
• มาตรการควบคุมที่จำเป็น
• มาตรการควบคุมในภาคผนวก A
• เหตุผลในการเลือกหรือไม่เลือกมาตรการ
• สถานะการนำมาตรการควบคุมไปปฏิบัติ

เอกสารแนวทางของ กลุ่มแนวปฏิบัติด้านการตรวจประเมิน ISO/IEC 27001 (ISO/IEC 27001 Auditing Practices Group: APG) อธิบายว่า SoA ไม่ใช่เพียงตารางแสดงความสอดคล้องกับภาคผนวก A และไม่จำเป็นต้องจัดเรียงโครงสร้างเหมือนภาคผนวก A ทุกประการ แต่ต้องสามารถแสดงสาระตามข้อกำหนดได้อย่างชัดเจน

SoA ต้องประกอบด้วยอะไรบ้าง

1. มาตรการควบคุมที่จำเป็น

SoA ต้องระบุมาตรการควบคุมที่องค์กรกำหนดว่าจำเป็นจากกระบวนการจัดการความเสี่ยง

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

2. เหตุผลของการนำมาตรการควบคุมมาใช้

องค์กรต้องแสดงเหตุผลว่าเหตุใดมาตรการควบคุมนั้นจึงจำเป็น

ตัวอย่างแหล่งที่มาของเหตุผล ได้แก่

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

ในตัวอย่าง SoA องค์กรอาจใช้รหัสเพื่อแสดงเหตุผล เช่น

การใช้รหัสไม่ใช่ข้อบังคับ แต่ช่วยให้ตรวจสอบความเชื่อมโยงของมาตรการได้ง่ายขึ้น

3. สถานะการนำมาตรการควบคุมไปปฏิบัติ

SoA ต้องระบุว่ามาตรการควบคุมที่จำเป็น

• นำไปปฏิบัติแล้ว
• นำไปปฏิบัติบางส่วน
• อยู่ระหว่างดำเนินการ
• ยังไม่ได้นำไปปฏิบัติ

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

4. เหตุผลของการไม่เลือกมาตรการในภาคผนวก A

หากมาตรการควบคุมในภาคผนวก A ไม่ถูกเลือก องค์กรต้องระบุเหตุผลรองรับ

ตัวอย่างเหตุผลที่อาจเหมาะสม ได้แก่

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

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

ตัวอย่างโครงสร้าง SoA ที่อ่านและตรวจสอบง่าย

ตารางนี้เป็นเพียงตัวอย่างรูปแบบ องค์กรสามารถออกแบบ SoA ให้เหมาะสมกับระบบงานของตนเองได้ แต่ต้องมีสาระครบตามข้อกำหนด

5. จัดทำแผนการจัดการความเสี่ยง

หลังจากกำหนดมาตรการควบคุมแล้ว องค์กรต้องจัดทำ แผนการจัดการความเสี่ยงด้านความมั่นคงปลอดภัยสำหรับสารสนเทศ

แผนควรตอบคำถามให้ได้ว่า

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

ตัวอย่างแผนการจัดการความเสี่ยง

ความเสี่ยง: ระบบ ERP ไม่พร้อมใช้จากความล้มเหลวของเซิร์ฟเวอร์หลัก

ผลต่อสารสนเทศ: ความพร้อมใช้

ทางเลือกในการจัดการ: ลดความเสี่ยง

มาตรการที่กำหนด:

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

ผู้รับผิดชอบดำเนินการ: ผู้ดูแลระบบและฝ่ายเทคโนโลยีสารสนเทศ

ผู้เป็นเจ้าของความเสี่ยง: เจ้าของกระบวนการ ERP หรือผู้บริหารที่รับผิดชอบกระบวนการธุรกิจ

หลักฐานที่คาดหวัง: ผลการสำรองข้อมูล รายงานการทดสอบกู้คืน บันทึกเหตุการณ์ และผลการทบทวน

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

6. ขออนุมัติจากผู้เป็นเจ้าของความเสี่ยง

คำว่า Risk Owner / ผู้เป็นเจ้าของความเสี่ยง

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

องค์กรต้องขอ

1. การอนุมัติแผนการจัดการความเสี่ยง
2. การยอมรับความเสี่ยงที่เหลืออยู่

จากผู้เป็นเจ้าของความเสี่ยง

ความเสี่ยงที่เหลืออยู่คืออะไร ?

Residual risk หมายถึง ความเสี่ยงที่เหลืออยู่หลังจากนำมาตรการจัดการความเสี่ยงไปปฏิบัติ

ตัวอย่างเช่น ก่อนดำเนินมาตรการ ระบบ ERP อาจมีความเสี่ยงระดับสูง หลังจากเพิ่มระบบสำรองและทดสอบการกู้คืนแล้ว ความเสี่ยงอาจลดลงเหลือระดับปานกลาง

ผู้เป็นเจ้าของความเสี่ยงต้องพิจารณาว่า

• มาตรการถูกนำไปปฏิบัติจริงหรือไม่
• ความเสี่ยงลดลงตามที่คาดไว้หรือไม่
• ความเสี่ยงที่เหลืออยู่เป็นไปตามเกณฑ์การยอมรับหรือไม่
• จำเป็นต้องมีมาตรการเพิ่มเติมหรือไม่

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

ความสัมพันธ์ระหว่างข้อ 6.1.2 และข้อ 6.1.3

ISO/IEC 27005 ระบุว่าการประเมินและการจัดการความเสี่ยงเป็นส่วนหนึ่งของวงจรการบริหารความเสี่ยงที่ต้องมีการสื่อสาร ติดตาม และทบทวนอย่างต่อเนื่อง

SoA แตกต่างจากแผนการจัดการความเสี่ยงอย่างไร ?

เอกสารแสดงการประยุกต์ใช้

SoA แสดงว่า

• มาตรการควบคุมใดจำเป็น
• เลือกหรือไม่เลือกมาตรการใด
• เลือกเพราะเหตุใด
• มาตรการอยู่ในสถานะใด
• อ้างอิงเอกสารหรือหลักฐานใด

แผนการจัดการความเสี่ยง

แผนการจัดการความเสี่ยงแสดงว่า

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

ดังนั้น SoA และแผนการจัดการความเสี่ยงสามารถเชื่อมโยงกันได้ แต่ไม่ควรรวมจนไม่สามารถแยกวัตถุประสงค์ของเอกสารทั้งสองออกจากกัน

ข้อผิดพลาดที่พบบ่อยในการประยุกต์ใช้ข้อ 6.1.3 ?

เลือกมาตรการจากภาคผนวก A ก่อนประเมินความเสี่ยง

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

คิดว่าต้องใช้มาตรการในภาคผนวก A ทุกข้อ

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

ระบุว่าไม่เกี่ยวข้องโดยไม่มีเหตุผล

ข้อความว่า “N/A” หรือ “ไม่เกี่ยวข้อง” เพียงอย่างเดียวไม่เพียงพอ ควรอธิบายตามขอบเขต ความเสี่ยง เทคโนโลยี หรือมาตรการทดแทน

SoA มีเฉพาะมาตรการในภาคผนวก A

หากองค์กรมีกฎหมาย ข้อกำหนดตามสัญญา หรือมาตรการที่ออกแบบขึ้นเอง มาตรการเหล่านั้นควรถูกสะท้อนใน SoA ด้วย

ระบุสถานะว่าดำเนินการแล้ว แต่ไม่มีหลักฐาน

การมีนโยบายไม่เท่ากับการนำมาตรการไปปฏิบัติ ต้องมีหลักฐาน เช่น บันทึกการดำเนินงาน ผลการติดตาม หรือผลการทดสอบ

ไม่มีการอนุมัติจากผู้เป็นเจ้าของความเสี่ยง

ฝ่าย IT หรือทีม ISMS ไม่ควรยอมรับความเสี่ยงแทนเจ้าของกระบวนการโดยไม่มีอำนาจที่ชัดเจน

ISO/IEC 27001 ข้อ 6.1.3

ISO/IEC 27001 ข้อ 6.1.3 กำหนดให้องค์กรจัดทำและประยุกต์ใช้กระบวนการจัดการความเสี่ยงด้านความมั่นคงปลอดภัยสำหรับสารสนเทศ โดยต้อง

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

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

บทความที่เกี่ยวข้อง: ISO/IEC 27001 ข้อ 6.1.2 การประเมินความเสี่ยง · ISO/IEC 27000 คืออะไร? สรุปชุดมาตรฐาน ISMS · ISO/IEC 27001:2022 อัพเดทใหม่ · คลังบทความทั้งหมด