ISO/IEC 27001 ข้อ 4.2 ความต้องการและความคาดหวังของผู้มีส่วนได้ส่วนเสีย

ทำไมมาตรฐานถึงต้องมีข้อนี้แยกจากข้อ 4.1

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

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

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

สามชั้นของกรวยกรอง

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

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

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

ข้อ 4.2 ส่งต่อไปที่ไหนบ้าง

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

เส้นแรกไปที่ข้อ 4.3 การกำหนดขอบเขตของ ISMS เพราะข้อ 4.3 กำหนดให้พิจารณาข้อเรียกร้องที่ได้จากข้อ 4.2 ประกอบการกำหนดขอบเขต ขอบเขตที่ตัดกิจกรรมซึ่งมีข้อผูกพันตามสัญญาออกไปโดยไม่มีคำอธิบาย จึงเป็นจุดที่ถูกตั้งคำถามได้

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

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

ตารางนี้เป็นการเรียบเรียงเชิงวิเคราะห์ของผู้เรียบเรียงเพื่ออธิบายลักษณะของหลักฐาน ไม่ใช่การสรุปตัวบทของมาตรฐาน

สิ่งที่ทำให้ทะเบียนนี้ยังมีชีวิต

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

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

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

อ่านประกอบ: ISO/IEC 27001 ข้อ 4.1 และ 4.3 บริบทองค์กรและการกำหนดขอบเขต ISMS · ISO/IEC 27001 ข้อ 6.1.3 การจัดการความเสี่ยงและเอกสารแสดงการบังคับใช้ · ISO/IEC 27001 ข้อ 7.4 การสื่อสาร

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

1. เลือกข้อเรียกร้องหนึ่งข้อจากทะเบียน แล้วชี้ได้หรือไม่ว่าถูกจัดการด้วยมาตรการใด (ที่มา: ข้อ 4.2 ต่อเนื่องถึงข้อ 6.1.3)
2. ข้อเรียกร้องที่องค์กรตัดสินใจไม่จัดการผ่าน ISMS มีข้อใดบ้าง และเหตุผลถูกบันทึกไว้ที่ใด (ที่มา: ข้อ 4.2)
3. เงื่อนไขด้านความมั่นคงปลอดภัยในสัญญาที่ลงนามในรอบปีที่ผ่านมา เข้าสู่ทะเบียนแล้วหรือยัง (ที่มา: ข้อ 4.2 ประกอบข้อ 9.3)
4. ขอบเขตของ ISMS ที่ประกาศไว้ ครอบคลุมกิจกรรมที่มีข้อผูกพันตามสัญญาครบหรือไม่ (ที่มา: ข้อ 4.3)
5. ใครเป็นผู้รับผิดชอบส่งต่อข้อเรียกร้องใหม่จากฝ่ายที่รับเรื่องมาถึงผู้ดูแล ISMS (ที่มา: ข้อ 5.3 ประกอบข้อ 4.2)

บทความใหม่ในชุดเดียวกัน: ISO 45001 ข้อ 10.3 การปรับปรุงอย่างต่อเนื่อง · ISO 14001:2026 ข้อ 6.1.3 พันธกรณีที่ต้องปฏิบัติตาม

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