21 July, 2026
No Comments

🛡️ ISO/IEC 27001:2022 — ฉบับสมบูรณ์

คู่มืออธิบายทุก Clause
ISO/IEC 27001:2022

เจาะลึกข้อกำหนดทุกข้อตั้งแต่ Clause 4–10 และ Annex A พร้อมตัวอย่างเอกสารจริง แนวทางปฏิบัติ และข้อผิดพลาดที่พบบ่อยในองค์กรไทย

Clause หลัก

Annex A Controls

Controls ใหม่ 2022

Themes ใน Annex A

🔍 ISO 27001:2022 คืออะไร?

ISO/IEC 27001:2022 คือมาตรฐานสากลสำหรับ ระบบการจัดการความมั่นคงปลอดภัยสารสนเทศ (ISMS) ที่ออกโดย ISO ร่วมกับ IEC

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

🎯 ทำไมต้องได้รับการรับรอง?

📌 สร้างความน่าเชื่อถือกับลูกค้าและคู่ค้า
📌 ปฏิบัติตามกฎหมาย PDPA, GDPR และข้อกำหนดภาครัฐ
📌 ลดความเสี่ยงจากภัยคุกคามทางไซเบอร์
📌 เพิ่มโอกาสทางธุรกิจ โดยเฉพาะ tender ภาครัฐ
📌 สร้างวัฒนธรรมองค์กรด้านความปลอดภัย
📌 ลดค่าใช้จ่ายจาก security incident

🏗️ โครงสร้างมาตรฐาน

📖 Clause 1-3: ขอบเขต อ้างอิง คำนิยาม
📖 Clause 4: Context of the Organization
📖 Clause 5: Leadership
📖 Clause 6: Planning
📖 Clause 7: Support
📖 Clause 8: Operation
📖 Clause 9: Performance Evaluation
📖 Clause 10: Improvement
📖 Annex A: 93 Information Security Controls

🆕 ความแตกต่างจากเวอร์ชัน 2013

หัวข้อ	2013	2022
Annex A Controls	114 controls / 14 domains	93 controls / 4 themes ใหม่
Clause 6.3	ไม่มี	Planning of Changes ใหม่
Controls ใหม่	–	11 controls เพิ่มใหม่ ใหม่
Attribute tagging	ไม่มี	มี 5 attribute sets ใหม่
Threat Intelligence	ไม่มี	A.5.7 เพิ่มใหม่ ใหม่

Clause 4

🏢 Context of the Organization

บริบทขององค์กร — รากฐานของ ISMS ที่ดี

4.1 บริบทองค์กร 4.2 ผู้มีส่วนได้ส่วนเสีย 4.3 ขอบเขต ISMS 4.4 ระบบการจัดการ

4.1 Understanding the Organization and its Context

องค์กรต้องระบุปัจจัยภายในและภายนอก (Internal & External Issues) ที่มีผลกระทบต่อความสามารถในการบรรลุวัตถุประสงค์ด้านความมั่นคงปลอดภัยของ ISMS

🔹 ปัจจัยภายใน: วัฒนธรรมองค์กร กระบวนการธุรกิจ เทคโนโลยีที่ใช้ ทรัพยากรบุคคล นโยบายภายใน
🔹 ปัจจัยภายนอก: กฎหมาย กฎระเบียบ สภาพแวดล้อมการแข่งขัน ภัยคุกคามไซเบอร์ ความต้องการของลูกค้า
🔹 เครื่องมือที่นิยมใช้: SWOT Analysis, PESTLE Analysis

4.2 Understanding Needs of Interested Parties

ระบุผู้มีส่วนได้ส่วนเสีย (Interested Parties) ที่เกี่ยวข้องกับ ISMS และความต้องการ/ความคาดหวังของพวกเขา

🔹 ลูกค้า (Customers): ต้องการความปลอดภัยของข้อมูลส่วนบุคคล
🔹 หน่วยงานกำกับดูแล: PDPA, พ.ร.บ.ว่าด้วยการกระทำความผิดเกี่ยวกับคอมพิวเตอร์
🔹 พนักงาน: นโยบาย BYOD, การใช้งานระบบ
🔹 Supplier/Vendor: ข้อกำหนด Security ใน Contract
🔹 ผู้ถือหุ้น: การบริหารความเสี่ยงด้านข้อมูล

4.3 Determining the Scope of ISMS

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

🔹 ระบุหน่วยงาน, สถานที่, กระบวนการ, เทคโนโลยีที่อยู่ในขอบเขต
🔹 ต้องมีเหตุผลชัดเจนหากไม่รวมส่วนใดของธุรกิจ
🔹 เอกสาร ISMS Scope Statement ต้องได้รับการอนุมัติจากผู้บริหาร

4.4 Information Security Management System

องค์กรต้องกำหนด นำไปใช้ ดำเนินการ ดูแลรักษา และปรับปรุง ISMS อย่างต่อเนื่องตามข้อกำหนดของมาตรฐาน

📄 ตัวอย่างเอกสารจริง

📋 ISMS Scope Statement — ตัวอย่างจริง

ISMS Scope Statement v1.2 บริษัท ABC Technology Co., Ltd. | วันที่มีผลบังคับใช้: 1 มกราคม 2567 ขอบเขต ISMS ครอบคลุม: • การพัฒนา ให้บริการ และสนับสนุนระบบ Cloud ERP สำหรับลูกค้าองค์กร • สำนักงานใหญ่: อาคาร X ชั้น 10-12 กรุงเทพมหานคร • Data Center: บริษัท AWS ap-southeast-1 (Singapore) • หน่วยงานที่เกี่ยวข้อง: IT, Dev, Operations, Sales, HR, Finance ไม่รวมในขอบเขต: • ระบบ Legacy ERP ที่กำลังจะ Decommission ภายใน Q2/2567 • สาขาเชียงใหม่ (พนักงาน 3 คน, ไม่มีการเข้าถึงระบบสำคัญ) อ้างอิงกฎหมาย/ข้อกำหนด: • พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA) • ISO/IEC 27001:2022 | อนุมัติโดย: CEO/MD | วันที่: 15/12/2566

📊 Interested Party Register — ตัวอย่างจริง

✅ แนวทางปฏิบัติที่ดี

✅ Best Practices สำหรับ Clause 4

จัดทำ PESTLE Analysis และ SWOT Analysis อย่างน้อยปีละครั้ง หรือเมื่อมีการเปลี่ยนแปลงธุรกิจสำคัญ
ใช้ Workshop ระดมสมองกับผู้บริหารและผู้เชี่ยวชาญจากทุกหน่วยงานในการกำหนด Interested Parties
กำหนด ISMS Scope ให้ชัดเจนและ Realistic — อย่ากำหนด Scope กว้างเกินไปจนไม่สามารถควบคุมได้
เชื่อมโยง Context กับการประเมินความเสี่ยงใน Clause 6 เพื่อให้ Risk Assessment สะท้อนความเป็นจริง
Review และอัปเดต Interested Party Register ทุกครั้งที่มีการเปลี่ยนแปลงนโยบายหรือกฎหมาย
บันทึก Interface ระหว่าง ISMS กับระบบการจัดการอื่น เช่น ISO 9001, ISO 22301 หากมี

⚠️ ข้อผิดพลาดที่พบบ่อย

❌ ข้อผิดพลาดที่พบบ่อยใน Clause 4

กำหนด ISMS Scope กว้างเกินไป เช่น “ทั้งองค์กร” โดยไม่มีรายละเอียด ทำให้ผู้ตรวจไม่สามารถประเมินได้
จัดทำ Interested Party Register แบบ Copy-Paste จากตัวอย่าง โดยไม่วิเคราะห์จริง
ไม่อัปเดต Context Document เมื่อมีการเปลี่ยนแปลงธุรกิจ เช่น เข้าซื้อกิจการ เปิดสาขาใหม่
SWOT/PESTLE ทำครั้งเดียวแล้วไม่ Review ทำให้ข้อมูลล้าสมัย
ไม่เชื่อมโยง Interested Party Requirements กับ ISMS Controls ทำให้ขาด Traceability

Clause 5

👔 Leadership

ภาวะผู้นำ — ผู้บริหารต้องเป็นเจ้าของ ISMS

5.1 ความมุ่งมั่นผู้บริหาร 5.2 นโยบาย Information Security 5.3 บทบาทและความรับผิดชอบ

5.1 Leadership and Commitment

ผู้บริหารระดับสูงต้องแสดงภาวะผู้นำและความมุ่งมั่นต่อ ISMS อย่างชัดเจน ไม่ใช่มอบหมายให้ IT ดำเนินการเพียงฝ่ายเดียว

🔹 กำหนดนโยบาย IS Policy และวัตถุประสงค์ที่สอดคล้องกับทิศทางธุรกิจ
🔹 จัดสรรทรัพยากรที่เพียงพอ (งบประมาณ, บุคลากร, เทคโนโลยี)
🔹 สื่อสารความสำคัญของ ISMS ให้พนักงานทราบทุกระดับ
🔹 เข้าร่วม Management Review อย่างสม่ำเสมอ

5.2 Information Security Policy

จัดทำนโยบายความมั่นคงปลอดภัยสารสนเทศ (IS Policy) ที่เหมาะสมกับวัตถุประสงค์ขององค์กร

🔹 ต้องมี: วัตถุประสงค์, ความมุ่งมั่นต่อการปฏิบัติตามข้อกำหนด, commitment to continual improvement
🔹 ต้องมีผลบังคับใช้เป็น Documented Information
🔹 ต้องสื่อสารให้พนักงานและ Interested Parties รับทราบ
🔹 ต้อง Review ประจำปีหรือเมื่อมีการเปลี่ยนแปลงสำคัญ

5.3 Organizational Roles, Responsibilities and Authorities

กำหนดบทบาท ความรับผิดชอบ และอำนาจหน้าที่ด้าน ISMS อย่างชัดเจนและสื่อสารให้ทั่วองค์กร

🔹 แต่งตั้ง CISO หรือ Information Security Manager อย่างเป็นทางการ
🔹 จัดทำ RACI Matrix สำหรับกระบวนการ ISMS
🔹 กำหนด Security Champion ในแต่ละหน่วยงาน

📄 ตัวอย่างเอกสารจริง

📜 Information Security Policy — ตัวอย่างย่อ

นโยบายความมั่นคงปลอดภัยสารสนเทศ (IS-POL-001) บริษัท ABC Technology Co., Ltd. | Version 2.1 | วันที่: 01/01/2567 1. วัตถุประสงค์ เพื่อปกป้องข้อมูลสารสนเทศขององค์กรและลูกค้าจากภัยคุกคาม โดยรักษา Confidentiality, Integrity และ Availability (CIA Triad) 2. ขอบเขตการบังคับใช้ บังคับใช้กับพนักงาน, Contractor, Vendor และบุคคลที่สามทุกคนที่เข้าถึงระบบสารสนเทศของบริษัท 3. ความมุ่งมั่นของผู้บริหาร • จัดสรรทรัพยากรเพียงพอสำหรับการดำเนินการ ISMS • ปฏิบัติตามกฎหมายและข้อกำหนดที่เกี่ยวข้อง • ปรับปรุง ISMS อย่างต่อเนื่อง ลงนามโดย: CEO/MD | วันที่: 15/12/2566 | Review Next Date: 15/12/2567

📊 RACI Matrix — บทบาทใน ISMS

กระบวนการ ISMS | CEO | CISO | IT Mgr | Dept Head | Staff ──────────────────────────────────────────────── IS Policy อนุมัติ | A | R | C | I | I Risk Assessment | I | A | R | C | I Security Training | I | A | C | R | R Incident Response | I | A | R | C | R Internal Audit | I | A | C | C | I Management Review | A | R | C | C | I Access Control Review| I | A | R | C | I Supplier Assessment | I | A | C | R | I R=Responsible, A=Accountable, C=Consulted, I=Informed

✅ แนวทางปฏิบัติที่ดี

✅ Best Practices สำหรับ Clause 5

ผู้บริหารต้องลงนามใน IS Policy ด้วยตนเอง ไม่ใช่ให้ IT Manager เป็นผู้ออก
จัด Kick-off Meeting ระดับ Board เพื่อประกาศ ISMS Program และแสดง Commitment
กำหนด Budget สำหรับ Information Security ในแผนงบประมาณประจำปีอย่างชัดเจน
แต่งตั้ง CISO ที่มีความรู้ด้าน Security และมี Direct Report ต่อ CEO หรือ Board
IS Policy ควรสั้น กระชับ ไม่เกิน 2 หน้า A4 เน้น “ผู้บริหารสั่งการ” ไม่ใช่รายละเอียดทางเทคนิค
จัดทำ Sub-Policy (Acceptable Use Policy, Password Policy ฯลฯ) แยกต่างหากจาก IS Policy หลัก

⚠️ ข้อผิดพลาดที่พบบ่อย

❌ ข้อผิดพลาดที่พบบ่อยใน Clause 5

IS Policy ออกโดย IT Manager แทนที่จะเป็น CEO/Board — ทำให้ขาด Top Management Commitment
Policy มีเนื้อหาทางเทคนิคมากเกินไป แทนที่จะเป็น High-level Statement of Intent
ไม่มีหลักฐาน (Evidence) ว่าผู้บริหารเข้าร่วมกิจกรรม ISMS เช่น Meeting Minutes ที่ไม่มีชื่อ CEO
RACI Matrix มีแต่ IT Department เป็น Responsible ทุกกระบวนการ
ไม่อัปเดต Policy หลังจากมีการเปลี่ยนแปลงองค์กรหรือกฎหมาย
พนักงานไม่ได้รับสำเนา Policy หรือไม่มีหลักฐานการรับทราบ

Clause 6

📋 Planning

การวางแผน — ประเมินความเสี่ยงและกำหนดวัตถุประสงค์

6.1 Risk & Opportunity 6.2 IS Objectives 6.3 Planning of Changes ✨ใหม่

6.1 Actions to Address Risks and Opportunities

กำหนดกระบวนการ Risk Assessment ที่สม่ำเสมอและ Risk Acceptance Criteria ที่ชัดเจน

🔹 กำหนด Risk Acceptance Criteria ก่อนทำ Risk Assessment
🔹 ระบุ Information Assets และ Associated Risks อย่างครอบคลุม
🔹 วิเคราะห์และประเมิน Risk Level (Likelihood × Impact)
🔹 เลือก Risk Treatment: Treat, Tolerate, Transfer, Terminate
🔹 จัดทำ Statement of Applicability (SoA) พร้อม Justification

6.2 Information Security Objectives

กำหนด IS Objectives ที่ SMART (Specific, Measurable, Achievable, Relevant, Time-bound)

🔹 ตัวอย่าง: “ลด Mean Time to Detect (MTTD) Security Incident จาก 72 ชม. เป็น 24 ชม. ภายใน Q4/2567”
🔹 กำหนด Owner, KPI, Timeline และ Budget สำหรับแต่ละ Objective
🔹 รายงานความคืบหน้าใน Management Review

6.3 Planning of Changes ✨ (ใหม่ใน 2022)

เมื่อองค์กรต้องการเปลี่ยนแปลง ISMS ต้องวางแผนการเปลี่ยนแปลงอย่างรอบคอบ พิจารณาวัตถุประสงค์ ผลกระทบที่อาจเกิด ทรัพยากร และความรับผิดชอบ

📄 ตัวอย่างเอกสารจริง

⚠️ Risk Register — ตัวอย่าง (6 รายการ)

Risk ID | Asset | Threat | L | I | Score | Treatment ───────────────────────────────────────────────────────── R-001 | Customer DB | SQL Injection | 4 | 5 | 20 | Treat: WAF + Code Review R-002 | Email System | Phishing Attack | 5 | 4 | 20 | Treat: Email Gateway + Training R-003 | Backup Data | Ransomware | 3 | 5 | 15 | Treat: Immutable Backup R-004 | Source Code | Insider Threat | 2 | 5 | 10 | Treat: Code Review + DLP R-005 | API Keys | Secret Leak to GitHub | 3 | 5 | 15 | Treat: Secrets Management R-006 | Network | DDoS Attack | 4 | 3 | 8 | Tolerate: CDN + Rate Limit L=Likelihood(1-5), I=Impact(1-5) Threshold: ≤8=Tolerate | 9-14=Review | ≥15=Must Treat

📋 Statement of Applicability (SoA) — ตัวอย่างย่อ

✅ แนวทางปฏิบัติที่ดี

✅ Best Practices สำหรับ Clause 6

ใช้วิธีการประเมินความเสี่ยงที่เป็นระบบและมีความสอดคล้อง เช่น ISO 27005 หรือ NIST SP 800-30
Risk Assessment ต้องครอบคลุม Information Assets ทั้งหมดในขอบเขต ISMS (ไม่ใช่แค่ IT Assets)
SoA ต้องระบุ Justification ชัดเจนสำหรับทั้ง Controls ที่ใช้และไม่ใช้
IS Objectives ควรมีไม่เกิน 5-7 ข้อ เน้น Priority สูงสุด และมี Owner ชัดเจน
สำหรับ 6.3 ให้จัดทำ Change Management Process เชื่อมโยงกับ ISMS Change Request Form
Review Risk Register อย่างน้อยปีละ 1 ครั้ง หรือเมื่อมี Significant Change

⚠️ ข้อผิดพลาดที่พบบ่อย

❌ ข้อผิดพลาดที่พบบ่อยใน Clause 6

Risk Assessment ประเมินแต่ IT Risks ไม่รวม Physical Security, People, Process Risks
SoA ทำเสร็จแล้วไม่เคย Update — Controls ระบุว่า “Applicable” แต่ยังไม่ได้ Implement จริง
IS Objectives ไม่สามารถวัดได้ เช่น “ปรับปรุงความปลอดภัยให้ดีขึ้น” โดยไม่มีตัวเลข
ไม่มีหลักฐานการอนุมัติ Risk Treatment Plan จากผู้บริหาร
ลืม Clause 6.3 ใหม่ — ไม่มี Process สำหรับการวางแผนการเปลี่ยนแปลง ISMS
Risk Scoring ไม่สม่ำเสมอ — Risk เดิมได้คะแนนต่างกันเมื่อประเมินโดยคนต่างกัน

Clause 7

🛠️ Support

การสนับสนุน — ทรัพยากร ความรู้ และเอกสารที่จำเป็น

7.1 ทรัพยากร 7.2 ความสามารถ 7.3 ความตระหนัก 7.4 การสื่อสาร 7.5 เอกสาร

7.1 Resources

องค์กรต้องจัดสรรทรัพยากรที่จำเป็นสำหรับการสร้าง ดำเนินการ และปรับปรุง ISMS ได้แก่ บุคลากร งบประมาณ เทคโนโลยี และโครงสร้างพื้นฐาน

7.2 Competence

กำหนดความสามารถที่จำเป็นสำหรับบุคลากรที่มีผลกระทบต่อ ISMS และจัดการให้พนักงานมีความสามารถเพียงพอ

🔹 กำหนด Job Description ที่ระบุ Security Competency Requirements ชัดเจน
🔹 จัดฝึกอบรมและประเมินผลความสามารถอย่างสม่ำเสมอ
🔹 เก็บ Training Records เป็นหลักฐาน (Documented Information)
🔹 ใช้ Certification เช่น CISSP, CISM, CEH เป็นส่วนหนึ่งของ Competency Framework

7.3 Awareness

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

🔹 จัด Security Awareness Training อย่างน้อยปีละ 1 ครั้ง
🔹 ทำ Phishing Simulation Test เพื่อวัด Awareness
🔹 สื่อสารผ่าน Poster, Email, Intranet, Security Newsletter
🔹 วัดผลด้วย Quiz หลังฝึกอบรม — Pass ≥ 80%

7.4 Communication

กำหนดสิ่งที่จะสื่อสาร เมื่อไหร่ กับใคร ใครเป็นคนสื่อสาร และสื่อสารผ่านช่องทางใด

🔹 Internal: Management Review, Security Bulletin, Incident Notification
🔹 External: ลูกค้า, หน่วยงานกำกับดูแล, สื่อ (กรณี Breach)
🔹 จัดทำ Communication Plan ที่ระบุ Who-What-When-How

7.5 Documented Information

ควบคุมเอกสารและข้อมูลที่บันทึกไว้ให้มีความถูกต้อง พร้อมใช้งาน และได้รับการปกป้อง

🔹 ต้องมีกระบวนการ: สร้าง/อัปเดต, ควบคุมการเปลี่ยนแปลง (Version Control)
🔹 กำหนด Document Classification: Public, Internal, Confidential, Restricted
🔹 กำหนด Retention Period และวิธีการทำลายเอกสาร

📄 ตัวอย่างเอกสารจริง

🎓 Training Record — ตัวอย่าง

📁 Document Control Procedure — ตัวอย่างย่อ

Document Control Procedure | IS-PRO-DOC-001 | v1.3 1. โครงสร้าง Document ID: [IS]-[ประเภท]-[ลำดับ] → IS-POL-001 (Policy), IS-PRO-002 (Procedure), IS-WI-003 (Work Instruction) 2. Approval Matrix: Level 1 (Policy): อนุมัติโดย CEO + CISO Level 2 (Procedure): อนุมัติโดย CISO Level 3 (Work Instruction): อนุมัติโดย Dept Manager 3. Version Control: Major (x.0): เปลี่ยนแปลงสาระสำคัญ — ต้อง Re-approve Minor (x.x): แก้ไขเล็กน้อย — อนุมัติโดย Document Owner 4. Retention Period: Active Document: ตลอดอายุการใช้งาน | Superseded: เก็บ 3 ปี | Training Records: เก็บ 5 ปี

✅ แนวทางปฏิบัติที่ดี

✅ Best Practices สำหรับ Clause 7

ใช้ Document Management System (DMS) เช่น SharePoint, Confluence ในการควบคุมเอกสาร
จัด Phishing Simulation Test 3-4 ครั้งต่อปี และรายงานผลให้ผู้บริหารทราบ
กำหนด Competency Matrix สำหรับ Security Roles ทุกตำแหน่งที่เกี่ยวข้อง
สร้าง Security Communication Calendar — วางแผนการสื่อสาร Security Topics ตลอดปี
เอกสาร ISMS ควรใช้ Template มาตรฐานที่มี Header/Footer แสดง Version, Date, Owner
ทำ Awareness ให้สนุกและมีส่วนร่วม เช่น Gamification, Quiz Competition ระหว่างแผนก

⚠️ ข้อผิดพลาดที่พบบ่อย

❌ ข้อผิดพลาดที่พบบ่อยใน Clause 7

Training Records ไม่ครบถ้วน — มีหลักสูตรแต่ไม่มีรายชื่อผู้เข้าร่วมหรือหลักฐานการผ่าน
Awareness Training ทำปีละครั้งแบบ “tick the box” ไม่มีการวัดผลหรือปรับปรุงเนื้อหา
Document Version ไม่อัปเดต — ใช้เอกสาร Version เก่าในการปฏิบัติงาน
ไม่มี Communication Plan ทำให้การสื่อสารเรื่อง Security เป็นแบบ Ad-hoc
กำหนด Documented Information มากเกินความจำเป็น — สร้างภาระแต่ไม่เพิ่มคุณค่า
ไม่มีกระบวนการทำลายเอกสารที่หมดอายุอย่างปลอดภัย (Secure Disposal)

Clause 8

⚙️ Operation

การปฏิบัติการ — นำแผนไปปฏิบัติจริงและควบคุม

8.1 Operational Planning & Control 8.2 IS Risk Assessment 8.3 IS Risk Treatment

8.1 Operational Planning and Control

วางแผนและควบคุมกระบวนการที่จำเป็นเพื่อให้เป็นไปตามข้อกำหนด IS และนำ Actions จาก Clause 6 ไปปฏิบัติ

🔹 ควบคุม Outsourced Process ที่มีผลต่อ ISMS เช่น Cloud Provider, Managed Security Service
🔹 เก็บ Documented Information เพื่อแสดงว่า Process ดำเนินการตามแผน
🔹 ใช้ Change Management เพื่อควบคุม Unplanned Changes ที่อาจกระทบ ISMS

8.2 Information Security Risk Assessment

ดำเนินการ Risk Assessment ตามแผนที่วางไว้ใน Clause 6 ในช่วงเวลาที่กำหนดหรือเมื่อมีการเปลี่ยนแปลงสำคัญ

🔹 ทำ Risk Assessment อย่างน้อยปีละ 1 ครั้ง หรือเมื่อมี Significant Change
🔹 Trigger Events: ระบบใหม่, การเปลี่ยน Vendor, M&A, เหตุการณ์ Security Incident
🔹 ทำ Vulnerability Assessment และ Penetration Testing เป็นส่วนหนึ่งของ Risk Assessment

8.3 Information Security Risk Treatment

นำ Risk Treatment Plan ที่วางแผนไว้ใน Clause 6 ไปปฏิบัติจริง

🔹 ดำเนินการตาม Annex A Controls ที่ระบุใน SoA
🔹 ติดตาม Progress ของ Risk Treatment Actions
🔹 รายงานสถานะ Risk Treatment ต่อผู้บริหารใน Management Review

📄 ตัวอย่างเอกสารจริง

🛡️ Risk Treatment Plan — ตัวอย่าง

🔍 Vulnerability Assessment Summary — ตัวอย่าง

Quarterly Vulnerability Assessment Report | Q1/2567 เครื่องมือ: Tenable Nessus, OWASP ZAP, Nmap | วันที่: 5-7 มีนาคม 2567 สรุปผลการสแกน: Critical: 3 รายการ → ต้องแก้ไขภายใน 72 ชั่วโมง High: 12 รายการ → ต้องแก้ไขภายใน 7 วัน Medium: 28 รายการ → ต้องแก้ไขภายใน 30 วัน Low: 45 รายการ → แก้ไขตาม Patch Schedule Critical Issues: 1. CVE-2024-XXXX: Apache Log4j บน App Server (CVSS 10.0) → อัปเดต Log4j ทันที 2. SQL Injection ใน API /v1/users → Parameterized Query + WAF Rule 3. Exposed Admin Panel → IP Whitelist + MFA Required

✅ แนวทางปฏิบัติที่ดี

✅ Best Practices สำหรับ Clause 8

จัดทำ Operational Security Calendar — กำหนดวันสำหรับ Patch, VA, Pen Test, Backup Test
ใช้ Automated Vulnerability Scanning ทุกสัปดาห์ และ Manual Penetration Test ปีละ 1-2 ครั้ง
ทำ Supplier Security Assessment สำหรับ Vendor ที่เข้าถึงข้อมูลสำคัญ
กำหนด Change Advisory Board (CAB) สำหรับอนุมัติการเปลี่ยนแปลงที่กระทบ ISMS
ทดสอบ Backup & Recovery อย่างน้อยปีละ 1 ครั้ง (ไม่ใช่แค่ Backup ไม่มีการ Restore Test)

⚠️ ข้อผิดพลาดที่พบบ่อย

❌ ข้อผิดพลาดที่พบบ่อยใน Clause 8

Risk Treatment ทำแค่ “บนกระดาษ” แต่ไม่มีหลักฐานว่า Controls ถูก Implement จริง
Outsourced Vendors ไม่ได้รับการประเมิน Security ทำให้เกิด Supply Chain Risk
ไม่ทำ Penetration Test เพราะ “แพงเกินไป” — เป็น Non-conformity ที่พบบ่อยมากในการ Audit
Vulnerability ระดับ Critical ถูก Defer โดยไม่มีเหตุผล
Backup มีแต่ไม่เคยทดสอบ Recovery — พอเกิดเหตุจริงพบว่า Backup เสีย

Clause 9

📊 Performance Evaluation

การประเมินผลการดำเนินงาน — วัดผล ตรวจสอบ และทบทวน

9.1 Monitoring & Measurement 9.2 Internal Audit 9.3 Management Review

9.1 Monitoring, Measurement, Analysis and Evaluation

กำหนดสิ่งที่จะติดตาม วัดผล วิเคราะห์ และประเมิน รวมถึงวิธีการและความถี่

🔹 KPI ตัวอย่าง: MTTD, MTTR, จำนวน Security Incident, % Patch Compliance, Phishing Click Rate
🔹 ใช้ SIEM Dashboard สำหรับ Real-time Security Monitoring
🔹 รายงานผลให้ผู้บริหารทุกเดือน/ไตรมาส

9.2 Internal Audit

ดำเนินการ Internal Audit ตามแผนที่กำหนด เพื่อประเมินว่า ISMS เป็นไปตามข้อกำหนดและดำเนินการอย่างมีประสิทธิผล

🔹 จัดทำ Annual Audit Program ที่ Risk-based ครอบคลุมทุก Clause
🔹 Auditor ต้องไม่ตรวจสอบงานของตนเอง (Independence & Impartiality)
🔹 รายงาน Audit Findings ต่อผู้บริหารและติดตามการแก้ไข

9.3 Management Review

ผู้บริหารระดับสูงต้องทบทวน ISMS ตามช่วงเวลาที่กำหนด (อย่างน้อยปีละ 1 ครั้ง)

🔹 Inputs ที่กำหนดใน Clause 9.3: สถานะ Actions ก่อนหน้า, Changes ที่กระทบ ISMS, Security Performance, Nonconformities, Audit Results, Supplier Feedback, Risk Assessment
🔹 Outputs: การตัดสินใจปรับปรุง ISMS, การเปลี่ยนแปลงที่จำเป็น, ทรัพยากรที่ต้องการ

📄 ตัวอย่างเอกสารจริง

📋 Internal Audit Report — ตัวอย่างย่อ

Internal Audit Report | ISMS-AUD-2024-01 ช่วงเวลา: 20-24 พฤษภาคม 2567 | Lead Auditor: นายสมหมาย ตรวจสอบ ขอบเขต: Clause 4-10 + Annex A Controls (IT, HR, Finance) สรุปผลการตรวจ: Major Nonconformity: 1 รายการ | Minor Nonconformity: 4 รายการ | Observation: 7 รายการ Major Nonconformity (NC-2024-001): Clause: 7.2 Competence | ระดับ: Major ข้อค้นพบ: พนักงาน 3 คนในทีม Security Operations ไม่ได้รับการอบรม Incident Response Procedure ในรอบ 12 เดือนที่ผ่านมา และไม่มีหลักฐาน Competency Requirement สำหรับตำแหน่งนี้ หลักฐาน: ไม่พบ Training Record สำหรับ EMP-045, EMP-067, EMP-089 ต้องแก้ไขภายใน: 30 วัน | Owner: HR Manager + CISO

✅ แนวทางปฏิบัติที่ดี

✅ Best Practices สำหรับ Clause 9

กำหนด Security Metrics ที่ Actionable — ตัวเลขที่วัดได้ต้องนำไปสู่การตัดสินใจได้จริง
ใช้ SIEM/SOAR Platform เพื่อ Automate การเก็บ Metrics และสร้าง Dashboard อัตโนมัติ
Internal Auditor ควรผ่านการรับรอง เช่น ISO 27001 Lead Auditor Course
Management Review ควรมี Agenda ครอบคลุมทุก Input ตาม Clause 9.3 และใช้เวลาไม่น้อยกว่า 2 ชั่วโมง
ติดตาม Nonconformity ด้วย Corrective Action Tracking System — มี Due Date และ Owner ชัดเจน
ทำ Mock Audit ก่อนการตรวจ Certification เพื่อค้นหาช่องโหว่

⚠️ ข้อผิดพลาดที่พบบ่อย

❌ ข้อผิดพลาดที่พบบ่อยใน Clause 9

KPI ที่กำหนดไม่สอดคล้องกับ IS Objectives ใน Clause 6.2 — ขาด Alignment
Internal Audit ทำโดยคนที่ตรวจสอบงานของตนเอง — ขาด Impartiality
Management Review Minutes ไม่ครอบคลุม Input ที่กำหนด หรือเป็นแค่ “ที่ประชุมรับทราบ” ไม่มี Decision
ปิด Nonconformity โดยไม่มี Root Cause Analysis หรือ Corrective Action จริง
ไม่มีหลักฐานว่าผู้บริหารเข้าร่วม Management Review จริง
Audit Program ไม่ Risk-based — ทุก Area ได้รับการ Audit เท่าๆ กัน โดยไม่คำนึงถึงความสำคัญ

Clause 10

🔄 Improvement

การปรับปรุง — แก้ไข เรียนรู้ และพัฒนา ISMS อย่างต่อเนื่อง

10.1 Continual Improvement 10.2 Nonconformity & Corrective Action

10.1 Continual Improvement

องค์กรต้องปรับปรุงความเหมาะสม ความเพียงพอ และประสิทธิผลของ ISMS อย่างต่อเนื่อง

🔹 ใช้ PDCA Cycle (Plan-Do-Check-Act) เป็นหัวใจของการปรับปรุง
🔹 รวบรวม Improvement Ideas จาก: Audit Findings, Incident Reviews, Employee Suggestions, Industry Benchmarks
🔹 จัดทำ Improvement Register เพื่อติดตาม Initiatives ด้าน Security
🔹 Benchmarking กับ Industry Standards เช่น CIS Controls, NIST CSF

10.2 Nonconformity and Corrective Action

เมื่อพบ Nonconformity ต้องดำเนินการแก้ไขอย่างเหมาะสมโดยมีกระบวนการที่เป็นระบบ

🔹 ขั้นตอน: React → Contain → Root Cause Analysis → Corrective Action → Verify Effectiveness
🔹 ใช้วิธี Root Cause Analysis เช่น 5 Whys, Fishbone Diagram, Fault Tree Analysis
🔹 Corrective Action ต้องแก้ที่ Root Cause ไม่ใช่แค่ Symptom
🔹 ตรวจสอบว่า Nonconformity เดียวกันอาจเกิดที่อื่นในองค์กรหรือไม่ (Systemic Issue)

📄 ตัวอย่างเอกสารจริง

📝 Corrective Action Report (CAR) — ตัวอย่าง

Corrective Action Report | CAR-2024-001 Clause: 7.2 Competence | ระดับ: Major | พบโดย: Internal Audit Immediate Containment Action: • Schedule Emergency Training สำหรับ 3 คนภายใน 2 สัปดาห์ ✓ • ทบทวน Incident Response Procedure กับทีมทั้งหมด ✓ Root Cause Analysis (5 Whys): Why 1: พนักงาน 3 คนไม่ได้รับการอบรม Why 2: ไม่มีการติดตามว่าใครอบรมแล้ว ใครยังไม่อบรม Why 3: ไม่มีระบบ Training Tracking ที่ครอบคลุมทุกคน Why 4: HR ติดตามแค่ Mandatory HR Training ไม่รวม Technical Security Training Why 5: ไม่มีนโยบายกำหนดให้ HR ติดตาม Security-specific Training Root Cause: ขาดกระบวนการ Centralized Training Tracking สำหรับ Security Training Corrective Actions: 1. นำ LMS (Learning Management System) มาใช้ — Owner: HR | Due: 30/06/67 2. กำหนด Competency Matrix สำหรับทุกตำแหน่ง Security — Owner: CISO | Due: 31/05/67 3. ตั้ง Monthly Training Compliance Report — Owner: HR | Due: 30/04/67 Effectiveness Verification: วันที่: 31/07/67 | ผล: ✅ Effective — Training Compliance 100%, LMS Deployed

📊 Improvement Register — ตัวอย่าง

✅ แนวทางปฏิบัติที่ดี

✅ Best Practices สำหรับ Clause 10

กำหนด Corrective Action Process ที่ชัดเจน รวมถึง Timeline สำหรับแต่ละระดับความรุนแรง
ใช้ Root Cause Analysis ทุกครั้ง — อย่าปิด NC ด้วยแค่การแก้ Symptom เพราะปัญหาจะกลับมา
สร้างวัฒนธรรม “No-blame” เพื่อให้พนักงานกล้ารายงาน Near Miss และ Security Issues
จัด Lessons Learned Session หลังทุก Security Incident เพื่อแปลงเหตุการณ์เป็นการปรับปรุง
ติดตาม Industry Trends และ Threat Intelligence เพื่อ Proactive Improvement
มี Improvement Backlog และ Prioritize ตาม Risk ไม่ใช่ First In First Out

⚠️ ข้อผิดพลาดที่พบบ่อย

❌ ข้อผิดพลาดที่พบบ่อยใน Clause 10

ปิด Nonconformity โดยแค่ “ทำเอกสารเพิ่มเติม” โดยไม่มีการเปลี่ยนแปลงกระบวนการจริง
Root Cause Analysis ผิวเผิน เช่น Root Cause = “พนักงานไม่ทำ” แทนที่จะวิเคราะห์ว่าทำไมถึงไม่ทำ
Continual Improvement เป็นแค่ “On Paper” — ไม่มี Improvement Initiative ที่เห็นผลจริง
ไม่ Verify Effectiveness ของ Corrective Action หลังดำเนินการ
Improvement Register ไม่ได้รับการอัปเดตหรือ Review ในที่ประชุมผู้บริหาร
ไม่ตรวจสอบว่า Nonconformity เดียวกันอาจเกิดในหน่วยงานอื่น (ปัญหาเชิงระบบ)

Annex A

🗂️ Information Security Controls 2022

93 Controls ใน 4 Themes — ปรับปรุงใหม่จาก 114 Controls / 14 Domains

🏢 Theme 5: Organizational

Controls ด้านนโยบาย กระบวนการ และการจัดการ เช่น Threat Intelligence, IS Supply Chain, Cloud Security

👥 Theme 6: People

Controls ด้านบุคลากร เช่น Screening, Terms of Employment, Remote Working, Disciplinary Process

🏗️ Theme 7: Physical

Controls ด้านกายภาพ เช่น Physical Perimeters, Clear Desk, Equipment Security, Secure Disposal

💻 Theme 8: Technological

Controls ด้านเทคโนโลยี เช่น Access Control, Cryptography, SIEM, Data Masking, Vulnerability Management

✨ Controls ใหม่ 11 ข้อที่เพิ่มใน ISO 27001:2022

✨ 11 New Controls — ISO/IEC 27001:2022 Annex A

Control ID	ชื่อ Control	Theme	ความสำคัญ
A.5.7	Threat Intelligence	Organizational	รวบรวมและวิเคราะห์ข้อมูลภัยคุกคามเพื่อ Proactive Defense
A.5.23	IS for Use of Cloud Services	Organizational	กำหนดนโยบายและ Controls สำหรับการใช้ Cloud (AWS, Azure, GCP)
A.5.30	ICT Readiness for Business Continuity	Organizational	เชื่อมโยง ISMS กับ BCP/DRP เพื่อความต่อเนื่องของ ICT
A.7.4	Physical Security Monitoring	Physical	ติดตามและตรวจจับการบุกรุกพื้นที่สำคัญด้วย CCTV, Sensors
A.8.9	Configuration Management	Technological	บริหารจัดการ Configuration ของระบบให้ปลอดภัยและสม่ำเสมอ
A.8.10	Information Deletion	Technological	ลบข้อมูลอย่างปลอดภัยเมื่อหมดความจำเป็น (สอดคล้อง PDPA)
A.8.11	Data Masking	Technological	ปกปิดข้อมูลสำคัญในสภาพแวดล้อม Non-production (Dev/Test)
A.8.12	Data Leakage Prevention (DLP)	Technological	ป้องกันข้อมูลรั่วไหลออกนอกองค์กรโดยไม่ได้รับอนุญาต
A.8.16	Monitoring Activities	Technological	ติดตามกิจกรรมในระบบเพื่อตรวจจับ Anomaly และภัยคุกคาม
A.8.23	Web Filtering	Technological	กรองการเข้าถึงเว็บไซต์อันตราย ลดความเสี่ยงจาก Malware
A.8.28	Secure Coding	Technological	กำหนดหลักเกณฑ์ Secure Coding เพื่อลดช่องโหว่ใน Application

🏷️ Attribute Tagging — นวัตกรรมใหม่ใน Annex A 2022

ISO 27001:2022 แนะนำ Attribute Sets สำหรับ Categorize Controls ซึ่งช่วยในการ Filter และ Map Controls:

🔹 Control Type: Preventive | Detective | Corrective
🔹 InfoSec Properties: Confidentiality | Integrity | Availability
🔹 Cybersecurity Concepts: Identify | Protect | Detect | Respond | Recover (NIST CSF)
🔹 Operational Capabilities: Governance | Asset Management | Physical Security | etc.
🔹 Security Domains: Governance & Ecosystem | Protection | Defence | Resilience

✅ Checklist เอกสารที่ต้องมีใน ISO 27001:2022

🔵

Clause 4: ContextISMS Scope Statement • Interested Party Register • Context Analysis (SWOT/PESTLE)

🟣

Clause 5: LeadershipIS Policy (CEO-signed) • RACI Matrix • Role & Responsibility Definition

🟢

Clause 6: PlanningRisk Assessment Report • Risk Register • Risk Treatment Plan • SoA • IS Objectives • Change Plan

🟡

Clause 7: SupportCompetency Matrix • Training Records • Awareness Evidence • Communication Plan • Document Control Procedure

🟠

Clause 8: OperationOperational Procedures • Vulnerability Assessment • Penetration Test Report • Risk Treatment Evidence

🔷

Clause 9: EvaluationKPI/Metrics Report • Internal Audit Plan & Report • Management Review Minutes

🔴

Clause 10: ImprovementNonconformity Log • Corrective Action Reports (CAR) • Improvement Register

⬛

Annex A: ControlsStatement of Applicability (SoA) • Control Implementation Evidence • Sub-Policies (Password, Access ฯลฯ)

🛤️ เส้นทางสู่การรับรอง ISO 27001:2022

📊 Gap Analysis (2-4 สัปดาห์)

ประเมินสถานะปัจจุบันเทียบกับ ISO 27001:2022 ระบุช่องว่างที่ต้องแก้ไข วางแผนโครงการ กำหนด Budget และ Timeline

🏗️ ISMS Design & Documentation (4-8 สัปดาห์)

กำหนด ISMS Scope, จัดทำ Policies & Procedures, ออกแบบ ISMS Framework ให้สอดคล้องกับ Clause 4-10

⚠️ Risk Assessment & Treatment (4-6 สัปดาห์)

ดำเนินการ Risk Assessment เต็มรูปแบบ กำหนด Risk Treatment Plan จัดทำ Statement of Applicability

⚙️ Implementation & Operation (8-16 สัปดาห์)

นำ Controls ไปปฏิบัติจริง จัด Security Awareness Training สร้าง Evidence ของการดำเนินงาน

🔍 Internal Audit (2-3 สัปดาห์)

ทำ Internal Audit ครั้งแรก ปิด Nonconformity ที่พบ จัด Management Review อย่างเป็นทางการ

🏅 Certification Audit — Stage 1 (2-3 วัน)

CB (Certification Body) ตรวจสอบ Documented Information และ ISMS Design ยืนยันความพร้อมสำหรับ Stage 2

🏆 Certification Audit — Stage 2 (3-5 วัน)

CB ตรวจสอบการ Implementation จริงและ Evidence ความสอดคล้อง หากผ่าน → ออกใบรับรอง ISO 27001:2022 (อายุ 3 ปี)

♻️ Surveillance (ปีที่ 1 & 2) + Re-certification (ปีที่ 3)

Surveillance Audit ปีละครั้งเพื่อรักษาการรับรอง Re-certification Audit ทุก 3 ปีเพื่อต่ออายุใบรับรอง

คู่มืออธิบายทุก Clause ISO/IEC 27001:2022

คู่มืออธิบายทุก ClauseISO/IEC 27001:2022

🔍 ISO 27001:2022 คืออะไร?

🎯 ทำไมต้องได้รับการรับรอง?

🏗️ โครงสร้างมาตรฐาน

🆕 ความแตกต่างจากเวอร์ชัน 2013

🏢 Context of the Organization

4.1 Understanding the Organization and its Context

4.2 Understanding Needs of Interested Parties

4.3 Determining the Scope of ISMS

4.4 Information Security Management System

👔 Leadership

5.1 Leadership and Commitment

5.2 Information Security Policy

5.3 Organizational Roles, Responsibilities and Authorities

📋 Planning

6.1 Actions to Address Risks and Opportunities

6.2 Information Security Objectives

6.3 Planning of Changes ✨ (ใหม่ใน 2022)

🛠️ Support

7.1 Resources

7.2 Competence

7.3 Awareness

7.4 Communication

7.5 Documented Information

⚙️ Operation

8.1 Operational Planning and Control

8.2 Information Security Risk Assessment

8.3 Information Security Risk Treatment

📊 Performance Evaluation

9.1 Monitoring, Measurement, Analysis and Evaluation

9.2 Internal Audit

9.3 Management Review

🔄 Improvement

10.1 Continual Improvement

10.2 Nonconformity and Corrective Action

🗂️ Information Security Controls 2022

🏢 Theme 5: Organizational

👥 Theme 6: People

🏗️ Theme 7: Physical

💻 Theme 8: Technological

🏷️ Attribute Tagging — นวัตกรรมใหม่ใน Annex A 2022

✅ Checklist เอกสารที่ต้องมีใน ISO 27001:2022

🛤️ เส้นทางสู่การรับรอง ISO 27001:2022

📊 Gap Analysis (2-4 สัปดาห์)

🏗️ ISMS Design & Documentation (4-8 สัปดาห์)

⚠️ Risk Assessment & Treatment (4-6 สัปดาห์)

⚙️ Implementation & Operation (8-16 สัปดาห์)

🔍 Internal Audit (2-3 สัปดาห์)

🏅 Certification Audit — Stage 1 (2-3 วัน)

🏆 Certification Audit — Stage 2 (3-5 วัน)

♻️ Surveillance (ปีที่ 1 & 2) + Re-certification (ปีที่ 3)