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

ISO/IEC 27001:2022 กำหนดให้องค์กรใช้กระบวนการบริหารความเสี่ยงที่ปรับให้เหมาะกับขนาด ความต้องการ และบริบทขององค์กร ไม่ได้กำหนดสูตรคำนวณ แบบฟอร์ม หรือวิธีประเมินเพียงรูปแบบเดียวสำหรับทุกองค์กร

บทความนี้อธิบายข้อกำหนด 6.1.2 ตามลำดับของมาตรฐาน พร้อมตัวอย่างการประยุกต์ใช้โดยอ้างอิงแนวคิดที่สอดคล้องกับแนวทางสากล เช่น ISO/IEC 27005, NIST SP 800-30 และแนวทางการบริหารความเสี่ยงของ ENISA ทั้งนี้ ตัวอย่างเป็นแนวทางประกอบความเข้าใจ ไม่ใช่ข้อความบังคับหรือวิธีปฏิบัติเพียงรูปแบบเดียวของ ISO/IEC 27001

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

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

ในทางปฏิบัติ การประเมินความเสี่ยงเป็นกระบวนการสำหรับ

1. ระบุความเสี่ยง
2. วิเคราะห์ความเสี่ยง
3. ประเมินและจัดลำดับความสำคัญของความเสี่ยง

แนวคิดนี้สอดคล้องกับ NIST SP 800-30 ซึ่งอธิบายการประเมินความเสี่ยงในฐานะกระบวนการระบุ ประมาณค่า และจัดลำดับความเสี่ยงด้านความมั่นคงปลอดภัยสำหรับสารสนเทศ โดยพิจารณาปัจจัยสำคัญ เช่น ภัยคุกคาม จุดอ่อน โอกาสเกิด และผลกระทบต่อภารกิจหรือการดำเนินธุรกิจ

อย่างไรก็ตาม NIST SP 800-30 เป็นแนวทางของ NIST ไม่ใช่ข้อกำหนดของ ISO/IEC 27001 องค์กรจึงสามารถใช้เป็นแหล่งอ้างอิงประกอบได้ แต่ยังต้องทำให้กระบวนการของตนสอดคล้องกับข้อกำหนด 6.1.2 โดยตรง

ISO/IEC 27001 ข้อ 6.1.2 กำหนดให้องค์กรดำเนินการอะไร

ข้อกำหนดสามารถแบ่งสาระสำคัญออกเป็น 5 ส่วน ได้แก่

1. กำหนดและคงไว้ซึ่งเกณฑ์ความเสี่ยง
2. ทำให้การประเมินซ้ำให้ผลที่สม่ำเสมอ ถูกต้อง และเปรียบเทียบได้
3. ระบุความเสี่ยงและผู้เป็นเจ้าของความเสี่ยง
4. วิเคราะห์ความเสี่ยง
5. ประเมินและจัดลำดับความเสี่ยง

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

1. กำหนดและคงไว้ซึ่งเกณฑ์ความเสี่ยง

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

1.1 เกณฑ์การยอมรับความเสี่ยง

Risk acceptance criteria /เกณฑ์การยอมรับความเสี่ยง

เกณฑ์นี้ใช้ตัดสินว่าความเสี่ยงระดับใดองค์กรสามารถยอมรับได้ และความเสี่ยงระดับใดต้องเข้าสู่กระบวนการจัดการความเสี่ยง ตัวอย่างเช่น

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

1.2 เกณฑ์สำหรับการดำเนินการประเมินความเสี่ยง

องค์กรต้องกำหนดเกณฑ์ที่ใช้ดำเนินการประเมิน เช่น

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

ISO/IEC 27001 ไม่ได้บังคับให้ใช้สูตร ความเสี่ยง = โอกาสเกิด × ผลกระทบ

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

ISO/IEC 27005 เป็นมาตรฐานที่ใช้สนับสนุนการจัดการความเสี่ยงด้านความมั่นคงปลอดภัยสำหรับสารสนเทศ และสามารถนำมาใช้ประกอบการออกแบบวิธีประเมินตาม ISO/IEC 27001 ได้

2. การประเมินซ้ำต้องให้ผลที่สม่ำเสมอ ถูกต้อง และเปรียบเทียบได้

องค์กรต้องทำให้มั่นใจว่าการประเมินความเสี่ยงที่ดำเนินการซ้ำให้ผลลัพธ์ที่

• สม่ำเสมอ
• ถูกต้อง
• สามารถเปรียบเทียบได้

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

ตัวอย่างสิ่งที่ควรกำหนดเพื่อสนับสนุนข้อกำหนดนี้ ได้แก่

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

ตัวอย่างเกณฑ์โอกาสเกิด

NIST SP 800-30 สนับสนุนการใช้ข้อมูลเกี่ยวกับภัยคุกคาม จุดอ่อน โอกาสเกิด และผลกระทบเป็นปัจจัยในการวิเคราะห์ความเสี่ยง ซึ่งช่วยให้องค์กรมีเหตุผลรองรับการให้ระดับคะแนนมากกว่าการใช้ความรู้สึกของผู้ประเมินเพียงอย่างเดียว

3. ระบุความเสี่ยงที่เกี่ยวข้องกับการสูญเสียคุณสมบัติของสารสนเทศ

องค์กรต้องประยุกต์ใช้กระบวนการประเมินความเสี่ยงเพื่อระบุความเสี่ยงที่เกี่ยวข้องกับการสูญเสีย

• ความลับ — Confidentiality
• ความถูกต้องครบถ้วน — Integrity
• ความพร้อมใช้ — Availability

ภายในขอบเขตของ ISMS

จุดสำคัญคือ ข้อกำหนดมุ่งให้ระบุ ความเสี่ยง ไม่ใช่เพียงจัดทำรายชื่อทรัพย์สิน ภัยคุกคาม หรือจุดอ่อนแยกจากกัน

ตัวอย่างที่ยังไม่สมบูรณ์ ได้แก่

• มัลแวร์
• ไฟฟ้าดับ
• รหัสผ่านไม่รัดกุม
• พนักงานลาออก
• เซิร์ฟเวอร์เสีย

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

รูปแบบข้อความความเสี่ยงที่ใช้ได้ในระดับสากล

องค์กรอาจใช้โครงสร้างดังนี้

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

ตัวอย่างเช่น

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

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

4. ระบุผู้เป็นเจ้าของความเสี่ยง

คำว่า Risk Owner /ผู้เป็นเจ้าของความเสี่ยง หรือองค์กรอาจกำหนดใช้คำว่า “เจ้าของความเสี่ยง” เป็นคำย่อภายในเอกสารได้ แต่ควรให้คำจำกัดความไว้ชัดเจน

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

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

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

5. วิเคราะห์ความเสี่ยงด้านความมั่นคงปลอดภัยสำหรับสารสนเทศ

การวิเคราะห์ความเสี่ยงตามข้อ 6.1.2 ครอบคลุมองค์ประกอบสำคัญสามประการ

5.1 ประเมินผลกระทบที่อาจเกิดขึ้น

องค์กรต้องประเมินผลกระทบที่อาจเกิดขึ้น หากความเสี่ยงที่ระบุเกิดขึ้นจริง

ผลกระทบควรเชื่อมโยงกับบริบทและวัตถุประสงค์ขององค์กร เช่น

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

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

5.2 ประเมินโอกาสเกิดที่สมเหตุสมผล

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

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

NIST SP 800-30 ใช้การวิเคราะห์ภัยคุกคาม จุดอ่อน โอกาสเกิด และผลกระทบเป็นองค์ประกอบหลักของการประเมินความเสี่ยง จึงเป็นแหล่งอ้างอิงสากลที่เหมาะสำหรับพัฒนาหลักเกณฑ์การให้เหตุผลประกอบคะแนน

5.3 กำหนดระดับความเสี่ยง

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

ตัวอย่างวิธีแบบกึ่งปริมาณ:

ช่วงคะแนนนี้เป็นเพียงตัวอย่าง ไม่ใช่ระดับที่ ISO/IEC 27001 กำหนด องค์กรต้องออกแบบเกณฑ์ให้เหมาะสมและตรวจสอบว่าไม่เกิดช่องว่างหรือความซ้ำซ้อนในการแบ่งระดับ

6. ประเมินความเสี่ยงและจัดลำดับความสำคัญ

หลังจากวิเคราะห์ความเสี่ยงแล้ว องค์กรต้อง

1. เปรียบเทียบผลการวิเคราะห์กับเกณฑ์ความเสี่ยงที่กำหนด
2. จัดลำดับความสำคัญของความเสี่ยงที่วิเคราะห์แล้ว เพื่อใช้ในการจัดการความเสี่ยง

การประเมินความเสี่ยงในขั้นนี้จึงไม่ใช่การคำนวณคะแนนซ้ำ แต่เป็นการตัดสินว่า

• ความเสี่ยงอยู่ภายในหรือเกินเกณฑ์การยอมรับ
• ความเสี่ยงใดต้องจัดการ
• ความเสี่ยงใดควรได้รับการจัดการก่อน
• ใครมีอำนาจตัดสินใจยอมรับความเสี่ยง

การจัดลำดับอาจพิจารณามากกว่าคะแนน เช่น

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

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

ตัวอย่างการประยุกต์ใช้ในโรงงานตามหลักข้อกำหนด

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

คะแนนทั้งหมดเป็นเพียงตัวอย่าง องค์กรต้องใช้เกณฑ์ที่ตนกำหนด

ตัวอย่างที่ 1 ระบบควบคุมการผลิตไม่พร้อมใช้

ตัวอย่างที่ 2 สูตรการผลิตถูกเปิดเผยแก่ผู้ไม่มีอำนาจ

ตัวอย่างที่ 3 ผลการตรวจสอบคุณภาพถูกแก้ไขโดยไม่ได้รับอนุญาต

ตัวอย่างที่ 4 ระบบ ERP ไม่พร้อมใช้ระหว่างการจัดส่ง

ตัวอย่างทะเบียนความเสี่ยงที่เหมาะสม

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

สารสนเทศที่เป็นเอกสารที่ต้องเก็บรักษา

ข้อ 6.1.2 กำหนดให้องค์กร เก็บรักษาสารสนเทศที่เป็นเอกสารเกี่ยวกับกระบวนการประเมินความเสี่ยงด้านความมั่นคงปลอดภัยสำหรับสารสนเทศ

คำว่า retain documented information /เก็บรักษาสารสนเทศที่เป็นเอกสาร

ไม่ควรสรุปเพียงว่า “ต้องเก็บเอกสารผลการประเมิน” เพราะข้อกำหนดกล่าวถึงสารสนเทศที่เป็นเอกสารเกี่ยวกับ กระบวนการ ด้วย

ตัวอย่างสารสนเทศที่ควรมี ได้แก่

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

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

ประเด็นที่ควรพิจารณา

1. ไม่ควรระบุ “ทรัพย์สิน” เป็นข้อบังคับโดยตรงของข้อ 6.1.2

การใช้แนวทางแบบอิงทรัพย์สินเป็นวิธีที่ยอมรับได้ แต่ ISO/IEC 27001:2022 ไม่ได้บังคับว่าทุกความเสี่ยงต้องเริ่มจากการจัดทำบัญชีทรัพย์สินเสมอไป องค์กรอาจใช้แนวทางแบบ

• อิงทรัพย์สิน
• อิงกระบวนการ
• อิงเหตุการณ์
• อิงสถานการณ์ความเสี่ยง
• ผสมหลายแนวทาง

ได้ หากสามารถระบุความเสี่ยงต่อความลับ ความถูกต้องครบถ้วน และความพร้อมใช้ภายในขอบเขต ISMS ได้ครบถ้วน

2. ไม่ควรบังคับให้ระบุภัยคุกคามและจุดอ่อนเป็นคอลัมน์แยกทุกกรณี

ภัยคุกคามและจุดอ่อนเป็นข้อมูลที่มีประโยชน์และได้รับการใช้แพร่หลายใน NIST SP 800-30 แต่ ISO/IEC 27001 ไม่ได้กำหนดรูปแบบตารางว่าต้องมีคอลัมน์ดังกล่าวเสมอไป

3. ต้องแยก “การประเมินความเสี่ยง” ออกจาก “การจัดการความเสี่ยง”

ข้อ 6.1.2 ครอบคลุมการระบุ วิเคราะห์ ประเมิน และจัดลำดับความเสี่ยง ส่วนการเลือกแนวทางจัดการ การกำหนดมาตรการควบคุม การเปรียบเทียบกับ Annex A การจัดทำ Statement of Applicability และแผนจัดการความเสี่ยง เป็นสาระของข้อ 6.1.3

4. คะแนนสูงไม่ได้หมายความว่าต้องใช้มาตรการทางเทคนิคเสมอไป

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

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

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

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

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

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

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

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

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

แนวทางสากล เช่น ISO/IEC 27005, NIST SP 800-30 และกรอบการบริหารความเสี่ยงของ ENISA สามารถใช้สนับสนุนการออกแบบวิธีประเมินได้ แต่ไม่ควรนำมาใช้แทนข้อกำหนด ISO/IEC 27001 โดยตรง เพราะแต่ละแหล่งมีวัตถุประสงค์และขอบเขตต่างกัน

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