Laws ตัวอย่างที่ Auditor ต้อง Aware (ไม่ต้องท่อง)#

CRM ระบุชัดเจน: “For the CISA exam, the IS auditor must be aware of these globally recognized concepts; however, knowledge of specific legislation and regulations will not be tested.”

แปลว่า exam ไม่ออกถามรายชื่อกฎหมาย — แต่ auditor ต้อง aware ว่ามี categories ของ laws ที่อาจ trigger audit:

จุดที่ exam ถามจริงๆ: บริษัทไทยขายของออนไลน์ + มีลูกค้า EU 1 คน → GDPR กระทบทันที เพราะ jurisdictional reach ดูที่อยู่ของ data subject ไม่ใช่ที่ตั้งบริษัท

IIA 7 Considerations — Framework สำหรับ Compliance Audit#

The Institute of Internal Auditors (IIA) ระบุ 7 considerations ที่ auditor ต้องดูเมื่อตรวจ regulatory compliance:

1. Standards and procedures — มี compliance standards + procedures ที่พนักงานทำตามได้มั้ย
2. Assignment of responsibility to senior personnel — มี individual ระดับ senior ที่ accountable มั้ย
3. Reliable / ethical employees — มี background check ก่อนให้ access ระบบ + data sensitive มั้ย
4. Communication and training — Standards ถูก communicate effectively ทั่วบริษัทมั้ย
5. Compliance monitoring and auditing — มี monitoring + reporting steps ที่ reasonable มั้ย
6. Consistent enforcement — Compliance ถูก enforce ผ่าน disciplinary mechanisms (รวม discipline ผู้ที่ fail to detect/report violations)
7. Appropriate response to offenses + prevention of similar offenses — เมื่อเจอ violation บริษัท report to authorities + put preventive measures มั้ย

ทำไม framework นี้สำคัญ? เพราะ กฎหมายเปลี่ยนทุกปี แต่ 7 considerations นี้ stable auditor ใช้เป็น checklist สำหรับ compliance audit ทุกประเภท ไม่ว่าจะกฎหมายไหน

Trap คลาสสิก: บริษัทที่บอกว่า “compliant” เพราะมี policy เขียนไว้ แต่ขาด consideration 4 (training) หรือ 5 (monitoring) → IIA framework บอกว่า ยังไม่ comply จริง

Sentencing Guidelines + International Adoption#

ในสหรัฐฯ — US Federal Sentencing Guidelines (1991) กำหนดว่าบริษัทที่มี compliance program ที่ effective อาจได้ penalty reduction

แนวคิดนี้ถูก adopt ทั่วโลก — OECD/COSO standards มี similar guidance ที่ countries หลายแห่งใช้เป็น base สำหรับ corporate liability laws

ในมุม auditor บริษัทที่มี compliance program ที่ documented + tested = demonstrate “due care” ลด liability เมื่อเกิด violation

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

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 เกิดขึ้นจริงไหม หรือเป็นแค่ป้ายแขวนบนผนัง

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 ของ “การออกบัญชีผู้ใช้ใหม่”:

1. ผู้จัดการของพนักงานใหม่กรอก request form ใน HR system
2. HR ส่ง request ไปยัง IT helpdesk ภายใน 1 วันทำการ
3. IT admin สร้าง account ใน Active Directory ตาม role template
4. IT admin ส่ง username + temporary password ผ่าน secure channel
5. ผู้ใช้เปลี่ยน password ในการ login ครั้งแรก (ระบบบังคับ)
6. ผู้จัดการยืนยันว่า access ถูกต้อง ภายใน 3 วันทำการ
7. 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