ข้อ 6.2 วัตถุประสงค์ด้านความมั่นคงปลอดภัยสารสนเทศและการวางแผนเพื่อบรรลุวัตถุประสงค์ ของ ISO/IEC 27001:2022 มีสองครึ่ง ครึ่งแรกว่าด้วยคุณสมบัติของตัววัตถุประสงค์เอง ครึ่งหลังว่าด้วยแผนที่จะไปให้ถึง ครึ่งหลังคือส่วนที่พิสูจน์ยากกว่า เพราะวัตถุประสงค์ที่เขียนไว้ดีจะยังใช้ไม่ได้ ถ้าไม่มีใครเป็นเจ้าของ ไม่มีกำหนดเสร็จ และไม่มีวิธีตัดสินว่าบรรลุแล้วหรือยัง จุดที่ทำให้ข้อนี้ต่างจากวัตถุประสงค์ของระบบบริหารฉบับอื่นคือ วัตถุประสงค์ต้องเชื่อมกลับไปหาผลการประเมินและการจัดการความเสี่ยง ไม่ใช่ตั้งขึ้นมาลอย ๆ จากความอยากของฝ่ายบริหาร
วัตถุประสงค์ ตัวชี้วัด และเป้าหมาย เป็นคนละสิ่ง
สามคำนี้ปนกันได้ง่ายในทางปฏิบัติ วัตถุประสงค์คือสภาพที่องค์กรต้องการให้เกิดขึ้นกับความมั่นคงปลอดภัยสารสนเทศ ตัวชี้วัดคือสิ่งที่วัดเพื่อบอกว่าเข้าใกล้สภาพนั้นหรือยัง เป้าหมายคือค่าที่ต้องการของตัวชี้วัดภายในกรอบเวลาหนึ่ง
ปัญหาเกิดเมื่อองค์กรเขียนตัวชี้วัดลงในช่องวัตถุประสงค์ เช่น เขียนว่า “จำนวนเหตุการณ์ด้านความมั่นคงปลอดภัยเท่ากับศูนย์” สิ่งนี้ไม่ได้บอกว่าองค์กรต้องการเปลี่ยนอะไร บอกแค่ตัวเลขที่อยากเห็น เมื่อผู้ตรวจประเมินถามว่าจะทำอย่างไรให้ได้ตัวเลขนั้น คำถามจะตอบไม่ได้ เพราะไม่มีสภาพปลายทางให้เกาะ
วัตถุประสงค์ที่ใช้ได้จะบอกทิศทาง เช่น ลดโอกาสที่สิทธิ์ระดับสูงจะตกค้างอยู่กับคนที่ไม่ได้ทำหน้าที่นั้นแล้ว จากนั้นค่อยเลือกตัวชี้วัดและเป้าหมายมาประกบ ลำดับนี้สำคัญ เพราะมาตรฐานให้วัตถุประสงค์เป็นตัวตั้ง ไม่ใช่ให้ตัวเลขเป็นตัวตั้ง
คำว่า “วัดผลได้ถ้าทำได้” ไม่ใช่ทางออกสำหรับการไม่วัด
ข้อ 6.2 กำหนดให้วัตถุประสงค์วัดผลได้เท่าที่ทำได้ในทางปฏิบัติ ถ้อยคำนี้เปิดช่องไว้สำหรับวัตถุประสงค์บางประเภทที่แปลงเป็นตัวเลขตรง ๆ ได้ยาก เช่น เรื่องความตระหนักของผู้ใช้งาน แต่ช่องนี้ไม่ได้อนุญาตให้ปล่อยวัตถุประสงค์ทั้งชุดไว้โดยไม่มีวิธีประเมิน
เมื่อวัดเป็นตัวเลขไม่ได้ องค์กรยังต้องบอกได้ว่าจะใช้อะไรเป็นหลักฐานว่าเข้าใกล้เป้าหมาย เช่น ผลการทดสอบสถานการณ์จำลอง ผลการทบทวนสิทธิ์การเข้าถึงตามรอบ หรือผลการประเมินความเสี่ยงที่เปลี่ยนไป การมีวิธีตัดสินที่ตกลงกันไว้ล่วงหน้าคือสิ่งที่ผู้ตรวจประเมินมองหา ไม่ใช่ตัวเลขสวย ๆ
ข้อแรกตกทันทีตอนถูกถามว่า “ตลอดเวลา” หมายถึงเท่าใด เพราะไม่มีเกณฑ์ให้ตัดสิน ข้อที่สองวัดได้แต่ไม่เชื่อมกับความเสี่ยงใด จึงเป็นกิจกรรมมากกว่าวัตถุประสงค์ ข้อที่สามใช้ได้ เพราะสืบกลับไปหาความเสี่ยงที่ระบุไว้ในทะเบียนได้ มีสิ่งที่วัดได้ และตอบได้ว่าถ้าตัวเลขไม่ดีขึ้นแปลว่าอะไร
สิ่งที่องค์กรนี้ต้องแก้ไม่ใช่การเขียนข้อความให้สวยขึ้น แต่คือการเริ่มจากผลการประเมินความเสี่ยงแล้วเดินมาหาวัตถุประสงค์
เส้นที่ต้องลากได้ระหว่างข้อ 6.1 กับข้อ 6.2
ข้อ 6.2 กำหนดให้วัตถุประสงค์คำนึงถึงข้อกำหนดด้านความมั่นคงปลอดภัยสารสนเทศที่บังคับใช้ และผลจากการประเมินความเสี่ยงกับการจัดการความเสี่ยง นี่คือประโยคที่ทำให้ข้อ 6.2 ของ ISO/IEC 27001 มีน้ำหนักมากกว่าวัตถุประสงค์ทั่วไปของระบบบริหารอื่น
ในทางตรวจประเมิน เส้นนี้ตรวจง่าย ผู้ตรวจประเมินจะหยิบวัตถุประสงค์หนึ่งข้อแล้วเดินย้อนกลับไปที่ทะเบียนความเสี่ยงและแผนการจัดการความเสี่ยง ถ้าเดินย้อนไม่ถึง แปลว่าวัตถุประสงค์นั้นเกิดจากที่อื่น ซึ่งไม่ได้ผิดโดยตัวมันเอง แต่องค์กรต้องอธิบายได้ว่ามาจากข้อกำหนดใด เช่น เงื่อนไขในสัญญากับลูกค้า หรือข้อกำหนดตามกฎหมายคุ้มครองข้อมูลส่วนบุคคล
ในทางกลับกัน เส้นนี้ยังใช้ตรวจย้อนอีกทางได้ด้วย ถ้าแผนการจัดการความเสี่ยงระบุการดำเนินการใหญ่ ๆ ไว้หลายเรื่องแต่ไม่มีเรื่องใดปรากฏในชุดวัตถุประสงค์เลย แสดงว่าสองเอกสารนี้ถูกทำแยกกันโดยคนละคน และไม่ได้ถูกใช้เป็นระบบเดียวกัน
ครึ่งหลังของข้อนี้คือแผน และเป็นจุดที่หลักฐานมักไม่พอ
ครึ่งหลังของข้อ 6.2 เปลี่ยนคำถามจาก “อยากได้อะไร” เป็น “จะไปถึงอย่างไร” สิ่งที่มาตรฐานต้องการเห็นคือแผนที่ระบุการดำเนินการ ทรัพยากรที่ต้องใช้ ผู้รับผิดชอบ กรอบเวลา และวิธีประเมินผล
สามส่วนที่พิสูจน์ยากที่สุดในทางปฏิบัติคือทรัพยากร ผู้รับผิดชอบ และวิธีประเมินผล เรื่องทรัพยากรพิสูจน์ยากเพราะงานด้านความมั่นคงปลอดภัยต้องอาศัยเวลาของทีมที่มีงานประจำอยู่ก่อนแล้ว ถ้าแผนไม่ได้ระบุว่าเวลานั้นมาจากไหน แผนก็จะไม่ขยับ เรื่องผู้รับผิดชอบพิสูจน์ยากเพราะการเขียนชื่อหน่วยงานแทนชื่อบทบาททำให้ไม่มีใครเป็นเจ้าของจริง เรื่องวิธีประเมินผลพิสูจน์ยากเพราะต้องตกลงกันไว้ก่อนเริ่ม ไม่ใช่ไปหาวิธีวัดเอาตอนสิ้นปี
| สิ่งที่เขียนไว้ | ทำไมจึงยังไม่พอ | สิ่งที่เพิ่มแล้วใช้ได้ |
|---|---|---|
| ยกระดับความมั่นคงปลอดภัยของระบบสำคัญ | ไม่มีขอบเขต ไม่มีสิ่งที่จะเปลี่ยน จึงประเมินผลไม่ได้ | ระบุระบบที่หมายถึง และคุณสมบัติที่ต้องการให้ดีขึ้น |
| ทบทวนสิทธิ์การเข้าถึงให้ครบตามรอบ | เป็นกิจกรรม ไม่ใช่สภาพปลายทาง | ระบุสภาพที่ต้องการ เช่น ไม่มีสิทธิ์ตกค้างหลังเปลี่ยนหน้าที่ |
| ผู้รับผิดชอบคือฝ่ายไอที | หน่วยงานรับผิดชอบร่วมกันแปลว่าไม่มีใครรับผิดชอบ | ระบุบทบาทที่มีอำนาจตัดสินใจและรายงานความคืบหน้า |
วัตถุประสงค์ต้องสื่อสารและปรับให้ทันสมัย
ข้อ 6.2 ระบุให้วัตถุประสงค์ถูกสื่อสารและถูกปรับปรุงให้ทันสมัยตามความเหมาะสม สองคำนี้มีผลต่อการตรวจมากกว่าที่เห็น การสื่อสารหมายถึงคนที่ต้องทำให้เกิดผลรู้ว่ามีวัตถุประสงค์นี้อยู่ ไม่ใช่แค่ผู้บริหารรู้ ส่วนการปรับให้ทันสมัยหมายถึงเมื่อผลการประเมินความเสี่ยงเปลี่ยน ขอบเขตเปลี่ยน หรือองค์กรเปลี่ยนผู้ให้บริการภายนอก ชุดวัตถุประสงค์ควรถูกทบทวนด้วย ไม่ใช่คงเดิมข้ามปีโดยไม่มีเหตุผล
จุดเชื่อมปลายทางอยู่ที่ข้อ 9.1 การเฝ้าระวัง การวัด การวิเคราะห์ และการประเมินผล และข้อ 9.3 การทบทวนโดยฝ่ายบริหาร ถ้าวัตถุประสงค์ไม่ปรากฏในข้อมูลนำเข้าของการทบทวนโดยฝ่ายบริหาร วงจรจะไม่ปิด และข้อ 6.2 จะกลายเป็นเอกสารที่จัดทำไว้เพื่อการตรวจเท่านั้น
อ่านต่อเรื่องเส้นทางจากความเสี่ยงมาสู่การตัดสินใจได้ที่ ISO/IEC 27001 ข้อ 6.1.3 การจัดการความเสี่ยงและ Statement of Applicability และอ่านเรื่องการวัดผลที่ปลายทางได้ที่ ISO/IEC 27001 ข้อ 9.1 การเฝ้าระวัง การวัด การวิเคราะห์ และการประเมินผล
คำถามที่ควรตอบได้
หนึ่ง เลือกวัตถุประสงค์มาหนึ่งข้อ แล้วเดินย้อนกลับไปยังความเสี่ยงหรือข้อกำหนดที่เป็นต้นทางได้หรือไม่ (ที่มาคือข้อ 6.2 อ่านคู่กับข้อ 6.1.2 และ 6.1.3)
สอง วัตถุประสงค์แต่ละข้อมีวิธีตัดสินว่าบรรลุแล้วหรือยัง และตกลงวิธีนั้นไว้ตั้งแต่เมื่อใด (ที่มาคือข้อ 6.2)
สาม ผู้รับผิดชอบที่ระบุไว้เป็นบทบาทที่มีอำนาจตัดสินใจจริงหรือเป็นชื่อหน่วยงาน (ที่มาคือข้อ 6.2 อ่านคู่กับข้อ 5.3)
สี่ คนที่ต้องลงมือทำรู้หรือไม่ว่ามีวัตถุประสงค์ข้อนี้อยู่ และรู้ผ่านช่องทางใด (ที่มาคือข้อ 6.2 อ่านคู่กับข้อ 7.4)
ห้า ชุดวัตถุประสงค์ถูกทบทวนครั้งล่าสุดเมื่อใด และอะไรเป็นเหตุให้ทบทวน (ที่มาคือข้อ 6.2 อ่านคู่กับข้อ 9.3)
อ่านบทความในชุดเดียวกันที่เผยแพร่พร้อมกันในรอบนี้ได้ที่ ISO 22000 ข้อ 8.7 การควบคุมการเฝ้าระวังและการวัด และ หลักฐานการตรวจประเมินและการสุ่มตัวอย่างตามแนวทาง ISO 19011:2026
บทความนี้เรียบเรียงขึ้นด้วยถ้อยคำของผู้เรียบเรียงเพื่ออธิบายและตีความข้อกำหนด ไม่ใช่การแปลหรือทำซ้ำเนื้อหาของมาตรฐาน ตัวอย่างทั้งหมดเป็นกรณีสมมติเพื่อประกอบคำอธิบาย การนำไปใช้จริงให้ยึดตัวมาตรฐานฉบับจริงเป็นหลัก
หลักสูตร 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 การวางแผนการเปลี่ยนแปลง: ตีความข้อกำหนดและตัวอย่างในบริบทไทย