ข้อ 5.3 ของ ISO/IEC 27001:2022 เป็นข้อสั้นที่มีผลกว้าง เจตนาคือให้ผู้บริหารระดับสูงมอบหมายและสื่อสารให้ชัดว่า ใครรับผิดชอบอะไรในระบบการจัดการความมั่นคงปลอดภัยสารสนเทศ (information security management system หรือ ISMS) และผู้ที่ได้รับมอบหมายมีอำนาจตัดสินใจแค่ไหน จุดที่ผู้ตรวจประเมินให้ความสนใจไม่ใช่การมีผังองค์กรสวยงาม แต่คือคำถามว่าเมื่อเกิดเรื่องขึ้นจริง ใครคือคนที่มีสิทธิ์สั่งหยุด และองค์กรรู้เรื่องนั้นตรงกันทั้งองค์กรหรือไม่
ข้อ 5.3 ต้องการอะไร
ข้อ 5.3 มีชื่อว่า บทบาท ความรับผิดชอบ และอำนาจหน้าที่ในองค์กร (organizational roles, responsibilities and authorities) อยู่ในหมวดภาวะผู้นำ ซึ่งบอกตำแหน่งของมันอยู่แล้วว่าเป็นหน้าที่ของผู้บริหารระดับสูง ไม่ใช่หน้าที่ของผู้จัดการฝ่ายไอทีที่จะเขียนขึ้นมาเอง
สาระของข้อนี้มีสามชั้นที่ต่อกัน ชั้นแรกคือการมอบหมาย ผู้บริหารต้องกำหนดว่าบทบาทใดที่จำเป็นต่อ ISMS และใครถือบทบาทนั้น ชั้นที่สองคือการให้อำนาจ เพราะการมอบความรับผิดชอบโดยไม่ให้อำนาจตัดสินใจเท่ากับมอบภาระ ไม่ใช่มอบหน้าที่ ชั้นที่สามคือการสื่อสาร ถ้าคนอื่นในองค์กรไม่รู้ว่าใครถือบทบาทใด การมอบหมายนั้นก็ยังไม่มีผลในทางปฏิบัติ
นอกจากนี้ข้อกำหนดยังชี้เฉพาะเจาะจงถึงหน้าที่หนึ่งที่ต้องมีเจ้าของแน่นอน คือหน้าที่รายงานผลการดำเนินงานของ ISMS ต่อผู้บริหารระดับสูง เหตุผลเชิงโครงสร้างคือถ้าไม่มีใครถือหน้าที่นี้ ข้อมูลจากการเฝ้าระวัง การตรวจติดตามภายใน และเหตุการณ์ด้านความมั่นคงปลอดภัย จะไม่มีเส้นทางไปถึงผู้ที่มีอำนาจจัดสรรทรัพยากร และการทบทวนของฝ่ายบริหารตามข้อ 9.3 ก็จะขาดวัตถุดิบ
ความรับผิดชอบกับอำนาจ ไม่ใช่คำเดียวกัน
ในภาษาไทยมีการพูดรวมกันว่าหน้าที่ความรับผิดชอบ แต่ข้อกำหนดแยกสองคำนี้ออกจากกันโดยตั้งใจ ความรับผิดชอบคือสิ่งที่คนคนนั้นต้องทำและต้องตอบได้ ส่วนอำนาจคือขอบเขตการตัดสินใจที่ทำได้โดยไม่ต้องขออนุมัติจากใครอีก
ความต่างนี้เห็นชัดที่สุดในสถานการณ์ที่ต้องตัดสินใจเร็ว เช่น เมื่อพบว่าบัญชีผู้ใช้ที่มีสิทธิ์สูงถูกใช้งานจากที่ที่ไม่คุ้นเคย คำถามคือผู้ที่พบเหตุมีอำนาจระงับบัญชีนั้นทันทีหรือไม่ หรือจะต้องรอการอนุมัติที่อาจใช้เวลาข้ามคืน ถ้าคำตอบคืออย่างหลัง องค์กรอาจมีเอกสารครบแต่ยังไม่ได้ตอบเจตนาของข้อ 5.3 เพราะอำนาจไม่ได้ถูกวางไว้ในจุดที่ต้องใช้
บริษัทให้บริการดูแลระบบให้ลูกค้าองค์กร มีเอกสารกำหนดหน้าที่ระบุว่าหัวหน้าทีมปฏิบัติการดูแลความมั่นคงปลอดภัยของระบบ เมื่อผู้ตรวจถามว่าถ้าพบพฤติกรรมผิดปกติในบัญชีผู้ดูแลระบบของลูกค้ารายหนึ่งตอนตีสอง ใครตัดสินใจตัดการเชื่อมต่อ คำตอบที่ได้จากสามคนไม่ตรงกัน คนหนึ่งบอกว่าต้องรอผู้จัดการ คนหนึ่งบอกว่าต้องแจ้งลูกค้าก่อน อีกคนบอกว่าทำได้เลย
สิ่งที่บริษัทปรับคือระบุในเอกสารมอบหมายว่า เจ้าหน้าที่เวรกลางคืนมีอำนาจระงับการเชื่อมต่อชั่วคราวได้ทันทีภายในเงื่อนไขที่กำหนดไว้ล่วงหน้า พร้อมหน้าที่แจ้งภายในกรอบเวลาที่ตกลงกับลูกค้า และซ้อมสถานการณ์นี้หนึ่งครั้งเพื่อยืนยันว่าทุกคนเข้าใจตรงกัน กรณีนี้เป็นกรณีสมมติเพื่อประกอบคำอธิบายเท่านั้น
บทบาทที่ ISMS ต้องมีเจ้าของ
ข้อกำหนดไม่ได้ระบุรายชื่อตำแหน่งที่องค์กรต้องมี เพราะโครงสร้างขององค์กรแต่ละแห่งต่างกัน สิ่งที่ข้อกำหนดต้องการคือให้ทุกหน้าที่ที่ระบบต้องใช้ มีคนถืออยู่จริง ตารางต่อไปนี้เป็นการจัดกลุ่มเชิงวิเคราะห์ของผู้เรียบเรียงเอง เพื่อช่วยตรวจสอบว่ามีช่องว่างหรือไม่ ไม่ใช่รายการที่ปรากฏในตัวมาตรฐาน
| หน้าที่ที่ระบบต้องใช้ | คำถามที่ต้องตอบได้ว่าใครคือเจ้าของ |
|---|---|
| การยอมรับความเสี่ยงที่เหลืออยู่ | ใครลงนามยอมรับความเสี่ยงที่ไม่ได้ลดต่อ และยอมรับในฐานะอะไร |
| การอนุมัติสิทธิ์การเข้าถึง | ใครอนุมัติสิทธิ์ระดับสูง และใครทบทวนว่าสิทธิ์ยังจำเป็นอยู่ |
| การตัดสินใจระหว่างเหตุการณ์ | ใครสั่งหยุดบริการหรือแยกระบบออกได้ทันที และในเงื่อนไขใด |
| การรายงานสมรรถนะของ ISMS | ใครรวบรวมและนำเสนอต่อผู้บริหารระดับสูง ในรอบเวลาใด |
| การกำกับผู้ให้บริการภายนอก | ใครติดตามว่าผู้ให้บริการทำตามข้อตกลงด้านความมั่นคงปลอดภัย |
คำว่าเจ้าของในตารางนี้ไม่จำเป็นต้องเป็นตำแหน่งใหม่ องค์กรขนาดเล็กอาจให้คนคนเดียวถือหลายบทบาทได้ ข้อกำหนดไม่ได้ห้าม แต่สิ่งที่ต้องระวังคือการให้คนคนเดียวเป็นทั้งผู้ปฏิบัติและผู้ตรวจสอบตัวเอง เพราะจะทำให้กลไกการถ่วงดุลหายไป แนวคิดเรื่องการแบ่งแยกหน้าที่จึงเป็นเหตุผลเชิงออกแบบที่ควรพิจารณาตั้งแต่ตอนมอบหมาย ไม่ใช่ตอนที่ผู้ตรวจถาม
ความเชื่อมโยงกับเจ้าของความเสี่ยงในหมวด 6
ข้อ 5.3 มีความสัมพันธ์โดยตรงกับข้อ 6.1.2 และข้อ 6.1.3 เพราะกระบวนการประเมินและจัดการความเสี่ยงด้านความมั่นคงปลอดภัยสารสนเทศพูดถึงเจ้าของความเสี่ยง (risk owner) ในฐานะผู้ที่ต้องอนุมัติแผนการจัดการความเสี่ยงและยอมรับความเสี่ยงที่เหลืออยู่
ในทางปฏิบัติ ชื่อที่ปรากฏในทะเบียนความเสี่ยงกับชื่อที่ปรากฏในเอกสารมอบหมายตามข้อ 5.3 ควรสอดคล้องกัน ถ้าทะเบียนความเสี่ยงระบุว่าเจ้าของความเสี่ยงของระบบสารสนเทศด้านการเงินคือผู้อำนวยการฝ่ายการเงิน แต่เอกสารมอบหมายไม่เคยระบุว่าผู้อำนวยการฝ่ายการเงินมีบทบาทใดใน ISMS และเจ้าตัวไม่ทราบว่าตนถือบทบาทนี้ ก็เท่ากับการมอบหมายยังไม่เกิดขึ้นจริง ซึ่งเป็นช่องว่างที่พบได้จากการสัมภาษณ์มากกว่าจากการอ่านเอกสาร
โรงงานขอการรับรอง ISMS โดยกำหนดขอบเขตครอบคลุมระบบวางแผนการผลิตและระบบจัดเก็บแบบผลิตภัณฑ์ของลูกค้า ผังองค์กรระบุคณะทำงานความมั่นคงปลอดภัยสารสนเทศไว้ครบ แต่เมื่อสัมภาษณ์หัวหน้าแผนกวิศวกรรมซึ่งเป็นผู้ดูแลแบบผลิตภัณฑ์ กลับไม่ทราบว่าตนเป็นผู้อนุมัติสิทธิ์เข้าถึงแฟ้มแบบ
การแก้ไขที่ตรงจุดไม่ใช่การเขียนเอกสารเพิ่ม แต่คือการสื่อสารและยืนยันการรับทราบ โรงงานจึงจัดประชุมสั้นเพื่อทบทวนบทบาทกับผู้ถือบทบาททุกคน แล้วเก็บหลักฐานการรับทราบไว้ ทำให้ทั้งด้านการมอบหมายและด้านการสื่อสารของข้อ 5.3 มีหลักฐานรองรับ กรณีนี้เป็นกรณีสมมติเพื่อประกอบคำอธิบายเท่านั้น
ข้อ 5.3 กับความเข้าใจผิดเรื่องผู้แทนฝ่ายบริหาร
มาตรฐานระบบการจัดการรุ่นปัจจุบันไม่ได้บังคับให้มีตำแหน่งผู้แทนฝ่ายบริหารเหมือนมาตรฐานรุ่นเก่า องค์กรจึงตั้งหรือไม่ตั้งก็ได้ แต่การไม่ตั้งไม่ได้แปลว่าไม่ต้องมีคนถือหน้าที่ ผลของการเปลี่ยนแปลงนี้คือความรับผิดชอบถูกกระจายกลับไปยังผู้บริหารระดับสูงโดยตรง และผู้บริหารต้องแสดงให้เห็นว่าได้มอบหมายหน้าที่ที่จำเป็นออกไปแล้วอย่างมีเจตนา
สิ่งที่ตามมาคือ องค์กรที่ยังใช้แนวคิดเดิมและฝากทุกอย่างไว้กับผู้จัดการ ISMS คนเดียว จะเจอปัญหาเมื่อบุคคลนั้นลาออก เพราะความรู้และอำนาจกระจุกอยู่ที่คนคนเดียว ข้อ 5.3 ที่ทำได้ดีจึงช่วยลดความเปราะบางของระบบไปพร้อมกัน
คำถามที่ควรตอบได้
- ผู้บริหารระดับสูงมอบหมายบทบาทใดบ้างใน ISMS และการมอบหมายนั้นปรากฏเป็นหลักฐานที่ใด (ที่มา ข้อ 5.3)
- ผู้ถือบทบาทแต่ละคนมีอำนาจตัดสินใจถึงระดับใดโดยไม่ต้องขออนุมัติเพิ่ม (ที่มา ข้อ 5.3)
- ใครคือผู้รับผิดชอบการรายงานสมรรถนะของ ISMS ต่อผู้บริหารระดับสูง และรายงานในรอบเวลาใด (ที่มา ข้อ 5.3 ประกอบข้อ 9.3)
- ชื่อเจ้าของความเสี่ยงในทะเบียนความเสี่ยงตรงกับบทบาทที่มอบหมายไว้หรือไม่ และเจ้าตัวทราบหรือไม่ (ที่มา ข้อ 5.3 ประกอบข้อ 6.1.2 และ 6.1.3)
- องค์กรสื่อสารการมอบหมายเหล่านี้ให้ผู้ที่เกี่ยวข้องทราบด้วยวิธีใด และยืนยันการรับทราบอย่างไร (ที่มา ข้อ 5.3 ประกอบข้อ 7.3 และ 7.4)
อ่านต่อในหัวข้อที่เกี่ยวข้อง
เรื่องเจ้าของความเสี่ยงและการอนุมัติแผนจัดการความเสี่ยง อ่านต่อได้ที่ ISO/IEC 27001 ข้อ 6.1.3 การจัดการความเสี่ยงและ Statement of Applicability ส่วนเอกสารระดับบนที่ผู้บริหารต้องออกและใช้เป็นกรอบให้บทบาทเหล่านี้ อยู่ที่ ISO/IEC 27001 ข้อ 5.2 นโยบายความมั่นคงปลอดภัยสารสนเทศ และปลายทางของการรายงานสมรรถนะอยู่ที่ ISO/IEC 27001 ข้อ 9.3 การทบทวนของฝ่ายบริหาร
บทความชุดเดียวกันที่เผยแพร่พร้อมกัน อ่านต่อได้ที่ ISO 45001 ข้อ 9.1.1 การเฝ้าระวัง การวัด การวิเคราะห์ และการประเมินสมรรถนะ และ ISO 14001:2026 ข้อ 4.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 การวางแผนการเปลี่ยนแปลง: ตีความข้อกำหนดและตัวอย่างในบริบทไทย