CISA Series ตอนที่ 15 : D2 - กฎที่ IT ต้องอยู่ใต้: Laws, Regulations, Policies, Standards, Procedures

ใน ตอน 14 ผมแย้มไว้ว่า Domain 2 จะเปลี่ยนมุมมาดู governance ขององค์กร และตอนนี้คือ บทแรกของจริง — กฎที่กดทับ IT ทุกชั้น

ตอนเริ่มอ่าน Section 2.1 + 2.3 ของ CRM ผมงงนิดหน่อยครับ — เพราะ 2.1 พูดถึงกฎหมายภายนอก (laws, regulations) ส่วน 2.3 พูดถึงกฎภายในองค์กร (policies, standards, procedures, guidelines) แต่จริงๆ ทั้งสอง section นี้มันคือ เรื่องเดียวกัน ที่มองคนละมุม

ผมเลยรวม 2 section นี้เข้าด้วยกันเป็นบทเดียว ภายใต้ frame “ลำดับชั้นของกฎ” ที่ไหลลงมาจากรัฐสภาจนถึงคู่มือ SOP ของพนักงานคนล่างสุด

โครงของบท:

ทำไม auditor ต้องสนใจกฎหมาย ในเมื่อมีทีมกฎหมายอยู่แล้ว
ภายนอก: laws / regulations / industry standards
ภายใน: policies / standards / procedures / guidelines (4 ชั้น)
Trap patterns ที่ออกข้อสอบ
ปิด: ทำไม “ลำดับชั้น” สำคัญกว่าที่คิด

ทำไม Auditor ต้องสนใจกฎหมาย?#

ผมเห็นคำถามนี้บ่อยจากเพื่อนสายไอที — “บริษัทมีฝ่ายกฎหมายแล้ว auditor ไปยุ่งทำไม?”

คำตอบสั้น: เพราะกฎหมายแต่ละข้อ กระทบ control design ของระบบ IT โดยตรง — ฝ่ายกฎหมายอ่านกฎหมายได้ แต่ไม่ใช่คนที่ออกแบบระบบ ส่วน IS auditor คือคน ตรวจว่าระบบสะท้อนกฎหมายจริงมั้ย

ลองดูตัวอย่าง:

PDPA (พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล ของไทย) บอกว่าลูกค้ามีสิทธิ์ขอลบข้อมูลตัวเอง → ระบบ CRM ของบริษัทต้อง มีปุ่ม delete ที่ลบข้อมูลในทุก database ที่เก็บไว้ ไม่ใช่แค่ใน front-end
GDPR บอกว่าต้องมี breach notification ภายใน 72 ชั่วโมง → ต้องมีระบบ alert + incident response procedure ที่ทดสอบจริง
กฎของแบงก์ชาติ เกี่ยวกับ data residency → server บางอย่างต้องอยู่ในไทย — กระทบ cloud strategy ทันที

ฝ่ายกฎหมายอ่านข้อความได้แต่ตอบไม่ได้ว่า “ระบบเรา comply จริงมั้ย” — นั่นเป็น technical compliance ที่ IS auditor ต้องตรวจ

เดี๋ยว Domain 5 จะลงเทคนิค privacy controls ในระดับลึก (เช่น encryption สำหรับ data at-rest, masking สำหรับ test environment) — ตอนนี้รู้แค่ว่ากฎหมายภายนอกคือ input ของ design ก็พอ

นั่นคือ “ทำไม” ของบทนี้ ทีนี้มาดูชั้นของกฎกัน

ชั้นที่ 1 (ภายนอก): Laws, Regulations และ Industry Standards#

Laws — กฎหมาย#

Law = กฎที่ออกโดยรัฐ มีผลบังคับ ฝ่าฝืนแล้วมีโทษ

ในมุม IT — กฎหมายที่กระทบโดยตรง:

PDPA ของไทย — คุ้มครองข้อมูลส่วนบุคคลของคนไทย
GDPR ของยุโรป — คุ้มครองข้อมูลของคนยุโรป (กระทบบริษัทไทยที่ขายของให้ลูกค้าในยุโรป)
กฎหมายเฉพาะวงการ เช่น กฎของหน่วยงานกำกับดูแลทางการเงิน, สาธารณสุข, การศึกษา — แต่ละวงการมีกฎ data ของตัวเอง

กับดักที่เจอบ่อย: “บริษัทเราอยู่ในไทย GDPR ไม่เกี่ยวข้อง”

ผิดครับ — GDPR ไม่ได้บังคับตามที่ตั้งของบริษัท แต่บังคับตาม ที่อยู่ของเจ้าของข้อมูล ถ้าคุณขายของออนไลน์และมีลูกค้าในยุโรปแม้คนเดียว — GDPR กระทบทันที

IS auditor ที่รับคำว่า “เราอยู่ในไทย GDPR ไม่เกี่ยว” โดยไม่ตรวจ customer base ของบริษัทจริง = ตรวจไม่ครบ

Regulations — กฎย่อยและประกาศ#

Regulation = ข้อกำหนดเฉพาะที่ออกโดยหน่วยงานกำกับดูแล — สอดคล้องกับ law ที่ใหญ่กว่า แต่ลงรายละเอียดมากกว่า

ตัวอย่าง: PDPA เป็นกฎหมาย → สำนักงานคุ้มครองข้อมูลส่วนบุคคลออก ประกาศ เรื่อง “มาตรการรักษาความมั่นคงปลอดภัย” — เป็น regulation ที่ลงรายละเอียดว่าต้องทำอะไรบ้าง

ในมุม audit: regulation ใกล้กับ “เกณฑ์ที่ใช้ตรวจ” มากกว่า law เพราะ specific กว่า

Industry Standards#

Industry Standard = มาตรฐานที่วงการเดียวกันยอมรับ — ไม่ได้เป็นกฎหมาย แต่ถ้าไม่ทำตาม คู่ค้าและลูกค้าจะไม่เชื่อถือ

ตัวอย่างที่ CISA ออกข้อสอบบ่อย:

PCI DSS — ถ้ารับบัตรเครดิต ต้อง comply (ไม่ใช่กฎหมายไทย แต่บัตรเครดิตจะไม่ออกให้ถ้าไม่ทำตาม)
ISO 27001 — มาตรฐานด้านความปลอดภัยข้อมูล
NIST CSF — กรอบ cybersecurity

ความแตกต่างที่สำคัญ: law บังคับโดยรัฐ / regulation บังคับโดยหน่วยงาน / industry standard บังคับโดย “ตลาด” (ถ้าไม่มี ลูกค้าไม่เลือก)

GRC: ทำไมต้องรวมกัน?#

CRM พูดถึงคำว่า GRC — Governance, Risk, Compliance

หลายบริษัทมีทั้งสามฝ่าย แต่ทำงานแยกกัน:

ฝ่าย governance (board, audit committee) ออก policy
ฝ่าย risk (CISO, risk manager) ประเมินความเสี่ยง
ฝ่าย compliance (legal, ผู้ดูแล regulation) ติดตามกฎหมาย

ปัญหา: ถ้า 3 ฝ่ายไม่คุยกัน — risk เรื่อง data breach อาจถูกประเมินแล้วในฝ่าย risk แต่ฝ่าย compliance ไม่รู้ว่ามันเกี่ยวข้องกับ PDPA ส่วน governance ก็ไม่รู้ว่าต้องอนุมัติ budget เสริม

GRC ที่ดี = 3 ฝ่ายทำงานเป็นภาพเดียว — IS auditor มองหาว่า GRC integration เกิดขึ้นจริง หรือเป็นแค่ป้ายแขวนบนผนัง

ชั้นที่ 2 (ภายใน): Policies, Standards, Procedures, Guidelines#

ทีนี้กฎจากภายนอกกระทบลงมาในองค์กร — องค์กรต้อง แปล กฎหมายเป็นกลไกภายในที่พนักงานทำตามได้จริง

ลำดับชั้น:

1
Policies (แสดงเจตจำนงของผู้บริหาร)
2
   ↓
3
Standards (มาตรฐานที่บังคับ — ห้ามต่อรอง)
4
   ↓
5
Procedures (ขั้นตอนทำจริง — Who/What/When/Where/Why/How)
6
   ↓
7
Guidelines (คำแนะนำ ไม่ได้บังคับ)

ทุกชั้นมีบทบาทที่ต่างกัน — IS auditor ต้องเข้าใจชั้นทั้งหมดเพื่อตรวจ control ได้ตรงจุด

Policy — เจตจำนงของฝ่ายบริหาร#

Policy = แถลงการณ์ระดับสูงของผู้บริหารว่า “บริษัทยึดอะไรเป็นหลัก”

นึกถึงรัฐธรรมนูญของบริษัท — กว้างพอที่จะครอบคลุมหลายสถานการณ์ แต่ชัดพอที่จะส่งสัญญาณว่าผู้บริหารเอาจริง

Policy ของ IT ที่ทุกบริษัทควรมี (อย่างน้อย):

Information Security Policy (ISP) — เอกสารแม่บทของ security ทั้งบริษัท
Acceptable Use Policy — พนักงานใช้ระบบบริษัทยังไงได้บ้าง
Access Control Policy — ใครเข้าระบบไหนได้
Data Classification Policy — ข้อมูลแบ่งเป็นกี่ชั้น (เดี๋ยวตอน 17 จะเล่า)
Incident Response Policy — ถ้าระบบล่มหรือมีการบุกรุก ทำอย่างไร
Remote Access Policy — work from home/remote ใช้ระบบยังไง

ลักษณะของ policy ที่ดี:

มีชื่อ owner ที่รับผิดชอบ (ไม่ใช่ “แผนก IT” แบบลอย ๆ)
มีวันที่ทบทวนล่าสุดและวันที่ทบทวนรอบหน้า
ถูกอนุมัติโดย senior management
ถูกสื่อสารถึงพนักงานทุกคน (ไม่ใช่ฝังอยู่ใน drawer ของ CIO)

Trap ที่ออกข้อสอบ: policy ที่ไม่มีวันที่ทบทวน = policy ที่อาจล้าสมัยตั้งแต่แรก IS auditor flag อันนี้แน่นอน

Standard — บังคับ ห้ามต่อรอง#

Standard = ข้อกำหนดเฉพาะที่ บังคับ — แปล policy ให้เป็น “ต้องทำอะไร, ทำยังไง”

เปรียบเทียบ:

Policy: “บริษัทใช้ password ที่แข็งแรงเพื่อปกป้อง account”
Standard: “Password ต้อง 12 ตัวอักษรขึ้นไป มีตัวพิมพ์ใหญ่ พิมพ์เล็ก ตัวเลข อักขระพิเศษ — เปลี่ยนทุก 90 วัน”

Policy บอกว่า ทำไม standard บอกว่า เท่าไหร่ / อะไรคือเส้น

Standard เป็น mandatory — ห้ามต่อรอง ถ้าฝ่าฝืนคือ violation ที่ต้อง report

Procedure — Who, What, When, Where, Why, How#

Procedure = ขั้นตอนเฉพาะ ทีละขั้น ที่บอกว่าจะทำตาม policy + standard ได้อย่างไร

ตัวอย่าง procedure ของ “การออกบัญชีผู้ใช้ใหม่”:

ผู้จัดการของพนักงานใหม่กรอก request form ใน HR system
HR ส่ง request ไปยัง IT helpdesk ภายใน 1 วันทำการ
IT admin สร้าง account ใน Active Directory ตาม role template
IT admin ส่ง username + temporary password ผ่าน secure channel
ผู้ใช้เปลี่ยน password ในการ login ครั้งแรก (ระบบบังคับ)
ผู้จัดการยืนยันว่า access ถูกต้อง ภายใน 3 วันทำการ
IT log ทุกขั้นตอนใน ticket system

แต่ละขั้นมี ใคร / ทำอะไร / เมื่อไหร่ / ที่ไหน / ทำไม / อย่างไร / มีหลักฐานอะไร — ครบ 7 ข้อ

Trap สำคัญ: procedure ที่ไม่มีใครรู้ = ไม่มี procedure procedure ต้องถูกสื่อสารและฝึกอบรม ไม่ใช่แค่เก็บไว้ในเอกสารกลาง

Guideline — แนะนำ ไม่บังคับ#

Guideline = คำแนะนำเสริม — ช่วยให้พนักงานทำ procedure ได้ดีขึ้น แต่ ไม่ใช่กฎ

ตัวอย่าง: procedure บอกว่า “ตั้งชื่อ user ตาม pattern firstname.lastname” — guideline เสริม: “ถ้ามีชื่อซ้ำ ให้เติมเลขประจำตัวพนักงาน 4 หลักท้าย”

Trap ใหญ่ที่ออกข้อสอบ: guideline ไม่ใช่ control ไม่ปฏิบัติตาม guideline = ไม่ใช่ violation IS auditor ที่เขียน finding ว่า “พบการไม่ปฏิบัติตาม guideline” = เขียนผิดตั้งแต่ classification

ถ้าจะให้สิ่งใดเป็น mandatory — ต้องเขียนเป็น standard ไม่ใช่ guideline

ภาพรวม: ทุกชั้นต้องเชื่อมกัน#

ผมขออธิบายลำดับชั้นด้วย scenario ของคลินิกแห่งหนึ่งที่ผมไปคุยให้คำปรึกษาเรื่อง PDPA:

Law (ภายนอก): PDPA บอกว่าต้องคุ้มครองข้อมูลผู้ป่วย

Regulation (ภายนอก): ประกาศของหน่วยงานกำกับดูแลด้านข้อมูล กำหนดมาตรการเพิ่มเติม

Industry Standard (ภายนอก): ISO 27001 ที่คลินิกอยากทำ certification

↓ คลินิกแปลกฎภายนอกเป็นกฎภายใน:

Policy (ภายใน): “คลินิกปกป้องข้อมูลผู้ป่วยตาม PDPA และมาตรฐานวิชาชีพ” — นโยบายที่ผู้อำนวยการลงนาม

Standard (ภายใน): “ข้อมูลผู้ป่วยที่เก็บใน database ต้อง encrypt ด้วย AES-256 / access ต้องผ่าน MFA / เก็บไว้ไม่เกิน 10 ปี”

Procedure (ภายใน): ขั้นตอนการให้สิทธิ์ดูข้อมูลผู้ป่วยให้แพทย์ใหม่ — 8 ขั้นตอนเฉพาะ

Guideline (ภายใน): “ในกรณีฉุกเฉินที่ต้องเข้าระบบเร่งด่วน แนะนำให้แจ้ง CISO ภายใน 24 ชั่วโมง”

ทุกชั้นต้อง trace ขึ้นและลงได้ — auditor ต้อง verify ว่า procedure ที่พนักงานทำ ตรงกับ standard ที่ standard ตรงกับ policy ที่ policy รองรับ law

ถ้ามี procedure ที่ไม่เชื่อมกลับ standard/policy — เป็นสัญญาณว่าสร้างขึ้นเอง โดยไม่มี governance รับรอง = control ที่ไม่มี backing

Trap Patterns ที่ออกข้อสอบ#

Trap	ความเข้าใจผิด	ความเข้าใจที่ถูก
Policy = Procedure	ใช้แทนกัน	คนละชั้น — policy = เจตจำนง / procedure = ขั้นตอนทำ
Guideline = mandatory	ปฏิบัติตามทุกข้อ	guideline = แนะนำ ไม่บังคับ — มีปัญหาแค่ note
Standard = optional	ฝ่าฝืนได้	standard = บังคับ ห้ามต่อรอง
GDPR = ใช้กับบริษัทยุโรป	บริษัทไทยไม่กระทบ	GDPR ใช้กับ data ของคน EU ไม่ว่าบริษัทอยู่ไหน
Compliance = control effectiveness	comply กฎหมาย = control ดี	comply = แค่ตามกฎ — control อาจยังอ่อน
Vendor ไม่ต้องตาม ISP	นโยบายภายในเฉพาะพนักงาน	vendor ที่ access data ต้องผูกใน contract

ปิดบท: ทำไม “ลำดับชั้น” สำคัญกว่าที่คิด#

ที่อยากให้ติดในหัวจากบทนี้คือ — ทุก control ที่ auditor เห็นในระบบจริง ต้อง trace กลับขึ้นไปได้ถึง law

ถ้า trace ไม่ได้ — หมายความว่า:

control นั้นอาจไม่จำเป็น (ทำไปทำไมก็ไม่รู้) → waste resource
หรือ control นั้นจำเป็น แต่ไม่มี policy รองรับ → ถ้าคนทำลาออก ไม่มีใครรู้ว่าต้องสานต่อ

นี่คือเหตุผลที่ Section 2.1 + 2.3 ของ CRM ต้องอ่านพร้อมกัน — กฎหมายภายนอกกับกฎภายในเป็น ระบบเดียวกัน ที่ผู้บริหารต้องสร้างให้เชื่อมกัน

ใน ตอน 07 ของ Domain 1 เราคุยเรื่อง compliance ในมุม audit planning ไปแล้ว — ตอนนี้เห็นภาพ governance side: compliance ไม่ได้เริ่มที่ checklist ของ auditor มันเริ่มที่ ลำดับชั้นของกฎ ที่ board ออกแบบไว้ตั้งแต่ต้น

ตอน 16 จะมาเจาะใจกลางของ Domain 2 — EGIT, Three Lines, SoD, Enterprise Architecture บทใหญ่ที่สุดของ Domain 2 ครับ ใครเป็นคนกำกับ IT จริงๆ และคนทำ-คนตรวจ-คนรับประกันต้องแยกกันยังไง

อ้างอิง CRM (CISA Review Manual 28th Edition): Domain 2: Section 2.1 Laws, Regulations and Industry Standards + Section 2.3 IT Policies, Standards, Procedures and Guidelines