ข้อ 7.4 การสื่อสาร (communication) ของ ISO/IEC 27001:2022 เป็นข้อที่สั้นที่สุดข้อหนึ่งของมาตรฐาน แต่เป็นข้อที่กำหนดว่าระบบบริหารความมั่นคงปลอดภัยสารสนเทศ (information security management system หรือ ISMS) จะเชื่อมกับคนจริงได้อย่างไร สิ่งที่มาตรฐานขอคือให้องค์กรตัดสินใจล่วงหน้าว่าเรื่องใดต้องสื่อสาร เมื่อใด กับใคร และด้วยวิธีใด ทั้งการสื่อสารภายในและภายนอก ความยากของข้อนี้ไม่ได้อยู่ที่การเขียนตาราง แต่อยู่ที่การยอมรับว่าเนื้อหาด้านความมั่นคงปลอดภัยบางเรื่องเป็นข้อมูลที่ต้องถูกปกป้องเสียเอง การออกแบบเส้นทางการสื่อสารจึงต้องคิดเรื่องช่องทางไปพร้อมกับเนื้อหา
ทำไมมาตรฐานด้านความมั่นคงปลอดภัยจึงมีข้อว่าด้วยการสื่อสาร
ISO/IEC 27001:2022 ใช้โครงสร้างเดียวกับมาตรฐานระบบการจัดการฉบับอื่น ข้อ 7.4 จึงปรากฏในตำแหน่งเดียวกับ ISO 9001, ISO 14001 และ ISO 45001 แต่เหตุผลที่ข้อนี้จำเป็นสำหรับ ISMS เป็นเหตุผลเฉพาะตัว ระบบความมั่นคงปลอดภัยสารสนเทศทำงานได้จริงก็ต่อเมื่อคนที่ไม่ได้อยู่ในทีมความมั่นคงปลอดภัยรู้ว่าตัวเองต้องทำอะไรและต้องแจ้งใครเมื่อเห็นสิ่งผิดปกติ
ในทางกลับกัน ข้อมูลด้านความมั่นคงปลอดภัยจำนวนหนึ่งเป็นข้อมูลที่ถ้ารั่วออกไปจะกลายเป็นแผนที่ให้ผู้โจมตี รายการช่องโหว่ที่ยังไม่ได้ปิด แผนผังระบบเครือข่าย หรือรายละเอียดของเหตุการณ์ที่กำลังจัดการอยู่ ล้วนเป็นข้อมูลที่มีค่าสำหรับฝ่ายตรงข้าม ข้อ 7.4 จึงไม่ใช่ข้อที่ขอให้องค์กร “สื่อสารให้มากขึ้น” แต่ขอให้ตัดสินใจอย่างมีเหตุผลว่าอะไรควรไปถึงใคร
อีกจุดที่ควรทราบสำหรับผู้ที่เคยใช้มาตรฐานฉบับก่อนหน้าคือ ฉบับ 2022 เขียนข้อ 7.4 ให้กระชับกว่าฉบับก่อน โดยตัดข้อย่อยที่ระบุให้กำหนดกระบวนการสื่อสารออกไป การตัดข้อย่อยนี้ไม่ได้แปลว่าองค์กรไม่ต้องมีวิธีทำงานที่ชัดเจน เพียงแต่มาตรฐานเปิดให้เลือกรูปแบบได้เองมากขึ้น
สามชั้นของการตัดสินใจที่ข้อนี้เรียกร้อง
แทนที่จะไล่ตามหัวข้อในตัวมาตรฐาน วิธีที่ใช้ออกแบบได้จริงคือแยกการตัดสินใจออกเป็นสามชั้น
ชั้นที่หนึ่ง คือขอบเขต องค์กรต้องแยกให้ออกว่าการสื่อสารเรื่องใดเป็นการสื่อสารภายใน และเรื่องใดจำเป็นต้องออกไปข้างนอก การสื่อสารภายนอกของ ISMS ไม่ได้จำกัดอยู่ที่การประชาสัมพันธ์ แต่รวมถึงการแจ้งลูกค้าตามข้อผูกพันในสัญญา การแจ้งหน่วยงานกำกับดูแลตามที่กฎหมายกำหนด และการประสานกับผู้ให้บริการภายนอกที่ดูแลระบบบางส่วนแทนองค์กร
ชั้นที่สอง คือเนื้อหาและผู้รับ ชั้นนี้ตอบว่าเรื่องอะไรต้องไปถึงใคร หลักที่ใช้ตัดสินคือผู้รับต้องได้รับข้อมูลในระดับรายละเอียดที่ทำให้เขาตัดสินใจหรือลงมือทำได้ ไม่มากกว่านั้น พนักงานทั่วไปที่ต้องรู้ว่าเห็นอีเมลน่าสงสัยแล้วต้องกดปุ่มใด ไม่จำเป็นต้องได้รับรายงานทางเทคนิคฉบับเต็ม ในขณะที่ผู้บริหารสูงสุดที่ต้องอนุมัติทรัพยากรจำเป็นต้องเห็นภาพความเสี่ยงในระดับที่ตัดสินใจได้
ชั้นที่สาม คือช่องทางและเวลา ชั้นนี้ตอบว่าจะส่งด้วยวิธีใดและภายในเมื่อใด ซึ่งเป็นชั้นที่ผูกกับความมั่นคงปลอดภัยโดยตรง เพราะช่องทางที่สะดวกที่สุดไม่จำเป็นต้องเป็นช่องทางที่ปลอดภัยที่สุด
ภาวะปกติกับภาวะเหตุการณ์ ใช้เส้นทางคนละเส้น
ความแตกต่างที่ทำให้ข้อ 7.4 ของ ISMS มีเนื้อหาต่างจากมาตรฐานฉบับอื่น คือ ISMS ต้องรองรับสถานการณ์ที่ช่องทางการสื่อสารตามปกติใช้การไม่ได้ ถ้าระบบอีเมลขององค์กรถูกกระทบจากเหตุการณ์ด้านความมั่นคงปลอดภัย การแจ้งเตือนเรื่องเหตุการณ์นั้นผ่านอีเมลย่อมไม่ทำงาน องค์กรจึงต้องกำหนดช่องทางสำรองไว้ล่วงหน้า และต้องทำให้คนที่เกี่ยวข้องรู้จักช่องทางนั้นก่อนที่จะต้องใช้จริง
เงื่อนไขเรื่องเวลาก็ต่างกันชัดเจน รายงานสถานะ ISMS ประจำไตรมาสมีกรอบเวลาเป็นสัปดาห์ ส่วนการแจ้งเหตุการณ์ที่กำลังเกิดขึ้นมีกรอบเวลาเป็นนาที และถ้าองค์กรมีข้อผูกพันตามสัญญาหรือตามกฎหมายที่กำหนดกรอบเวลาการแจ้งไว้ กรอบเวลานั้นจะกลายเป็นข้อกำหนดที่ต้องออกแบบระบบให้รองรับ ไม่ใช่เป้าหมายที่พยายามทำให้ได้
ผู้ให้บริการระบบไอทีแห่งหนึ่งในกรุงเทพฯ ให้บริการโฮสต์ระบบงานแก่ลูกค้าองค์กรหลายราย และมีข้อผูกพันในสัญญากับลูกค้าบางรายว่าต้องแจ้งเหตุการณ์ด้านความมั่นคงปลอดภัยที่กระทบข้อมูลของลูกค้าภายในกรอบเวลาที่ตกลงกันไว้
ตอนออกแบบการสื่อสารตามข้อ 7.4 ทีมพบว่าตารางที่เคยทำไว้ระบุแค่ “แจ้งลูกค้าเมื่อเกิดเหตุการณ์” ซึ่งไม่พอสำหรับสามคำถาม คำถามแรกคือ ใครมีอำนาจตัดสินว่าเหตุการณ์นี้กระทบข้อมูลของลูกค้ารายใดบ้าง คำถามที่สองคือ ข้อความที่ส่งออกไปในชั่วโมงแรกซึ่งข้อเท็จจริงยังไม่ครบ ควรมีเนื้อหาแค่ไหนจึงจะไม่ทำให้ลูกค้าเข้าใจผิดและไม่เปิดเผยรายละเอียดทางเทคนิคที่เป็นประโยชน์กับผู้โจมตี คำถามที่สามคือ ถ้าระบบอีเมลขององค์กรเองเป็นสิ่งที่ถูกกระทบ จะแจ้งด้วยช่องทางใด
ผลของการทบทวนคือทีมกำหนดผู้มีอำนาจตัดสินไว้เป็นตำแหน่ง ไม่ใช่ตัวบุคคล พร้อมผู้ทำหน้าที่แทนเมื่อไม่อยู่ กำหนดโครงร่างข้อความแจ้งครั้งแรกที่ระบุเฉพาะสิ่งที่ยืนยันแล้วและสิ่งที่ลูกค้าควรทำ และกำหนดช่องทางสำรองพร้อมรายชื่อผู้ติดต่อที่เก็บไว้แบบออฟไลน์ จากนั้นจึงซ้อมใช้ช่องทางสำรองหนึ่งครั้งเพื่อยืนยันว่าข้อมูลติดต่อยังใช้ได้จริง
ช่องทางต้องเหมาะกับชั้นความลับของเนื้อหา
ประเด็นที่ควรระวังเป็นพิเศษคือการสื่อสารเรื่องความมั่นคงปลอดภัยผ่านช่องทางที่ไม่ได้ถูกออกแบบมาเพื่อรองรับข้อมูลระดับนั้น การส่งรายการช่องโหว่ที่ยังไม่ได้ปิดผ่านแอปพลิเคชันแชตทั่วไป การแนบผลการทดสอบเจาะระบบไปกับอีเมลที่ไม่มีการเข้ารหัส หรือการพูดคุยรายละเอียดของเหตุการณ์ในกลุ่มสนทนาที่มีสมาชิกจากหลายหน่วยงาน ล้วนเป็นการสร้างความเสี่ยงใหม่ขึ้นระหว่างการจัดการความเสี่ยงเดิม
วิธีคิดที่ใช้ได้คือถือว่าทุกรายการในตารางการสื่อสารต้องมีสองคอลัมน์ที่มาคู่กันเสมอ คือระดับชั้นความลับของเนื้อหา และช่องทางที่อนุญาตให้ใช้กับชั้นความลับนั้น เมื่อสองคอลัมน์นี้อยู่ในตารางเดียวกัน ความไม่สอดคล้องจะปรากฏให้เห็นเองตั้งแต่ตอนออกแบบ ไม่ต้องรอให้เกิดเหตุ
| ประเภทการสื่อสาร | ผู้รับ | กรอบเวลา | สิ่งที่ต้องตัดสินใจเพิ่ม |
|---|---|---|---|
| นโยบายและกฎการใช้งาน | ผู้ปฏิบัติงานทุกคน | ตามรอบและเมื่อมีการแก้ไข | จะยืนยันการรับทราบอย่างไร |
| รายงานสถานะและตัวชี้วัด | ผู้บริหารและเจ้าของความเสี่ยง | ตามรอบที่กำหนด | ระดับรายละเอียดที่พอต่อการตัดสินใจ |
| การแจ้งเหตุการณ์ภายใน | ทีมรับมือเหตุการณ์ | ทันทีที่พบ | ช่องทางสำรองเมื่อระบบหลักใช้ไม่ได้ |
| การแจ้งเหตุการณ์ภายนอก | ลูกค้า คู่สัญญา หน่วยงานกำกับ | ตามข้อผูกพันที่มีอยู่ | ใครมีอำนาจอนุมัติข้อความก่อนส่ง |
| การประสานกับผู้ให้บริการภายนอก | ผู้ให้บริการที่ดูแลระบบบางส่วน | ตามที่ระบุในข้อตกลง | ข้อมูลใดส่งได้ ข้อมูลใดส่งไม่ได้ |
เส้นเชื่อมกับข้ออื่นในมาตรฐาน
ข้อ 7.4 เป็นข้อที่ทำงานคู่กับข้ออื่นเกือบตลอด ข้อ 5.2 นโยบายความมั่นคงปลอดภัยสารสนเทศ กำหนดให้นโยบายต้องถูกสื่อสารภายในองค์กรและเปิดให้ผู้มีส่วนได้ส่วนเสียเข้าถึงได้ตามความเหมาะสม ซึ่งเป็นรายการหนึ่งที่ต้องปรากฏในตารางการสื่อสาร ส่วนข้อ 7.3 ความตระหนักเป็นคนละเรื่องกับข้อ 7.4 แม้จะใช้ช่องทางเดียวกันได้ เพราะข้อ 7.3 ถามว่าคนเข้าใจและตระหนักหรือไม่ ส่วนข้อ 7.4 ถามว่าข้อมูลเดินทางไปถึงหรือไม่
ทางด้านผลลัพธ์ ผลของการสื่อสารจะไหลเข้าสู่ ข้อ 9.3 การทบทวนฝ่ายบริหาร ในรูปของข้อมูลนำเข้า และเมื่อการสื่อสารล้มเหลวจนกระทบต่อการจัดการเหตุการณ์ สิ่งที่ตามมาคือกระบวนการตาม ข้อ 10.2 ความไม่สอดคล้องและการปฏิบัติการแก้ไข ส่วนบันทึกที่เกิดจากการสื่อสารจะถูกควบคุมภายใต้ ข้อ 7.5 เอกสารสารสนเทศ
เมื่อขยายภาพออกไปนอกมาตรฐานฉบับนี้ การตัดสินใจว่าใครควรได้รับข้อมูลระดับใดยังเกี่ยวข้องกับการจัดการองค์ความรู้ขององค์กรด้วย ซึ่งอธิบายไว้ในบทความเรื่อง ข้อ 7.1.6 ความรู้ขององค์กรตาม ISO 9001
หลักฐานที่ใช้แสดงว่าข้อนี้ทำงานอยู่จริง
ข้อ 7.4 ไม่ได้กำหนดให้ต้องมีเอกสารสารสนเทศเป็นการเฉพาะ องค์กรจึงเลือกรูปแบบได้เอง แต่ในทางปฏิบัติ การจะแสดงว่าองค์กร “ได้ตัดสินใจแล้ว” ว่าเรื่องใดสื่อสารกับใคร ย่อมต้องมีร่องรอยบางอย่าง รูปแบบที่ตรวจสอบได้ง่ายที่สุดคือตารางเดียวที่รวมทุกรายการไว้ พร้อมระบุผู้รับผิดชอบ ช่องทาง และกรอบเวลา
สิ่งที่ผู้ตรวจประเมินจะทำต่อจากการดูตาราง คือหยิบหนึ่งแถวขึ้นมาแล้วขอหลักฐานว่าการสื่อสารนั้นเกิดขึ้นจริงตามที่เขียนไว้ ตารางที่สวยแต่ไม่มีร่องรอยการใช้งานจริงจะถูกตั้งคำถามทันที ในทางกลับกัน องค์กรที่สื่อสารกันอย่างมีระเบียบอยู่แล้วแต่ไม่เคยเขียนลงเป็นตาราง จะพบว่าการทำตารางเป็นเพียงการบันทึกสิ่งที่ทำอยู่ ไม่ใช่การสร้างงานใหม่
คำถามที่ควรตอบได้
- องค์กรกำหนดไว้ที่ใดว่าเรื่องใดต้องสื่อสารภายใน และเรื่องใดต้องสื่อสารออกภายนอก (ที่มา: ข้อ 7.4)
- ผู้รับแต่ละกลุ่มได้รับข้อมูลในระดับรายละเอียดที่ต่างกันอย่างไร และใช้หลักอะไรตัดสิน (ที่มา: ข้อ 7.4)
- ถ้าช่องทางการสื่อสารหลักใช้การไม่ได้เพราะเหตุการณ์ด้านความมั่นคงปลอดภัย จะใช้ช่องทางใดแทน และเคยทดสอบแล้วหรือไม่ (ที่มา: ข้อ 7.4)
- ข้อความที่ส่งออกภายนอกต้องผ่านการอนุมัติจากใครก่อน และมีกรอบเวลาตามข้อผูกพันใดบ้าง (ที่มา: ข้อ 7.4)
- ตารางการสื่อสารระบุระดับชั้นความลับของเนื้อหาคู่กับช่องทางที่อนุญาตหรือไม่ (ที่มา: ข้อ 7.4 ประกอบการจัดการความเสี่ยงตามข้อ 6.1.3)
บทความนี้เรียบเรียงขึ้นด้วยถ้อยคำของผู้เรียบเรียงเพื่ออธิบายและตีความข้อกำหนด ไม่ใช่การแปลหรือทำซ้ำเนื้อหาของมาตรฐาน ตัวอย่างทั้งหมดเป็นกรณีสมมติเพื่อประกอบคำอธิบาย การนำไปใช้จริงให้ยึดตัวมาตรฐานฉบับจริงเป็นหลัก
หลักสูตรที่เกี่ยวข้อง: ISO/IEC 27001:2022 ระบบบริหารความมั่นคงปลอดภัยสารสนเทศ
Equal Assurance (Thailand) Ltd. เป็นหน่วยรับรองระบบและผู้ให้บริการฝึกอบรม เปิดหลักสูตรทั้งแบบ Public และ In-house สอนเป็นภาษาไทยและอังกฤษ

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 การวางแผนการเปลี่ยนแปลง: ตีความข้อกำหนดและตัวอย่างในบริบทไทย