Pattern ที่เจอบ่อย#

หลายบริษัทคิดว่า “Privacy compliance = post privacy notice บนเว็บ” ผิดครับ

นั่นเป็นแค่ outward-facing piece ของ program ใหญ่ที่ต้องครอบคลุม:

• People — ใครรับผิดชอบ data privacy (DPO ใน GDPR)
• Process — ขั้นตอนรับ + ตอบ data subject request
• Technology — ระบบที่ implement การ delete, export, mask ข้อมูล
• Documentation — PIA, DPIA, data inventory, breach register, training records
• Training — พนักงานรู้และมีหลักฐานว่าได้รับการอบรม
• Audit — กระบวนการประเมิน privacy controls เป็นระยะ

Privacy Notice vs Privacy Policy#

คู่นี้คนใช้สลับกันบ่อยครับ:

Privacy Notice — เอกสาร ภายนอก สำหรับ data subjects + data protection authorities

• Outward-facing — บอกอะไรเก็บ ทำไม shared กับใคร
• เป็น legal accountability — privacy notice ที่บริษัท publish = ผูกพัน

Privacy Policy — เอกสาร ภายใน ที่กำหนดว่าพนักงานจัดการ personal data ยังไง

• Inward-facing — internal rules + procedures
• ผูกกับ Information Security Policy hierarchy ที่คุยใน ตอน 15

ทั้งสองต้อง consistent กัน — Notice บอกว่า “ไม่แชร์ข้อมูลกับ third party” แต่ Policy บอกว่า “แชร์ได้กับ partner ภายใต้ NDA” → contradiction → legal violation

Privacy Notice ต้องบอกอะไร#

CRM ระบุ Privacy Notice ต้อง disclose:

• What personal data are collected
• Why the data are collected (purpose)
• How data are collected
• How data are used, processed, shared
• With whom data are shared
• What choices data subjects have
• How data collection may impact data subjects
• Where + how data are destroyed (when applicable)

Privacy Notice ที่ดี = ใช้ plain language ไม่ใช่ legal jargon ที่อ่านไม่รู้เรื่อง

วิธีการ Deliver Notice (5 รูปแบบ)#

CRM list 5 ways:

1. Web page ที่ dedicated สำหรับ privacy
2. Forms ที่ขอ personal information พร้อม advise
3. Brochures (ส่งทางไปรษณีย์ในบางวงการ เช่น healthcare)
4. Documents ที่อยู่ใน facility (โรงพยาบาล, คลินิก)
5. Contracts (banking, financial services)
6. Signs (CCTV warning signs) — partial form

ที่ exam มัก trap: บริษัทใช้ “Terms of Use” รวมกับ Privacy Notice — best practice = แยกเป็น 2 documents เพื่อไม่ให้ privacy ถูกฝังใน fine print

Consent — Mechanism ของ Privacy Notice#

Consent form = เอกสารที่ data subject ยอมรับ terms ของ Privacy Notice

ต้องครอบคลุม:

• Obtaining consent สำหรับ existing personal data
• Revoking consent — กลไกถอน consent ได้

รูปแบบ consent ที่เจอ:

• Opt-in button — บังคับเลือก yes ก่อนใช้
• Opt-out checkbox — default = consent / กดถ้าไม่ยอม
• Tick box ใต้ privacy notice
• Signature line ในเอกสารกระดาษ

Opt-In vs Opt-Out — Trap คลาสสิก#

GDPR + PDPA เน้น opt-in สำหรับ sensitive data opt-out ไม่เพียงพอ สำหรับ data ที่ regulated หนัก

Withdrawal of Consent#

Data subjects ต้อง withdraw consent ได้ทุกเวลา — และบริษัทต้อง:

• มี mechanism รับ withdrawal request
• Process withdrawal ใน timeframe ที่กฎหมายกำหนด (PDPA = 30 วัน, GDPR = 1 เดือน)
• Document การ withdrawal
• Stop processing ทันที (ยกเว้นที่กฎหมายอื่นบังคับเก็บ เช่น tax records)

Trap: บริษัทที่ “สมัครง่าย ยกเลิกยาก” privacy notice ที่ไม่มี clear withdrawal mechanism = legal violation

Ongoing Disclosure / Consent#

Informed consent ไม่ใช่ event เดียว มันคือ ongoing exchange:

• ส่ง update เมื่อ privacy practice เปลี่ยน
• แจ้ง data subject เรื่อง breach (PDPA + GDPR บังคับ 72 ชั่วโมง)
• รับ + ตอบ data subject inquiries

1. Audit Logs#

บันทึก privacy management activities — automated หรือ manual:

• Source ของ data collection
• Date ของ processing/sharing activity
• Number of transactions/data elements shared
• Transfer destination

2. Data Protection Impact Assessments (DPIA)#

เอกสารระบุ legal requirements ที่ apply กับ operations + reviewed periodically — ใช้สำหรับ activity ที่ high risk

3. Data Sheets#

สำหรับ services, applications, networks ที่ store/handle personal data — ระบุว่า system นั้น store ข้อมูลอะไร purpose อะไร

4. Privacy Management Process Descriptions#

Document ที่อธิบาย privacy management process ในรายละเอียดที่:

• เข้าใจง่ายโดย broad audience
• Authorized โดย management
• Reference legal requirements (GDPR, CCPA, PDPA)

5. Privacy Impact Assessment (PIA) Reports#

PIA = process ระบุว่า personal information ได้รับการ:

• Safeguarded อย่างเหมาะสม
• Used ตาม purpose
• Shared ตาม consent
• Made available to data subjects
• Destroyed ตาม retention

PIA report ระบุ findings + corrective measures + projected dates + estimated costs

6. Privacy Governance Reports#

Reports ที่ consolidate privacy compliance status across enterprise — ใช้สำหรับ:

• Demonstrate value ของ privacy infrastructure
• Increase awareness ใน management
• Communicate successes + improvements
• Engage stakeholders

7. Training Attendance#

Records ว่าใครเข้า training events:

• Topics ของ training
• Attendees + dates
• Method of delivery
• Quiz/assessment results

ทำไม training records สำคัญ? เพราะ “พนักงานเรารู้แล้ว” + ไม่มีหลักฐาน = defendable claim ในศาลทำไม่ได้ เลย

8. Data Incident Register + Individual Rights Register#

Data Incident Register

• Records ของ privacy data incidents ทั้งหมด
• Source ของ breach, security impact, remedial measures, preventive measures
• Used สำหรับ trend analysis + regulatory reporting

Individual Rights Register

• Records ของ data subject requests (access, deletion, correction, portability)
• When received + when resolved + by whom
• ใช้พิสูจน์ compliance กับ legal response timeframes

Privacy Audit ทำอะไรบ้าง#

CRM ระบุ Privacy Audit เป็น annual element ที่ aid compliance:

• Establish framework สำหรับ auditing/measuring/monitoring
• Assess compliance กับ privacy policies + standards + legal requirements
• Cost + implementation ของ privacy tools
• Advancements in privacy enhancing technologies
• Changes in privacy legislation
• Risk areas + third parties

IS Auditor’s Role ใน Privacy Program#

CRM ระบุชัดเจนว่า IS auditors evaluate:

• Third-party contracts — มี data privacy requirements มั้ย
• Data retention + destruction — implemented ตาม policy มั้ย
• Cross-border regulations — comply กับ data flow restrictions
• Employee training — เกิดจริง + มีหลักฐาน
• Data inventory — created + maintained
• Data subject requests — handled appropriately within timeframes

เดี๋ยว Domain 5 จะลงเทคนิค privacy controls (encryption, masking, access control, DLP) ตอนนี้รู้แค่ว่า privacy program คือ governance framework ที่ทำให้ technical controls ใน D5 มีที่อยู่

Data Classification — ก่อนทุกอย่าง#

คุณปกป้อง data ทุกชิ้นเหมือนกันไม่ได้ — ทำได้ แต่ไม่คุ้ม + ไม่มีประสิทธิภาพ

Data classification = แบ่ง data ตาม sensitivity เพื่อ apply control ที่เหมาะสม

CRM ระบุ standard 4 levels (จากต่ำไปสูง):

Level 1: Public#

• เข้าถึงได้โดยทุกคน
• Read, revised, redistributed ได้
• ตัวอย่าง: marketing material, press releases, public reports
• Control: minimal

Level 2: Internal Use Only (Sensitive)#

• Generally accessible โดย authorized personnel
• Disclosure / loss ไม่สร้าง significant risk
• ตัวอย่าง: employee phone directories, internal policies, internal memos
• Control: access control พนักงานทั้งบริษัท

Level 3: Confidential#

• ต้องเก็บ private
• Disclosure อาจสร้าง competitive impact
• ตัวอย่าง: financial information, customer lists, payment card information, contracts, full data files for testing
• Control: role-based access, encryption

Level 4: Restricted#

• Highly sensitive — disclosure อาจนำไปสู่ criminal charges + legal fines
• ตัวอย่าง: proprietary information, R&D, trade secrets, data protected by statutes
• Control: strict access, encryption, monitoring, audit

(บางบริษัทใช้ 3 ระดับ บางบริษัท 5 — concept เดียวกัน)

Information Owner — รับผิดชอบ Classification#

Information Owner = business manager ที่:

• รับผิดชอบ information asset
• ตัดสินใจ classification ตาม policy
• กำหนด access rules ใน classification ของตัวเอง
• Review classifications regularly + ensure access aligns กับ policy

ที่สำคัญ: Information Owner ≠ IT owner = business side, custodian = IT side (เราคุยใน ตอน 16B ไปแล้ว)

Classification Standards ต้องระบุอะไร#

CRM ระบุ:

• Importance ของ information asset
• Information asset custodian (ใครดูแล)
• Process for granting access
• Process + provisions for approving access rights + access levels
• Extent + depth of security controls

Trap คลาสสิก: Developer เข้าถึง Production Data#

หนึ่งใน scenario ที่ออกข้อสอบ ISACA บ่อยที่สุด:

Scenario: บริษัท software house — developer ขอ access production database เพื่อ debug ปัญหาที่เกิดเฉพาะใน production — ผู้จัดการ IT บอก “เร่งด่วน อนุมัติให้ก่อน”

คำถาม: auditor มองว่าเป็นปัญหา?

คำตอบ: ใช่ครับ มี 2 ปัญหา:

1. SoD violation — developer ไม่ควรเข้า production data เพราะ developer = build ไม่ใช่ run/operate
2. Authorization violation — IT manager ไม่ใช่ data owner ผู้อนุมัติต้องเป็น data owner (ฝั่ง business)

วิธีที่ถูกคือใช้ anonymized / masked data ใน test environment

Legal Purpose#

Data controller ต้อง:

• Describe + detail purpose ใน privacy notice
• Purpose ต้อง comply กับ applicable law
• Subsequent use ต้อง align กับ original purpose + consent obtained

ตัวอย่าง: บริษัทเก็บ email สำหรับ “ส่ง newsletter” — เปลี่ยนไปใช้ “share กับ marketing partner” = ต้องขอ consent ใหม่ (ไม่ใช่ implicit ใน original purpose)

Consent (ลึกขึ้นจากส่วนที่ 3)#

Multiple regulations มี requirements เฉพาะ:

• GDPR — informed, specific, unambiguous, freely given, withdrawable
• HIPAA — written authorization for protected health information
• PDPA — explicit consent + ระบุ specific purpose

Privacy engineers ต้อง ensure:

• Consent options provided appropriately + consistently
• Consents + withdrawals tracked
• Method to document denial (digital + manual)

Legitimate Interest — Legal Basis ที่ Tricky ที่สุด#

Legitimate Interest = legal basis ที่อนุญาต processing โดยไม่ต้องขอ consent แต่ต้อง balance กับ rights ของ data subject

Conditions:

• Relevant + appropriate relationship ระหว่าง data subject + controller (client, customer, employee, etc.)
• Data subject ควรคาดหวังได้ reasonably ว่า processing จะเกิด
• Interest ของ controller ไม่ override rights ของ individual

ตัวอย่าง legitimate interest:

• Security cookies ตอน user เข้า website — เพื่อ session security
• Public health monitoring — เช่น tracking COVID-19 cases ใน geographic area
• Fraud prevention — analyze transaction patterns

Trap: บริษัทที่ใช้ “legitimate interest” เป็น blank check สำหรับ marketing → ผิดครับ Legitimate interest ต้องผ่าน 3-part balancing test + documented assessment ไม่ใช่แค่ assert ลอยๆ

GDPR commonly references legitimate interest assessment หลายกฎหมายอื่นก็ allow คล้ายกัน

2 Privacy-Specific Functions#

CRM ระบุ 2 functions หลัก:

Control-P (Control of Processing)

Develop + implement activities ที่ enable:

• Enterprise + individuals มี suitable understanding ของ data processing
• Dialog ระหว่าง enterprise + data subject เกี่ยวกับ privacy risk

Sub-categories ของ Control-P:

• Policies, processes, procedures — maintained + governed with legal review
• Data processing standards — clauses ระบุ scope of processing activities
• Dissociated processing (CT-DP-P) — increase dissociability + enable privacy principles (เช่น data minimization)

Dissociability — Concept ใหม่#

Dissociability = ความสามารถในการ แยก data จาก individual identity

ตัวอย่าง:

• Pseudonymization — แทน customer name ด้วย ID — ยัง re-identify ได้ถ้ามี mapping
• Anonymization — ลบ identifying info จน re-identify ไม่ได้

Trap: “เรา anonymize data แล้ว ไม่ใช่ personal data อีกแล้ว” ผิดถ้า re-identify ยังเป็นไปได้ GDPR ระบุชัด: anonymization ที่ไม่ irreversible = ยังเป็น personal data อยู่ดี

Communicate-P (Communicate-P Purposes)

Communication policies ที่:

• Increase transparency ของ data processing practices (purpose, scope, roles, responsibilities)
• Subjects + enterprises มี reliable knowledge เกี่ยวกับ processing practices
• Mechanisms maintain predictability consistent with data processing ecosystem

ทำไม Transborder ถึงเป็น Issue#

Cross-border transfer สร้าง compliance complexity เพราะ:

• Source country + destination country อาจมีกฎหมาย privacy ต่างกัน
• Data security + integrity ระหว่าง transmission อาจไม่เท่ากัน
• Privacy laws ของแต่ละประเทศอาจ conflict กันเอง

ตัวอย่างที่ exam ออก:

• บริษัทไทยใช้ Salesforce (US-based) → personal data ของลูกค้าไทยถูก transfer ไป US → ต้องผ่าน mechanism ที่ PDPA accept (e.g., explicit consent + adequate safeguards)
• บริษัทเอเชียใช้ data center ใน EU → GDPR applies for EU residents’ data

Mitigation Mechanisms#

CRM ไม่ระบุ mechanisms ละเอียด แต่ที่ exam รู้:

• Standard Contractual Clauses (SCC) — GDPR-approved contracts
• Adequacy decisions — country ที่ EU บอกว่า “privacy law level เพียงพอ”
• Binding Corporate Rules (BCR) — สำหรับ multinational corp
• Explicit consent — data subject ยอม transfer

Internet Communications — Hidden Transborder#

Trap ที่ตกใจ: ใน internet location ของ information อาจไม่ fixed:

• 2 computers ใน Bangkok คุยกัน packet อาจ route ผ่าน Singapore + Tokyo
• Cloud service ที่ระบุ “Asia region” อาจมี sub-region ใน Japan + Australia
• Cross-border เกิดได้ แม้ทั้ง endpoints อยู่ในประเทศเดียวกัน

auditor ก็เลยต้องตรวจ:

• ระบบมี data residency controls ที่ enforce location จริงๆ มั้ย
• มี logging ของ data flow path มั้ย
• Mechanism ใดถูกใช้สำหรับ transborder ที่เกิดขึ้น

รวม Mental Model 17A + 17B#

ทั้ง 2 ตอน = Section 2.5 + 2.6 + 2.7 ของ CRM ครบ แต่แยกตามชั้นของความเฉพาะ:

• 17A (ERM) — บริหาร risk ทุกประเภท เป็นวงจร
• 17B (Privacy + Data Governance) — zoom ลงไปที่ data risk โดยเฉพาะ เพราะ regulator + ISACA มองพิเศษ

จากนี้ Domain 2 Part A (Foundation) ครบแล้ว: Laws → Hierarchy of Policies → Governance Structure → Risk → Privacy/Data

ตอน 18 จะเปิด Part B (Operational) เริ่มที่ IT Resource Management: คน เงิน การเปลี่ยนแปลง — operational governance ที่ทำให้ทุกอย่างใน Part A เกิดผลในวันธรรมดา

อ้างอิง CRM (CISA Review Manual 28th Edition): Domain 2: Section 2.6 Data Privacy Program and Principles (รวม 2.6.1 Privacy Documentation, 2.6.2 Audit and Compliance) + Section 2.7 Data Governance and Classification (รวม 2.7.1 Data Inventory and Classification, 2.7.2 Legal Purpose Consent and Legitimate Interest, 2.7.3 Data Subject Rights + NIST Privacy Framework)