ข้อ 9.1 การเฝ้าระวัง การวัดผล การวิเคราะห์ และการประเมินผล (monitoring, measurement, analysis and evaluation) ของ ISO/IEC 27001:2022 เป็นข้อที่ถามคำถามซึ่งเอกสารตอบแทนไม่ได้ นั่นคือระบบบริหารความมั่นคงปลอดภัยสารสนเทศ (information security management system หรือ ISMS) และมาตรการควบคุมที่เลือกใช้ ให้ผลตามที่ตั้งใจไว้จริงหรือไม่ สิ่งที่มาตรฐานขอไม่ใช่รายงานที่หนาขึ้น แต่เป็นการตัดสินใจล่วงหน้าว่าจะวัดอะไร ด้วยวิธีที่ให้ผลซึ่งเปรียบเทียบกันได้และทำซ้ำได้อย่างไร และใครเป็นผู้ตีความผลนั้น
ความต่างระหว่างการมีมาตรการควบคุมกับการรู้ว่ามันได้ผล
ISMS ที่จัดทำเอกสารครบสามารถแสดงได้ว่ามีมาตรการควบคุมอะไรบ้าง ใครรับผิดชอบ และมาตรการนั้นถูกเลือกด้วยเหตุผลใดตามผลการจัดการความเสี่ยง แต่ทั้งหมดนี้ยังไม่ตอบคำถามว่ามาตรการนั้นทำงานได้ผลหรือไม่ในสภาพการใช้งานจริง
ข้อ 9.1 จึงถูกวางไว้เป็นข้อแรกของหมวดการประเมินสมรรถนะ ก่อนข้อ 9.2 การตรวจประเมินภายใน และข้อ 9.3 การทบทวนของผู้บริหาร ลำดับนี้บอกเป็นนัยว่าข้อมูลเชิงปริมาณควรมาก่อน แล้วการตรวจประเมินภายในจึงเข้ามาตรวจสอบความน่าเชื่อถือของข้อมูลและกระบวนการ จากนั้นผู้บริหารจึงใช้ทั้งสองอย่างประกอบการตัดสินใจ
ในทางปฏิบัติ ความต่างนี้เห็นชัดที่สุดเมื่อเกิดเหตุการณ์จริง ระบบที่วัดเฉพาะว่ามีมาตรการอยู่จะรายงานว่าทุกอย่างเป็นไปตามแผน ส่วนระบบที่วัดประสิทธิผลจะเห็นสัญญาณล่วงหน้า เช่น เวลาเฉลี่ยตั้งแต่ตรวจพบจนถึงการจำกัดขอบเขตของเหตุการณ์ที่ยาวขึ้นเรื่อย ๆ แม้จำนวนเหตุการณ์จะยังเท่าเดิม
สามการตัดสินใจที่ต้องทำก่อนเริ่มวัด
เจตนาของข้อนี้สรุปได้เป็นการตัดสินใจสามเรื่องที่ต้องทำล่วงหน้า ไม่ใช่ทำย้อนหลังตอนเขียนรายงาน
เรื่องแรกคือ ต้องเลือกว่าจะเฝ้าระวังและวัดอะไร ซึ่งหมายถึงทั้งตัว ISMS ในภาพรวมและมาตรการควบคุมที่เลือกใช้ การเลือกนี้ควรไล่ย้อนไปหาความเสี่ยงที่มีนัยสำคัญตามผลการประเมินความเสี่ยง ไม่ใช่เลือกจากสิ่งที่เก็บข้อมูลได้ง่ายที่สุด
เรื่องที่สองคือ ต้องเลือกวิธีการที่ให้ผลซึ่งเชื่อถือได้ มาตรฐานใช้แนวคิดว่าผลที่ได้ต้องเปรียบเทียบกันได้และทำซ้ำได้ ซึ่งเป็นเงื่อนไขที่มีความหมายมากกว่าที่เห็น เพราะแปลว่านิยามของตัวชี้วัด แหล่งข้อมูล และช่วงเวลาที่ใช้ ต้องคงที่พอที่คนละคนวัดแล้วได้ผลใกล้เคียงกัน และตัวเลขของเดือนนี้เทียบกับเดือนก่อนได้อย่างมีความหมาย
เรื่องที่สามคือ ต้องกำหนดจังหวะเวลาและผู้รับผิดชอบ ทั้งฝั่งผู้เก็บข้อมูลและฝั่งผู้วิเคราะห์และประเมินผล การแยกสองบทบาทนี้ออกจากกันมีเหตุผลด้านความน่าเชื่อถือ เพราะผู้ที่ดูแลมาตรการควบคุมและเป็นผู้เก็บตัวเลขเอง ย่อมอยู่ในตำแหน่งที่ประเมินผลงานของตนเองได้ยาก
ผู้ให้บริการด้านไอทีแห่งหนึ่งในกรุงเทพฯ รายงานตัวชี้วัดด้านความมั่นคงปลอดภัยต่อผู้บริหารทุกไตรมาส ตัวชี้วัดชุดเดิมประกอบด้วยจำนวนพนักงานที่ผ่านการอบรมความตระหนัก จำนวนแพตช์ที่ติดตั้ง และจำนวนเหตุการณ์ที่ปิดแล้ว ทุกตัวเป็นสีเขียวต่อเนื่องหลายไตรมาส
เมื่อทบทวนตามข้อ 9.1 ทีมงานตั้งคำถามว่าตัวเลขเหล่านี้ตอบคำถามเรื่องประสิทธิผลหรือเพียงยืนยันว่ามีกิจกรรมเกิดขึ้น จึงเปลี่ยนบางตัวเป็นตัวชี้วัดที่ผูกกับผลลัพธ์ เช่น สัดส่วนของอีเมลทดสอบที่พนักงานรายงานเข้าช่องทางแจ้งเหตุภายในเวลาที่กำหนด และระยะเวลาตั้งแต่มีการเผยแพร่ช่องโหว่ระดับวิกฤตจนถึงเวลาที่ปิดครบทุกเครื่องในขอบเขต
ผลที่ได้คือภาพที่ต่างไป จำนวนคนผ่านอบรมยังสูงเหมือนเดิม แต่สัดส่วนการรายงานอีเมลน่าสงสัยอยู่ในระดับต่ำ และเวลาปิดช่องโหว่ยาวกว่าที่นโยบายภายในกำหนดในกลุ่มเครื่องของทีมพัฒนา ข้อมูลชุดนี้เปลี่ยนหัวข้อสนทนาในการทบทวนของผู้บริหารจากการรายงานกิจกรรม ไปเป็นการตัดสินใจเรื่องทรัพยากร
ตัวชี้วัดกิจกรรมกับตัวชี้วัดประสิทธิผล
ความสับสนอย่างหนึ่งในการออกแบบตัวชี้วัดของ ISMS คือการนำตัวเลขที่บอกว่ามีกิจกรรมเกิดขึ้นมาใช้แทนตัวเลขที่บอกว่ากิจกรรมนั้นได้ผล ตัวชี้วัดกิจกรรมไม่ได้ไร้ประโยชน์ แต่ตอบคนละคำถามและไม่ควรถูกใช้เป็นหลักฐานของประสิทธิผล
| เรื่องที่ต้องการควบคุม | ตัวชี้วัดที่บอกว่ามีกิจกรรม | ตัวชี้วัดที่บอกว่าได้ผล |
|---|---|---|
| ความตระหนักของผู้ใช้งาน | จำนวนชั่วโมงอบรมที่จัด | สัดส่วนผู้ที่รายงานสิ่งผิดปกติเข้าช่องทางที่กำหนดภายในเวลาที่ตั้งไว้ |
| การจัดการช่องโหว่ | จำนวนแพตช์ที่ติดตั้ง | ระยะเวลาปิดช่องโหว่ระดับวิกฤตจนครบทุกเครื่องในขอบเขต |
| การควบคุมสิทธิ์การเข้าถึง | จำนวนรอบการทบทวนสิทธิ์ที่ทำเสร็จ | จำนวนบัญชีของผู้ที่พ้นสภาพซึ่งยังใช้งานได้ ณ วันที่ตรวจ |
| การตอบสนองต่อเหตุการณ์ | จำนวนเหตุการณ์ที่ปิดแล้ว | เวลาตั้งแต่ตรวจพบจนจำกัดขอบเขตได้ แยกตามระดับความรุนแรง |
ข้อควรระวังคือ ตัวชี้วัดที่บอกประสิทธิผลมีต้นทุนในการเก็บสูงกว่า และบางตัวต้องอาศัยการทดสอบเพื่อให้ได้ข้อมูล องค์กรจึงควรเลือกจำนวนที่ดูแลไหวและผูกกับความเสี่ยงที่สำคัญที่สุดก่อน แทนที่จะสร้างชุดตัวชี้วัดยาวที่ไม่มีใครใช้
ความถี่ต้องเลือกจากจังหวะที่ความเสี่ยงเปลี่ยน
มาตรฐานไม่ได้กำหนดความถี่ตายตัว จึงเป็นหน้าที่ขององค์กรที่ต้องเลือกและอธิบายเหตุผลได้ หลักที่ใช้ตัดสินได้ตรงที่สุดคือจังหวะที่สิ่งซึ่งกำลังวัดสามารถเปลี่ยนแปลงได้จริง ไม่ใช่จังหวะของรอบการประชุม
ตัวอย่างของหลักการนี้คือ สถานะของช่องโหว่บนเครื่องที่เชื่อมต่ออินเทอร์เน็ตเปลี่ยนได้ทุกวัน การวัดไตรมาสละครั้งจึงให้ภาพที่ล้าสมัยตั้งแต่วันที่รายงานถูกจัดทำ ในทางกลับกัน ผลของโครงการปรับปรุงสถาปัตยกรรมที่ใช้เวลาหลายเดือนอาจไม่มีอะไรเปลี่ยนหากวัดทุกสัปดาห์ และการวัดถี่เกินไปจะสร้างภาระโดยไม่เพิ่มข้อมูล
อีกเงื่อนไขที่ควรกำหนดไว้ล่วงหน้าคือเหตุการณ์ที่กระตุ้นให้ต้องวัดนอกรอบ เช่น การเปลี่ยนผู้ให้บริการภายนอกรายสำคัญ การเปิดใช้ระบบใหม่ที่ประมวลผลข้อมูลส่วนบุคคล หรือเหตุการณ์ด้านความมั่นคงปลอดภัยที่มีความรุนแรงสูง การเขียนเงื่อนไขเหล่านี้ไว้ทำให้การวัดนอกรอบเป็นสิ่งที่ระบบออกแบบไว้ ไม่ใช่การตอบสนองเฉพาะกิจ
ผลที่วัดได้ต้องเดินต่อไปที่ไหน
มาตรฐานกำหนดให้เก็บหลักฐานของผลการเฝ้าระวังและการวัดไว้เป็นเอกสารสารสนเทศ จุดประสงค์ไม่ใช่การสะสมรายงาน แต่เพื่อให้ผลนั้นถูกใช้ต่อได้ในสามทาง
ทางแรกคือเข้าสู่การทบทวนของผู้บริหารตามข้อ 9.3 ในฐานะข้อมูลนำเข้า ทางที่สองคือเป็นวัตถุดิบให้การตรวจประเมินภายในตามข้อ 9.2 ใช้เลือกพื้นที่ที่ควรเข้าตรวจ และทางที่สามคือ เมื่อผลชี้ว่ามาตรการควบคุมไม่ให้ผลตามที่คาด สิ่งที่ตามมาคือการทบทวนการประเมินความเสี่ยงและการจัดการความเสี่ยง ไม่ใช่การเปลี่ยนตัวชี้วัดให้ตัวเลขดูดีขึ้น
ทางที่สามนี้เป็นจุดที่แยกระบบที่ใช้ได้จริงออกจากระบบที่ทำเพื่อผ่านการตรวจ เพราะการยอมรับว่ามาตรการที่เลือกไว้ไม่ได้ผล หมายถึงการกลับไปเปิดผลการจัดการความเสี่ยงและเอกสารแสดงการบังคับใช้มาตรการควบคุมอีกครั้ง ซึ่งเป็นงานที่หนักกว่าการเขียนคำอธิบายในรายงาน
ผู้ที่ต้องการอ่านต่อเรื่องการนำผลไปใช้ในขั้นถัดไป สามารถอ่านบทความ ISO/IEC 27001 ข้อ 9.2 การตรวจประเมินภายใน และบทความ ISO/IEC 27001 ข้อ 9.3 การทบทวนของผู้บริหาร ประกอบ
คำถามที่ควรตอบได้
- ตัวชี้วัดที่ใช้อยู่ถูกเลือกจากความเสี่ยงข้อใด และใครเป็นผู้อนุมัติการเลือกนั้น (ที่มา: ข้อ 9.1)
- นิยามของตัวชี้วัดแต่ละตัวคงที่พอที่คนละคนวัดแล้วได้ผลใกล้เคียงกันหรือไม่ (ที่มา: ข้อ 9.1 เรื่องความเปรียบเทียบได้และทำซ้ำได้)
- ผู้เก็บข้อมูลกับผู้วิเคราะห์และประเมินผลเป็นคนเดียวกันหรือไม่ และถ้าใช่ จัดการเรื่องความเป็นกลางอย่างไร (ที่มา: ข้อ 9.1)
- ตัวชี้วัดใดในชุดปัจจุบันบอกประสิทธิผล และตัวใดบอกเพียงว่ามีกิจกรรมเกิดขึ้น (ที่มา: ข้อ 9.1)
- เมื่อผลการวัดชี้ว่ามาตรการควบคุมไม่ได้ผล องค์กรเดินต่อไปที่ขั้นตอนใด และมีหลักฐานของครั้งล่าสุดหรือไม่ (ที่มา: ข้อ 9.1 ต่อเนื่องข้อ 9.3 และข้อ 10)
บทความนี้เรียบเรียงขึ้นด้วยถ้อยคำของผู้เรียบเรียงเพื่ออธิบายและตีความข้อกำหนด ไม่ใช่การแปลหรือทำซ้ำเนื้อหาของมาตรฐาน ตัวอย่างทั้งหมดเป็นกรณีสมมติเพื่อประกอบคำอธิบาย การนำไปใช้จริงให้ยึดตัวมาตรฐานฉบับจริงเป็นหลัก
หลักสูตรที่เกี่ยวข้อง: 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 การวางแผนการเปลี่ยนแปลง: ตีความข้อกำหนดและตัวอย่างในบริบทไทย