ISO/IEC 27001 ข้อ 5.3 บทบาท ความรับผิดชอบ และอำนาจหน้าที่ในองค์กร

ISO/IEC 27001 ข้อ 5.3 บทบาท ความรับผิดชอบ และอำนาจหน้าที่ในองค์กร | EQA Thailand
สรุปสั้นก่อน
ข้อ 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 ที่ทำได้ดีจึงช่วยลดความเปราะบางของระบบไปพร้อมกัน

คำถามที่ควรตอบได้

  1. ผู้บริหารระดับสูงมอบหมายบทบาทใดบ้างใน ISMS และการมอบหมายนั้นปรากฏเป็นหลักฐานที่ใด (ที่มา ข้อ 5.3)
  2. ผู้ถือบทบาทแต่ละคนมีอำนาจตัดสินใจถึงระดับใดโดยไม่ต้องขออนุมัติเพิ่ม (ที่มา ข้อ 5.3)
  3. ใครคือผู้รับผิดชอบการรายงานสมรรถนะของ ISMS ต่อผู้บริหารระดับสูง และรายงานในรอบเวลาใด (ที่มา ข้อ 5.3 ประกอบข้อ 9.3)
  4. ชื่อเจ้าของความเสี่ยงในทะเบียนความเสี่ยงตรงกับบทบาทที่มอบหมายไว้หรือไม่ และเจ้าตัวทราบหรือไม่ (ที่มา ข้อ 5.3 ประกอบข้อ 6.1.2 และ 6.1.3)
  5. องค์กรสื่อสารการมอบหมายเหล่านี้ให้ผู้ที่เกี่ยวข้องทราบด้วยวิธีใด และยืนยันการรับทราบอย่างไร (ที่มา ข้อ 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 สอนเป็นภาษาไทยและอังกฤษ

ดูตารางอบรม   สอบถามรายละเอียด

ติดตามบทความและตารางอบรมใหม่ ๆ ได้ที่เพจ Facebook ของ EQA Thailand

ติดตามเพจ EQA Thailand