Policy = intent ของผู้บริหารระดับสูง#

Policy (นโยบาย — เอกสารระดับสูงสุดที่บอกเจตนา) = เอกสารที่บอกว่า บริษัทถือเรื่องนี้เป็นเรื่องสำคัญ + มีจุดยืนแบบไหน + ขอบเขตการบังคับใช้ — โดยมีลายเซ็นของ CEO หรือ Board เป็นคนรับรอง

ลองเทียบกับรัฐธรรมนูญครับ. รัฐธรรมนูญไม่ได้บอกว่า “ห้ามจอดรถใน ซ.5”. รัฐธรรมนูญบอกว่า “รัฐมีอำนาจออกกฎหมายเพื่อความสงบเรียบร้อย / ทุกคนต้องเสียภาษี / สิทธิเสรีภาพมีข้อจำกัดได้เพื่อประโยชน์สาธารณะ”. มัน กว้าง + บอกเจตนา + ไม่มี detail การปฏิบัติ

Policy ของบริษัทเป็นแบบเดียวกัน. ตัวอย่างประโยคใน Information Security Policy ของบริษัทระดับโลก:

“บริษัทถือว่าข้อมูลของลูกค้า พนักงาน และคู่ค้า เป็นทรัพย์สินที่ต้องปกป้อง. ผู้บริหารระดับสูงรับผิดชอบในการจัดสรรทรัพยากรเพื่อปกป้องข้อมูลตามระดับความสำคัญ. พนักงานทุกคนมีหน้าที่ปฏิบัติตามมาตรฐานความปลอดภัยที่บริษัทกำหนด. การละเมิดมีผลทางวินัยจนถึงเลิกจ้าง”

สังเกตครับ — ไม่มีคำว่า AES-256 ไม่มีคำว่า 12 ตัวอักษร ไม่มีคำว่า MFA. เพราะ Policy ไม่ลงรายละเอียดเทคนิค. หน้าที่ของ Policy คือ — ตั้งจุดยืน + ให้อำนาจ + มอบหมายความรับผิดชอบ

Policy หลัก 3 ตัวที่ทุกบริษัทควรมี#

1. Information Security Policy (นโยบายความปลอดภัยสารสนเทศ) — แม่ของทุก policy. บอกว่าบริษัทถือ security เป็นเรื่องระดับ board. ระบุ scope (ครอบใคร — พนักงานทุกคน / contractor / vendor). ระบุผู้รับผิด (CISO / Information Security Committee). ระบุการ enforce (ละเมิดแล้วเกิดอะไร)

2. Acceptable Use Policy (AUP — นโยบายการใช้งานที่ยอมรับได้) — บอกพนักงานว่าใช้ระบบบริษัทยังไงได้บ้าง / ห้ามทำอะไร. ตัวอย่าง: ห้ามใช้ email บริษัทส่งเรื่องส่วนตัวที่ไม่เกี่ยวธุรกิจ / ห้าม install software ที่ไม่ได้รับอนุญาต / ห้ามเชื่อม USB ส่วนตัวเข้าเครื่องบริษัท / ห้ามแชร์ account ของบริษัทให้คนอื่น. AUP ที่พนักงานเซ็นรับทราบ = เกราะคุ้มกัน HR เวลาต้องเลิกจ้างคนที่ทำผิด

3. Privacy Policy (นโยบายความเป็นส่วนตัว) — บอกว่าบริษัทเก็บข้อมูลส่วนบุคคลของลูกค้า / พนักงานยังไง / ใช้ทำอะไร / เก็บกี่ปี / แชร์ให้ใคร. ใน EP.49 เราจะเจาะลึก เพราะ PDPA / GDPR บังคับให้ทุกบริษัทมี Privacy Policy ที่เปิดเผยต่อสาธารณะ

นอกจาก 3 ตัวนี้ ยังมี Incident Response Policy / BCP Policy / Vendor Management Policy / Data Classification Policy ฯลฯ. แต่ 3 ตัวข้างต้นเป็น ขั้นต่ำ ที่ทุกบริษัทควรมี — ไม่ว่าจะเล็กแค่ไหน

ลายเซ็นที่ทำให้ Policy เป็น Policy#

หัวใจของ Policy ที่หลายบริษัทพลาด — ใครเซ็น

Policy ที่ IT Manager เซ็น = manual ภายในของ IT team. ไม่ใช่ Policy. เพราะ IT Manager ไม่มีอำนาจสั่งฝ่ายขาย ไม่มีอำนาจสั่งฝ่ายบัญชี ไม่มีอำนาจตัดเงินเดือน

Policy ที่ CEO เซ็น (หรือ Board เซ็นในบริษัทใหญ่) = เอกสารระดับองค์กร. ทุกคนต้องปฏิบัติตาม. ละเมิดมีผลทางวินัยถึงเลิกจ้าง. คือเหตุผลที่ Policy ต้องอยู่บนสุดของลำดับชั้น — เพราะแหล่งอำนาจมาจากบนสุด

มุมผู้บริหาร: เอาตรงๆ ครับ — ถ้าวันนี้บริษัทคุณยังไม่มี Information Security Policy ที่ CEO เซ็น + พนักงานทุกคนเซ็น Acceptable Use Policy ตอน onboarding — คุณยังไม่ได้เริ่ม security เลย. ที่มีอยู่คือ tool. แต่ tool ไม่ใช่ governance. วันที่ auditor มา / วันที่ลูกค้ารายใหญ่ขอ vendor assessment / วันที่ต้องเลิกจ้างพนักงานที่เอาข้อมูลลูกค้าไปขาย — คุณต้องการเอกสารที่เซ็นแล้ว ไม่ใช่ firewall log. หา template ฟรีจาก SANS / NIST. ใส่ชื่อบริษัท. ปรับ scope. ให้ legal review. CEO เซ็น. ใช้เวลา 2-4 สัปดาห์. ทำครั้งเดียว update ปีละครั้ง. นี่คือ ROI สูงที่สุดในงาน security ที่บริษัทไทยส่วนใหญ่ข้ามไป

Standard = เปลี่ยน intent เป็น measurable requirement#

Standard (มาตรฐาน — ข้อบังคับที่เฉพาะเจาะจง วัดได้) = เอกสารที่บอก specifically ว่าต้องทำอะไรบ้างเพื่อให้ตาม Policy. ทุกข้อใน Standard ต้อง วัดได้ — มี audit ก็ตรวจได้ว่า pass หรือ fail

ลองนึกครับ. Policy บอก “เราต้องปกป้องข้อมูลให้แข็งแรง”. Password Standard จะบอก:

• รหัสผ่านต้องยาวอย่างน้อย 12 ตัวอักษร
• ต้องมี ตัวอักษรพิมพ์ใหญ่ + พิมพ์เล็ก + ตัวเลข + สัญลักษณ์พิเศษ อย่างน้อย 3 ใน 4 หมวด
• ห้ามใช้คำที่อยู่ใน dictionary ทั่วไป (ตรวจด้วย common password list)
• เก็บใน database ในรูปแบบ bcrypt หรือ Argon2id ด้วย salt อย่างน้อย 16 bytes
• หมดอายุทุก 365 วัน (แนวทาง NIST 800-63B ใหม่)
• บัญชี admin ต้องเปิด MFA บังคับ — ไม่มีข้อยกเว้น
• ห้ามใช้รหัสซ้ำกับ 12 ครั้งล่าสุด

สังเกตครับ — ทุกข้อ มีตัวเลข. ทุกข้อ auditor ตรวจได้. ทุกข้อ engineer ทำให้ระบบบังคับใช้ได้

นี่คือสะพานระหว่าง เจตนา (Policy) กับ การปฏิบัติจริง (Procedure ที่จะคุยต่อ). Standard เป็นชั้นที่ compliance team กับ auditor ใช้คุยกันมากที่สุด — เพราะมี criteria ที่ชี้นิ้วได้

Standard ที่บริษัทยุค 2026 ควรมี#

Password Standard — อย่างที่อธิบาย

Encryption Standard — ระบุ algorithm ที่อนุญาต. ตัวอย่าง:

• Symmetric: AES-256 เท่านั้น (ไม่ใช่ DES / 3DES / AES-128 สำหรับ data ที่ classify เป็น Confidential ขึ้นไป)
• Asymmetric: RSA 2048-bit ขั้นต่ำ (กำลังย้ายไป 3072 / 4096) หรือ ECC P-256 ขึ้นไป
• Hashing: SHA-256 ขึ้นไป (ห้าม MD5 / SHA-1)
• TLS: TLS 1.2 ขั้นต่ำ — ยอมรับเฉพาะ cipher suite ใน approved list
• Post-quantum: เริ่ม pilot ภายในปี 2027

Access Control Standard — บอกว่าระบบ classify เป็น Confidential ขึ้นไปต้องใช้ MFA / Privileged account ต้องผ่าน PAM / Account ของพนักงานที่ออกต้อง disable ภายใน 4 ชั่วโมง

Vendor Security Standard — บอกว่า vendor ที่จะเข้าระบบบริษัทต้องผ่าน security assessment / ต้องเซ็น DPA (Data Processing Agreement) / ต้องมี SOC 2 หรือ ISO 27001

Logging Standard — บอกว่าทุกระบบที่ classify เป็น Confidential ขึ้นไปต้อง log อย่างน้อย authentication / privileged action / data access — เก็บอย่างน้อย 1 ปี (หรือ 7 ปีถ้าเป็นข้อมูลการเงิน)

จะเห็นว่า — Standard มี บริบทของอุตสาหกรรม. ธนาคารต้องเก็บ log 7 ปีตาม Bank of Thailand. โรงพยาบาลต้องเก็บ medical record 10 ปีตาม HIPAA / PDPA. ร้านอาหารไม่มีข้อบังคับนี้

Standard = ภาษากลางของ compliance#

ที่บริษัทไทยมักเจอ — ลูกค้าต่างประเทศส่ง Vendor Security Questionnaire มา 200 ข้อ. คำถามทุกข้อตรง standard control. ถ้าบริษัทคุณไม่มี Standard เป็นเอกสาร — ตอบไม่ได้. หรือตอบมั่ว. หรือตอบว่า “yes” ทั้งหมดโดยไม่มีหลักฐาน — นี่คือ compliance theater ที่เราคุยใน EP.09

บริษัทที่มี Standard ดี — ตอบ questionnaire ได้ภายใน 1-2 วัน. เพราะคำตอบมีเอกสารรองรับทุกข้อ. ดีลปิดได้

มุมผู้บริหาร: ทำไม Standard ถึงต้องเขียน — ไม่ใช่แค่ “ฝัง” ในการตั้งค่าระบบ? เพราะระบบเปลี่ยน — server เก่าปลด server ใหม่ขึ้น / cloud provider เปลี่ยน / ทีม IT เปลี่ยนคน. ถ้า “12 ตัวอักษร” อยู่แค่ใน config — เมื่อ migrate ระบบครั้งหน้า admin ใหม่ที่ไม่รู้ history อาจเซ็ตเป็น 8 ตัว. แต่ถ้า “12 ตัวอักษร” อยู่ใน Password Standard ที่เซ็นโดย CISO — admin คนใหม่จะรู้ว่าต้องเซ็ต 12 — เพราะถ้าเซ็ต 8 จะ fail audit. Standard = memory ของบริษัท ที่ไม่ขึ้นกับว่าใครยังทำงานอยู่

Procedure = how to step-by-step#

Procedure (ขั้นตอนปฏิบัติ — เอกสารบอกวิธีทำทีละขั้น) = เอกสารระดับ operation ที่บอกว่า — เมื่อเกิดเหตุการณ์ X ทีมต้องทำขั้นตอน 1, 2, 3, … จนเสร็จ. ทุกขั้นมีคนรับผิด มีระยะเวลา มีหลักฐานที่ต้องเก็บ

ตัวอย่าง — Offboarding Procedure (ขั้นตอนการเลิกจ้าง):

1. Day -7 (1 สัปดาห์ก่อนวันสุดท้าย) — HR แจ้ง IT Service Desk ผ่าน Jira ticket type Offboarding ระบุชื่อพนักงาน + ตำแหน่ง + วันสุดท้าย + manager
2. Day -7 ถึง Day -1 — IT เตรียม checklist ระบบที่ต้อง disable (ดู Master List ของระบบในบริษัท)
3. Day 0 (วันสุดท้าย) เวลา 17:00 — Manager confirm กับ HR ว่าพนักงานคืน laptop + บัตร + ทรัพย์สิน
4. Day 0 เวลา 17:30 (ภายใน 4 ชั่วโมงตาม Standard) — IT disable account ใน Active Directory (ระบบหลัก) — auto-trigger disable ใน Okta / Slack / Github / Jira ผ่าน SCIM provisioning
5. Day 0 เวลา 17:30 — IT disable account ใน ระบบที่ไม่อยู่ใน SSO (manual list — เช่น VPN / SaaS เก่า) — ตามลำดับ priority
6. Day +1 — IT confirm ว่า account ทุกระบบ disable แล้ว — log evidence (screenshot + timestamp) เก็บไว้ใน ticket
7. Day +1 — ถ้าพนักงานมี privileged access — Security team rotate shared password ทุกตัวที่เขารู้ + revoke API key ที่เขาสร้าง
8. Day +1 — Manager review ของในเครื่องที่พนักงานคืนมา — โอน / ลบ file ตามนโยบาย
9. Day +30 — Account ที่ disable แล้ว 30 วัน → delete (ตาม Data Retention Standard)
10. Quarterly — Internal Audit สุ่มตรวจ ticket offboarding ของ quarter ที่แล้ว — pass / fail ตาม SLA

สังเกตครับ — ทีละขั้น มีลำดับ มีเวลา มีคนรับผิด มีหลักฐาน. นี่คือ Procedure

Procedure ที่บริษัทยุค 2026 ต้องมี#

Onboarding Procedure — ตรงข้ามกับ Offboarding. เมื่อพนักงานเข้า — ใครสร้าง account ระบบไหน? ใครให้ training อะไร? เซ็น AUP เมื่อไหร่?

Incident Response Procedure — ใน EP.47 เราคุยเรื่อง NIST 800-61 6-phase framework. Procedure จะแปลง framework เป็น playbook ที่ทีมรันได้จริง — รวมเบอร์โทร / ลำดับการ escalate / template ของ communication

Backup Procedure — backup เวลาไหน เก็บที่ไหน ทดสอบ restore ทุกเมื่อไหร่

Change Management Procedure — มี change request → CAB review → approve → implement → verify → close

Vulnerability Patching Procedure — เมื่อ CVSS critical → patch ภายในกี่ชั่วโมง / high → กี่วัน / process emergency change

Access Request Procedure — พนักงานขอเข้าระบบใหม่ → manager approve → data owner approve → IT provision → log

ทุก procedure มีโครงคล้ายกัน — input → step-by-step → output + evidence. คนที่อ่าน procedure ครั้งแรกแล้วทำตามได้ — procedure ที่ดี. ถ้าต้องเรียกถามคนเขียน — procedure ที่ไม่สมบูรณ์

Procedure = ภาษาของ operation team#

ที่ผิดบ่อยในบริษัทไทย — Procedure อยู่ใน หัวของ admin คนเดียว. คนคนนั้นรู้ทุกอย่าง — รู้ระบบไหน disable ก่อน รู้ว่า script ไหนต้องรัน รู้ว่า team ไหนต้อง notify

วันที่คนคนนั้นลาออก — ความรู้หาย. ทีมใหม่ต้อง reverse engineer จาก log / script เก่า — ใช้เวลาเป็นเดือน. ในระหว่างนั้น — quality ของ operation ตก. SLA fail. ในเคสที่หนัก — security incident เกิดจาก mistake ของคนใหม่ที่ไม่รู้ procedure ที่ถูก

Procedure ที่เขียนเป็นเอกสาร = business continuity. ไม่ใช่แค่เรื่อง security — เป็นเรื่อง ลด key person dependency

มุมผู้บริหาร: ถ้าวันนี้บริษัทคุณมี IT admin คนเดียวที่ “รู้ทุกอย่าง” + “ทุกคนถามคนนี้” — นี่คือ single point of failure ที่ใหญ่ที่สุดในบริษัท. ไม่ใช่ admin คนนั้นไม่ดี — แต่บริษัทไม่ดี ที่ไม่ทำให้ความรู้กลายเป็นเอกสาร. มาตรการง่ายๆ — กำหนดให้ admin เขียน procedure 1 ตัวต่อสัปดาห์ — ใน 6 เดือนจะได้ procedure 26 ตัว. ยังไม่ครบทุกระบบ — แต่ครอบครู scenario สำคัญที่สุด. นี่คือการเปลี่ยน tribal knowledge เป็น institutional knowledge — ROI ในการ scale + ลด risk + ลด burnout ของ admin คนเดิม

Guideline = best practice ที่แนะนำ ไม่บังคับ#

Guideline (แนวทาง / คำแนะนำ — เอกสารที่ให้คำแนะนำ ไม่บังคับ) = เอกสารที่บอก best practice ที่บริษัทแนะนำให้พนักงานทำ — แต่ละเมิดไม่มีผลทางวินัย. ใช้ ดุลพินิจ ของพนักงานเอง

ตัวอย่าง — Remote Work Guideline:

• แนะนำ ให้ทำงานในพื้นที่ที่ไม่มีคนอื่นมองเห็นจอ
• แนะนำ ใช้ headphone เพื่อกันคนอื่นได้ยินเสียง call
• แนะนำ lock screen ทุกครั้งที่ลุกออกจากที่ — แม้ในบ้านตัวเอง
• แนะนำ ใช้ Wi-Fi ที่บ้านที่มีรหัส (ไม่ใช่ open Wi-Fi ในร้านกาแฟ)
• แนะนำ ถ้าจำเป็นต้องใช้ public Wi-Fi — เปิด VPN ของบริษัทก่อนเสมอ
• แนะนำ ไม่พูดเรื่อง confidential ในที่สาธารณะ

สังเกต — ทุกข้อใช้คำว่า แนะนำ. ไม่มี ต้อง. ถ้าพนักงานทำในร้านกาแฟไม่เปิด VPN — ไม่ผิดวินัย — แต่ถ้าเกิด incident จาก behavior นี้ — บริษัทบันทึกได้ว่า “guideline บอกแล้ว แต่พนักงานเลือกไม่ทำตาม”

ทำไมไม่ทำให้ทุกอย่างเป็น Standard ไปเลย?#

คำถามที่ดี — ทำไมไม่ทำให้ “ทุกข้อใน Remote Work Guideline” เป็น Standard บังคับ?

เหตุผล:

1. บังคับไม่ได้จริง — บริษัทจะตรวจยังไงว่าพนักงาน lock screen ที่บ้าน?
2. บริบทต่างกัน — บางคนอยู่บ้านคนเดียว lock screen น้อยลงก็ยังปลอดภัย / บางคนอยู่กับ housemate ต้อง lock ทุกครั้ง — บังคับเหมือนกันไม่ make sense
3. เปลี่ยน behavior ผ่านการบังคับยาก — เปลี่ยนผ่าน awareness + dignity ดีกว่า. Guideline + training = behavior change ที่ยั่งยืนกว่า rules ที่บังคับ
4. เก็บ Standard ไว้ใช้กับเรื่องสำคัญจริง — ถ้าบังคับทุกอย่าง — พนักงาน fatigue / fail audit เรื่องเล็ก / ลด credibility ของ Standard ตัวสำคัญ

Guideline ก็เลยเป็น ชั้นนุ่ม ของ governance — แนะนำ ให้ดุลพินิจ — แต่ยังบอกชัดว่าบริษัทคิดยังไง

Guideline ที่บริษัทยุค 2026 ควรมี#

Remote Work Guideline — อย่างที่อธิบาย

Password Manager Guideline — แนะนำให้พนักงานใช้ password manager (1Password / Bitwarden / Dashlane) แทนการจำ — บริษัทอาจ subsidize ค่าใช้จ่าย

Social Media Guideline — แนะนำว่าโพสต์อะไรเกี่ยวกับบริษัทได้ / อะไรไม่ควร / ห้ามเปิดเผยข้อมูลภายในแม้ใน private chat

AI Tool Usage Guideline — แนะนำว่าใช้ ChatGPT / Claude / Copilot กับงานบริษัทยังไงได้บ้าง — เริ่มต้นจาก ห้าม paste data ที่ classify เป็น Confidential ลง free-tier tool (ตัวนี้อาจอยู่ใน Standard ด้วย — แล้วแต่บริษัท)

BYOD Guideline — ถ้าพนักงานใช้เครื่องส่วนตัว — แนะนำให้แยก work profile / ใช้ MDM container / เปิด screen lock

มุมผู้บริหาร: Guideline ไม่ใช่ “Policy ที่ขี้เกียจ enforce”. เป็น เครื่องมือบริหารคน ที่ใช้ตรงที่ regulation บังคับไม่ได้แต่ behavior สำคัญ. ลองนึกฉาก — บริษัทออก Standard ใหม่ “ห้ามใช้ ChatGPT กับงาน” — พนักงานทุกคนใช้ลับๆ. กลายเป็น shadow IT ที่ track ไม่ได้. ถ้าออก Guideline + trainings + approved alternative tool ของบริษัทที่ enterprise-grade — พนักงานเลือกใช้ tool ที่บริษัทอนุญาตเพราะสะดวก. นี่คือศิลปะของ governance — อย่าออก rule ที่บังคับไม่ได้ — มันลด credibility ของ rule อื่นที่บังคับได้

Document Lifecycle 7 ขั้น#

ลองนึกฉากครับ. ทีม security ของบริษัทเขียน Cloud Security Standard เพราะปีนี้ย้ายงานขึ้น AWS. กระบวนการเป็นยังไง?

ขั้น 1 — Draft (ร่าง) — security architect เขียนร่างแรก. อิง template จาก NIST / CSA. ปรับให้ตรง business + tech stack ของบริษัท

ขั้น 2 — Review (ทบทวน) — ส่งให้ผู้เกี่ยวข้อง review — DevOps team / Legal / Risk / Compliance / business owner. รับ comment ปรับ. รอบ review อาจมี 2-3 รอบ

ขั้น 3 — Approve (อนุมัติ) — ผ่าน Information Security Committee → approve. ถ้าเป็น Policy → ต้องผ่าน CEO / Board

ขั้น 4 — Publish (เผยแพร่) — เอกสารขึ้น intranet / wiki / document management system. version control. ทุกคนเข้าถึงได้

ขั้น 5 — Train (อบรม) — ทีมที่กระทบต้องผ่าน training. ลายเซ็นรับทราบ (acknowledgement). นี่คือขั้นที่หลายบริษัทพลาด — เขียนเอกสาร publish ไว้ แต่ไม่มีใครรู้ว่ามี

ขั้น 6 — Maintain (รักษา + update) — review ทุก 12-24 เดือน. หรือเมื่อเกิด trigger เช่น regulation เปลี่ยน / tech stack เปลี่ยน / incident เกิด. ทุก revision มีบันทึก change log

ขั้น 7 — Retire (เลิกใช้) — เมื่อเทคโนโลยีล้าสมัย / business pivot. เอกสารเก่า archive ไว้ — ไม่ลบทิ้ง — เพราะ audit อาจขอย้อนดู

วงจรนี้ — ทุก document ในระบบ governance ต้องผ่าน. บริษัทที่ดี — มี document register ที่ track ทุก document + เจ้าของ + วันที่ approve + วันที่ต้อง review ครั้งหน้า

เริ่มที่ไหน — ใช้ template ของวงการ#

ข่าวดี — บริษัทคุณไม่ต้องเขียนทุก policy จากศูนย์. วงการมี template ฟรี ระดับโลกที่ใช้ได้

NIST (National Institute of Standards and Technology — สหรัฐฯ) — มี framework สมบูรณ์ที่สุดในโลก:

• NIST Cybersecurity Framework (CSF) — กรอบกว้างที่ใช้กำหนด policy
• NIST 800-53 — control catalog ที่ใช้เขียน standard
• NIST 800-61 — incident response template
• NIST 800-63 — digital identity / password standard
• ฟรีทั้งหมด — download ได้จาก nist.gov

SANS Institute — มี template policy + procedure ที่ใช้ได้ทันที — โครงร่างของ Information Security Policy / AUP / Incident Response Plan ฯลฯ

ISO 27002 — มาตรฐานสากลที่ใช้กับ ISO 27001 certification — ระบุ 93 control ใน 4 หมวด — ใช้เป็น checklist ในการเขียน standard

CIS Critical Security Controls (v8) — 18 control area + sub-control — ใช้กำหนด priority ของ standard ที่ควรเขียนก่อน

สำหรับบริษัทไทย — เพิ่ม:

• PDPA — Privacy Policy + Data Protection guidelines
• ETDA / สพธอ. — มี baseline สำหรับ critical infrastructure
• Bank of Thailand IT Risk Management — ถ้าเป็นสถาบันการเงิน

Approach ที่แนะนำ:

1. เริ่มที่ Information Security Policy ตัวเดียว (1 หน้า) — CEO เซ็น — ปูฐาน
2. เพิ่ม Acceptable Use Policy — ให้พนักงานเซ็นตอน onboarding
3. ค่อยขยับไป Standard ที่สำคัญที่สุดของบริษัทคุณ — password / encryption / access control
4. Procedure ตามมาทีหลัง — โฟกัสที่ scenario ที่เกิดบ่อย (onboarding / offboarding / incident response)
5. Guideline เป็นชั้นสุดท้าย — เพิ่มเมื่อ behavior เริ่มเป็นเรื่อง

อย่าทำพร้อมกันทุกอัน — ทำทีละ 1-2 document ต่อเดือน. ใน 1 ปีจะได้ basic governance ที่ใช้งานจริง. บริษัทไทยที่ออก governance maturity เร็ว — ทำตามจังหวะนี้แล้วได้

มุมผู้บริหาร: Template ฟรีระดับโลกเอามาใช้ได้ — แต่ห้าม copy paste แล้วใช้เป๊ะ. ทุก template ต้อง adapt ให้ตรง business / scale / tech stack / regulator ของคุณ. เคสที่เจอบ่อย — บริษัทไทยขนาดเล็ก copy NIST template ของ federal agency — กลายเป็นเอกสาร 200 หน้าที่ไม่มีใครอ่าน — security team บังคับใช้ไม่ได้ — auditor เห็นว่ามี gap ระหว่างเอกสารกับ practice. แย่กว่าไม่มีเอกสาร เพราะ auditor flag เป็น willful non-compliance. หลักคิด — เอกสารที่ทำตามจริงได้ทุกข้อ ดีกว่าเอกสารที่สวยแต่ไม่ทำ

สิ่งที่ผู้นำต้องจำ#

ข้อแรก — ไม่มีเอกสาร = ไม่มี governance. ไม่ว่าจะมี firewall ดีแค่ไหน มี EDR ดีแค่ไหน มี SOC ดีแค่ไหน — ถ้าไม่มี Information Security Policy + Acceptable Use Policy ที่เซ็นแล้ว — บริษัทคุณยังไม่ได้เริ่ม security. วันที่ auditor / regulator / ลูกค้ารายใหญ่ / ศาล ถาม — คุณต้องการ เอกสาร ไม่ใช่ log file. และเอกสารใช้เวลาเขียน 2-4 สัปดาห์ — ไม่ใช่ 2-4 ชั่วโมงตอนต้องการ. ถ้าวันนี้ยังไม่มี — เริ่มสัปดาห์นี้. ใช้ template ของ SANS / NIST. CEO เซ็น

ข้อสอง — แยกชั้นให้ถูก. อย่าผสมกัน. Policy ที่ลงรายละเอียดเทคนิค = Policy ที่ต้อง update ทุก 3 เดือน — CEO จะเซ็นไม่ไหว. Standard ที่ไม่วัด = Standard ที่ตรวจไม่ได้ — เสีย credibility. Procedure ที่กว้าง = Procedure ที่ทีมทำตามไม่ได้ — กลายเป็น tribal knowledge. Guideline ที่บังคับ = Guideline ที่ใครๆ ก็ละเมิด — กลายเป็น ครับๆ พิธีกรรม. แต่ละชั้นมี purpose ของตัวเอง — เคารพ purpose นั้น. หลักง่ายๆ — ถ้าเอกสารต้อง update บ่อย → ขยับลงชั้นล่าง. ถ้า audit ตรวจไม่ได้ → ขยับขึ้นชั้นบน (เปลี่ยนจาก Standard เป็น Guideline). 4 ชั้นนี้คือ โครงสร้าง ของ governance ทั้งโลก — ไม่ใช่แค่ trick ของวงการ — เป็น mental model ที่ใช้กับทุก domain ที่บริษัทต้องการ governance — security / privacy / quality / safety