ISO/IEC 27001 สำหรับบริษัทซอฟต์แวร์และผู้ให้บริการ: ตรวจอะไร กำหนดขอบข่ายอย่างไร และเวลาตรวจคิดจากอะไร

บทความนี้เขียนสำหรับบริษัทซอฟต์แวร์และผู้ให้บริการด้านสารสนเทศที่ได้รับแบบสอบถามด้านความมั่นคงปลอดภัยจากลูกค้าองค์กรหรือลูกค้าต่างประเทศ และในแบบสอบถามมีช่องถามว่า “มีใบรับรอง ISO/IEC 27001 หรือไม่” คำถามที่ตามมาสำหรับผู้บริหารคือ การรับรองนี้ตรวจอะไร ครอบคลุมซอฟต์แวร์ที่บริษัทพัฒนาหรือไม่ ต้องกำหนดขอบข่ายอย่างไรเมื่อระบบอยู่บนคลาวด์และทีมทำงานจากที่บ้าน และหน่วยรับรองคิดเวลาตรวจจากอะไร บทความนี้ตอบคำถามเหล่านี้จากเอกสารสาธารณะ คือ ISO/IEC 27001:2022, ISO/IEC 27006-1:2024 และ ISO/IEC 17021-1:2015 โดยไม่ระบุตัวเลขของหน่วยรับรองใด

สรุปสั้นก่อน

• ใบรับรอง ISO/IEC 27001 รับรอง “ระบบการจัดการความมั่นคงปลอดภัยสารสนเทศ” (Information Security Management System, ISMS) ขององค์กรในขอบข่ายที่ระบุ ไม่ได้รับรองว่าซอฟต์แวร์ชิ้นใดปลอดภัย และไม่ได้รับรองการปฏิบัติตามกฎหมายคุ้มครองข้อมูลส่วนบุคคล
• ขอบข่ายของ ISMS ตามข้อ 4.3 ต้องคำนึงถึงงานที่องค์กรอื่นทำให้ด้วย สำหรับบริษัทที่ใช้บริการคลาวด์ คำถามที่ตามมาคือองค์กรได้นำผู้ให้บริการคลาวด์เข้ามาในการพิจารณานี้แล้วอย่างไร
• เวลาตรวจสำหรับการรับรอง ISMS อยู่ภายใต้ ISO/IEC 27006-1:2024 ไม่ใช่ IAF MD 5 จุดตั้งต้นคือจำนวนบุคลากรที่ทำงานภายใต้การควบคุมขององค์กรในขอบข่าย และปรับด้วยปัจจัยความซับซ้อนของธุรกิจและระบบสารสนเทศ

การรับรองตรวจอะไร และไม่ตรวจอะไร

ISO/IEC 27001 เป็นมาตรฐานข้อกำหนดของระบบการจัดการ ข้อ 4 ถึงข้อ 10 กำหนดสิ่งที่ระบบต้องมี ตั้งแต่บริบท ภาวะผู้นำ การประเมินและการจัดการความเสี่ยง ไปจนถึงการตรวจติดตามภายในและการปรับปรุง ส่วนภาคผนวก A เป็นรายการมาตรการควบคุมอ้างอิงที่องค์กรใช้เทียบกับมาตรการที่ตนกำหนดขึ้นจากกระบวนการจัดการความเสี่ยง (risk treatment) ตามข้อ 6.1.3 ผลของการเทียบนั้นคือเอกสารที่เรียกว่าแถลงการณ์การประยุกต์ใช้ (Statement of Applicability, SoA)

สำหรับบริษัทซอฟต์แวร์ ประเด็นที่ผู้เรียบเรียงเห็นว่าสำคัญสำหรับผู้บริหารตั้งแต่ต้นคือ การตรวจรับรองไม่ใช่การทดสอบโค้ดหรือการทดสอบเจาะระบบ สิ่งที่อยู่ในขอบข่ายการตรวจตาม ISO/IEC 17021-1 คือระบบการจัดการ กล่าวคือกระบวนการที่องค์กรกำหนดขึ้นเพื่อให้การพัฒนาซอฟต์แวร์มั่นคงปลอดภัย และหลักฐานว่ากระบวนการนั้นถูกนำไปปฏิบัติ ภาคผนวก A มีมาตรการควบคุมกลุ่มที่เกี่ยวกับการพัฒนาโดยตรง เช่น ข้อ 8.25 วงจรชีวิตการพัฒนาที่มั่นคงปลอดภัย (Secure development life cycle) และข้อ 8.31 การแยกสภาพแวดล้อมสำหรับพัฒนา ทดสอบ และใช้งานจริง (Separation of development, test and production environments) ผู้เรียบเรียงเห็นว่ามาตรการเหล่านี้จึงเป็นเรื่องของกระบวนการขององค์กร ไม่ใช่คุณสมบัติของผลิตภัณฑ์

สิ่งที่การรับรองไม่ครอบคลุมอีกเรื่องคือกฎหมายคุ้มครองข้อมูลส่วนบุคคล ISO/IEC 27001 มีมาตรการควบคุมที่กำหนดให้องค์กรชี้บ่งข้อกำหนดทางกฎหมายและตามสัญญาที่เกี่ยวกับความมั่นคงปลอดภัยสารสนเทศ ซึ่งอ่านได้ที่ ISO/IEC 27001:2022 ภาคผนวก A ข้อ 5.31 แต่ใบรับรอง ISO/IEC 27001 ไม่ใช่ใบรับรองว่าองค์กรปฏิบัติตามพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคลของไทย ส่วนขยายสำหรับระบบการจัดการข้อมูลส่วนบุคคล (Privacy Information Management System, PIMS) คือ ISO/IEC 27701:2019 ซึ่งเป็นมาตรฐานส่วนขยายของ ISO/IEC 27001 และ ISO/IEC 27002 และอยู่นอกขอบข่ายของบทความนี้

การกำหนดขอบข่ายเมื่อระบบอยู่บนคลาวด์และทีมกระจายตัว

ข้อ 4.3 ของ ISO/IEC 27001:2022 กำหนดให้องค์กรนำความเชื่อมโยงกับงานที่องค์กรอื่นทำให้มาพิจารณาเมื่อกำหนดขอบเขตของ ISMS ผู้เรียบเรียงเห็นว่าข้อนี้มีน้ำหนักเป็นพิเศษสำหรับบริษัทซอฟต์แวร์ที่ใช้บริการคลาวด์ เพราะโครงสร้างพื้นฐานของบริการอยู่ภายใต้การดำเนินงานของผู้ให้บริการคลาวด์ ขอบข่ายที่เขียนว่า “การพัฒนาและให้บริการซอฟต์แวร์บริหารงานบุคคลผ่านอินเทอร์เน็ต” จึงนำมาสู่คำถามว่าองค์กรได้พิจารณาส่วนที่อยู่บนคลาวด์ในการกำหนดขอบข่ายแล้วอย่างไร แม้ศูนย์ข้อมูลของผู้ให้บริการคลาวด์จะอยู่นอกการควบคุมโดยตรงขององค์กรก็ตาม ประเด็นนี้อ่านต่อได้ที่ ภาคผนวก A ข้อ 5.23 ความมั่นคงปลอดภัยสารสนเทศสำหรับการใช้บริการคลาวด์ (Information security for use of cloud services)

เรื่องที่สองคือสถานที่ บริษัทที่ทีมพัฒนาทำงานจากที่บ้านหรือจากพื้นที่ทำงานร่วม ต้องตัดสินว่าขอบข่ายจะระบุสถานที่อย่างไร และมาตรการควบคุมสำหรับการทำงานระยะไกลถูกกำหนดว่าประยุกต์ใช้ในแถลงการณ์การประยุกต์ใช้หรือไม่ ผู้เรียบเรียงเห็นว่าขอบข่ายที่เขียนไว้แคบกว่าบริการที่ให้จริง อาจนำมาสู่คำถามจากลูกค้าว่าส่วนที่ให้บริการอยู่ในขอบข่ายหรือไม่ ประเด็นนี้อ่านต่อได้ที่ ภาคผนวก A ข้อ 6.7 การทำงานระยะไกล (Remote working) และหลักทั่วไปเรื่องขอบข่ายอ่านได้ที่ ISO/IEC 27001:2022 ข้อ 4.1–4.3 บริบทองค์กรและการกำหนดขอบเขต ISMS

หน่วยรับรองคิดเวลาตรวจจากอะไร

สำหรับระบบบริหารคุณภาพ สิ่งแวดล้อม และอาชีวอนามัยและความปลอดภัย เอกสารที่กำหนดวิธีคิดเวลาตรวจคือ IAF MD 5 แต่สำหรับ ISMS เอกสารที่หน่วยรับรองต้องปฏิบัติตามคือ ISO/IEC 27006-1:2024 ซึ่งเป็นมาตรฐานข้อกำหนดสำหรับหน่วยรับรองที่ตรวจและรับรอง ISMS ฉบับนี้ประกาศใช้เมื่อเดือนมีนาคม 2024 แทน ISO/IEC 27006:2015 และฉบับแก้ไขเพิ่มเติมปี 2020

หลักการที่อ่านได้จาก ISO/IEC 27006-1 คือเวลาตรวจเริ่มจากจำนวนบุคลากรที่ทำงานภายใต้การควบคุมขององค์กรภายในขอบข่ายของ ISMS แล้วปรับด้วยปัจจัยที่ทำให้การตรวจใช้เวลามากขึ้นหรือน้อยลง เช่น ความซับซ้อนของธุรกิจและของระบบสารสนเทศ ปัจจัยอื่นที่ใช้ปรับ ผู้อ่านต้องเปิดจากตัวมาตรฐาน ISO/IEC 27006-1:2024 ผู้เรียบเรียงเห็นว่านี่คือเหตุผลที่ใบสมัครขอการรับรอง ISO/IEC 27001 ของ EQA มีส่วนประเมินความซับซ้อนทางธุรกิจและความซับซ้อนของระบบสารสนเทศแนบอยู่ในหน้า การตรวจรับรอง ISO/IEC 27001 คำตอบในส่วนนั้นเป็นข้อมูลนำเข้าของการคำนวณเวลาตรวจ ไม่ใช่แบบทดสอบ

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

ลำดับขั้นตอน และเอกสารที่ลูกค้าของบริษัทอาจขอดู

ขั้นตอนการรับรอง ISMS ใช้กรอบเดียวกับระบบการจัดการอื่นตาม ISO/IEC 17021-1 คือใบสมัคร การทบทวนใบสมัคร การตรวจขั้นที่ 1 การตรวจขั้นที่ 2 การตัดสินใจให้การรับรอง แล้วจึงเข้ารอบการตรวจติดตามและการตรวจต่ออายุ รายละเอียดอ่านได้ที่ ขั้นตอนและระยะเวลาการขอรับรอง ISO ผู้เรียบเรียงเห็นว่าสิ่งที่ต่างสำหรับ ISMS อยู่ที่เอกสารซึ่งลูกค้าของบริษัทอาจขอดูหลังได้รับการรับรอง ซึ่งไม่ได้มีเฉพาะใบรับรอง

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

กรณีสมมติ — บริษัทพัฒนาระบบชำระเงินสำหรับร้านค้า กรุงเทพมหานคร

บริษัทมีพนักงานสี่สิบคน ทีมพัฒนาสิบแปดคนทำงานจากที่บ้านสามวันต่อสัปดาห์ ระบบให้บริการอยู่บนคลาวด์สาธารณะ และมีลูกค้าธนาคารหนึ่งรายส่งแบบสอบถามที่ถามถึงใบรับรอง ISO/IEC 27001 ในการประชุมภายใน ฝ่ายบริหารเสนอให้กำหนดขอบข่ายเฉพาะ “สำนักงานใหญ่และฝ่ายปฏิบัติการ” โดยไม่รวมทีมพัฒนา เพื่อให้เริ่มได้เร็ว

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

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

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

ข้อความเต็มของข้อกำหนดที่อ้างถึงข้างต้น ผู้อ่านต้องเปิดจากตัวมาตรฐาน ISO/IEC 27001:2022, ISO/IEC 27006-1:2024 และ ISO/IEC 17021-1:2015

อ่านต่อในบทความที่เกี่ยวข้อง

• วิธีเลือกหน่วยรับรอง ISO: 7 ข้อที่ตรวจสอบได้ก่อนเซ็นสัญญา
• ค่าใช้จ่ายในการขอรับรอง ISO คิดจากอะไร
• ขั้นตอนและระยะเวลาการขอรับรอง ISO ตั้งแต่ยื่นใบสมัครจนได้ใบรับรอง
• การตรวจขั้นที่ 1 (Stage 1) กับขั้นที่ 2 (Stage 2) ต่างกันอย่างไร
• ใบรับรอง ISO จะเป็นที่ยอมรับในต่างประเทศหรือไม่
• แบบประเมินความพร้อมก่อนรับการตรวจประเมิน
• การตรวจรับรอง ISO/IEC 27001 กับ EQA

บทความนี้เรียบเรียงขึ้นด้วยถ้อยคำของผู้เรียบเรียงเพื่ออธิบายหลักการของ ISO/IEC 27001:2022, ISO/IEC 27006-1:2024 และ ISO/IEC 17021-1:2015 ไม่ใช่การแปลหรือทำซ้ำเนื้อหาของมาตรฐาน ตัวอย่างทั้งหมดเป็นกรณีสมมติเพื่อประกอบคำอธิบาย การกำหนดขอบข่ายและการเลือกมาตรการควบคุมเป็นการตัดสินใจขององค์กร