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

ISO/IEC 27001 ข้อ 6.3 การวางแผนการเปลี่ยนแปลง: ตีความข้อกำหนดและตัวอย่างในบริบทไทย

6 กันยายน 2026 10 นาที 27 Views

สรุปสั้นก่อน
ข้อ 6.3 การวางแผนการเปลี่ยนแปลง (planning of changes) ของ ISO/IEC 27001:2022 เป็นข้อที่สั้นที่สุดข้อหนึ่งของมาตรฐาน แต่ถามคำถามที่แรงมาก คือเมื่อองค์กรเห็นว่าระบบการจัดการความมั่นคงปลอดภัยสารสนเทศ (information security management system หรือ ISMS) ต้องเปลี่ยน องค์กรเปลี่ยนมันอย่างมีแผนหรือเปลี่ยนไปตามสถานการณ์ ข้อนี้พูดถึงการเปลี่ยนแปลงของตัวระบบ ไม่ใช่การเปลี่ยนแปลงของงานไอทีรายวัน และนั่นคือจุดที่ผู้ตรวจประเมินกับผู้ถูกตรวจมองคนละภาพกันได้ง่ายที่สุด

ข้อ 6.3 ต้องการอะไร

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

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

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

เส้นแบ่งระหว่างข้อ 6.3 กับข้อ 8.1

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

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

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

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

กรณีสมมติ — ผู้ให้บริการไอทีในกรุงเทพฯ
บริษัทสมมติแห่งหนึ่งให้บริการพัฒนาและดูแลระบบ ได้รับการรับรอง ISO/IEC 27001 มาแล้วสองปี ขอบเขตของ ISMS ครอบคลุมสำนักงานใหญ่และศูนย์ปฏิบัติการที่ให้บริการลูกค้า

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

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

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

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

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

การเปลี่ยนแปลงแบบใดที่ควรถูกจับด้วยข้อ 6.3

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

เหตุการณ์	สิ่งที่ต้องหยิบมาพิจารณาซ้ำ
เพิ่มสถานที่ทำงานหรือรูปแบบการทำงานใหม่	ขอบเขตตามข้อ 4.3 และการประเมินความเสี่ยงตามข้อ 6.1.2
เพิ่มบริการหรือลูกค้าที่มีข้อกำหนดด้านความมั่นคงปลอดภัยต่างจากเดิม	ความต้องการของผู้มีส่วนได้ส่วนเสียตามข้อ 4.2 และแผนจัดการความเสี่ยงตามข้อ 6.1.3
เปลี่ยนโครงสร้างองค์กรหรือผู้รับผิดชอบหลัก	บทบาทและอำนาจตามข้อ 5.3 และเจ้าของความเสี่ยงในทะเบียนความเสี่ยง
เปลี่ยนเกณฑ์ยอมรับความเสี่ยงหรือวิธีประเมิน	ผลการประเมินความเสี่ยงเดิมทั้งชุดตามข้อ 6.1.2 และข้อ 8.2
ใช้ผู้ให้บริการภายนอกรายใหม่ในกระบวนการสำคัญ	การควบคุมกระบวนการที่ใช้ผู้ให้บริการภายนอกตามข้อ 8.1 และความเสี่ยงที่เกี่ยวข้อง

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

“อย่างเป็นแผน” ทิ้งหลักฐานอะไรไว้

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

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

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

อ่านประกอบ: ISO/IEC 27001 ข้อ 6.1.3 การจัดการความเสี่ยงและเอกสารแสดงความเกี่ยวข้องของมาตรการควบคุม · ISO/IEC 27001 ข้อ 8.1 การวางแผนและควบคุมการปฏิบัติการ · ISO/IEC 27001 ข้อ 4.1 ถึง 4.3 บริบทและขอบเขตของ ISMS

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

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

บทความชุดเดียวกันที่เผยแพร่พร้อมกัน: ISO 45001 ข้อ 5.2 นโยบายอาชีวอนามัยและความปลอดภัย · ISO 14001:2026 ข้อ 6.1.4 และ 6.1.5 ความเสี่ยง โอกาส และการวางแผนปฏิบัติการ

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