soc2-compliance

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

SOC 2 Compliance

SOC 2合规

SOC 2 Type I and Type II compliance preparation for SaaS companies. Covers Trust Service Criteria mapping, control matrix generation, evidence collection, gap analysis, and audit readiness assessment.

面向SaaS企业的SOC 2 Type I和Type II合规准备指南。涵盖Trust Service Criteria（信任服务准则）映射、控制矩阵生成、证据收集、差距分析以及审计就绪评估。

Overview

概述

What Is SOC 2?

什么是SOC 2？

SOC 2 (System and Organization Controls 2) is an auditing framework developed by the AICPA that evaluates how a service organization manages customer data. It applies to any technology company that stores, processes, or transmits customer information — primarily SaaS, cloud infrastructure, and managed service providers.

SOC 2（System and Organization Controls 2）是由AICPA（美国注册会计师协会）开发的审计框架，用于评估服务机构如何管理客户数据。它适用于任何存储、处理或传输客户信息的科技公司——主要是SaaS、云基础设施和托管服务提供商。

Type I vs Type II

Aspect	Type I	Type II
Scope	Design of controls at a point in time	Design AND operating effectiveness over a period
Duration	Snapshot (single date)	Observation window (3-12 months, typically 6)
Evidence	Control descriptions, policies	Control descriptions + operating evidence (logs, tickets, screenshots)
Cost	$20K-$50K (audit fees)	$30K-$100K+ (audit fees)
Timeline	1-2 months (audit phase)	6-12 months (observation + audit)
Best For	First-time compliance, rapid market need	Mature organizations, enterprise customers

维度	Type I	Type II
范围	某一时间点的控制设计	一段时间内的设计及运行有效性
时长	快照（单一日期）	观察周期（3-12个月，通常为6个月）
证据	控制说明、政策文件	控制说明 + 运行证据（日志、工单、截图）
成本	2万-5万美元（审计费用）	3万-10万美元以上（审计费用）
时间线	1-2个月（审计阶段）	6-12个月（观察+审计）
适用场景	首次合规、快速满足市场需求	成熟企业、面向企业客户

Who Needs SOC 2?

谁需要SOC 2？

SaaS companies selling to enterprise customers
Cloud infrastructure providers handling customer workloads
Data processors managing PII, PHI, or financial data
Managed service providers with access to client systems
Any vendor whose customers require third-party assurance

面向企业客户的SaaS公司
处理客户工作负载的云基础设施提供商
管理PII（个人可识别信息）、PHI（受保护健康信息）或财务数据的数据处理商
可访问客户系统的托管服务提供商
客户要求第三方担保的任何供应商

Typical Journey

典型流程

Gap Assessment → Remediation → Type I Audit → Observation Period → Type II Audit → Annual Renewal
    (4-8 wk)      (8-16 wk)     (4-6 wk)       (6-12 mo)          (4-6 wk)       (ongoing)

差距评估 → 整改 → Type I审计 → 观察期 → Type II审计 → 年度更新
    (4-8周)      (8-16周)     (4-6周)       (6-12个月)          (4-6周)       (持续进行)

Trust Service Criteria

Trust Service准则

SOC 2 is organized around five Trust Service Criteria (TSC) categories. Security is required for every SOC 2 report; the remaining four are optional and selected based on business need.

SOC 2围绕五个Trust Service Criteria（TSC）类别构建。**Security（安全）**是所有SOC 2报告的必填项；其余四项为可选，可根据业务需求选择。

Security (Common Criteria CC1-CC9) — Required

Security（通用准则CC1-CC9）—— 必填

The foundation of every SOC 2 report. Maps to COSO 2013 principles.

Criteria	Domain	Key Controls
CC1	Control Environment	Integrity/ethics, board oversight, org structure, competence, accountability
CC2	Communication & Information	Internal/external communication, information quality
CC3	Risk Assessment	Risk identification, fraud risk, change impact analysis
CC4	Monitoring Activities	Ongoing monitoring, deficiency evaluation, corrective actions
CC5	Control Activities	Policies/procedures, technology controls, deployment through policies
CC6	Logical & Physical Access	Access provisioning, authentication, encryption, physical restrictions
CC7	System Operations	Vulnerability management, anomaly detection, incident response
CC8	Change Management	Change authorization, testing, approval, emergency changes
CC9	Risk Mitigation	Vendor/business partner risk management

所有SOC 2报告的基础，与COSO 2013原则相对应。

准则	领域	关键控制措施
CC1	控制环境	诚信/道德、董事会监督、组织结构、胜任能力、问责制
CC2	沟通与信息	内外部沟通、信息质量
CC3	风险评估	风险识别、欺诈风险、变更影响分析
CC4	监控活动	持续监控、缺陷评估、纠正措施
CC5	控制活动	政策/流程、技术控制、通过政策部署
CC6	逻辑与物理访问	访问权限配置、身份验证、加密、物理限制
CC7	系统运维	漏洞管理、异常检测、事件响应
CC8	变更管理	变更授权、测试、审批、紧急变更
CC9	风险缓解	供应商/业务合作伙伴风险管理

Availability (A1) — Optional

Availability（A1）—— 可选

Criteria	Focus	Key Controls
A1.1	Capacity management	Infrastructure scaling, resource monitoring, capacity planning
A1.2	Recovery operations	Backup procedures, disaster recovery, BCP testing
A1.3	Recovery testing	DR drills, failover testing, RTO/RPO validation

Select when: Customers depend on your uptime; you have SLAs; downtime causes direct business impact.

准则	重点	关键控制措施
A1.1	容量管理	基础设施扩容、资源监控、容量规划
A1.2	恢复操作	备份流程、灾难恢复、BCP（业务连续性计划）测试
A1.3	恢复测试	DR（灾难恢复）演练、故障转移测试、RTO（恢复时间目标）/RPO（恢复点目标）验证

选择场景： 客户依赖您的服务可用性；您有SLA（服务水平协议）；停机直接影响业务。

Confidentiality (C1) — Optional

Confidentiality（C1）—— 可选

Criteria	Focus	Key Controls
C1.1	Identification	Data classification policy, confidential data inventory
C1.2	Protection	Encryption at rest and in transit, DLP, access restrictions
C1.3	Disposal	Secure deletion procedures, media sanitization, retention enforcement

Select when: You handle trade secrets, proprietary data, or contractually confidential information.

准则	重点	关键控制措施
C1.1	识别	数据分类政策、机密数据清单
C1.2	保护	静态和传输中数据加密、DLP（数据丢失防护）、访问限制
C1.3	处置	安全删除流程、介质清理、保留执行

选择场景： 您处理商业机密、专有数据或合同约定的保密信息。

Processing Integrity (PI1) — Optional

Processing Integrity（PI1）—— 可选

Criteria	Focus	Key Controls
PI1.1	Accuracy	Input validation, processing checks, output verification
PI1.2	Completeness	Transaction monitoring, reconciliation, error handling
PI1.3	Timeliness	SLA monitoring, processing delay alerts, batch job monitoring
PI1.4	Authorization	Processing authorization controls, segregation of duties

Select when: Data accuracy is critical (financial processing, healthcare records, analytics platforms).

准则	重点	关键控制措施
PI1.1	准确性	输入验证、处理检查、输出验证
PI1.2	完整性	交易监控、对账、错误处理
PI1.3	及时性	SLA监控、处理延迟警报、批处理作业监控
PI1.4	授权	处理授权控制、职责分离

选择场景： 数据准确性至关重要（财务处理、医疗记录、分析平台）。

Privacy (P1-P8) — Optional

Privacy（P1-P8）—— 可选

Criteria	Focus	Key Controls
P1	Notice	Privacy policy, data collection notice, purpose limitation
P2	Choice & Consent	Opt-in/opt-out, consent management, preference tracking
P3	Collection	Minimal collection, lawful basis, purpose specification
P4	Use, Retention, Disposal	Purpose limitation, retention schedules, secure disposal
P5	Access	Data subject access requests, correction rights
P6	Disclosure & Notification	Third-party sharing, breach notification
P7	Quality	Data accuracy verification, correction mechanisms
P8	Monitoring & Enforcement	Privacy program monitoring, complaint handling

Select when: You process PII and customers expect privacy assurance (complements GDPR compliance).

准则	重点	关键控制措施
P1	通知	隐私政策、数据收集通知、用途限制
P2	选择与同意	选择加入/退出、同意管理、偏好跟踪
P3	收集	最小化收集、合法依据、用途说明
P4	使用、保留、处置	用途限制、保留计划、安全处置
P5	访问	数据主体访问请求、更正权利
P6	披露与通知	第三方共享、 breach（数据泄露）通知
P7	质量	数据准确性验证、更正机制
P8	监控与执行	隐私计划监控、投诉处理

选择场景： 您处理PII且客户期望隐私保障（与GDPR合规互补）。

Control Matrix Generation

控制矩阵生成

A control matrix maps each TSC criterion to specific controls, owners, evidence, and testing procedures.

控制矩阵将每个TSC准则映射到具体的控制措施、负责人、证据和测试流程。

Matrix Structure

矩阵结构

Field	Description
Control ID	Unique identifier (e.g., SEC-001, AVL-003)
TSC Mapping	Which criteria the control addresses (e.g., CC6.1, A1.2)
Control Description	What the control does
Control Type	Preventive, Detective, or Corrective
Owner	Responsible person/team
Frequency	Continuous, Daily, Weekly, Monthly, Quarterly, Annual
Evidence Type	Screenshot, Log, Policy, Config, Ticket
Testing Procedure	How the auditor verifies the control

字段	描述
控制ID	唯一标识符（例如：SEC-001, AVL-003）
TSC映射	该控制措施对应的准则（例如：CC6.1, A1.2）
控制措施描述	控制措施的具体内容
控制类型	预防性、检测性或纠正性
负责人	负责的人员/团队
执行频率	持续、每日、每周、每月、每季度、每年
证据类型	截图、日志、政策、配置、工单
测试流程	审计师验证控制措施的方式

Control Naming Convention

控制命名规范

{CATEGORY}-{NUMBER}
SEC-001 through SEC-NNN  → Security
AVL-001 through AVL-NNN  → Availability
CON-001 through CON-NNN  → Confidentiality
PRI-001 through PRI-NNN  → Processing Integrity
PRV-001 through PRV-NNN  → Privacy

{CATEGORY}-{NUMBER}
SEC-001至SEC-NNN  → Security
AVL-001至AVL-NNN  → Availability
CON-001至CON-NNN  → Confidentiality
PRI-001至PRI-NNN  → Processing Integrity
PRV-001至PRV-NNN  → Privacy

Workflow

流程

Select applicable TSC categories based on business needs
Run
```
control_matrix_builder.py
```
to generate the baseline matrix
Customize controls to match your actual environment
Assign owners and evidence requirements
Validate coverage — every selected TSC criterion must have at least one control

根据业务需求选择适用的TSC类别
运行
```
control_matrix_builder.py
```
生成基线矩阵
自定义控制措施以匹配您的实际环境
分配负责人和证据要求
验证覆盖范围——每个选定的TSC准则必须至少对应一项控制措施

Gap Analysis Workflow

差距分析流程

Phase 1: Current State Assessment

第一阶段：当前状态评估

Document existing controls — inventory all security policies, procedures, and technical controls
Map to TSC — align existing controls to Trust Service Criteria
Collect evidence samples — gather proof that controls exist and operate
Interview control owners — verify understanding and execution

记录现有控制措施——盘点所有安全政策、流程和技术控制措施
映射到TSC——将现有控制措施与Trust Service准则对齐
收集证据样本——收集证明控制措施存在并运行的证据
访谈控制负责人——验证理解和执行情况

Phase 2: Gap Identification

第二阶段：差距识别

Run

gap_analyzer.py

against your current controls to identify:

Missing controls — TSC criteria with no corresponding control
Partially implemented — Control exists but lacks evidence or consistency
Design gaps — Control designed but does not adequately address the criteria
Operating gaps (Type II only) — Control designed correctly but not operating effectively

运行

gap_analyzer.py

分析您当前的控制措施，以识别：

缺失的控制措施——没有对应控制措施的TSC准则
部分实施——控制措施存在但缺乏证据或一致性
设计差距——控制措施已设计但未充分满足准则要求
运行差距（仅Type II）——控制措施设计正确但运行无效

Phase 3: Remediation Planning

第三阶段：整改计划

For each gap, define:

Field	Description
Gap ID	Reference identifier
TSC Criteria	Affected criteria
Gap Description	What is missing or insufficient
Remediation Action	Specific steps to close the gap
Owner	Person responsible for remediation
Priority	Critical / High / Medium / Low
Target Date	Completion deadline
Dependencies	Other gaps or projects that must complete first

针对每个差距，定义：

字段	描述
差距ID	参考标识符
TSC准则	受影响的准则
差距描述	缺失或不足的内容
整改措施	关闭差距的具体步骤
负责人	负责整改的人员
优先级	关键 / 高 / 中 / 低
目标日期	完成截止日期
依赖项	必须先完成的其他差距或项目

Phase 4: Timeline Planning

第四阶段：时间线规划

Priority	Target Remediation
Critical	2-4 weeks
High	4-8 weeks
Medium	8-12 weeks
Low	12-16 weeks

优先级	整改目标时间
关键	2-4周
高	4-8周
中	8-12周
低	12-16周

Evidence Collection

证据收集

Evidence Types by Control Category

按控制类别划分的证据类型

Control Area	Primary Evidence	Secondary Evidence
Access Management	User access reviews, provisioning tickets	Role matrix, access logs
Change Management	Change tickets, approval records	Deployment logs, test results
Incident Response	Incident tickets, postmortems	Runbooks, escalation records
Vulnerability Management	Scan reports, patch records	Remediation timelines
Encryption	Configuration screenshots, certificate inventory	Key rotation logs
Backup & Recovery	Backup logs, DR test results	Recovery time measurements
Monitoring	Alert configurations, dashboard screenshots	On-call schedules, escalation records
Policy Management	Signed policies, version history	Training completion records
Vendor Management	Vendor assessments, SOC 2 reports	Contract reviews, risk registers

控制领域	主要证据	次要证据
访问管理	用户访问审核记录、权限配置工单	角色矩阵、访问日志
变更管理	变更工单、审批记录	部署日志、测试结果
事件响应	事件工单、事后分析报告	运行手册、升级记录
漏洞管理	扫描报告、补丁记录	整改时间线
加密	配置截图、证书清单	密钥轮换日志
备份与恢复	备份日志、DR测试结果	恢复时间测量数据
监控	警报配置、仪表板截图	值班安排、升级记录
政策管理	签署的政策文件、版本历史	培训完成记录
供应商管理	供应商评估报告、SOC 2报告	合同审核、风险登记册

Automation Opportunities

自动化机会

Area	Automation Approach
Access reviews	Integrate IAM with ticketing (automatic quarterly review triggers)
Configuration evidence	Infrastructure-as-code snapshots, compliance-as-code tools
Vulnerability scans	Scheduled scanning with auto-generated reports
Change management	Git-based audit trail (commits, PRs, approvals)
Uptime monitoring	Automated SLA dashboards with historical data
Backup verification	Automated restore tests with success/failure logging

领域	自动化方法
访问审核	将IAM（身份访问管理）与工单系统集成（自动触发季度审核）
配置证据	基础设施即代码快照、合规即代码工具
漏洞扫描	定期扫描并自动生成报告
变更管理	基于Git的审计追踪（提交记录、PR、审批）
可用性监控	自动生成SLA仪表板及历史数据
备份验证	自动恢复测试并记录成功/失败情况

Continuous Monitoring

持续监控

Move from point-in-time evidence collection to continuous compliance:

Automated evidence gathering — scripts that pull evidence on schedule
Control dashboards — real-time visibility into control status
Alert-based monitoring — notify when a control drifts out of compliance
Evidence repository — centralized, timestamped evidence storage

从时点性证据收集转向持续合规：

自动化证据收集——定期拉取证据的脚本
控制仪表板——实时查看控制措施状态
基于警报的监控——当控制措施偏离合规时发出通知
证据存储库——集中化、带时间戳的证据存储

Audit Readiness Checklist

审计就绪检查清单

Pre-Audit Preparation (4-6 Weeks Before)

审计前准备（审计前4-6周）

Readiness Scoring

就绪评分

Score	Rating	Meaning
90-100%	Audit Ready	Proceed with confidence
75-89%	Minor Gaps	Address before scheduling audit
50-74%	Significant Gaps	Remediation required
< 50%	Not Ready	Major program build-out needed

分数	评级	含义
90-100%	已就绪	可放心推进审计
75-89%	微小差距	安排审计前解决
50-74%	显著差距	需要整改
< 50%	未就绪	需要大规模构建合规体系

Common Audit Findings

常见审计发现

Finding	Root Cause	Prevention
Incomplete access reviews	Manual process, no reminders	Automate quarterly review triggers
Missing change approvals	Emergency changes bypass process	Define emergency change procedure with post-hoc approval
Stale vulnerability scans	Scanner misconfigured	Automated weekly scans with alerting
Policy not acknowledged	No tracking mechanism	Annual e-signature workflow
Missing vendor assessments	No vendor inventory	Maintain vendor register with review schedule

问题	根本原因	预防措施
访问审核不完整	手动流程、无提醒	自动触发季度审核
缺失变更审批	紧急变更绕过流程	定义紧急变更流程并要求事后审批
漏洞扫描过期	扫描器配置错误	自动每周扫描并设置警报
政策未确认签收	无跟踪机制	年度电子签名流程
缺失供应商评估	无供应商清单	维护供应商登记册并设置审核时间表

Vendor Management

供应商管理

Third-Party Risk Assessment

第三方风险评估

Every vendor that accesses, stores, or processes customer data must be assessed:

Vendor inventory — maintain a register of all service providers
Risk classification — categorize vendors by data access level
Due diligence — collect SOC 2 reports, security questionnaires, certifications
Contractual protections — ensure DPAs, security requirements, breach notification clauses
Ongoing monitoring — annual reassessment, continuous news monitoring

所有访问、存储或处理客户数据的供应商必须经过评估：

供应商清单——维护所有服务提供商的登记册
风险分类——按数据访问级别对供应商进行分类
尽职调查——收集SOC 2报告、安全问卷、认证
合同保障——确保包含DPA（数据处理协议）、安全要求、数据泄露通知条款
持续监控——年度重新评估、持续新闻监控

Vendor Risk Tiers

供应商风险等级

Tier	Data Access	Assessment Frequency	Requirements
Critical	Processes/stores customer data	Annual + continuous monitoring	SOC 2 Type II, penetration test, security review
High	Accesses customer environment	Annual	SOC 2 Type II or equivalent, questionnaire
Medium	Indirect access, support tools	Annual questionnaire	Security certifications, questionnaire
Low	No data access	Biennial questionnaire	Basic security questionnaire

等级	数据访问权限	评估频率	要求
关键	处理/存储客户数据	年度 + 持续监控	SOC 2 Type II、渗透测试、安全审核
高	访问客户环境	年度	SOC 2 Type II或同等认证、问卷
中	间接访问、支持工具	年度问卷	安全认证、问卷
低	无数据访问	每两年一次问卷	基础安全问卷

Subservice Organizations

子服务机构

When your SOC 2 report relies on controls at a subservice organization (e.g., AWS, GCP, Azure):

Inclusive method — your report covers the subservice org's controls (requires their cooperation)
Carve-out method — your report excludes their controls but references their SOC 2 report
Most companies use carve-out and include complementary user entity controls (CUECs)

当您的SOC 2报告依赖子服务机构（如AWS、GCP、Azure）的控制措施时：

包含法——您的报告涵盖子服务机构的控制措施（需要其配合）
排除法——您的报告排除其控制措施但引用其SOC 2报告
大多数公司使用排除法并补充用户实体控制措施（CUECs）

Continuous Compliance

持续合规

From Point-in-Time to Continuous

从时点性到持续性

Aspect	Point-in-Time	Continuous
Evidence collection	Manual, before audit	Automated, ongoing
Control monitoring	Periodic review	Real-time dashboards
Drift detection	Found during audit	Alert-based, immediate
Remediation	Reactive	Proactive
Audit preparation	4-8 week scramble	Always ready

维度	时点性	持续性
证据收集	手动、审计前进行	自动化、持续进行
控制监控	定期审核	实时仪表板
偏差检测	审计期间发现	基于警报、即时发现
整改	被动响应	主动预防
审计准备	4-8周仓促准备	随时就绪

Implementation Steps

实施步骤

Automate evidence gathering — cron jobs, API integrations, IaC snapshots
Build control dashboards — aggregate control status into a single view
Configure drift alerts — notify when controls fall out of compliance
Establish review cadence — weekly control owner check-ins, monthly steering
Maintain evidence repository — centralized, timestamped, auditor-accessible

自动化证据收集——定时任务、API集成、IaC快照
构建控制仪表板——将控制措施状态汇总到单一视图
配置偏差警报——当控制措施不符合合规要求时发出通知
建立审核节奏——每周控制负责人检查、每月指导会议
维护证据存储库——集中化、带时间戳、审计师可访问

Annual Re-Assessment Cycle

年度重新评估周期

Quarter	Activities
Q1	Annual risk assessment, policy refresh, vendor reassessment launch
Q2	Internal control testing, remediation of findings
Q3	Pre-audit readiness review, evidence completeness check
Q4	External audit, management assertion, report distribution

季度	活动
Q1	年度风险评估、政策更新、启动供应商重新评估
Q2	内部控制测试、整改发现的问题
Q3	审计前就绪审核、证据完整性检查
Q4	外部审计、管理层声明、报告分发

Anti-Patterns

反模式

Anti-Pattern	Why It Fails	Better Approach
Point-in-time compliance	Controls degrade between audits; gaps found during audit	Implement continuous monitoring and automated evidence
Manual evidence collection	Time-consuming, inconsistent, error-prone	Automate with scripts, IaC, and compliance platforms
Missing vendor assessments	Auditors flag incomplete vendor due diligence	Maintain vendor register with risk-tiered assessment schedule
Copy-paste policies	Generic policies don't match actual operations	Tailor policies to your actual environment and technology stack
Security theater	Controls exist on paper but aren't followed	Verify operating effectiveness; build controls into workflows
Skipping Type I	Jumping to Type II without foundational readiness	Start with Type I to validate control design before observation
Over-scoping TSC	Including all 5 categories when only Security is needed	Select categories based on actual customer/business requirements
Treating audit as a project	Compliance degrades after the report is issued	Build compliance into daily operations and engineering culture

反模式	失败原因	更佳方案
时点性合规	控制措施在审计之间退化；审计期间发现差距	实施持续监控和自动化证据收集
手动证据收集	耗时、不一致、易出错	使用脚本、IaC和合规平台自动化
缺失供应商评估	审计师标记供应商尽职调查不完整	维护供应商登记册并按风险等级设置评估时间表
复制粘贴政策	通用政策与实际运营不符	根据实际环境和技术栈定制政策
安全形式主义	控制措施仅存在于纸面未被执行	验证运行有效性；将控制措施融入工作流程
跳过Type I	未具备基础就绪就直接进行Type II	先通过Type I验证控制设计，再进入观察期
TSC范围过度扩大	实际仅需Security却包含所有5个类别	根据实际客户/业务需求选择类别
将审计视为一次性项目	报告发布后合规性退化	将合规融入日常运营和工程文化

Tools

工具

Control Matrix Builder

控制矩阵生成器

Generates a SOC 2 control matrix from selected TSC categories.

bash

undefined

根据选定的TSC类别生成SOC 2控制矩阵。

bash

undefined

Generate full security matrix in markdown

生成完整的安全矩阵（markdown格式）

python scripts/control_matrix_builder.py --categories security --format md

Generate matrix for multiple categories as JSON

生成多类别矩阵（JSON格式）

python scripts/control_matrix_builder.py --categories security,availability,confidentiality --format json

All categories, CSV output

所有类别，CSV输出

python scripts/control_matrix_builder.py --categories security,availability,confidentiality,processing-integrity,privacy --format csv

undefined

python scripts/control_matrix_builder.py --categories security,availability,confidentiality,processing-integrity,privacy --format csv

undefined

Evidence Tracker

证据追踪器

Tracks evidence collection status per control.

bash

undefined

跟踪每个控制措施的证据收集状态。

bash

undefined

Check evidence status from a control matrix

检查控制矩阵中的证据状态

python scripts/evidence_tracker.py --matrix controls.json --status

JSON output for integration

输出JSON用于集成

python scripts/evidence_tracker.py --matrix controls.json --status --json

undefined

python scripts/evidence_tracker.py --matrix controls.json --status --json

undefined

Gap Analyzer

差距分析器

Analyzes current controls against SOC 2 requirements and identifies gaps.

bash

undefined

分析当前控制措施与SOC 2要求的差距并识别问题。

bash

undefined

Type I gap analysis

Type I差距分析

python scripts/gap_analyzer.py --controls current_controls.json --type type1

Type II gap analysis (includes operating effectiveness)

Type II差距分析（包含运行有效性）

python scripts/gap_analyzer.py --controls current_controls.json --type type2 --json

---

python scripts/gap_analyzer.py --controls current_controls.json --type type2 --json

---

References

参考资料

Trust Service Criteria Reference — All 5 TSC categories with sub-criteria, control objectives, and evidence examples
Evidence Collection Guide — Evidence types per control, automation tools, documentation requirements
Type I vs Type II Comparison — Detailed comparison, timeline, cost analysis, and upgrade path

Trust Service准则参考 — 所有5个TSC类别及其子准则、控制目标和证据示例
证据收集指南 — 各控制领域的证据类型、自动化工具、文档要求
Type I vs Type II对比 — 详细对比、时间线、成本分析及升级路径

Cross-References

交叉引用

gdpr-dsgvo-expert — SOC 2 Privacy criteria overlaps significantly with GDPR requirements; use together when processing EU personal data
information-security-manager-iso27001 — ISO 27001 Annex A controls map closely to SOC 2 Security criteria; organizations pursuing both can share evidence
isms-audit-expert — Audit methodology and finding management patterns transfer directly to SOC 2 audit preparation

gdpr-dsgvo-expert — SOC 2隐私准则与GDPR要求高度重叠；处理欧盟个人数据时可结合使用
information-security-manager-iso27001 — ISO 27001附录A的控制措施与SOC 2安全准则密切对应；同时追求两项合规的企业可共享证据
isms-audit-expert — 审计方法和问题管理模式可直接应用于SOC 2审计准备

soc2-compliance

Original

Translation

SOC 2 Compliance

SOC 2合规

Table of Contents

目录

Overview

概述

What Is SOC 2?

什么是SOC 2？

Type I vs Type II

Type I vs Type II

Who Needs SOC 2?

谁需要SOC 2？

Typical Journey

典型流程

Trust Service Criteria

Trust Service准则

Security (Common Criteria CC1-CC9) — Required

Security（通用准则CC1-CC9）—— 必填

Availability (A1) — Optional

Availability（A1）—— 可选

Confidentiality (C1) — Optional

Confidentiality（C1）—— 可选

Processing Integrity (PI1) — Optional

Processing Integrity（PI1）—— 可选

Privacy (P1-P8) — Optional

Privacy（P1-P8）—— 可选

Control Matrix Generation

控制矩阵生成

Matrix Structure

矩阵结构

Control Naming Convention

控制命名规范

Workflow

流程

Gap Analysis Workflow

差距分析流程

Phase 1: Current State Assessment

第一阶段：当前状态评估

Phase 2: Gap Identification

第二阶段：差距识别

Phase 3: Remediation Planning

第三阶段：整改计划

Phase 4: Timeline Planning

第四阶段：时间线规划

Evidence Collection

证据收集

Evidence Types by Control Category

按控制类别划分的证据类型

Automation Opportunities

自动化机会

Continuous Monitoring

持续监控

Audit Readiness Checklist

审计就绪检查清单

Pre-Audit Preparation (4-6 Weeks Before)

审计前准备（审计前4-6周）

Readiness Scoring

就绪评分

Common Audit Findings

常见审计发现

Vendor Management

供应商管理

Third-Party Risk Assessment

第三方风险评估

Vendor Risk Tiers

供应商风险等级

Subservice Organizations

子服务机构

Continuous Compliance

持续合规

From Point-in-Time to Continuous

从时点性到持续性

Implementation Steps

实施步骤

Annual Re-Assessment Cycle

年度重新评估周期

Anti-Patterns