CISA Series ตอนที่ 17B : D2 - Privacy Program + Data Governance — ข้อมูลที่ Governance ปกป้อง

ผมเพิ่งเข้าใจว่าทำไมหลายบริษัทถึง “ทำ privacy ผิด” ทั้งที่ตั้งใจดี — เพราะคำว่า privacy มันใหญ่กว่าที่คนทั่วไปคิดมาก

ตอนผมอ่าน PDPA + GDPR รอบแรก ความรู้สึกแรกคือ “กฎหมายนี้น่ากลัวมาก” 555+ ค่าปรับสูงสุด €20 ล้าน หรือ 4% ของ global turnover, นิยามคำว่า data subject กับสิทธิ์ที่ตามมา, deadline 72 ชั่วโมง — ทุกข้อดูเหมือนกับดักรอบตัว ผมต้องอ่านซ้ำหลายรอบกว่าจะเริ่มแยกออกว่าอะไรเป็น โครงสร้าง อะไรเป็น รายละเอียด

จุดที่ผมเริ่มไม่กลัวอีกต่อไปคือตอนเจอคำว่า Privacy Notice ≠ Privacy Policy และ Data Controller ≠ Data Processor ครับ พอแยกคู่นี้ออก กฎหมายที่ดูเหมือน chaos ก็เริ่มจัดตัวเอง — Notice คือเอกสารที่บอกข้างนอก, Policy คือกติกาข้างใน, Controller ตัดสินใจ, Processor ทำตาม จากตรงนี้ค่อยมาเรื่อง consent, withdrawal, transborder ทีละชั้น

อีกเรื่องที่กระทบใจผมคือ ISACA Privacy Principle 9 — Monitoring, Measuring, Reporting — มันบอกว่า privacy ไม่ใช่ checkbox ปีละครั้ง แต่เป็นกิจกรรมต่อเนื่อง ในมุมผม นี่คือเส้นแบ่งระหว่างบริษัทที่ “compliant” กับบริษัทที่ “ปกป้องข้อมูลจริง” — สองอันนี้ไม่เหมือนกันเลย

บันทึกตอนนี้ผมเลยอยากตั้งใจวางโครงให้คนอ่านที่กลัวกฎหมาย privacy เหมือนผมตอนแรก เห็นว่ามันมี mental map ที่อ่านได้

ตอน 17A เราคุย ERM ครอบ risk ทุกประเภท — Risk lifecycle, threat actors, control matrix, risk methods

ตอนนี้ zoom ลงไปที่ risk เฉพาะ ที่ ISACA + regulator ทั่วโลกมองเป็นพิเศษ — Data Privacy

ทำไม Privacy ได้บทแยก ไม่ใช่ subset ของ ERM?

กฎหมายเฉพาะ — PDPA + GDPR + CCPA + กฎเฉพาะวงการ (HIPAA สำหรับวงการสาธารณสุข, GLBA สำหรับการเงิน)
ISACA Privacy Principle 9 (Monitoring, Measuring and Reporting) — กรอบงานที่ยืนเดี่ยวได้
บทลงโทษสูงมาก — GDPR สูงสุด €20 ล้าน หรือ 4% ของ global annual turnover (แล้วแต่อันไหนสูงกว่า) / PDPA สูงสุด 5 ล้านบาท + ค่าเสียหายแก่เอกชน
Data subjects มีสิทธิ์เฉพาะ (access, deletion, portability) ที่ความเสี่ยงประเภทอื่นไม่มี

โครงตอน 17B:

Privacy Program — มากกว่า notice บนหน้าเว็บ
Data Controller vs Data Processor — เส้นที่ GDPR ลาก
Privacy Notice + Consent Mechanism (opt-in/out, withdrawal)
8 Documentation Types ที่ Privacy Program ต้องมี
ISACA Privacy Principle 9 + Privacy Audit
Data Governance + 4 Classification Levels
Section 2.7.2: Legal Purpose, Consent, Legitimate Interest
NIST Privacy Framework (Control-P + Communicate-P)
Transborder Data Flow
Trap Patterns + Close

ส่วนที่ 1: Privacy Program — มากกว่า Notice บนหน้าเว็บ#

ใน ตอน 15 เราคุย PDPA + GDPR ในระดับ law ตอนนี้ลงมาที่ operational program ที่บริษัทต้องสร้างเพื่อปฏิบัติจริง

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

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

นั่นเป็นแค่ส่วนที่ หันหน้าออกข้างนอก ของโปรแกรมใหญ่ที่ต้องครอบคลุม:

People — ใครรับผิดชอบ data privacy (DPO ใน GDPR)
Process — ขั้นตอนรับและตอบ data subject request
Technology — ระบบที่รองรับการลบ ส่งออก และปิดบัง (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

หันหน้าออกข้างนอก — บอกว่าเก็บอะไร ทำไม แชร์กับใคร
เป็น legal accountability — privacy notice ที่บริษัทประกาศออกไป = ผูกพันทางกฎหมาย

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

หันหน้าเข้าข้างใน — กฎและขั้นตอนภายใน
ผูกกับ Information Security Policy hierarchy ที่คุยใน ตอน 15

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

คู่นี้ออกข้อสอบบ่อย + สำคัญสำหรับ GDPR/PDPA compliance ครับ:

Data Controller

บุคคลหรือนิติบุคคลที่ กำหนดวัตถุประสงค์และวิธีการ ในการประมวลผล personal data
เป็นคน “ตัดสินใจ” ว่าทำไมเก็บ และทำยังไงกับข้อมูล
รับผิดชอบทางกฎหมายต่อ data subject และผู้กำกับดูแล (regulator)
ตัวอย่าง: บริษัท e-commerce ที่เก็บข้อมูลลูกค้าเพื่อทำ marketing

Data Processor

บุคคลหรือนิติบุคคลที่ ประมวลผลข้อมูลตามคำสั่งของ controller
ไม่ตัดสินใจเอง แค่ทำตามที่ controller สั่ง
ตัวอย่าง: cloud provider ที่ host ฐานข้อมูลลูกค้า, payment processor ที่จัดการธุรกรรม

ทำไมต้องแยกให้ชัด? เพราะ ความรับผิด (liability) ต่างกัน:

Controller = primary liability — รับผิดชอบโดยตรงต่อ data subjects
Processor = secondary liability — รับผิดเฉพาะส่วนที่ตัวเองทำผิดเงื่อนไขสัญญา

ในมุมสัญญา — Controller-Processor agreement ต้องระบุ:

Purpose limitation — ประมวลผลได้แค่ขอบเขตที่ตกลง
Security requirements — ระดับมาตรการทางเทคนิคและเชิงองค์กร
Sub-processor controls — processor จะใช้ third party ต่อได้มั้ย ภายใต้เงื่อนไขอะไร
Data subject rights handling — ใครรับคำขอ ใครส่งต่อ
Breach notification — กรอบเวลาและผู้รับผิดชอบ

Trap: บริษัทไทยที่ใช้ AWS / Microsoft 365 / Google Workspace — บริษัทคือ controller ส่วน vendor คือ processor บริษัทยังต้องดูแลให้ processor ทำตามกฎหมายผ่านสัญญา ไม่ใช่โยนให้ vendor รับผิดชอบเอง

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

CRM ระบุว่า Privacy Notice ต้องเปิดเผย:

What — เก็บ personal data อะไรบ้าง
Why — เก็บไปทำไม (purpose)
How — เก็บข้อมูลด้วยวิธีไหน
How — ใช้ ประมวลผล แชร์ข้อมูลยังไง
With whom — แชร์กับใคร
What choices — data subjects มีทางเลือกอะไรบ้าง
How — การเก็บข้อมูลอาจกระทบ data subjects ยังไง
Where + how — ทำลายข้อมูลที่ไหน ยังไง (ถ้ามี)

Privacy Notice ที่ดี = ใช้ plain language ไม่ใช่ภาษากฎหมายที่อ่านไม่รู้เรื่อง

วิธีส่ง Notice (5 รูปแบบ)#

CRM ลิสต์ไว้ 5 ทาง:

Web page ที่อุทิศให้กับ privacy โดยเฉพาะ
Forms ที่ขอข้อมูลส่วนบุคคลพร้อมแจ้งเตือน
Brochures (ส่งทางไปรษณีย์ในบางวงการ เช่น healthcare)
Documents ที่อยู่ในสถานที่ (โรงพยาบาล, คลินิก)
Contracts (banking, financial services)
Signs (ป้ายเตือน CCTV) — รูปแบบบางส่วน

ข้อสอบมักดักด้วย: บริษัทใช้ “Terms of Use” รวมกับ Privacy Notice — แนวทางที่ดีคือแยกเป็น 2 เอกสาร เพื่อไม่ให้ privacy ถูกฝังอยู่ใน fine print

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

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

Obtaining consent สำหรับ personal data ที่มีอยู่แล้ว
Revoking consent — มีกลไกให้ถอน consent ได้

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

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

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

Mechanism	ค่าเริ่มต้น	ใช้เมื่อ
Opt-in	ไม่ consent (ต้องกดยอมรับเอง)	ข้อมูลอ่อนไหวสูง — สุขภาพ การเงิน การตลาด
Opt-out	consent (ต้องกดปฏิเสธเอง)	การใช้งานเชิงปฏิบัติที่ความเสี่ยงต่ำ

GDPR และ PDPA เน้น opt-in สำหรับ sensitive data — opt-out ไม่เพียงพอ สำหรับข้อมูลที่ถูกกำกับเข้ม

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

มีกลไกรับ withdrawal request
จัดการคำขอถอนภายในกรอบเวลาที่กฎหมายกำหนด (PDPA = 30 วัน, GDPR = 1 เดือน)
บันทึกการถอน consent
หยุดประมวลผลทันที (ยกเว้นที่กฎหมายอื่นบังคับให้เก็บ เช่น tax records)

Trap: บริษัทที่ “สมัครง่าย ยกเลิกยาก” — privacy notice ที่ไม่มีกลไกการถอน consent ชัดเจน = ผิดกฎหมาย

Informed consent ไม่ใช่เหตุการณ์ครั้งเดียว มันคือ การสื่อสารต่อเนื่อง:

ส่ง update เมื่อแนวปฏิบัติด้าน privacy เปลี่ยน
แจ้ง data subject เมื่อเกิด breach (PDPA และ GDPR บังคับ 72 ชั่วโมง)
รับและตอบคำถามจาก data subject

ส่วนที่ 4: 8 Documentation Types — Privacy Program ต้องมี#

CRM ลิสต์เอกสารที่ Privacy Program ต้องดูแลไว้ ครอบคลุม 8 ประเภทหลัก (ที่ข้อสอบออกในหลายรูปแบบ):

1. Audit Logs#

บันทึกกิจกรรมการบริหาร privacy — แบบ automated หรือ manual:

แหล่งที่มาของการเก็บข้อมูล
วันที่เกิดการประมวลผลหรือแชร์ข้อมูล
จำนวนธุรกรรมหรือ data elements ที่แชร์
ปลายทางของการส่งข้อมูล

2. Data Protection Impact Assessments (DPIA)#

เอกสารระบุข้อบังคับทางกฎหมายที่ใช้กับการดำเนินงาน และทบทวนเป็นระยะ — ใช้กับกิจกรรมที่ความเสี่ยงสูง

3. Data Sheets#

สำหรับ services, applications, networks ที่เก็บหรือจัดการ personal data — ระบุว่าระบบนั้นเก็บข้อมูลอะไร เพื่อวัตถุประสงค์อะไร

4. Privacy Management Process Descriptions#

เอกสารที่อธิบายกระบวนการบริหาร privacy ในรายละเอียดที่:

เข้าใจง่ายสำหรับผู้อ่านวงกว้าง
ผ่านการอนุมัติจากผู้บริหาร
อ้างอิงข้อบังคับทางกฎหมาย (GDPR, CCPA, PDPA)

5. Privacy Impact Assessment (PIA) Reports#

PIA = กระบวนการตรวจสอบว่า personal information ได้รับการ:

ป้องกันอย่างเหมาะสม
ใช้งานตามวัตถุประสงค์
แชร์ตาม consent
เปิดให้ data subjects เข้าถึงได้
ทำลายตามนโยบาย retention

PIA report ระบุข้อค้นพบ มาตรการแก้ไข วันที่คาดว่าจะแล้วเสร็จ และประมาณการค่าใช้จ่าย

6. Privacy Governance Reports#

รายงานที่รวบรวมสถานะการปฏิบัติตามกฎหมาย privacy ทั่วทั้งองค์กร ใช้สำหรับ:

แสดงคุณค่าของโครงสร้าง privacy
เพิ่มความตระหนักของผู้บริหาร
สื่อสารความสำเร็จและสิ่งที่ปรับปรุง
ดึงผู้มีส่วนได้เสียให้มีส่วนร่วม

7. Training Attendance#

บันทึกว่าใครเข้า training events บ้าง:

หัวข้อของ training
ผู้เข้าและวันที่
วิธีการอบรม
ผลการทดสอบ

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

8. Data Incident Register + Individual Rights Register#

Data Incident Register

บันทึกเหตุการณ์ที่กระทบข้อมูล privacy ทั้งหมด
แหล่งที่มาของ breach, ผลกระทบด้านความมั่นคง, มาตรการแก้ไข, มาตรการป้องกัน
ใช้วิเคราะห์แนวโน้มและรายงานต่อผู้กำกับ

Individual Rights Register

บันทึกคำขอจาก data subject (access, deletion, correction, portability)
รับเมื่อไร เสร็จเมื่อไร โดยใคร
ใช้พิสูจน์ว่าทำตามกรอบเวลาที่กฎหมายกำหนด

ส่วนที่ 5: ISACA Privacy Principle 9 + Privacy Audit#

ISACA Privacy Principles เป็นกรอบงาน privacy ของ ISACA ที่มีทั้งหมด 14 หลักการ ครอบคลุมตั้งแต่ accountability, notice, consent, collection limitation ไปจนถึง security safeguards

Principle 9 (ข้อที่ 9 จาก 14) ชื่อ “Monitoring, Measuring and Reporting” — เน้นว่า บริษัทต้องมี การเฝ้าระวัง วัดผล และรายงานอย่างเป็นระบบ ของ privacy program ไม่ใช่แค่ทำเสร็จแล้วลืม

ในตอนนี้ผม zoom เข้า Principle 9 เป็นพิเศษ เพราะเป็นข้อที่บริษัทไทยส่วนใหญ่ตกที่สุด — กฎหมายให้น้ำหนัก privacy notice + consent ส่วนการ monitor + measure ระยะยาว มักถูกข้ามไป

(หลักข้ออื่นใน 14 หลักจะ touch ในตอนอื่นของซีรีส์ตามจังหวะของ Domain — Principle 1-3 governance ใน D2, Principle 4-7 collection/use ใน D5, Principle 11-14 security safeguards ใน D5)

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

CRM ระบุว่า Privacy Audit เป็น องค์ประกอบประจำปี ที่ช่วยให้ปฏิบัติตามกฎ:

วางกรอบงานสำหรับการตรวจสอบ วัดผล และเฝ้าระวัง
ประเมินการปฏิบัติตาม privacy policies, มาตรฐาน, และข้อกฎหมาย
ค่าใช้จ่ายและการนำ privacy tools มาใช้
ความก้าวหน้าของ privacy enhancing technologies
การเปลี่ยนแปลงของกฎหมาย privacy
พื้นที่ความเสี่ยงและ third parties

บทบาทของ IS Auditor ใน Privacy Program#

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

Third-party contracts — มีข้อกำหนดด้าน data privacy หรือไม่
Data retention + destruction — ทำตาม policy หรือไม่
Cross-border regulations — สอดคล้องกับข้อจำกัดเรื่อง data flow หรือไม่
Employee training — เกิดขึ้นจริงและมีหลักฐาน
Data inventory — สร้างและดูแลรักษาอยู่
Data subject requests — จัดการอย่างเหมาะสมภายในกรอบเวลา

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

ส่วนที่ 6: Data Governance + 4 Classification Levels#

Privacy เป็น subset ของ data governance ที่ใหญ่กว่า ทีนี้มาดูภาพใหญ่กัน

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

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

Data classification = แบ่งข้อมูลตามระดับความอ่อนไหว เพื่อใช้ control ที่เหมาะสม

CRM ระบุมาตรฐาน 4 ระดับ (จากต่ำไปสูง):

Level 1: Public#

เข้าถึงได้โดยทุกคน
อ่าน แก้ไข เผยแพร่ต่อได้
ตัวอย่าง: marketing material, press releases, public reports
Control: ขั้นต่ำ

Level 2: Internal Use Only (Sensitive)#

เข้าถึงได้โดยทั่วไปสำหรับพนักงานที่ได้รับอนุญาต
หากรั่วหรือสูญหาย ไม่สร้างความเสี่ยงใหญ่
ตัวอย่าง: สมุดเบอร์โทรพนักงาน, internal policies, internal memos
Control: คุมการเข้าถึงเฉพาะพนักงานทั้งบริษัท

Level 3: Confidential#

ต้องเก็บเป็นความลับ
หากรั่ว อาจกระทบเชิงการแข่งขัน
ตัวอย่าง: ข้อมูลการเงิน, รายชื่อลูกค้า, payment card information, สัญญา, ไฟล์ข้อมูลเต็มสำหรับ testing
Control: role-based access, encryption

Level 4: Restricted#

อ่อนไหวสูงมาก — หากรั่ว อาจนำไปสู่ความผิดทางอาญาและค่าปรับตามกฎหมาย
ตัวอย่าง: proprietary information, R&D, trade secrets, ข้อมูลที่กฎหมายคุ้มครอง
Control: เข้มงวด, encryption, monitoring, audit

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

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

Information Owner = ผู้บริหารฝั่ง business ที่:

รับผิดชอบ information asset
ตัดสินใจ classification ตาม policy
กำหนดกฎการเข้าถึงใน classification ของตัวเอง
ทบทวน classification เป็นประจำ และดูให้ access สอดคล้องกับ policy

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

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

CRM ระบุ:

ความสำคัญ ของ information asset
Information asset custodian (ใครดูแล)
กระบวนการให้สิทธิ์เข้าถึง
กระบวนการและเงื่อนไขในการอนุมัติสิทธิ์ และระดับสิทธิ์
ขอบเขตและความลึกของ security controls

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

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

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

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

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

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

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

CRM 2.7.2 ระบุ 3 legal bases สำหรับการประมวลผล personal data แต่ละ basis มีเงื่อนไขต่างกัน:

Legal Purpose#

Data controller ต้อง:

อธิบายและระบุ purpose อย่างละเอียดใน privacy notice
Purpose ต้องสอดคล้องกับกฎหมายที่ใช้บังคับ
การนำไปใช้ในภายหลังต้องสอดคล้องกับ purpose เดิมและได้ consent มาแล้ว

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

กฎหมายแต่ละฉบับมีเงื่อนไขเฉพาะ:

GDPR — informed, specific, unambiguous, freely given, withdrawable
HIPAA — ต้องมี written authorization สำหรับ protected health information
PDPA — explicit consent และต้องระบุ specific purpose

Privacy engineers ต้องดูแลให้:

มีตัวเลือก consent ที่เหมาะสมและสม่ำเสมอ
ติดตาม consent และการถอน consent ได้
มีวิธีบันทึกการปฏิเสธ (ทั้งดิจิทัลและกระดาษ)

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

Legitimate Interest = legal basis ที่อนุญาตให้ประมวลผล โดยไม่ต้องขอ consent แต่ต้องชั่งน้ำหนักกับสิทธิ์ของ data subject

เงื่อนไข:

มีความสัมพันธ์ที่เหมาะสมระหว่าง data subject กับ controller (client, customer, employee, ฯลฯ)
Data subject คาดหวังได้อย่างสมเหตุสมผล ว่าจะมีการประมวลผลแบบนี้เกิดขึ้น
ผลประโยชน์ของ controller ไม่ลบล้างสิทธิ์ของบุคคล

ตัวอย่าง legitimate interest:

Security cookies ตอน user เข้าเว็บ — เพื่อความปลอดภัยของ session
Public health monitoring — เช่น tracking COVID-19 cases ในพื้นที่หนึ่ง
Fraud prevention — วิเคราะห์รูปแบบธุรกรรม

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

GDPR มักอ้างถึง Legitimate Interest Assessment เป็นเครื่องมือมาตรฐาน ส่วนกฎหมายฉบับอื่นทั่วโลกก็มีเงื่อนไขทำนองเดียวกันให้ใช้ได้

ส่วนที่ 8: NIST Privacy Framework — Control-P + Communicate-P#

NIST Privacy Framework เป็น กรอบงานสมัยใหม่ ที่องค์กรใช้สร้างโครงการบริหาร privacy

2 Privacy-Specific Functions#

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

Control-P (Control of Processing)

พัฒนาและใช้กิจกรรมที่ทำให้:

องค์กรและบุคคลมี ความเข้าใจที่เหมาะสม เกี่ยวกับการประมวลผลข้อมูล
มี บทสนทนา ระหว่างองค์กรกับ data subject เรื่องความเสี่ยงด้าน privacy

หมวดย่อยของ Control-P:

Policies, processes, procedures — ดูแลรักษาและกำกับโดยมี legal review
Data processing standards — ข้อกำหนดที่ระบุขอบเขตของการประมวลผล
Dissociated processing (CT-DP-P) — เพิ่ม dissociability และทำให้ privacy principles ใช้ได้ (เช่น data minimization)

Dissociability — แนวคิดใหม่#

Dissociability = ความสามารถในการ แยกข้อมูลออกจากตัวตนของบุคคล

ตัวอย่าง:

Pseudonymization — แทนชื่อลูกค้าด้วย ID — ยังย้อนกลับมาระบุตัวตนได้ถ้ามี mapping
Anonymization — ลบข้อมูลระบุตัวตนจนย้อนระบุตัวไม่ได้

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

Communicate-P (Communicate-P Purposes)

นโยบายการสื่อสารที่ทำให้:

เพิ่ม transparency ของวิธี process data — บอกชัดว่าเก็บไปทำอะไร เก็บแค่ไหน ใครรับผิดชอบส่วนไหน
ทั้ง data subject และองค์กรเองมี ความเข้าใจที่เชื่อถือได้ เกี่ยวกับวิธี process data จริง
มีกลไกที่รักษา predictability ให้สอดคล้องกับ ecosystem ของการ process data ทั้งหมด

ส่วนที่ 9: Transborder Data Flow#

Transborder Data Flow = การส่งข้อมูลข้ามพรมแดนประเทศ

ช่องทาง:

Email
Web services
Payment services
Submarine cables, โทรศัพท์, wireless, satellites

ทำไม Transborder ถึงเป็นปัญหา#

การโอนข้ามพรมแดนสร้างความยุ่งยากด้าน compliance เพราะ:

ประเทศต้นทางและปลายทาง อาจมีกฎหมาย privacy ต่างกัน
Data security + integrity ระหว่างการส่งอาจไม่เท่ากัน
กฎหมาย privacy ของแต่ละประเทศอาจขัดกันเอง

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

บริษัทไทยใช้ Salesforce (ฐานอยู่ US) → personal data ของลูกค้าไทยถูกส่งไป US → ต้องผ่านกลไกที่ PDPA ยอมรับ (เช่น explicit consent + adequate safeguards)
บริษัทเอเชียใช้ data center ใน EU → GDPR มีผลกับข้อมูลของผู้ที่อยู่ใน EU

Mitigation Mechanisms#

CRM ไม่ลงรายละเอียดของกลไก แต่ที่ข้อสอบรู้:

Standard Contractual Clauses (SCC) — สัญญาที่ GDPR อนุมัติ
Adequacy decisions — ประเทศที่ EU บอกว่า “ระดับกฎหมาย privacy เพียงพอ”
Binding Corporate Rules (BCR) — สำหรับองค์กรข้ามชาติ
Explicit consent — data subject ยอมให้โอน

Internet Communications — Transborder ซ่อนอยู่#

Trap ที่หลายคนตกใจ: บนอินเทอร์เน็ต ตำแหน่งของข้อมูลไม่แน่นอน:

คอมพิวเตอร์ 2 เครื่องในกรุงเทพคุยกัน packet อาจวิ่งผ่าน Singapore และ Tokyo
Cloud service ที่ระบุ “Asia region” อาจมี sub-region อยู่ใน Japan และ Australia
การข้ามพรมแดนเกิดได้ แม้ทั้งสองปลายทางอยู่ในประเทศเดียวกัน

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

ระบบมี data residency controls ที่บังคับตำแหน่งจริงๆ มั้ย
มี logging ของ data flow path มั้ย
กลไกแบบไหนถูกใช้สำหรับการข้ามพรมแดนที่เกิดขึ้น

ส่วนที่ 10: Trap Patterns รวม#

Trap	ความเข้าใจผิด	ความเข้าใจที่ถูก
Privacy = post privacy notice	กฎหมายผ่าน	program ครอบคลุม people/process/tech/training/docs/audit
GDPR ไม่กระทบบริษัทไทย	อยู่ไทยใช้แต่ PDPA	กระทบ ถ้าจัดการ data ของคน EU
Controller = Processor	ใช้แทนกัน	คนละ liability — Controller ตัดสินใจ, Processor ทำตาม
Opt-out = sufficient consent	”default OK”	Sensitive data ต้อง opt-in
Anonymized = no longer personal data	”ลบชื่อแล้วจบ”	ถ้า re-identify ได้ — ยังเป็น personal data
Legitimate interest = blank check	”อ้างได้ตลอด”	ต้องผ่าน 3-part balancing test + documented
Privacy training = ไม่ต้อง record	”พนักงานรู้แล้ว”	ต้องมี training records พิสูจน์ได้
Personal info inventory = one-time	สร้างครั้งเดียวเก็บไว้	living document — update ตามระบบเปลี่ยน
IT classify data	technical decision	Information Owner (business) classify, ไม่ใช่ IT
Developer ใช้ production data debug	”เร่งด่วน OK ครั้งเดียว”	masked data ใน test env เท่านั้น
Internet 2 endpoints ในประเทศเดียวกัน = no transborder	”ไม่ได้ส่งข้ามประเทศ”	Packet routing อาจข้ามได้โดยไม่รู้ตัว
Privacy audit = annual checkbox	”ทำให้ผ่าน compliance”	ISACA Principle 9 = ongoing monitoring + measuring + reporting

ปิดบท: Privacy + Data Governance Mental Map#

ตอน 17B เน้นที่ risk เฉพาะของ data:

1
[ Privacy Program (Section 2.6) ]
2
   ├── Privacy Notice (external) + Privacy Policy (internal)
3
   ├── Data Controller vs Data Processor
4
   ├── Consent Mechanism (opt-in/out + withdrawal)
5
   ├── 7+1 Documentation Types
6
   └── ISACA Principle 9: Monitoring, Measuring, Reporting
7

8
[ Data Governance + Classification (Section 2.7) ]
9
   ├── 4 Classification Levels (Public → Internal → Confidential → Restricted)
10
   ├── Information Owner vs Custodian (recall จาก 16B)
11
   ├── 3 Legal Bases: Legal Purpose / Consent / Legitimate Interest (2.7.2)
12
   ├── NIST Privacy Framework (Control-P + Communicate-P)
13
   ├── Dissociability (pseudonymization vs anonymization)
14
   └── Transborder Data Flow + mitigation mechanisms

รวม 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

สิ่งที่ผมเก็บได้จากบทนี้#

ในมุมผม Section 2.6 + 2.7 สอนเรื่องที่ลึกกว่ากฎหมายเยอะ — มันสอน วิธีคิดว่า data เป็นทรัพย์สินที่มี lifecycle และมีเจ้าของ ครับ “Information Owner ≠ IT” คือประโยคที่ผมจดตัวโตที่สุดในบทนี้ เพราะมันเปลี่ยนกรอบความคิดของผมเรื่องการจัดการข้อมูลทั้งหมด — IT เป็นแค่ custodian, business เป็นคนตัดสินว่า classify ระดับไหน access ใครได้ ถ้าผิดที่ ปัญหาตามมาทั้งสาย

ที่ผมคิดว่าจะติดอยู่ในใจไปนานคือ scenario ของ developer ขอ production data ไป debug ครับ มันเป็นสถานการณ์ที่ฟังดูสมเหตุสมผลทุกบรรทัด — “เร่งด่วน, แก้ปัญหา customer, IT manager อนุมัติแล้ว” — แต่ในมุม audit ผิด 2 ชั้นเลย SoD violation + authorization violation บริษัทที่ปกป้องข้อมูลจริงๆ จะเตรียม masked data ใน test environment ไว้พร้อมก่อนสถานการณ์แบบนี้เกิด ไม่ใช่ตัดสินใจตอนกำลังไฟไหม้

อีกประโยคที่ผมอยากจำคือเรื่อง anonymization ที่ re-identify ได้ = ยังเป็น personal data หลายบริษัทคิดว่า “ลบชื่อแล้วจบ” จริงๆ ยังไม่จบ ถ้าจับคู่กับ data set อื่นแล้วระบุตัวบุคคลได้ ก็ยังเป็น personal data ตามกฎหมาย ตรงนี้ subtle มาก และผมเชื่อว่า exam จะออก

สิ่งที่ผมจดสำหรับวันสอบสรุปคือ — Privacy Notice (external) ≠ Privacy Policy (internal); Controller (ตัดสินใจ) ≠ Processor (ทำตาม); Opt-in สำหรับ sensitive data; Information Owner = business ไม่ใช่ IT; ทุกข้อความ “ลบชื่อแล้วจบ” ตอบผิดเสมอ ห้าอันนี้ครอบ trap ส่วนใหญ่ของบท

ตอน 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)