ข้อ 9.2 ของ ISO/IEC 27001:2022 แบ่งเป็นสองส่วนคือ ข้อ 9.2.1 ที่บอกว่าการตรวจประเมินภายในมีไว้เพื่ออะไร และข้อ 9.2.2 ที่บอกว่าโปรแกรมการตรวจประเมินต้องมีอะไร จุดที่ทำให้บทนี้ต่างจากมาตรฐานระบบบริหารตัวอื่นคือคำว่า “ข้อกำหนดขององค์กรเอง” ซึ่งในบริบทของ ISMS หมายรวมถึงประกาศการประยุกต์ใช้ (Statement of Applicability) และแผนการจัดการความเสี่ยงที่องค์กรตัดสินใจไว้เอง ไม่ใช่แค่ข้อ 4 ถึง 10 ของตัวมาตรฐาน
สองคำถามที่การตรวจประเมินภายในต้องตอบ
ข้อ 9.2.1 วางเป้าหมายไว้สองชั้น ชั้นแรกคือความสอดคล้อง ซึ่งแยกย่อยอีกเป็นสองทาง คือสอดคล้องกับสิ่งที่องค์กรกำหนดไว้เอง และสอดคล้องกับข้อกำหนดของมาตรฐาน ชั้นที่สองคือระบบถูกนำไปปฏิบัติและคงไว้อย่างสัมฤทธิ์ผลหรือไม่
ชั้นที่สองคือชั้นที่รายงานการตรวจประเมินภายในมักตอบไม่ครบ เพราะการตอบว่ามีเอกสารครบและทำตามขั้นตอนแล้วตอบได้แค่ชั้นแรก การตอบชั้นที่สองต้องดูว่ามาตรการที่ประกาศว่าใช้อยู่นั้นทำงานจริงหรือไม่ เช่น การทบทวนสิทธิ์การเข้าถึงเกิดขึ้นตามรอบจริงหรือไม่ และผลการทบทวนนำไปสู่การเพิกถอนสิทธิ์ที่ไม่จำเป็นจริงหรือไม่
เกณฑ์การตรวจของ ISMS กว้างกว่าที่หลายทีมตั้งไว้
ข้อ 9.2.2 กำหนดให้ระบุเกณฑ์และขอบเขตของการตรวจประเมินในแต่ละครั้ง สำหรับ ISMS เกณฑ์ที่ครบควรประกอบด้วยตัวมาตรฐาน นโยบายและขั้นตอนที่องค์กรออกเอง ผลการประเมินความเสี่ยงและการตัดสินใจจัดการความเสี่ยง ประกาศการประยุกต์ใช้ และข้อกำหนดตามกฎหมายหรือสัญญาที่องค์กรระบุไว้ว่าเกี่ยวข้อง
ถ้าเกณฑ์ตั้งไว้แค่ตัวมาตรฐาน การตรวจจะไม่มีวันไปแตะว่ามาตรการที่ประกาศว่าใช้อยู่ถูกนำไปปฏิบัติจริงหรือไม่ ซึ่งเป็นส่วนที่ผู้ตรวจประเมินจากหน่วยรับรองจะเข้าไปดูแน่นอน
เมื่อหน่วยรับรองเข้าตรวจ กลับพบว่ามาตรการเรื่องการจัดการสิทธิ์ของผู้ใช้ที่องค์กรประกาศว่าใช้อยู่ ไม่ได้ถูกทบทวนมาสองปี
สาเหตุไม่ได้อยู่ที่ผู้ตรวจภายในทำงานไม่ดี แต่อยู่ที่เกณฑ์การตรวจไม่ได้รวมประกาศการประยุกต์ใช้ไว้ตั้งแต่ต้น แบบตรวจจึงไม่มีคำถามใดที่จะพาไปเจอเรื่องนี้ได้เลย
โปรแกรมการตรวจประเมินไม่ใช่ตารางนัดหมาย
ข้อ 9.2.2 ระบุองค์ประกอบของโปรแกรมไว้ชัด คือความถี่ วิธีการ หน้าที่ความรับผิดชอบ ความต้องการในการวางแผน และการรายงานผล ที่สำคัญคือเมื่อกำหนดโปรแกรม องค์กรต้องพิจารณาความสำคัญของกระบวนการที่เกี่ยวข้อง และผลของการตรวจประเมินครั้งก่อน
สองเงื่อนไขนี้แปลว่าโปรแกรมที่ให้น้ำหนักทุกกระบวนการเท่ากันทุกปีโดยไม่เปลี่ยนแปลงเลย ยังไม่ตอบข้อกำหนด กระบวนการที่มีความเสี่ยงสูงกว่า หรือกระบวนการที่ปีก่อนพบข้อบกพร่อง ควรถูกตรวจถี่กว่าหรือลึกกว่า และควรเห็นร่องรอยการปรับโปรแกรมตามผลที่ผ่านมา
| องค์ประกอบตามข้อ 9.2.2 | สิ่งที่ควรเห็นในทางปฏิบัติ |
|---|---|
| ความถี่ | ต่างกันตามความเสี่ยงของแต่ละกระบวนการ ไม่ใช่ปีละครั้งเท่ากันหมด |
| วิธีการ | สัมภาษณ์ ดูหลักฐานในระบบ สุ่มตัวอย่างบันทึก หรือทดสอบการตั้งค่า |
| หน้าที่ความรับผิดชอบ | ระบุผู้จัดโปรแกรม ผู้ตรวจ และผู้อนุมัติแผน แยกจากกันชัดเจน |
| เกณฑ์และขอบเขตแต่ละครั้ง | ระบุไว้ในแผนการตรวจแต่ละรอบ รวมประกาศการประยุกต์ใช้ด้วย |
| การรายงานผล | ถึงผู้บริหารที่เกี่ยวข้อง และเชื่อมเข้าสู่การทบทวนของผู้บริหารตามข้อ 9.3 |
| หลักฐาน | สารสนเทศเป็นลายลักษณ์อักษรของทั้งตัวโปรแกรมและผลการตรวจ |
ความเป็นกลางในองค์กรที่ทีมไอทีมีไม่กี่คน
ข้อกำหนดให้เลือกผู้ตรวจและดำเนินการตรวจในลักษณะที่รักษาความเป็นกลางของกระบวนการไว้ ในทางปฏิบัติหมายถึงผู้ตรวจไม่ควรตรวจงานที่ตัวเองทำ ซึ่งเป็นโจทย์จริงสำหรับองค์กรที่มีคนดูแลระบบเพียงหนึ่งถึงสองคน
ทางออกที่ใช้ได้มีหลายแบบ เช่น ให้คนจากสายงานอื่นที่ผ่านการอบรมเป็นผู้ตรวจในหัวข้อที่ไม่ต้องใช้ความลึกทางเทคนิคมาก จับคู่ตรวจไขว้ระหว่างหน่วยงาน หรือใช้ผู้ตรวจจากภายนอกที่มีคุณสมบัติมาทำในนามขององค์กร สิ่งที่ต้องมีคือเหตุผลที่บันทึกไว้ว่าเลือกวิธีใดและวิธีนั้นรักษาความเป็นกลางได้อย่างไร
เส้นทางของผลการตรวจหลังจบงาน
ข้อกำหนดให้รายงานผลไปยังผู้บริหารที่เกี่ยวข้อง คำว่าเกี่ยวข้องหมายถึงผู้ที่มีอำนาจสั่งการแก้ไขในเรื่องนั้นจริง ไม่ใช่ส่งเข้าแฟ้มกลางแล้วจบ จากนั้นผลการตรวจจะไหลต่อไปเป็นข้อมูลนำเข้าของการทบทวนของผู้บริหารตามข้อ 9.3 และข้อบกพร่องที่พบจะเข้าสู่กระบวนการตามข้อ 10.2
อ่านต่อเรื่องต้นทางของเกณฑ์การตรวจได้ที่บทความ ISO/IEC 27001 ข้อ 6.1.3 การจัดการความเสี่ยงและ Statement of Applicability
คำถามที่ควรตอบได้
- โปรแกรมการตรวจประเมินกำหนดความถี่ วิธีการ ผู้รับผิดชอบ และการรายงานไว้อย่างไร (ที่มา ข้อ 9.2.2)
- ความสำคัญของกระบวนการและผลการตรวจครั้งก่อน ถูกนำมาใช้ปรับโปรแกรมอย่างไร (ที่มา ข้อ 9.2.2)
- เกณฑ์การตรวจในแต่ละรอบครอบคลุมประกาศการประยุกต์ใช้และข้อกำหนดตามสัญญาหรือไม่ (ที่มา ข้อ 9.2.2)
- รักษาความเป็นกลางของผู้ตรวจอย่างไร โดยเฉพาะเมื่อทีมมีขนาดเล็ก (ที่มา ข้อ 9.2.2)
- ผลการตรวจถูกรายงานถึงใคร และเชื่อมเข้าสู่การทบทวนของผู้บริหารอย่างไร (ที่มา ข้อ 9.2.2 ประกอบข้อ 9.3)
บทความนี้เรียบเรียงขึ้นด้วยถ้อยคำของผู้เรียบเรียงเพื่ออธิบายและตีความข้อกำหนด ไม่ใช่การแปลหรือทำซ้ำเนื้อหาของมาตรฐาน ตัวอย่างทั้งหมดเป็นกรณีสมมติเพื่อประกอบคำอธิบาย การนำไปใช้จริงให้ยึดตัวมาตรฐานฉบับจริงเป็นหลัก
หลักสูตรฝึกอบรม ISO/IEC 27001:2022
Equal Assurance (Thailand) Ltd. เป็นหน่วยรับรองระบบและผู้ให้บริการฝึกอบรม เปิดหลักสูตรทั้งแบบ Public และ In-house สอนเป็นภาษาไทยและอังกฤษ
เกี่ยวกับผู้ตรวจทานบทความ

จีรศักดิ์ ม่วงชิน (Jeerasak Muangchin)
ผู้ตรวจประเมิน / วิทยากร – ระบบยานยนต์ คุณภาพ สิ่งแวดล้อม อาชีวอนามัยและความปลอดภัย และความมั่นคงปลอดภัยสารสนเทศ · ผู้ตรวจประเมินขึ้นทะเบียน IATF · Certified in Cybersecurity (CC) · DPO Certified Level 1 & 2 (ICDL)
- ปริญญาตรี เทคโนโลยีสารสนเทศและการสื่อสาร (มสธ.) · ปริญญาโท MBA (มหาวิทยาลัยรามคำแหง หลักสูตรนานาชาติ) · ปริญญาตรี วิศวกรรมไฟฟ้ากำลัง (มจธ.)
- Lead Auditor และวิทยากรกับหน่วยรับรองระดับสากลตั้งแต่ปี 2006 · เคยเป็นวิทยากรหลักที่ได้รับอนุมัติสำหรับหลักสูตร IRCA ISO 9001 Lead Auditor
- ประสบการณ์ 4 ปีในตำแหน่ง Division Manager โรงงานอุปกรณ์ไฟฟ้าและฉีดพลาสติก ทำงานกับทีม APQP, MSA, SPC และ QMS
- ตรวจประเมินและสอน IATF 16949, ISO 9001, ISO 14001, ISO 45001, ISO 22301, ISO 39001, ISO/IEC 17025, ISO/IEC 27001 และ 27701, ISO 13485, ISCC, RSPO, คาร์บอนฟุตพริ้นท์ (CFO/CFP), Core Tools (APQP, PPAP, FMEA, MSA, SPC), VDA 6.3 และ TISAX
ภาษาที่สอน: ไทยและอังกฤษ
หลักสูตรที่เกี่ยวข้อง
ISO/IEC 27001 ความมั่นคงปลอดภัยสารสนเทศ (ISMS)
EQA Thailand เปิดอบรมหลักสูตรนี้ และเป็นหน่วยตรวจรับรอง (Certification Body) ที่สามารถตรวจรับรองระบบตามมาตรฐานนี้ได้ด้วย
หลักสูตรมีเนื้อหาเป็นการทั่วไป ไม่ใช่การให้คำปรึกษาเฉพาะราย และการเข้าอบรมไม่มีผลต่อผลการตรวจประเมิน
อ่านต่อเกี่ยวกับมาตรฐานนี้: ISO/IEC 27001 ความมั่นคงปลอดภัยสารสนเทศ
ขอการรับรอง ISO/IEC 27001 กับ EQA
- ขั้นตอนและระยะเวลาตั้งแต่ยื่นใบสมัครถึงได้ใบรับรอง
- ค่าตรวจรับรองคิดจากอะไร (IAF MD 5)
- วิธีเลือกหน่วยรับรอง 7 ข้อที่ตรวจสอบได้
กรอกใบสมัครขอรับรอง ISO/IEC 27001
EQA เป็นหน่วยรับรอง (Certification Body) จึงไม่ให้คำปรึกษาในการจัดทำระบบ บทความนี้เป็นความรู้ทั่วไป

ISO/IEC 27001 สำหรับบริษัทซอฟต์แวร์และผู้ให้บริการ: ตรวจอะไร กำหนดขอบข่ายอย่างไร และเวลาตรวจคิดจากอะไร
ISO/IEC 27001:2022 ภาคผนวก A ข้อ 5.31 ข้อกำหนดทางกฎหมาย ข้อบังคับ ระเบียบ และสัญญา: ทะเบียนกฎหมายยังไม่ใช่คำตอบทั้งหมด
ISO/IEC 27001:2022 ภาคผนวก A ข้อ 6.7 การทำงานระยะไกล: เมื่อขอบเขตของ ISMS ขยายออกนอกสถานที่ขององค์กร