ภาคผนวกและแบบฟอร์มปฏิบัติการ

ชื่อ-นามสกุล

_____________________________

บทบาท / ตำแหน่ง

_____________________________

วันที่ปฐมนิเทศ

_____________________________

ลายเซ็น

_____________________________

คำประกาศ

ข้าพเจ้าขอประกาศว่า:

• ได้รับ อ่าน และเข้าใจประมวลจริยธรรมของ NexStudio ฉบับปัจจุบันแล้ว
• สัญญาว่าจะเคารพหลักการ กฎการประพฤติ และขั้นตอนที่กำหนดไว้
• ได้รับหรือจะได้รับตามแผนการฝึกอบรม ซึ่งการฝึกอบรมบังคับเกี่ยวกับความปลอดภัยสารสนเทศ ความเป็นส่วนตัว (PDPA และ GDPR) การจัดการข้อมูลอ่อนไหว การใช้ AI อย่างรับผิดชอบ และแนวปฏิบัติการเขียนโค้ดอย่างปลอดภัย
• สัญญาว่าจะรายงานโดยสุจริตผ่านช่องทางที่กำหนด การละเมิดประมวลใดๆ ที่ข้าพเจ้าทราบ
• ทราบว่าการละเมิดประมวลอาจนำไปสู่มาตรการทางวินัยตามสัดส่วน รวมถึงการสิ้นสุดความสัมพันธ์ตามสัญญา
• ยอมรับให้คำประกาศนี้เก็บในแฟ้มบุคลากรและใช้เพื่อการกำกับดูแลองค์กร

1. คำนิยามข้อมูลที่เป็นความลับ

• "ข้อมูลที่เป็นความลับ" หมายถึง ข้อมูล เอกสาร ความรู้ รหัสต้นฉบับ ข้อกำหนดทางเทคนิค กลยุทธ์ทางการค้า ข้อมูลส่วนบุคคลหรือข้อมูลอ่อนไหว การสื่อสารหรือวัสดุใดๆ — ในรูปแบบใดก็ตาม (ลายลักษณ์อักษร วาจา อิเล็กทรอนิกส์ ภาพ) — ที่ฝ่ายหนึ่ง ("ฝ่ายเปิดเผย") สื่อสารกับอีกฝ่าย ("ฝ่ายรับ") ที่เกี่ยวข้องกับวัตถุประสงค์ของความสัมพันธ์ โดยไม่คำนึงว่าจะระบุว่าเป็นความลับอย่างชัดแจ้งหรือไม่
• ข้อมูลที่เป็นความลับยังรวมถึงข้อมูลส่วนบุคคลที่ประมวลผลในนามของผู้ควบคุม ข้อมูลเกี่ยวกับผู้ป่วย ลูกค้า และผู้รับการดูแล (สำหรับขอบเขต Legal Tech และ Health Tech) บันทึกระบบ ข้อมูลประจำตัว และผลการทดสอบและการตรวจสอบ

2. หน้าที่ของฝ่ายรับ

• ใช้ข้อมูลที่เป็นความลับเฉพาะเพื่อวัตถุประสงค์ที่ตกลงกันและเพื่อการปฏิบัติตามความสัมพันธ์ตามสัญญาเท่านั้น
• ไม่เปิดเผย คัดลอก ทำซ้ำ หรือแจกจ่ายข้อมูลที่เป็นความลับแก่บุคคลภายนอกโดยไม่ได้รับอนุญาตเป็นลายลักษณ์อักษรล่วงหน้าจากฝ่ายเปิดเผย
• จำกัดการเข้าถึงข้อมูลที่เป็นความลับเฉพาะบุคคลที่ได้รับอนุญาตที่มีความจำเป็นต้องรู้และผูกพันตามหน้าที่การรักษาความลับอย่างน้อยเทียบเท่า
• ใช้มาตรการความปลอดภัยทางเทคนิคและองค์กรที่เพียงพอเพื่อป้องกันข้อมูลที่เป็นความลับจากการเข้าถึงโดยไม่ได้รับอนุญาต การสูญหาย การโจรกรรม หรือการเปิดเผย
• ในกรณีการมอบช่วง (sub-processing) ขออนุญาตเป็นลายลักษณ์อักษรล่วงหน้าและกำหนดหน้าที่ตามสัญญาเทียบเท่าแก่ผู้ประมวลผลช่วง

3. ข้อยกเว้น

• ข้อมูลที่เป็นสาธารณสมบัติอยู่แล้วโดยไม่ละเมิดข้อตกลงนี้
• ข้อมูลที่ฝ่ายรับครอบครองอยู่แล้วก่อนการเปิดเผย ตามที่บันทึกไว้
• ข้อมูลที่ได้รับโดยชอบจากบุคคลภายนอกโดยไม่มีหน้าที่รักษาความลับ
• ข้อมูลที่ฝ่ายรับต้องเปิดเผยตามกฎหมายหรือคำสั่งเจ้าหน้าที่ (โดยแจ้งฝ่ายเปิดเผยล่วงหน้าเมื่อทำได้)

4. การแจ้งเมื่อเกิดการละเมิด (Breach Notification)

• ฝ่ายรับต้องแจ้งฝ่ายเปิดเผยถึงการเข้าถึงโดยไม่ได้รับอนุญาต การสูญหาย หรือการเปิดเผยข้อมูลที่เป็นความลับ ภายใน 24 ชั่วโมงนับแต่พบ โดยระบุ: คำอธิบายเหตุการณ์ ข้อมูลและหมวดหมู่ข้อมูลที่เกี่ยวข้อง มาตรการที่ดำเนินการหรือเสนอเพื่อบรรเทาผลกระทบ จุดติดต่อสำหรับข้อมูล

5. ระยะเวลาและการคืน

• หน้าที่รักษาความลับมีผลตลอดระยะเวลาความสัมพันธ์และ 5 ปีหลังจากสิ้นสุด เว้นแต่มีหน้าที่ตามกฎหมายที่ยาวกว่า
• เมื่อสิ้นสุดความสัมพันธ์ ฝ่ายรับต้องคืนหรือทำลายข้อมูลที่เป็นความลับทั้งหมด โดยให้หนังสือรับรอง

6. มาตรการความปลอดภัยเทียบเท่า

• การเข้ารหัสขณะพักและขณะส่งด้วยอัลกอริทึมที่ทันสมัย (ขั้นต่ำ AES-256, TLS 1.3)
• การควบคุมการเข้าถึงด้วยหลักสิทธิ์น้อยที่สุดและ MFA บังคับ
• บันทึกที่แก้ไขไม่ได้สำหรับการเข้าถึงข้อมูลอ่อนไหว
• ขั้นตอนจัดการเหตุการณ์ที่บันทึกไว้
• การฝึกอบรมพนักงานเกี่ยวกับความปลอดภัยและความเป็นส่วนตัว

7. กฎหมายที่ใช้บังคับและเขตอำนาจศาล

• กฎหมายไทย โดยอาจอ้างถึงข้อ GDPR/PDPA สำหรับการประมวลผลข้อมูลส่วนบุคคล ศาลที่มีเขตอำนาจ: กรุงเทพฯ ประเทศไทย เว้นแต่ตกลงเป็นลายลักษณ์อักษรเป็นอย่างอื่น

ความปลอดภัย

Code review เสร็จสิ้นและอนุมัติแล้ว

[ ]

การทดสอบอัตโนมัติผ่าน (CI สีเขียว)

[ ]

การวิเคราะห์โค้ดแบบคงที่ (SAST) ไม่มีช่องโหว่ระดับวิกฤตหรือสูง

[ ]

การสแกนการพึ่งพา (SCA) ไม่มีช่องโหว่ที่ทราบด้วย CVSS ≥ 7

[ ]

Penetration test หรือสแกนแบบพลวัต (DAST) ทำบน build ก่อนปล่อย

[ ]

ไม่มีข้อมูลประจำตัว โทเค็น หรือความลับที่ฝังในโค้ด

[ ]

HTTP security headers ตั้งค่าแล้ว (HSTS, CSP, X-Frame-Options, ฯลฯ)

[ ]

CORS ตั้งค่าถูกต้อง (ไม่มี wildcard บน origin ที่อ่อนไหว)

[ ]

Rate limiting ทำงานบน endpoint สาธารณะ

[ ]

การพึ่งพาอัปเดตเป็นเวอร์ชันเสถียรล่าสุด (หรือแพตช์ความปลอดภัยใช้แล้ว)

[ ]

ความเป็นส่วนตัวและข้อมูล

ไม่มีข้อมูลส่วนบุคคลจริงในสภาพแวดล้อมทดสอบ (เฉพาะข้อมูลสังเคราะห์/ไม่ระบุตัวตน)

[ ]

การเข้ารหัสขณะพักเปิดใช้สำหรับข้อมูลอ่อนไหวทั้งหมด

[ ]

การเข้ารหัสขณะส่ง (TLS 1.3) ทำงานบนทุก endpoint

[ ]

บันทึกไม่มีข้อมูลส่วนบุคคลหรือข้อมูลอ่อนไหวในรูปแบบข้อความธรรมดา

[ ]

กลไกความยินยอมตรวจสอบได้และบันทึกไว้ (ถ้ามี)

[ ]

ขั้นตอนการลบ/สิทธิในการลบ ทดสอบแล้วและทำงาน

[ ]

นโยบายการเก็บรักษานำไปใช้และตรวจสอบแล้ว

[ ]

DPIA อัปเดตสำหรับการประมวลผลที่เกี่ยวข้องในการปล่อยนี้

[ ]

ปฏิบัติการ

แผน rollback บันทึกและทดสอบแล้ว

[ ]

Changelog จัดทำพร้อมผลกระทบที่ทราบ

[ ]

แจ้งผู้มีส่วนได้ส่วนเสียภายใน (สนับสนุน ความปลอดภัย DPO)

[ ]

การติดตามและ alerting ตั้งค่าสำหรับฟีเจอร์ใหม่

[ ]

ลายเซ็น: ผู้พัฒนา _______   ผู้ตรวจสอบ _______   CISO/DPO _______   วันที่ _______

แผนภูมิ: ขั้นตอนการจัดการเหตุการณ์

• 1. การตรวจจับ — เหตุการณ์ถูกตรวจพบโดย: ระบบติดตามอัตโนมัติ, การรายงานภายใน, bug bounty/ผู้รายงานภายนอก, การแจ้งจากผู้ให้บริการหรือพันธมิตร
• 2. การคัดแยกและจำแนกประเภท (สูงสุด 1 ชั่วโมง) — ทีมความปลอดภัยประเมิน: ประเภทเหตุการณ์ (การละเมิดข้อมูล, การเข้าถึงโดยไม่ได้รับอนุญาต, มัลแวร์, DDoS, ฯลฯ), ความรุนแรง (ต่ำ/กลาง/สูง/วิกฤต), ขอบเขตที่เกี่ยวข้อง (แพลตฟอร์ม, Legal Tech, Health Tech), ข้อมูลที่เกี่ยวข้อง (ส่วนบุคคล, อ่อนไหว, สุขภาพ, กฎหมาย)
• 3. การกักกัน (ทันที) — แยกระบบที่ถูกบุกรุก, ยกเลิกข้อมูลประจำตัวหรือโทเค็นที่เปิดเผย, บล็อก IP หรือบัญชีที่เป็นอันตราย, เรียกทีมตอบสนองที่กำหนด
• 4. การกำจัด — ลบสาเหตุต้นตอ (แพตช์, กำหนดค่าใหม่, กำจัดมัลแวร์), ตรวจสอบว่าไม่มี backdoor หรือการคงอยู่, บันทึกการดำเนินการ
• 5. การกู้คืน — กู้คืนระบบจาก backup ที่สะอาด, ใช้แพตช์และการบรรเทา, ตรวจสอบการทำงานในสภาพแวดล้อมแยกก่อนกลับสู่ production
• 6. การแจ้ง — ภายใน 72 ชั่วโมงนับแต่พบ: แจ้ง DPO และ Legal & Compliance; หากเป็นการละเมิดข้อมูลส่วนบุคคล ประเมินหน้าที่แจ้งหน่วยงาน (PDPA/GDPR) และเจ้าของข้อมูล ใช้เทมเพลตการแจ้ง (ดูด้านล่าง)
• 7. POST-MORTEM (ภายใน 5 วันทำการ) — วิเคราะห์สาเหตุต้นตอ, บทเรียนที่ได้รับ, อัปเดต playbook และการควบคุมความปลอดภัย, การสื่อสารภายใน (ไม่ตำหนิ)

เทมเพลตการแจ้งเหตุการณ์

ส่งภายใน และหากจำเป็น ภายนอก

รหัสเหตุการณ์

INC-YYYY-NNN

วันที่และเวลาที่ตรวจพบ

_____________________

วันที่และเวลาที่กักกัน

_____________________

ความรุนแรง

[ ] ต่ำ [ ] กลาง [ ] สูง [ ] วิกฤต

ประเภท

[ ] การละเมิดข้อมูล [ ] การเข้าถึงโดยไม่ได้รับอนุญาต [ ] มัลแวร์ [ ] DDoS [ ] อื่นๆ: ___

ขอบเขต

[ ] แพลตฟอร์ม [ ] Legal Tech / LexAura [ ] Health Tech / MediAura

ระบบที่เกี่ยวข้อง

_____________________

ข้อมูลที่เกี่ยวข้อง

หมวดหมู่: ___ จำนวนเจ้าของข้อมูลโดยประมาณ: ___

คำอธิบาย

_____________________

การดำเนินการ

_____________________

มาตรการสำหรับเจ้าของข้อมูล

_____________________

จุดติดต่อ

ชื่อ: ___ อีเมล: ___ โทรศัพท์: ___

ผู้จัดทำ

_____________________

แบบ DPIA — ส่วนที่จำเป็น

1. ชื่อการประมวลผล

คำอธิบายย่อของการประมวลผลที่ประเมิน

2. ผู้ควบคุมและผู้ประมวลผล

ผู้ควบคุม: ___ ผู้ประมวลผล: ___ ผู้ประมวลผลช่วง: ___ DPO: ___

3. วัตถุประสงค์การประมวลผล

อธิบายว่าทำไมข้อมูลถูกประมวลผล ฐานทางกฎหมาย และความจำเป็น

4. หมวดหมู่ข้อมูล

[ ] ส่วนบุคคลทั่วไป [ ] หมวดหมู่พิเศษ (สุขภาพ กฎหมาย ชีวมิติ) [ ] อาญา

5. หมวดหมู่เจ้าของข้อมูล

[ ] ผู้ป่วย [ ] ลูกค้าสำนักงาน [ ] พนักงาน [ ] ผู้ใช้แพลตฟอร์ม [ ] อื่นๆ: ___

6. การดำเนินการประมวลผล

การเก็บรวบรวม การบันทึก การจัดระเบียบ การจัดเก็บ การปรึกษา การเปิดเผย การลบ ฯลฯ

7. เทคโนโลยีที่ใช้

ฐานข้อมูล คลาวด์ API AI/ML ฯลฯ

8. การประเมินความเสี่ยง

ความน่าจะเป็น × ผลกระทบ สำหรับแต่ละความเสี่ยงที่ระบุ มาตรการบรรเทาที่วางแผนไว้

9. มาตรการความปลอดภัย

การเข้ารหัส การควบคุมการเข้าถึง การบันทึก การสำรองข้อมูล ฯลฯ

10. การปรึกษา DPO

ความเห็น DPO: ___ วันที่: ___

11. การตัดสินใจสุดท้าย

[ ] ความเสี่ยงยอมรับได้ [ ] ความเสี่ยงบรรเทาแล้ว [ ] ต้องปรึกษาหน่วยงาน [ ] ไม่ควรเริ่มการประมวลผล

12. วันที่และลายเซ็น

ผู้จัดทำ: ___ DPO: ___ ผู้ควบคุม: ___

ตัวอย่างที่กรอกแล้ว — MediAura: การจัดการข้อมูลคลินิกบนคลาวด์

1. ชื่อ

การจัดการและจัดเก็บข้อมูลคลินิกผู้ป่วยบนแพลตฟอร์ม MediAura (คลาวด์ กรุงเทพฯ)

2. ผู้ควบคุมและผู้ประมวลผล

ผู้ควบคุม: คลินิก/สถานพยาบาลที่สมัครสมาชิก ผู้ประมวลผล: NexStudio ผู้ประมวลผลช่วง: ผู้ให้บริการคลาวด์รับรอง ISO 27001

3. วัตถุประสงค์

จัดเก็บและปรึกษาข้อมูลคลินิกเพื่อสนับสนุนการประกอบวิชาชีพเวชกรรม ฐานทางกฎหมาย: การปฏิบัติตามสัญญาและความยินยอมผู้ป่วย (ประกาศลงนามแล้ว)

4. หมวดหมู่ข้อมูล

หมวดหมู่พิเศษ: ข้อมูลสุขภาพ (การวินิจฉัย ใบสั่งยา รายงาน) ส่วนบุคคลทั่วไป: ข้อมูลประจำตัว การติดต่อ

5. เจ้าของข้อมูล

ผู้ป่วย (ผู้ใหญ่และผู้เยาว์ผ่านผู้ปกครอง)

6. การดำเนินการ

การเก็บรวบรวม การบันทึก การจัดระเบียบ การจัดเก็บ การปรึกษาโดยเจ้าหน้าที่ที่ได้รับอนุญาต การลบตามคำขอ

7. เทคโนโลยี

ฐานข้อมูลเข้ารหัส (AES-256) REST API พร้อม TLS 1.3 AI สำหรับข้อเสนอแนะทางคลินิก (ต้องมีมนุษย์กำกับ)

8. ความเสี่ยง

การเข้าถึงข้อมูลสุขภาพโดยไม่ได้รับอนุญาต (ความน่าจะเป็นต่ำ ผลกระทบสูง → บรรเทาด้วย MFA การเข้ารหัส และ audit log) การสูญหายข้อมูล (ความน่าจะเป็นต่ำ ผลกระทบวิกฤต → บรรเทาด้วย backup รายวัน disaster recovery ที่ทดสอบแล้ว)

9. มาตรการความปลอดภัย

การเข้ารหัสขณะพัก AES-256 และขณะส่ง TLS 1.3 MFA บังคับ บันทึกที่แก้ไขไม่ได้ backup อัตโนมัติรายวัน ทดสอบกู้คืนรายไตรมาส

10. DPO

ความเห็นชอบ พร้อมคำแนะนำให้ตรวจสอบประจำปี

11. การตัดสินใจ

ความเสี่ยงบรรเทาแล้ว — อนุมัติการประมวลผลพร้อมทบทวนประจำปี

ประกาศการประมวลผลข้อมูลส่วนบุคคล

ตาม PDPA (ประเทศไทย) และ GDPR (EU) เมื่อใช้บังคับ

ผู้ควบคุมข้อมูล

[ชื่อสำนักงาน/องค์กร] ที่อยู่ [ที่อยู่] อีเมล: [___] โทรศัพท์: [___]

ผู้ประมวลผลข้อมูล (ผู้ให้บริการแพลตฟอร์ม)

NexStudio กรุงเทพฯ ประเทศไทย อีเมล: privacy@nexstudio.com

วัตถุประสงค์การประมวลผล

การจัดการบริการ [กฎหมาย/สุขภาพ] การจัดเก็บเอกสาร การสื่อสารเกี่ยวกับบริการ หน้าที่ตามกฎหมาย

ฐานทางกฎหมาย

[ความยินยอมเจ้าของข้อมูล / การปฏิบัติตามสัญญา / หน้าที่ตามกฎหมาย / ประโยชน์อันชอบธรรม]

หมวดหมู่ข้อมูล

ข้อมูลประจำตัวและการติดต่อ ข้อมูลเกี่ยวกับการปฏิบัติ [กฎหมาย/สุขภาพ] [หากสุขภาพ: ข้อมูลสุขภาพตามมาตรา 9 GDPR / PDPA]

ระยะเวลาเก็บรักษา

[X ปี] จากสิ้นสุดความสัมพันธ์ หรือตามนโยบายการเก็บรักษา

ผู้รับข้อมูล

เจ้าหน้าที่ผู้ควบคุมที่ได้รับอนุญาต NexStudio (ผู้ประมวลผลข้อมูล) ผู้ให้บริการคลาวด์ (ผู้ประมวลผลช่วงพร้อมหลักประกันตามสัญญา) หน่วยงานของรัฐ หากกฎหมายกำหนด

การโอนระหว่างประเทศ

[อธิบายว่าข้อมูลถูกโอนนอกประเทศไทย/EU หรือไม่ และบนฐานทางกฎหมายใด]

สิทธิเจ้าของข้อมูล

การเข้าถึง การแก้ไข การลบ การจำกัด การโอนย้าย การคัดค้าน การถอนความยินยอม เพื่อใช้สิทธิ ติดต่อผู้ควบคุมตามที่อยู่ข้างต้น

ข้อร้องเรียน

เจ้าของข้อมูลมีสิทธิร้องเรียนต่อหน่วยงานควบคุมที่เกี่ยวข้อง (PDPC ในประเทศไทย / หน่วยงานคุ้มครองข้อมูลใน EU)

แบบความยินยอม

ให้เจ้าของข้อมูลกรอกและลงนาม

• ข้าพเจ้า _____________________ เกิดวันที่ ____________
• ขอประกาศว่าได้รับและอ่านประกาศการประมวลผลข้อมูลส่วนบุคคลแล้ว
• [ ] ยินยอมให้ประมวลผลข้อมูลส่วนบุคคลเพื่อวัตถุประสงค์ที่ระบุในประกาศ
• [ ] ยินยอมให้ประมวลผลข้อมูลหมวดหมู่พิเศษ (เช่น ข้อมูลสุขภาพ / ข้อมูลกฎหมาย) เพื่อวัตถุประสงค์ที่ระบุ
• [ ] ยินยอมให้เปิดเผยข้อมูลแก่บุคคลที่ระบุในประกาศ
• วันที่: ____________   ลายเซ็น: _____________________

คำแนะนำ

กรอกสำหรับแต่ละส่วนประกอบ open source หรือบุคคลที่สามที่ใช้ในผลิตภัณฑ์ อัปเดตทุกครั้งที่ปล่อย

• สร้างอัตโนมัติด้วยเครื่องมือเช่น: CycloneDX, SPDX, Syft, Trivy, OWASP Dependency-Track
• รูปแบบที่แนะนำคือ CycloneDX JSON หรือ SPDX tag-value
• ด้านล่างเป็นเทมเพลตรูปแบบตารางสำหรับการตรวจสอบด้วยตนเอง

รายการส่วนประกอบ

ชื่อส่วนประกอบ

เวอร์ชัน | ใบอนุญาต | ประเภทใบอนุญาต (copyleft/permissive) | ผู้ให้บริการ/URL | การใช้งานในผลิตภัณฑ์ | ช่องโหว่ที่ทราบ (CVE) | คะแนน CVSS | วันที่อัปเดตล่าสุด

ตัวอย่างแถวแรก: React | 18.3.1 | MIT | Permissive | https://react.dev | Frontend UI | ไม่มี | N/A | 2026-04-01

สรุป

ส่วนประกอบทั้งหมด

___

ส่วนประกอบที่มีใบอนุญาต copyleft

___ (ตรวจสอบความเข้ากันได้)

ส่วนประกอบที่มีช่องโหว่ที่ทราบ

___ (รายละเอียดด้านบน)

ส่วนประกอบที่ไม่มีใบอนุญาตระบุ

___ (ต้องตรวจสอบ)

วันที่สร้าง SBOM

____________

สร้างโดย

[ชื่อ] — [บทบาท]

หลักการทั่วไป

• ข้อมูลส่วนบุคคลถูกเก็บรักษาเฉพาะเวลาที่จำเป็นเพื่อบรรลุวัตถุประสงค์ที่เก็บรวบรวม
• เมื่อสิ้นสุดระยะเวลาเก็บรักษา ข้อมูลจะถูกทำให้ไม่ระบุตัวตนหรือลบอย่างปลอดภัยและไม่สามารถกู้คืนได้
• ระยะเวลาเก็บรักษาถูกบันทึก มีเหตุผล และแจ้งเจ้าของข้อมูลในประกาศความเป็นส่วนตัว
• นโยบายนี้ต้องทบทวนอย่างน้อยปีละครั้งหรือเมื่อมีการเปลี่ยนแปลงกฎระเบียบ

ตารางระยะเวลาเก็บรักษา

ข้อมูลประจำตัวและการติดต่อ

ระยะเวลา: 10 ปีจากสิ้นสุดความสัมพันธ์ (หน้าที่ทางภาษีและกฎหมาย) เหตุผล: กฎหมายภาษีไทย การลบ: ทำให้ไม่ระบุตัวตนเมื่อครบกำหนด

ข้อมูลสุขภาพ (MediAura / Health Tech)

ระยะเวลา: ระยะเวลาความสัมพันธ์ + 10 ปี (หรือตามกฎระเบียบท้องถิ่นที่ใช้) เหตุผล: กฎระเบียบสุขภาพ การฟ้องร้อง ความต้องการทางคลินิก การลบ: ทำลายอย่างปลอดภัยพร้อมใบรับรอง

ข้อมูลกฎหมาย / แฟ้มคดี (LexAura / Legal Tech)

ระยะเวลา: ระยะเวลาความสัมพันธ์ + 10 ปี เหตุผล: หน้าที่จรรยาบรรณกฎหมาย อายุความ การฟ้องร้อง การลบ: หลังตรวจสอบกับผู้ควบคุมสำนักงาน

บันทึกการเข้าถึงและ audit trail

ระยะเวลา: 2 ปี เหตุผล: ความปลอดภัย การสอบสวน การปฏิบัติตามกฎ การลบ: หมุนเวียนอัตโนมัติ

ข้อมูลการเรียกเก็บเงิน

ระยะเวลา: 10 ปี เหตุผล: หน้าที่ทางภาษีและบัญชี การลบ: ทำให้ไม่ระบุตัวตนเมื่อครบกำหนด

ข้อมูลผู้สมัครที่ไม่ได้รับการว่าจ้าง

ระยะเวลา: 12 เดือนจากการสมัคร เหตุผล: โอกาสในอนาคตที่เป็นไปได้ (ด้วยความยินยอม) การลบ: ทำลายเมื่อครบกำหนด

คุกกี้และข้อมูลติดตาม

ระยะเวลา: ตามนโยบายคุกกี้ (สูงสุด 12 เดือน) เหตุผล: การวิเคราะห์และฟังก์ชันเว็บไซต์ การลบ: หมดอายุอัตโนมัติหรือตามคำขอ

Backup

ระยะเวลา: 30 วัน (backup ปฏิบัติการ) 12 เดือน (backup ประวัติ) เหตุผล: disaster recovery และความต่อเนื่องทางธุรกิจ การลบ: หมุนเวียนอัตโนมัติ ข้อมูลส่วนบุคคลใน backup อยู่ภายใต้ระยะเวลาเก็บรักษาเดียวกันและถูกลบจาก backup ที่ใช้งานเมื่อครบกำหนด

วิธีการลบ

• การลบตรรกะ: ข้อมูลถูกทำให้ไม่สามารถเข้าถึงได้โดยผู้ใช้ แต่เก็บในพื้นที่แยกสำหรับระยะเวลาเก็บรักษา
• การลบกายภาพ: เมื่อสิ้นสุดระยะเวลาเก็บรักษา ข้อมูลถูกเขียนทับหรือทำลายอย่างไม่สามารถกู้คืนได้ (crypto-shredding, degaussing, การทำลายกายภาพสำหรับสื่อ)
• การทำให้ไม่ระบุตัวตน: ข้อมูลถูกแปลงอย่างไม่สามารถกู้คืนได้เป็นรูปแบบนิรนาม ไม่สามารถระบุเจ้าของข้อมูลได้
• สำหรับการลบแต่ละครั้ง มีการจัดทำหลักฐานเอกสาร (บันทึก ใบรับรอง)

ข้อมูลทั่วไป

ชื่อระบบ/โมเดล

_____________________

เวอร์ชัน

_____________________

ขอบเขต

[ ] แพลตฟอร์ม [ ] Legal Tech / LexAura [ ] Health Tech / MediAura

ผู้รับผิดชอบทางเทคนิค

_____________________

วันที่ประเมิน

_____________________

1. คำอธิบายระบบ AI

• อธิบายวัตถุประสงค์ของระบบ ฟังก์ชัน ผู้ใช้เป้าหมาย และบริบทการใช้งาน ระบุว่าระบบตัดสินใจอัตโนมัติหรือให้คำแนะนำโดยมีมนุษย์กำกับ

2. ชุดข้อมูลและแหล่งที่มา

แหล่งข้อมูล training

[ ] ข้อมูลภายใน [ ] ข้อมูลสาธารณะ [ ] ข้อมูลบุคคลที่สาม [ ] ข้อมูลสังเคราะห์

ปริมาณและลักษณะ

จำนวน record: ___ Features: ___ ความสมดุลคลาส: ___

คุณภาพและข้อจำกัดที่ทราบ

อธิบาย bias ที่ทราบ ข้อมูลขาด เสียงรบกวน คุณภาพการติดป้าย

การเตรียมข้อมูลล่วงหน้า

อธิบายการทำความสะอาด การทำให้เป็นมาตรฐาน feature engineering

การปฏิบัติตามความเป็นส่วนตัว

[ ] ข้อมูลไม่ระบุตัวตน [ ] ได้รับความยินยอม [ ] DPIA ดำเนินการแล้ว [ ] ฐานทางกฎหมายบันทึกไว้

3. การประเมินอคติ (Bias assessment)

• อธิบายการวิเคราะห์ที่ดำเนินการเพื่อระบุและบรรเทาอคติ (ประชากร วัฒนธรรม เพศ ชาติพันธุ์ ฯลฯ)
• ระบุเมตริก fairness ที่ใช้และผลลัพธ์
• [object Object]
• [object Object]
• [object Object]

4. การกำกับโดยมนุษย์

ระดับอัตโนมัติ

[ ] อัตโนมัติเต็ม [ ] Human-in-the-loop [ ] Human-on-the-loop [ ] คำแนะนำเท่านั้น

กลไกการ override

ผู้ใช้สามารถลบล้างการตัดสินใจของระบบได้อย่างไร?

คำเตือนและข้อจำกัด

คำเตือนใดที่แสดงแก่ผู้ใช้เกี่ยวกับข้อจำกัดของระบบ?

5. ความสามารถอธิบายและความโปร่งใส

วิธี explainability

[ ] SHAP [ ] LIME [ ] Feature importance [ ] Attention maps [ ] อื่นๆ: ___

เอกสารสำหรับผู้ใช้

อธิบายว่าการตัดสินใจถูกอธิบายแก่ผู้ใช้ปลายทางอย่างไร

ข้อจำกัดที่สื่อสาร

ข้อจำกัด ความแม่นยำ และขอบความผิดพลาดถูกสื่อสารอย่างไร?

6. การติดตามหลังปล่อย

เมตริกที่ติดตาม

ความแม่นยำ precision recall F1 drift detection fairness metrics ความหน่วง

ความถี่การติดตาม

[ ] ต่อเนื่อง [ ] รายวัน [ ] รายสัปดาห์ [ ] รายเดือน

Alerting

กำหนดเกณฑ์แจ้งเตือนสำหรับ drift และการลดลงของประสิทธิภาพ

แผน rollback

ขั้นตอนปิดใช้หรือแทนที่โมเดลในกรณีพฤติกรรมไม่คาดคิดหรือเป็นอันตราย

7. การประเมินความเสี่ยง

ผลกระทบต่อสิทธิพื้นฐาน

[ ] ต่ำ [ ] กลาง [ ] สูง — อธิบาย: ___

ผลกระทบต่อสุขภาพหรือความปลอดภัย

[ ] ไม่มี [ ] เป็นไปได้ [ ] โดยตรง — อธิบาย: ___

ความเสี่ยงการเลือกปฏิบัติ

[ ] ต่ำ [ ] กลาง [ ] สูง — อธิบาย: ___

ความเสี่ยงความทึบ

[ ] ต่ำ [ ] กลาง [ ] สูง — อธิบาย: ___

8. การอนุมัติ

ผู้จัดทำ

ชื่อ: ___ ลายเซ็น: ___ วันที่: ___

CTO / ผู้รับผิดชอบเทคนิค

ชื่อ: ___ ลายเซ็น: ___ วันที่: ___

DPO / ผู้รับผิดชอบความเป็นส่วนตัว

ชื่อ: ___ ลายเซ็น: ___ วันที่: ___

Legal & Compliance

ชื่อ: ___ ลายเซ็น: ___ วันที่: ___

คณะกรรมการจริยธรรม (ถ้ามี)

ความเห็น: ___ วันที่: ___

1. วัตถุประสงค์

• ให้ผู้ร่วมงานทุกคนรู้จักประมวลจริยธรรม หน้าที่ด้านความปลอดภัยและความเป็นส่วนตัว และขอบเขตบทบาทต่อข้อมูล (แพลตฟอร์ม Legal Tech Health Tech)
• ลดความเสี่ยงเชิงปฏิบัติการและกฎระเบียบใน 90 วันแรก และรักษาทักษะด้วยการทบทวนประจำปี
• สร้างหลักฐานเอกสาร (ใบรับรอง แบบทดสอบ ทะเบียน) สำหรับการตรวจสอบและ KPI การฝึกอบรมที่เสร็จ

2. ผู้รับและหน้าที่

ผู้ร่วมงานทั้งหมด

ผู้ก่อตั้ง พนักงาน ที่ปรึกษา และผู้รับเหมาที่มีสิทธิเข้าถึงระบบหรือข้อมูล NexStudio

เจ้าของแผน

HR (ปฏิทิน ทะเบียน การเตือน)

เจ้าของเนื้อหา

CISO (ความปลอดภัย) DPO (ความเป็นส่วนตัว) Legal (ประมวล/compliance) CTO (secure coding / AI)

ผู้จัดการสายงาน

ตรวจสอบการสำเร็จตามกำหนด และรายงานความล่าช้าให้ HR

3. โมดูลบังคับ (core)

M1 — ประมวลจริยธรรมและการประพฤติ

ระยะเวลา: 1.5 ชม. เนื้อหา: คุณค่า ผลประโยชน์ทับซ้อน การรายงาน การลงโทษ ผลลัพธ์: ประกาศยอมรับลงนาม

M2 — ความปลอดภัยสารสนเทศ

ระยะเวลา: 2 ชม. เนื้อหา: phishing รหัสผ่าน/MFA การจำแนกข้อมูล อุปกรณ์ การรายงานเหตุการณ์ ผลลัพธ์: แบบทดสอบ ≥ 80%

M3 — ความเป็นส่วนตัว PDPA และ GDPR

ระยะเวลา: 2 ชม. เนื้อหา: ฐานทางกฎหมาย สิทธิเจ้าของข้อมูล การโอน การแจ้ง breach 72 ชม. บทบาทผู้ควบคุม/ผู้ประมวลผล ผลลัพธ์: แบบทดสอบ ≥ 80%

M4 — ข้อมูลอ่อนไหวและขอบเขตผลิตภัณฑ์

ระยะเวลา: 1.5 ชม. เนื้อหา: LexAura (ความลับวิชาชีพ) MediAura (ข้อมูลสุขภาพ) การลดข้อมูล การเข้าถึงพิเศษ ผลลัพธ์: เช็กลิสต์ความเข้าใจลงนาม

M5 — การใช้ AI/ML อย่างรับผิดชอบ

ระยะเวลา: 1.5 ชม. เนื้อหา: อคติ การกำกับโดยมนุษย์ ข้อจำกัดโมเดล ห้ามใช้ไม่สอดคล้อง ผลลัพธ์: แบบทดสอบ ≥ 80%

M6 — การเขียนโค้ดอย่างปลอดภัยและการปล่อย (บทบาทเทคนิค)

ระยะเวลา: 2 ชม. เนื้อหา: OWASP ความเสี่ยงหลัก การจัดการความลับ เช็กลิสต์ก่อนปล่อย SBOM บังคับสำหรับนักพัฒนา DevOps QA ผลลัพธ์: แบบทดสอบ ≥ 80% + แบบฝึกเช็กลิสต์

4. ปฏิทินปฐมนิเทศ 90 วัน

วัน 0–7 (สัปดาห์ 1)

M1 ประมวลจริยธรรม + ลงนามยอมรับและ NDA หากใช้ได้ เข้าถึงระบบหลัง MFA และบรีฟความปลอดภัยพื้นฐาน (ส่วนของ M2)

วัน 8–30 (เดือน 1)

M2 ความปลอดภัยครบ + M3 ความเป็นส่วนตัว ห้ามเข้าถึงข้อมูล production โดยไม่มี M2/M3 เสร็จ

วัน 31–60 (เดือน 2)

M4 ขอบเขตผลิตภัณฑ์ (LexAura/MediAura ตามบทบาท) + M5 AI บทบาทเทคนิค: เริ่ม M6

วัน 61–90 (เดือน 3)

ทำ M6 ให้เสร็จ (ถ้าต้อง) ทบทวนกับผู้จัดการ: ช่องว่าง การอบรมเพิ่ม ยืนยันทะเบียน จุดตรวจ HR: โมดูลบังคับของบทบาทครบ 100%

กำหนดตายตัว: ยอมรับภายใน 7 วัน core M2–M5 ภายใน 60 วัน M6 ภายใน 90 วันสำหรับบทบาทเทคนิค ล่าช้า > 14 วัน: escalate ไป HR และผู้จัดการ อาจจำกัดการเข้าถึง

5. การฝึกอบรมประจำปี

• ทบทวนบังคับภายใน 12 เดือนนับจากการสำเร็จครั้งก่อน (หรือวันปฐมนิเทศ)
• ระยะเวลารวมขั้นต่ำ: 3 ชั่วโมง (M1 อัปเดต + ส่วนต่างกฎ M2/M3 + ทบทวน AI)
• ตัวกระตุ้นเพิ่ม: การเปลี่ยนกฎสำคัญ เหตุการณ์ร้ายแรง ขอบเขตผลิตภัณฑ์ใหม่ การเปลี่ยนบทบาทวิกฤต
• รูปแบบที่ยอมรับ: เซสชันสด e-learning พร้อมแบบทดสอบ หรือเวิร์กช็อปภายในที่มีเอกสาร

6. การฝึกอบรมเพิ่มสำหรับบทบาทวิกฤต

CISO / ความปลอดภัย

playbook ตอบสนองเหตุการณ์ tabletop ประจำปี threat modeling

DPO / ความเป็นส่วนตัว

เวิร์กช็อป DPIA สิทธิเจ้าของข้อมูล การโอนระหว่างประเทศ

Legal & compliance

อัปเดตกฎ LexAura/MediAura สัญญาผู้ประมวลผลช่วง

วิศวกรรม / DevOps

Secure SDLC ขั้นสูง ทบทวน SBOM walkthrough ผลการ penetration test

สนับสนุน / customer success

สิทธิ์น้อยสุดบนข้อมูลลูกค้า สคริปต์ escalate ห้ามใช้ นอกตั๋ว

7. รูปแบบการจัดและสื่อ

• ภาษา: อิตาลี อังกฤษ ไทย (สอดคล้องกับเว็บไซต์และประมวลจริยธรรม)
• สื่อ: สไลด์/วิดีโอภายใน ประมวลฉบับปัจจุบัน ภาคผนวกปฏิบัติการ (เช็กลิสต์ DPIA AI impact)
• การประเมิน: แบบทดสอบหลายตัวเลือก (เกณฑ์ 80%) หรือใบยืนยันการเข้าร่วม + แบบฝึกสำหรับเวิร์กช็อป
• สอบใหม่: หากไม่ผ่าน สอบใหม่ภายใน 14 วันพร้อม mentoring จากเจ้าของโดเมน

8. ทะเบียนการฝึกอบรม (เทมเพลตแถว)

ฟิลด์บังคับต่อรายการ

ชื่อผู้ร่วมงาน | บทบาท | โมดูล (M1–M6 / ประจำปี / วิกฤต) | วันที่ | ระยะเวลา (ชม.) | ผล (ผ่าน / ต้องสอบใหม่) | หลักฐาน (ลิงก์แบบทดสอบ / PDF / ลายเซ็น) | ผู้ตรวจสอบ

ระยะเวลาเก็บทะเบียน: ตามนโยบายการเก็บรักษา (บันทึกการฝึกอบรมและประกาศยอมรับ) รูปแบบแนะนำ: ชีตแชร์หรือ HRIS พร้อม export สำหรับ audit

9. KPI และการควบคุม

• % ปฐมนิเทศที่โมดูลบังคับเสร็จภายใน 90 วัน (เป้า ≥ 95%)
• % บุคลากรที่ทบทวนประจำปีครบ (เป้า ≥ 95%)
• เวลาเฉลี่ยในการทำ M1–M5 ให้เสร็จ
• จำนวนความล่าช้า > 14 วัน และการแก้ไข

1. วัตถุประสงค์

• ให้ผู้วิจัยและผู้ใช้รายงานช่องโหว่โดยสุจริต พร้อมเวลาตอบสนองที่กำหนด และไม่เสี่ยงต่อการดำเนินคดีหากปฏิบัติตามนโยบายนี้
• ปกป้องข้อมูลลูกค้า ผู้ป่วย และสำนักงาน (LexAura / MediAura) และความพร้อมใช้ของบริการ SaaS

2. ขอบเขต (in scope)

• เว็บไซต์และเว็บแอปสาธารณะของ NexStudio (โดเมนหลักและหน้า IT/EN/TH)
• API และ endpoint ที่ต้องยืนยันตัวตนของ LexAura และ MediAura ใน production หรือ staging สาธารณะ
• โครงสร้างคลาวด์ที่เป็นของ NexStudio โดยตรงและเข้าถึงได้จากอินเทอร์เน็ต
• การตั้งค่าผิดพลาดที่เปิดเผยข้อมูลส่วนบุคคล ความลับ สำรอง หรือแผงผู้ดูแล

3. นอกขอบเขต (out of scope)

• DoS/DDoS การ flood การทดสอบความเครียดโดยไม่ประสาน
• Social engineering ต่อพนักงาน ลูกค้า หรือผู้ให้บริการ (phishing pretexting)
• สแปม การส่งมัลแวร์ ความปลอดภัยทางกายภาพ
• ช่องโหว่ของผลิตภัณฑ์บุคคลที่สามที่ NexStudio ไม่ได้ดำเนินการ เว้นแต่เกิดจากการตั้งค่าผิดของเรา
• รายงานจากสแกนเนอร์อย่างเดียวโดยไม่มี PoC ที่ทำซ้ำได้
• ประเด็นที่ทราบแล้วและอยู่ระหว่าง remediation

4. กฎการทดสอบโดยสุจริต

• อย่าเข้าถึง แก้ไข หรือลบข้อมูลของบุคคลที่สามเกินกว่าที่จำเป็นเพื่อพิสูจน์ปัญหา
• หยุดทันทีหากพบข้อมูลส่วนบุคคลหรือสุขภาพจริง; รายงานโดยไม่นำข้อมูลออก
• อย่ารัน exploit ที่ทำให้บริการแย่ลงหรือกระทบผู้ใช้อื่น
• อย่าเรียกค่าไถ่หรือเปิดเผยสาธารณะก่อนประสาน (embargo ที่สมเหตุสมผล)
• ใช้บัญชีทดสอบของตนเองหรือ staging เมื่อมี

5. วิธีรายงาน

ช่องทาง

อีเมล: security@nexstudio.com (PGP เป็นทางเลือกในภายหลังหากเผยแพร่)

เนื้อหาขั้นต่ำของรายงาน

ชื่อเรื่องสั้น | URL / endpoint / ส่วนประกอบ | คำอธิบายและผลกระทบ | ขั้นตอนทำซ้ำ (PoC) | ความรุนแรงโดยประมาณ (Low/Medium/High/Critical) | ช่องทางติดต่อติดตาม | หากเห็นข้อมูล: หมวดหมู่และปริมาณ (อย่าแนบข้อมูลจริง)

หัวข้อแนะนำ: [SECURITY] ชื่อสั้น อย่าแนบ dump ของข้อมูลจริง

6. SLA การตอบสนองและการแก้ไข

Ack (รับเรื่อง)

ภายใน 72 ชั่วโมงทำการนับจากรายงานที่ถูกต้อง

Triage เบื้องต้น

ภายใน 5 วันทำการ: ยืนยัน in/out of scope และความรุนแรงเบื้องต้น

เป้าหมายการแก้ไข (โดยประมาณ)

Critical: กักกันทันที; แก้หรือบรรเทาภายใน 7 วัน | High: 14 วัน | Medium: 30 วัน | Low: 90 วัน หรือรอบปล่อยถัดไป

การสื่อสาร

อัปเดตผู้รายงานจนปิดเรื่อง; advisory สาธารณะหลังแก้ หากขอเครดิต

7. Safe harbor

• NexStudio จะไม่ดำเนินคดีกับผู้ที่รายงานโดยสุจริตและปฏิบัติตามนโยบายนี้กับกฎหมายที่ใช้บังคับ
• Safe harbor ไม่ครอบคลุมกิจกรรมนอกขอบเขต การขโมยข้อมูล การขู่กรรโชก หรือความเสียหายโดยเจตนา

8. การยอมรับและ bug bounty

• ระยะปัจจุบัน (soft bounty): คำขอบคุณเป็นลายลักษณ์อักษร และหากผู้รายงานยินยอม ระบุชื่อใน hall of fame / advisory
• รางวัลเงินหรือของที่ระลึก: ไม่รับประกัน; อาจมีภายหลังพร้อมตารางสาธารณะโดยไม่เปลี่ยนช่องทาง security@
• รายการซ้ำและนอกขอบเขต: ack สุภาพโดยไม่มีรางวัล

9. ผู้รับผิดชอบภายใน

CISO / Security

Triage การแก้ไข การสื่อสารกับผู้รายงาน

DPO

เกี่ยวข้องหากช่องโหว่เกี่ยวกับข้อมูลส่วนบุคคลหรือ breach

Legal

ประเมิน safe harbor และการเปิดเผยสาธารณะ

CTO

ลำดับความสำคัญทางเทคนิคและทรัพยากรแก้ไข

1. หลักการร่วม

• เจ้าของทะเบียน: บทบาทที่ระบุชื่อ (DPO CISO CTO หรือ Legal) พร้อมตัวสำรอง
• การอัปเดต: ทุกครั้งที่มีการประมวลผลใหม่ / เหตุการณ์ / การปล่อย / การลบสำคัญ; ทบทวนอย่างน้อยรายไตรมาส
• การเก็บรักษา: ตามนโยบาย retention; export ได้สำหรับหน่วยงานและ audit
• รูปแบบ: หนึ่งแถว = หนึ่งรายการ; ID ไม่ซ้ำ; วันที่อัปเดตล่าสุดบังคับ

2. ทะเบียนการประมวลผล (RoPA / GDPR ม.30 / PDPA)

ฟิลด์แถว

รหัสการประมวลผล (เช่น TRT-001) | ชื่อ / คำอธิบาย | ขอบเขต (แพลตฟอร์ม / LexAura / MediAura) | ผู้ควบคุม | ผู้ประมวลผล / ผู้ประมวลผลช่วง | หมวดหมู่เจ้าของข้อมูล | หมวดหมู่ข้อมูล (ทั่วไป / พิเศษ) | วัตถุประสงค์ | ฐานทางกฎหมาย | การโอนนอก TH/EU (ใช่/ไม่ + เครื่องมือ) | มาตรการความปลอดภัย (อ้างอิง) | Retention (อ้างอิงนโยบาย) | DPIA (ใช่/ไม่ + ลิงก์) | เจ้าของ | อัปเดตล่าสุด

สำหรับการประมวลผลความเสี่ยงสูง: เชื่อมรหัส DPIA จากภาคผนวกแบบ DPIA อย่าใส่ข้อมูลส่วนบุคคลของเจ้าของข้อมูลในทะเบียน

3. ทะเบียนเหตุการณ์และการละเมิดข้อมูล

ฟิลด์แถว

รหัสเหตุการณ์ (INC-YYYY-NNN) | วันเวลาที่ตรวจพบ | วันเวลาที่กักกัน | ความรุนแรง | ประเภท (breach / เข้าถึงโดยไม่ได้รับอนุญาต / มัลแวร์ / อื่นๆ) | ขอบเขต | ระบบที่เกี่ยวข้อง | หมวดหมู่ข้อมูล / จำนวนเจ้าของข้อมูลโดยประมาณ | แจ้งหน่วยงาน (ใช่/ไม่/N.A. + วันที่) | แจ้งเจ้าของข้อมูล (ใช่/ไม่/N.A. + วันที่) | สถานะ (เปิด / กำลังดำเนินการ / ปิด) | สาเหตุต้นตอ (สรุป) | การแก้ไข | เจ้าของ | ลิงก์ post-mortem

ใช้เทมเพลตการแจ้งจากภาคผนวกจัดการเหตุการณ์แนบกับรายการ

4. ทะเบียน SBOM / บัญชีส่วนประกอบ (ปฏิบัติการ)

ฟิลด์แถว (ต่อ release หรือชุดส่วนประกอบวิกฤต)

รหัส release / commit | ผลิตภัณฑ์ (แพลตฟอร์ม / LexAura / MediAura) | วันที่สร้าง SBOM | รูปแบบ (CycloneDX / SPDX) | ลิงก์ไฟล์ SBOM | จำนวนส่วนประกอบ | ช่องโหว่เปิด (CVSS ≥ 7) | ใบอนุญาต copyleft / ทบทวน IP | เจ้าของเทคนิค | ผล gate ก่อนปล่อย (OK / บล็อก) | หมายเหตุ

รายละเอียดส่วนประกอบอยู่ในไฟล์ SBOM; ทะเบียนนี้ติดตามการสร้างและ gate ให้สอดคล้องกับเช็กลิสต์ก่อนปล่อย

5. ทะเบียน retention และการลบ

ฟิลด์แถว

รหัสงาน (RET-001) | หมวดหมู่ข้อมูล (อ้างอิงนโยบาย retention) | ระบบ / datastore | ระยะเวลา retention ที่ใช้ | ตัวกระตุ้น (ครบกำหนด / คำขอเจ้าของข้อมูล / สิ้นสุดสัญญา) | การดำเนินการ (ทำให้ไม่ระบุตัวตน / ลบตรรกะ / ลบกายภาพ) | วันที่ดำเนินการ | หลักฐาน (บันทึก / ตั๋ว / ใบรับรอง) | จำนวน record (รวม) | ผู้ดำเนินการ | การตรวจสอบ DPO/CISO (วันที่)

อย่าระบุตัวตนเจ้าของข้อมูล; ใช้เฉพาะค่าสรุปและอ้างอิงทางเทคนิค ให้สอดคล้องกับนโยบาย retention

6. ทะเบียนผู้ให้บริการและผู้ประมวลผลช่วง (ขั้นต่ำ)

ฟิลด์แถว

รหัสผู้ให้บริการ | ชื่อ / บริการ | บทบาท (ผู้ประมวลผลช่วง / vendor) | ข้อมูลที่ประมวลผล (หมวดหมู่) | ที่ตั้ง / การโอน | DPA / NDA (ลิงก์ + วันที่ลงนาม) | มาตรการความปลอดภัยเทียบเท่า (ใช่/ไม่) | วันที่ทบทวน | เจ้าของ Legal | สถานะ (ใช้งาน / กำลังออก / สิ้นสุด)

7. เจ้าของและ KPI

ทะเบียนการประมวลผล + DPIA

DPO (สำรอง: Legal)

ทะเบียนเหตุการณ์

CISO (สำรอง: CTO)

ทะเบียน SBOM

CTO / engineering lead

ทะเบียน retention

DPO + engineering

ทะเบียนผู้ประมวลผลช่วง

Legal (สำรอง: DPO)

KPI ตัวอย่าง

% การประมวลผลที่มีเจ้าของและอัปเดต < 90 วัน | เหตุการณ์เปิดเกิน SLA | release ที่ไม่มี SBOM = 0 | งาน retention ที่ทำ vs ที่วางแผน