SOC 2 Type II: ข้อกำหนด Penetration Testing และการตรวจประเมินสำหรับ SaaS
คู่มือเจาะลึกมาตรฐาน AICPA SOC 2 Type II เกณฑ์ Trust Services Criteria CC4.1 และ CC7.1 สำหรับการประเมินช่องโหว่และการทดสอบเจาะระบบประจำปี พร้อมแนวทางการเตรียมหลักฐานสำหรับผู้สอบบัญชี CPA
- กลุ่มเป้าหมายที่บังคับใช้
- ผู้ให้บริการเทคโนโลยี ผู้ให้บริการคลาวด์ SaaS ฟินเทค และศูนย์ข้อมูลที่จัดเก็บหรือประมวลผลข้อมูลของลูกค้า
- ความถี่ในการทดสอบ
- ประเมิน Type II ครอบคลุมช่วงเวลาดำเนินงาน (Audit Window ปกติ 6 ถึง 12 เดือน) พร้อม Pentest ประจำปีตามเกณฑ์ CC7.1
- ขอบเขตการทดสอบ
- Trust Services Criteria หมวด Security (CC7.1), ขอบเขตคลาวด์, โครงสร้างพื้นฐาน, ซอฟต์แวร์ SaaS, API และระบบ CI/CD
- ความเสี่ยงหากไม่ปฏิบัติตาม
- รายงานจาก CPA Auditor ติดข้อยกเว้น (Qualified Opinion), สูญเสียความเชื่อมั่นจากลูกค้าองค์กร และไม่ผ่านเกณฑ์จัดซื้อจัดจ้างระดับสากล
SOC 2 คืออะไร และความแตกต่างระหว่าง Type I กับ Type II
SOC 2 เป็นมาตรฐานการสอบทานระบบควบคุมความมั่นคงปลอดภัยสำหรับองค์กรผู้ให้บริการซอฟต์แวร์และคลาวด์ที่พัฒนาโดย AICPA

ภาพสรุปเพื่อประกอบการอ่าน โปรดพิจารณาขอบเขตและรายละเอียดในบทความ
- Security — การรักษาความมั่นคงปลอดภัย
- Availability — ความพร้อมใช้งาน
- Confidentiality — การรักษาความลับ
- Processing Integrity — ความครบถ้วนถูกต้องของการประมวลผล
- Privacy — ความเป็นส่วนตัว

- ออกแบบมาสำหรับผู้ให้บริการ SaaS, Cloud Infrastructure, ผู้พัฒนาซอฟต์แวร์ และ Managed Service Providers ที่ต้องพิสูจน์ความปลอดภัยแก่ลูกค้าองค์กร
- ครอบคลุม 5 หมวด Trust Services Criteria: หมวด Security (Common Criteria) เป็นเกณฑ์บังคับ (ต้องทำ - Mandatory) สำหรับทุกรายงาน SOC 2 ส่วน Availability, Processing Integrity, Confidentiality และ Privacy เป็นเกณฑ์ที่เลือกนำมาใช้ตามความเหมาะสมของบริการ (Applicable / Optional)
- Type I ประเมินความเหมาะสมของการออกแบบระบบควบคุม (Design of Controls) ณ วันใดวันหนึ่ง ซึ่งเหมาะสำหรับระบบที่เพิ่งเริ่มต้นใช้งาน
- Type II ประเมินประสิทธิผลการทำงานจริงของระบบควบคุม (Operating Effectiveness) ตลอดระยะเวลาการตรวจประเมิน 3 ถึง 12 เดือน ซึ่งเป็นเกณฑ์มาตรฐานที่ลูกค้าระดับ Enterprise ร้องขอ
เกณฑ์ Common Criteria CC4.1 และ CC7.1: การบริหารช่องโหว่และการทดสอบเจาะระบบ
AICPA SOC 2 เป็นมาตรฐานแบบ Principles-based โดยตัวเกณฑ์ไม่ได้ระบุคำว่า Pentest ในตัวบทหลัก แต่ Point of Focus ของ CC4.1 และเกณฑ์ CC7.1 กำหนดให้ต้องมีการตรวจสอบความมั่นคงปลอดภัยอย่างมีประสิทธิผล

ภาพสรุปเพื่อประกอบการอ่าน โปรดพิจารณาขอบเขตและรายละเอียดในบทความ
- ขอบเขตระบบ — แอปพลิเคชัน API และโครงสร้างพื้นฐาน
- ทดสอบตามความเสี่ยง — ตรวจการควบคุมและบันทึกผล
- แก้ไขและทดสอบซ้ำ — ติดตามเจ้าของงานและหลักฐาน
- เตรียมให้ผู้สอบบัญชี — ขอบเขต วิธีการ ผล และข้อจำกัด

- เกณฑ์ CC4.1 (Monitoring Activities - COSO Principle 12): ใน Point of Focus กำหนดให้ฝ่ายบริหารต้องจัดให้มี Penetration Testing เพื่อประเมินว่าระบบควบคุมทำงานได้จริงตามที่ออกแบบไว้
- เกณฑ์ CC7.1 (System Operations): เป็นเกณฑ์บังคับ (ต้องทำ) ที่กำหนดให้จัดทำ Vulnerability Assessments สแกนหาช่องโหว่ของโครงสร้างพื้นฐาน คลาวด์ และแอปพลิเคชันอย่างสม่ำเสมอ
- ข้อกำหนดปฏิบัติจริง (De Facto Mandatory): ผู้สอบบัญชี CPA Firm ล้วนคาดหวังรายงาน Penetration Testing ประจำปีโดยผู้เชี่ยวชาญภายนอกที่เป็นอิสระ เพื่อใช้เป็นหลักฐานสนับสนุนการออกรายงานแบบ Unqualified Opinion
- ขอบเขตการทดสอบครอบคลุมทั้ง External Perimeter, Web Applications, APIs, Cloud Control Plane (AWS/Azure/GCP) และ Kubernetes Container Clusters พร้อมทดสอบ Multi-Tenant Data Isolation
การจัดการช่องโหว่ตามเกณฑ์ CC4.2 และการเตรียมหลักฐานสำหรับ CPA Firm
การเชื่อมโยงผลการทดสอบเจาะระบบเข้ากับแผนจัดการความเสี่ยงและหลักฐานการทดสอบซ้ำเพื่อยื่นต่อผู้สอบบัญชี

ตัวอย่างการเตรียมหลักฐานระหว่างช่วงตรวจประเมิน Type II ผู้สอบบัญชีเป็นผู้ประเมินหลักฐานและให้ความเห็น ผล Pentest ไม่ได้รับประกันความเห็นในรายงาน
- กำหนดช่วงและขอบเขต — ระบุระบบและการควบคุมที่ประเมิน
- ประเมินการควบคุม — รวบรวมหลักฐานการปฏิบัติงาน
- ติดตามข้อบกพร่อง — แก้ไขและยืนยันผลทดสอบซ้ำ
- ผู้สอบบัญชีพิจารณา — ประเมินหลักฐานและออกรายงาน

- เมื่อตรวจพบช่องโหว่ระดับ Critical หรือ High ต้องดำเนินการแก้ไข (Remediation) ภายในกรอบเวลา SLA ที่กำหนดไว้ในนโยบายขององค์กร
- ต้องมีการทดสอบซ้ำ (Re-testing) โดยผู้ทดสอบอิสระเพื่อยืนยันว่าช่องโหว่ได้รับการปิดอย่างสมบูรณ์ภายในช่วงเวลาการตรวจประเมิน (Audit Window)
- ผู้ให้บริการ Pentest จะออก Attestation Letter (หนังสือรับรองผลการทดสอบ) สรุปขอบเขต วิธีการ และสถานะการแก้ไข เพื่อแนบเป็นหลักฐานในรายงาน SOC 2
- ผู้สอบบัญชี CPA Firm จะตรวจสอบคุณสมบัติของผู้ทดสอบ (OSCP, CREST, CISSP) และความเป็นอิสระในการปฏิบัติงาน เพื่อออกรายงานแบบ Unqualified Opinion
ตารางเปรียบเทียบข้อกำหนดและการทดสอบความปลอดภัย
สรุปรายละเอียดประกาศ บทบัญญัติ และขอบเขตการทดสอบความปลอดภัยที่จำเป็น
| ประกาศ และข้อกำหนด | สาระสำคัญ | ขอบเขตการทดสอบ | รอบเวลาทดสอบ |
|---|---|---|---|
| Trust Services Criteria CC7.1 | การบริหารจัดการช่องโหว่และการทดสอบเจาะระบบ (Vulnerability Management & Pentest) | สแกนช่องโหว่และจัดให้มีผู้เชี่ยวชาญอิสระภายนอกทดสอบเจาะระบบคลาวด์ โครงสร้างพื้นฐาน และแอปพลิเคชัน SaaS | สแกนช่องโหว่อย่างสม่ำเสมอ และทดสอบเจาะระบบอย่างน้อยปีละ 1 ครั้งภายในรอบ Audit Window |
| Trust Services Criteria CC6.1 - CC6.3 | การควบคุมการเข้าถึงระบบและความปลอดภัยเชิงตรรกะ (Logical Access Controls) | ประเมินการจัดการสิทธิ์ Identity & Access Management (IAM), การแบ่งแยกหน้าที่ (Separation of Duties), และการบังคับใช้ MFA | ตรวจสอบตลอดช่วงเวลาประเมิน Type II (Period of Performance) |
| Trust Services Criteria CC6.6 - CC6.7 | การป้องกันเครือข่ายและการเข้ารหัสข้อมูล (Perimeter Security & Encryption) | ทดสอบความแข็งแกร่งของ WAF, Firewall, การเข้ารหัสข้อมูลขณะส่งผ่าน (In-transit) และจัดเก็บ (At-rest) | ประเมินตามรอบและทดสอบซ้ำเมื่อมีการเปลี่ยนแปลงสถาปัตยกรรม |
| Trust Services Criteria CC7.3 - CC7.4 | การตอบสนองต่อเหตุการณ์ความปลอดภัยและการแก้ไขช่องโหว่ (Incident Response & Remediation) | ตรวจติดตามแผนการแก้ไขช่องโหว่ (Remediation Tracking), SLA การปิดจุดอ่อน, และการทดสอบซ้ำ (Retesting) | ติดตามผลอย่างต่อเนื่องและเก็บหลักฐานสำหรับ CPA Auditor |
เครื่องมือประเมินความพร้อม
คลิกเลือกรายการที่องค์กรของท่านได้ดำเนินการแล้ว เพื่อคำนวณระดับความพร้อมเบื้องต้น
คำถามที่พบบ่อย (FAQ)
คำถามและข้อสงสัยสำคัญเกี่ยวกับข้อกำหนดและการตรวจประเมินตามมาตรฐาน
SOC 2 Type I กับ Type II แตกต่างกันอย่างไรในแง่ของการทดสอบเจาะระบบ?
รายงาน Type I ตรวจสอบการออกแบบมาตรการควบคุม ณ จุดเวลาใดเวลาหนึ่ง (Point in time) ขณะที่รายงาน Type II ตรวจสอบประสิทธิผลการทำงานของมาตรการควบคุมตลอดช่วงเวลา (เช่น 6 หรือ 12 เดือน) ซึ่งผู้สอบบัญชี CPA จะต้องเห็นหลักฐานการทดสอบเจาะระบบ แผนการปรับปรุงแก้ไข และการทดสอบซ้ำภายในช่วงเวลาดังกล่าว
การสแกนช่องโหว่อัตโนมัติ (Vulnerability Scan) เพียงพอที่จะผ่านเกณฑ์ CC7.1 หรือไม่?
ไม่เพียงพอ เกณฑ์ CC7.1 และแนวทางการตรวจประเมินของ AICPA กำหนดให้องค์กรต้องมีการทดสอบเจาะระบบ (Penetration Testing) เชิงลึกโดยผู้เชี่ยวชาญอิสระเพื่อประเมินจุดอ่อนทางตรรกะและการเจาะผ่านชั้นการป้องกัน ซึ่งเครื่องมือสแกนอัตโนมัติไม่สามารถทดแทนได้
ผู้ว่าจ้างสามารถแชร์รายงานผลการทดสอบเจาะระบบฉบับเต็มให้ลูกค้าได้หรือไม่?
รายงานผลการทดสอบเจาะระบบฉบับเต็มมักมีรายละเอียดช่องโหว่เชิงลึกที่อ่อนไหวสูง บริษัทรักษาความปลอดภัยส่วนใหญ่รวมถึง STH จึงออก 'Attestation Letter' หรือ 'Letter of Attestation' สรุปผลการทดสอบและรับรองความปลอดภัยสำหรับให้ผู้ว่าจ้างส่งมอบแก่ลูกค้าและผู้สอบบัญชี CPA ได้อย่างปลอดภัย
