ISO/IEC 27001 ความมั่นคงปลอดภัยสารสนเทศ บทความ

ISO/IEC 27001:2022 ข้อ 7.2 ความสามารถ และข้อ 7.3 ความตระหนัก ต่างกันอย่างไร

2 กันยายน 2026 10 นาที 30 Views

สรุปสั้นก่อน
ข้อ 7.2 ความสามารถ (competence) และข้อ 7.3 ความตระหนัก (awareness) ของ ISO/IEC 27001:2022 อยู่ติดกัน และในทางปฏิบัติสามารถถูกยุบรวมเป็นกิจกรรมเดียวคือการอบรมประจำปีได้ง่าย แต่สองข้อนี้ตอบคำถามคนละคำถาม ข้อ 7.2 ถามว่าคนที่ทำงานนั้นทำได้จริงหรือไม่ ข้อ 7.3 ถามว่าคนในองค์กรรู้หรือไม่ว่าตัวเองเกี่ยวข้องกับความมั่นคงปลอดภัยสารสนเทศอย่างไร คนหนึ่งคนอาจผ่านข้อหนึ่งแต่ตกอีกข้อหนึ่งได้ และการอบรมหนึ่งครั้งไม่ได้ปิดทั้งสองข้อโดยอัตโนมัติ

ความสามารถกับความตระหนัก ต่างกันที่คำถามปลายทาง

ความสามารถเป็นเรื่องของการทำงานเฉพาะให้ได้ผลตามที่ต้องการ ผู้ดูแลระบบที่ต้องกำหนดสิทธิ์การเข้าถึงต้องรู้ว่าจะตั้งค่าอย่างไรให้ตรงกับหลักการให้สิทธิ์เท่าที่จำเป็น นี่คือความสามารถ วัดจากผลงาน ไม่ได้วัดจากการนั่งฟัง

ความตระหนักเป็นเรื่องของความเข้าใจร่วมกันทั้งองค์กรว่านโยบายความมั่นคงปลอดภัยสารสนเทศมีอยู่เพื่ออะไร ตัวเองมีส่วนช่วยให้ระบบทำงานได้อย่างไร และถ้าไม่ทำตามจะเกิดผลอะไรตามมา พนักงานบัญชีไม่จำเป็นต้องตั้งค่าไฟร์วอลล์เป็น แต่ต้องรู้ว่าอีเมลที่ขอให้เปลี่ยนเลขบัญชีปลายทางกะทันหันคือสิ่งที่ต้องหยุดและตรวจสอบก่อน

เมื่อแยกสองคำถามนี้ออกจากกันจะเห็นทันทีว่าเนื้อหาที่ใช้ต่างกัน กลุ่มเป้าหมายต่างกัน และวิธีพิสูจน์ว่าได้ผลก็ต่างกันด้วย

มุมเปรียบเทียบ	ข้อ 7.2 ความสามารถ	ข้อ 7.3 ความตระหนัก
ใครเกี่ยวข้อง	คนที่ทำงานซึ่งส่งผลต่อผลการดำเนินงานด้านความมั่นคงปลอดภัย	ทุกคนที่ทำงานภายใต้การควบคุมขององค์กร
คำถามหลัก	ทำงานนี้ได้ผลจริงหรือไม่	รู้หรือไม่ว่าตนเองเกี่ยวข้องอย่างไร
หลักฐานที่พูดแทนได้	ผลการประเมินความสามารถ ผลงานที่ตรวจสอบได้ การสอบทานงานโดยผู้มีประสบการณ์	การตอบคำถามหน้างานได้ตรงกับนโยบาย พฤติกรรมการรายงานเหตุการณ์
เมื่อยังไม่พอ ต้องทำอะไร	ดำเนินการเพื่อให้ได้ความสามารถ แล้วประเมินว่าสิ่งที่ทำไปได้ผลหรือไม่	สื่อสารซ้ำในรูปแบบที่เข้าถึงกลุ่มนั้นจริง

คำว่า “ทำงานภายใต้การควบคุมขององค์กร” กว้างกว่าคำว่าพนักงาน

นี่คือจุดที่ขอบเขตของสองข้อนี้กว้างกว่าที่คำว่าบุคลากรชวนให้เข้าใจ ถ้อยคำที่มาตรฐานใช้ไม่ได้จำกัดอยู่ที่ลูกจ้างประจำ แต่ครอบคลุมผู้ที่ทำงานให้องค์กรภายใต้การกำกับขององค์กร ซึ่งในบริบทงานไอทีของไทยครอบคลุมได้ถึงผู้รับเหมาช่วงพัฒนาซอฟต์แวร์ พนักงานจ้างเหมาบริการที่ประจำอยู่ในสำนักงาน และทีมดูแลระบบจากภายนอกที่มีสิทธิ์เข้าถึงระดับผู้ดูแล

คำถามที่ตามมาคือ องค์กรพิสูจน์ความสามารถของคนกลุ่มนี้อย่างไร คำตอบที่ใช้ได้จริงไม่จำเป็นต้องเป็นการส่งคนกลุ่มนี้เข้าอบรมเอง ทางที่ตรงกว่าคือการกำหนดเกณฑ์ความสามารถไว้ในเงื่อนไขสัญญาหรือข้อกำหนดการจัดหา แล้วขอหลักฐานเมื่อรับคนเข้ามาทำงาน ซึ่งเชื่อมต่อไปยังการควบคุมความสัมพันธ์กับผู้ส่งมอบและการวางแผนควบคุมการปฏิบัติงานตามข้อ 8.1

กรณีสมมติ: ผู้ให้บริการไอทีแห่งหนึ่งในกรุงเทพฯ (กรณีสมมติเพื่อประกอบคำอธิบาย) มีทีมพัฒนาภายในสิบคนและใช้ผู้รับเหมาช่วงอีกหกคนสำหรับงานเชื่อมต่อระบบของลูกค้า ในการตรวจประเมิน องค์กรแสดงทะเบียนการอบรมที่มีชื่อพนักงานสิบคนครบถ้วน

ผู้ตรวจถามต่อว่าผู้รับเหมาช่วงหกคนที่มีสิทธิ์เข้าถึงเซิร์ฟเวอร์ทดสอบซึ่งมีข้อมูลลูกค้าจริงอยู่ ได้รับการพิจารณาตามข้อ 7.2 และข้อ 7.3 อย่างไร คำตอบที่องค์กรให้คือคนกลุ่มนี้ไม่ใช่พนักงาน จึงไม่อยู่ในทะเบียนอบรม

ช่องว่างตรงนี้ไม่ได้แก้ด้วยการเพิ่มชื่อหกคนลงในทะเบียนอบรม แต่แก้ด้วยการตัดสินใจก่อนว่าคนกลุ่มนี้ต้องมีความสามารถระดับใดจึงจะให้สิทธิ์เข้าถึงได้ แล้วจึงกำหนดวิธีพิสูจน์และวิธีสร้างความตระหนักที่เหมาะกับความสัมพันธ์แบบสัญญาจ้าง

หลักฐานความสามารถไม่ได้แปลว่าใบประกาศ

ข้อ 7.2 ระบุให้พิจารณาความสามารถจากการศึกษา การฝึกอบรม หรือประสบการณ์ ซึ่งหมายความว่าเส้นทางไปสู่ความสามารถมีได้หลายทาง ไม่ได้บังคับให้ทุกคนต้องมีวุฒิบัตร ผู้ดูแลระบบที่ทำงานมาแปดปีและผ่านการสอบทานงานโดยหัวหน้าทีมอย่างสม่ำเสมอ อาจมีหลักฐานความสามารถที่หนักแน่นกว่าคนที่เพิ่งเรียนจบหลักสูตรสามวัน

ท่อนที่มีน้ำหนักในทางปฏิบัติคือ เมื่อองค์กรพบว่าความสามารถยังไม่พอและตัดสินใจทำอะไรบางอย่างเพื่อเติมเต็ม องค์กรต้องประเมินด้วยว่าสิ่งที่ทำไปนั้นได้ผลหรือไม่ นั่นแปลว่าการส่งคนไปอบรมแล้วเก็บใบประกาศไว้ ยังไม่ปิดข้อกำหนด ต้องมีร่องรอยว่าหลังอบรมแล้วคนนั้นทำงานได้ต่างจากเดิมอย่างไร

ร่องรอยแบบนี้ไม่จำเป็นต้องซับซ้อน การให้หัวหน้าทีมสอบทานงานชิ้นแรกหลังอบรมแล้วบันทึกผล หรือการมอบหมายงานจริงแล้วตรวจผลลัพธ์ ก็เป็นหลักฐานการประเมินประสิทธิผลได้ ตราบใดที่บันทึกไว้เป็นเอกสารสารสนเทศตามข้อ 7.5

ความตระหนักที่ใช้ได้ ต้องเจาะจงกับบทบาท

ข้อ 7.3 กำหนดสามเรื่องที่คนต้องตระหนัก ได้แก่ นโยบายความมั่นคงปลอดภัยสารสนเทศ ส่วนที่ตัวเองมีต่อประสิทธิผลของระบบ และผลที่จะตามมาถ้าไม่ทำตามข้อกำหนดของระบบ

เรื่องที่สองคือเรื่องที่ทำให้เนื้อหาต้องต่างกันไปตามกลุ่ม เพราะ “ส่วนที่ตัวเองมี” ของพนักงานฝ่ายจัดซื้อ กับของนักพัฒนาซอฟต์แวร์ ไม่ใช่เรื่องเดียวกันเลย การใช้สไลด์ชุดเดียวกับทุกฝ่ายจึงตอบข้อนี้ได้เพียงบางส่วน เพราะทุกคนจะจำได้แต่หลักการกว้าง ๆ ที่ไม่ผูกกับงานตรงหน้า

กรณีสมมติ: โรงงานอิเล็กทรอนิกส์แห่งหนึ่งในปทุมธานี (กรณีสมมติ) ที่ขอการรับรอง ISO/IEC 27001:2022 จัดอบรมความตระหนักปีละครั้งด้วยเนื้อหาชุดเดียวทั้งบริษัท

เมื่อผู้ตรวจเดินสายการผลิตแล้วถามพนักงานควบคุมเครื่องจักรว่า ถ้าพบว่าจอควบคุมแสดงข้อความแปลกที่ไม่เคยเห็น ต้องทำอย่างไร คำตอบที่ได้คือแจ้งหัวหน้ากะ ซึ่งถูกต้อง แต่เมื่อถามต่อว่าเหตุการณ์นี้นับเป็นเหตุการณ์ด้านความมั่นคงปลอดภัยสารสนเทศหรือไม่ และต้องรายงานเข้าช่องทางใด คำตอบเริ่มไม่ตรงกันระหว่างกะ

สิ่งที่ขาดไม่ใช่จำนวนชั่วโมงอบรม แต่คือเนื้อหาที่เจาะจงพอจะบอกคนหน้าเครื่องได้ว่าอะไรคือสัญญาณที่ต้องรายงาน และรายงานไปที่ไหน ซึ่งเชื่อมกลับไปยังการสื่อสารตามข้อ 7.4

สองข้อนี้ไปโผล่ที่ไหนอีกในระบบ

ความสามารถและความตระหนักไม่ได้จบในหมวดสนับสนุน เมื่อองค์กรเลือกมาตรการควบคุมและบันทึกไว้ในเอกสารแสดงการบังคับใช้ตามข้อ 6.1.3 มาตรการจำนวนหนึ่งจะพึ่งพาคนโดยตรง มาตรการที่ดีที่สุดจะไม่ทำงานถ้าคนที่ต้องใช้ไม่เข้าใจว่าต้องทำอะไร

ในทางกลับกัน เมื่อเกิดความไม่สอดคล้องขึ้น การวิเคราะห์สาเหตุที่ลงเอยด้วยคำว่าขาดความตระหนักซ้ำแล้วซ้ำอีก เป็นสัญญาณว่าการวิเคราะห์ยังไม่ลึกพอ เพราะคำถามถัดไปที่ควรถามคือ ทำไมคนนั้นถึงไม่ตระหนัก ระบบสื่อสารพลาดตรงไหน หรือความสามารถที่กำหนดไว้ตั้งแต่ต้นไม่ตรงกับงานจริง

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

องค์กรกำหนดไว้ที่ใดว่าบทบาทใดต้องมีความสามารถระดับใด และกำหนดจากอะไร (ที่มา: ข้อ 7.2)
ผู้รับเหมาช่วงและผู้ให้บริการภายนอกที่มีสิทธิ์เข้าถึงระบบ ถูกพิจารณาภายใต้ข้อ 7.2 และ 7.3 อย่างไร (ที่มา: ข้อ 7.2 และ 7.3 ประกอบข้อ 8.1)
เมื่อองค์กรจัดอบรมเพื่อเติมความสามารถ มีการประเมินหรือไม่ว่าการอบรมนั้นได้ผล และประเมินด้วยวิธีใด (ที่มา: ข้อ 7.2)
เนื้อหาความตระหนักของแต่ละกลุ่มบทบาทต่างกันอย่างไร หรือใช้ชุดเดียวกันทั้งองค์กร (ที่มา: ข้อ 7.3)
คนหน้างานอธิบายได้หรือไม่ว่าผลที่จะตามมาถ้าไม่ปฏิบัติตามข้อกำหนดของระบบคืออะไร (ที่มา: ข้อ 7.3)

อ่านเพิ่มเติมในหัวข้อที่เกี่ยวข้อง: นโยบายความมั่นคงปลอดภัยสารสนเทศตามข้อ 5.2 และ การตรวจติดตามภายในตามข้อ 9.2

บทความชุดเดียวกันที่เผยแพร่พร้อมกัน: ISO 45001 ข้อ 6.2 วัตถุประสงค์ OH&S และการวางแผนเพื่อบรรลุ และ ISO 14001:2026 ข้อ 8.1 การควบคุมการปฏิบัติงาน

บทความนี้เรียบเรียงขึ้นด้วยถ้อยคำของผู้เรียบเรียงเพื่ออธิบายและตีความข้อกำหนด ไม่ใช่การแปลหรือทำซ้ำเนื้อหาของมาตรฐาน ตัวอย่างทั้งหมดเป็นกรณีสมมติเพื่อประกอบคำอธิบาย การนำไปใช้จริงให้ยึดตัวมาตรฐานฉบับจริงเป็นหลัก