EP5 งบประมาณ ที่ปรึกษา และกับดักที่ทำให้สะดุดตอน Audit

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

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

ทั้งสองแบบนั้นมีจุดดีและจุดด้อยต่างกัน

กระบวนการที่เหมาะสม และที่ได้มักจะได้ผลจริงคือรูปแบบที่สามนั้นคือแบบ Hybrid จ้างที่ปรึกษาทำในส่วนที่ต้องอาศัยประสบการณ์ เช่น Gap Analysis, การเขียน SoA และการเตรียมการก่อนที่จะ Audit ส่วนทีมภายในรับหน้าที่ทำ Implementation และจัดเก็บ Evidence เพราะคนในรู้บริบทองค์กรได้ดีกว่าคนนอกเสมอ

กรณีที่จะจ้างที่ปรึกษา ต้องขอดูหลักฐานก่อนว่าเคยพา ลูกค้าผ่าน ISO 27001:2022 มาแล้วกี่ราย และขอ Reference จาก Client จริงที่โทรหาได้ ที่ปรึกษาที่ดีจะไม่ลังเล ถ้าลังเลก็รู้แล้วว่าต้องทำยังไง

รวมทั้งหมดสำหรับรอบแรกอยู่ที่ประมาณ 880,000–3,100,000 บาท ตัวเลขนี้ดูใหญ่ แต่ถ้าเทียบกับค่าเฉลี่ย Data Breach ในหลายอุตสาหกรรมที่อยู่ที่ 5–15 ล้านบาท ให้มองว่าเป็นการประกันความเสี่ยงที่คำนวณแล้วถือว่าคุ้มกว่ามาก ยังไม่นับโอกาสทางธุรกิจที่ได้เพิ่มจากการที่ลูกค้าและคู่ค้าเชื่อถือองค์กรมากขึ้น

• Scope กว้างเกินไปในรอบแรก หลายองค์กรอยากครอบคลุมทุกอย่างตั้งแต่วันแรก แต่ยิ่ง Scope กว้าง โอกาสที่จะมี Evidence ไม่ครบบางจุดก็ยิ่งสูง แนะนำให้เริ่มจาก Scope แคบที่ความเสี่ยงสูงก่อน เช่น ระบบ Cloud หรือระบบที่เก็บข้อมูลลูกค้า แล้วค่อยขยายใน Surveillance Audit ปีถัดไป

• SoA ที่ Include ทุก Control แบบไม่ลืมหูลืมตา บางองค์กรคิดว่า Include ทุกอย่างปลอดภัยกว่า แต่พอ Auditor ถามว่า "มี Evidence อะไร?" แล้วตอบไม่ได้ มันกลายเป็น NC ทันที Include เฉพาะสิ่งที่มีหลักฐานได้จริง ถ้า Exclude ก็ให้เหตุผลที่ชัดเจนไว้

• ไม่มีหลักฐาน Climate Risk ใน Context Registry ใน Amendment 2024 เพิ่มข้อกำหนดใน Clause 4.1 และ 4.2 เรื่อง Climate Risk แต่หลายองค์กรยังไม่รู้ แค่เพิ่มส่วน Climate Risk Consideration เข้าไปใน Context Registry โดยระบุว่าวิเคราะห์แล้วและส่งผลต่อ Data Center หรือ Supply Chain ยังไง ก็สามารถปิดจุดนี้ได้แล้ว

• Checklist Mentality เอกสารครบ นโยบายสวยงาม แต่พอ Auditor ถามพนักงานว่าทำอะไรเมื่อเจอ Phishing ตอบไม่ได้ จบ แนะนำว่าควรซ้อมการสัมภาษณ์กับทีมทุกระดับก่อน Stage 2 อย่างน้อย 2 สัปดาห์ เพราะ Auditor จะคุยกับคนที่ไม่ใช่ทีม ISMS ด้วย

• Internal Audit แบบตรวจตัวเอง ให้ทีม ISMS ตรวจสอบงานของตัวเองแล้ว Auditor จะมองว่าไม่ Independent ผลที่ออกมาก็ไม่น่าเชื่อถือ ให้ทีมจากฝ่ายอื่นมาทำ หรือจ้าง Internal Auditor ภายนอกดีกว่า

• 11 Controls ใหม่ที่ไม่มี Evidence โดยเฉพาะ Threat Intelligence (5.7) และ Cloud Security (5.23) ที่หลายองค์กรอ้างว่าครอบคลุมโดย Controls เดิมอยู่แล้ว แต่ไม่มีหลักฐานยืนยัน จัดทำ Evidence Folder ของ 11 Controls ใหม่แยกออกมาให้ชัด ก่อนเข้า Stage 2

ปิดท้าย Series

ตลอด 5 EP ที่ผ่านมา สิ่งที่อยากให้กลับไปคิดมากที่สุดไม่ใช่เรื่อง Controls หรือ Clause ไหนครับ มันคือเรื่องของ Mindset

องค์กรที่ผ่าน ISO 27001:2022 ได้จริงและรักษาไว้ได้นานมักมีสิ่งหนึ่งที่เหมือนกัน คือเขามองโปรเจกต์นี้เป็นการสร้างโครงสร้างพื้นฐานขององค์กร ไม่ใช่การทำเครื่องหมายถูกในกระดาษ ความต่างตรงนี้เล็กมาก แต่ผลลัพธ์ที่ได้ต่างกันมาก

และถ้าองค์กรไหนยังอยู่กับ ISO 27001:2013 อยู่ ต้องบอกตรงๆ ว่าเส้นตายผ่านไปแล้วตั้งแต่ 31 ตุลาคม 2568 ใบรับรองที่มีอยู่ไม่ Valid แล้ว การเริ่ม Recertification ตอนนี้ไม่ใช่เรื่องเตรียมตัวอีกต่อไป แต่คือการแก้ปัญหาที่เกิดขึ้นแล้ว

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