soc2-compliance

SOC 2 合规

面向 SaaS 公司的 SOC 2 Type I 与 Type II 合规准备。涵盖信任服务标准映射、控制矩阵生成、证据收集、差距分析以及审计就绪评估。

目录

• 概述
• 信任服务标准
• 控制矩阵生成
• 差距分析工作流
• 证据收集
• 审计就绪清单
• 供应商管理
• 持续合规
• 反模式
• 工具
• 参考资料
• 交叉引用

---

概述

什么是 SOC 2？

SOC 2（System and Organization Controls 2，系统与组织控制 2）是由 AICPA 制定的审计框架，用于评估服务机构如何管理客户数据。它适用于任何存储、处理或传输客户信息的技术公司，主要包括 SaaS、云基础设施和托管服务提供商。

Type I 与 Type II 对比

方面	Type I	Type II
范围	某一时间点的控制设计	一段时间内的控制设计与运行有效性
期限	快照（单一日期）	观察期（3-12 个月，通常为 6 个月）
证据	控制描述、政策	控制描述 + 运行证据（日志、工单、截图）
成本	2 万-5 万美元（审计费用）	3 万-10 万美元以上（审计费用）
时间线	1-2 个月（审计阶段）	6-12 个月（观察期 + 审计）
最适合	首次合规、市场需求紧迫	成熟组织、企业客户

谁需要 SOC 2？

• 向企业客户销售的 SaaS 公司
• 承载客户工作负载的云基础设施提供商
• 管理 PII、PHI 或金融数据的数据处理方
• 可访问客户系统的托管服务提供商
• 任何客户要求第三方保证的供应商

典型流程

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)

---

信任服务标准

SOC 2 围绕五类信任服务标准（TSC）构建。安全性是每份 SOC 2 报告的必需项；其余四类为可选项，可根据业务需要选择。

安全性（通用标准 CC1-CC9）— 必需

每份 SOC 2 报告的基础。映射到 COSO 2013 原则。

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

可用性（A1）— 可选

标准	重点	关键控制
A1.1	容量管理	基础设施扩展、资源监控、容量规划
A1.2	恢复运营	备份程序、灾难恢复、BCP 测试
A1.3	恢复测试	灾备演练、故障切换测试、RTO/RPO 验证

适用情形： 客户依赖你的正常运行时间；你有 SLA；停机会直接造成业务影响。

机密性（C1）— 可选

标准	重点	关键控制
C1.1	识别	数据分类策略、机密数据清单
C1.2	保护	静态和传输中加密、DLP、访问限制
C1.3	处置	安全删除流程、介质清除、保留期限执行

适用场景： 你处理商业秘密、专有数据或合同约定的机密信息。

处理完整性（PI1）— 可选

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

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

隐私（P1-P8）— 可选

标准	重点	关键控制
P1	告知	隐私政策、数据收集告知、目的限制
P2	选择与同意	选择加入/退出、同意管理、偏好跟踪
P3	收集	最小化收集、合法依据、目的说明
P4	使用、保留、处置	目的限制、保留时间表、安全处置
P5	访问	数据主体访问请求、更正权
P6	披露与通知	第三方共享、违规通知
P7	质量	数据准确性核验、更正机制
P8	监控与执行	隐私项目监控、投诉处理

适用场景： 你处理个人身份信息，且客户期望获得隐私保障（可与 GDPR 合规相辅相成）。

---

控制矩阵生成

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

矩阵结构

字段	说明
控制 ID	唯一标识符（例如 SEC-001、AVL-003）
TSC 映射	该控制措施涵盖的标准（例如 CC6.1、A1.2）
控制描述	该控制措施的作用
控制类型	预防性、检测性或纠正性
负责人	负责的个人或团队
频率	持续、每日、每周、每月、每季度、每年
证据类型	截图、日志、政策、配置、工单
测试程序	审计人员如何验证该控制措施

控制命名规范

{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

工作流程

1. 根据业务需求选择适用的 TSC 类别
2. 运行 control_matrix_builder.py 生成基线矩阵
3. 根据实际环境定制控制措施
4. 分配负责人并明确证据要求
5. 验证覆盖范围——每个已选 TSC 标准至少须有一项控制措施

---

差距分析工作流程

第一阶段：当前状态评估

1. 记录现有控制措施——盘点所有安全政策、程序和技术控制措施
2. 映射到 TSC——将现有控制措施与信任服务标准对齐
3. 收集证据样本——获取控制措施存在并有效运行的证明
4. 访谈控制负责人——核实其理解和执行情况

第二阶段：差距识别

针对当前控制措施运行 gap_analyzer.py，以识别：

• 缺失的控制措施——没有对应控制措施的 TSC 标准
• 部分实施——控制措施存在，但缺乏证据或执行不一致
• 设计缺陷——控制措施已设计，但未能充分满足标准
• 运行缺陷（仅限 Type II）——控制措施设计正确，但运行不够有效

第 3 阶段：整改规划

针对每个差距，定义以下字段：

字段	说明
Gap ID	参考标识符
TSC Criteria	受影响的标准条款
Gap Description	缺失或不充分之处
Remediation Action	关闭差距的具体步骤
Owner	负责整改的人员
Priority	Critical / High / Medium / Low
Target Date	完成期限
Dependencies	必须先完成的其他差距或项目

第 4 阶段：时间规划

优先级	目标整改时限
Critical	2-4 周
High	4-8 周
Medium	8-12 周
Low	12-16 周

---

证据收集

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

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

自动化机会

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

持续监控

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

1. 自动化证据采集：按计划定时拉取证据的脚本
2. 控制仪表盘：实时查看控制状态
3. 基于告警的监控：控制偏离合规状态时发出通知
4. 证据库：集中存储并带时间戳的证据

---

审计准备检查清单

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

• 所有控制项均已记录描述、负责人和执行频率
• 已收集整个观察期（Type II）的证据
• 控制矩阵已评审，差距已整改
• 策略已在过去 12 个月内签署并分发
• 访问评审已按要求频率完成
• 漏洞扫描为最新（无超出 SLA 未修补的严重/高危漏洞）
• 事件响应计划已在过去 12 个月内测试
• 所有分包服务组织的供应商风险评估均为最新
• 灾备/业务连续性计划已在过去 12 个月内测试并记录
• 全体员工已完成安全培训

准备度评分

分数	评级	含义
90-100%	Audit Ready	可放心推进
75-89%	Minor Gaps	安排审计前先行整改
50-74%	Significant Gaps	需要整改
< 50%	Not Ready	需要大规模搭建合规体系

常见审计发现

发现	根本原因	预防措施
访问权限审查不完整	流程人工操作，无提醒	自动触发季度审查
缺少变更审批	紧急变更绕过流程	定义紧急变更流程，并在事后补充审批
漏洞扫描结果过期	扫描器配置有误	自动每周扫描并配置告警
政策未确认	缺少跟踪机制	年度电子签名工作流
缺少供应商评估	没有供应商清单	维护供应商登记册并制定审查计划

---

供应商管理

第三方风险评估

凡访问、存储或处理客户数据的供应商，都必须接受评估：

1. 供应商清单：维护所有服务提供商的登记册
2. 风险分级：按数据访问级别对供应商进行分类
3. 尽职调查：收集 SOC 2 报告、安全问卷和认证材料
4. 合同保护：确保签订 DPA，并包含安全要求和数据泄露通知条款
5. 持续监控：每年重新评估，并持续关注相关新闻动态

供应商风险等级

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

转包服务机构

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

• 包含法：你的报告涵盖转包服务机构的控制措施（需要其配合）
• 剔除法：你的报告排除其控制措施，但引用其 SOC 2 报告
• 大多数公司采用剔除法，并纳入互补用户实体控制（CUEC）

---

持续合规

从时点合规到持续合规

维度	时点合规	持续合规
证据收集	人工，审计前进行	自动化，持续进行
控制监控	定期审查	实时仪表盘
偏差检测	在审计时发现	基于告警，即时发现
整改	被动	主动
审计准备	4 至 8 周仓促准备	随时可接受审计

实施步骤

1. 自动化证据收集：定时任务、API 集成、IaC 快照
2. 构建控制仪表盘：将控制状态汇总到统一视图
3. 配置偏差告警：控制措施不再合规时及时通知
4. 建立审查节奏：控制负责人每周对接，每月召开指导会议
5. 维护证据库：集中存储、带时间戳，并可供审计人员访问

年度重新评估周期

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

---

反模式

反模式	失败原因	更好的做法
时点式合规	审计之间控制措施会逐渐失效；审计时才发现缺口	实施持续监控和自动化证据收集
手动收集证据	耗时、不一致、容易出错	借助脚本、IaC 和合规平台实现自动化
缺失供应商评估	审计师会指出供应商尽职调查不完整	维护供应商台账，并制定基于风险分级的评估计划
照搬政策模板	通用政策与实际运营不符	根据实际环境和技术栈定制政策
安全表演	控制措施只存在于纸面，并未被执行	验证运行有效性；将控制措施嵌入工作流
跳过 Type I	在缺乏基础就绪度的情况下直接进行 Type II	先通过 Type I 验证控制设计，再进行运行观察
TSC 范围过大	只需要安全性时却纳入全部 5 个类别	根据实际客户和业务需求选择类别
把审计当作一次性项目	出具报告后合规水平随即下降	将合规融入日常运营和工程文化

---

工具

控制矩阵生成器

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

# Generate full security matrix in markdown
python scripts/control_matrix_builder.py --categories security --format md

# Generate matrix for multiple categories as JSON
python scripts/control_matrix_builder.py --categories security,availability,confidentiality --format json

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

证据跟踪器

跟踪每项控制的证据收集状态。

# Check evidence status from a control matrix
python scripts/evidence_tracker.py --matrix controls.json --status

# JSON output for integration
python scripts/evidence_tracker.py --matrix controls.json --status --json

差距分析器

将当前控制措施与 SOC 2 要求进行对比，并识别差距。

# Type I gap analysis
python scripts/gap_analyzer.py --controls current_controls.json --type type1

# Type II gap analysis (includes operating effectiveness)
python scripts/gap_analyzer.py --controls current_controls.json --type type2 --json

---

参考资料

• Trust Service Criteria Reference — 全部 5 个 TSC 类别及其子标准、控制目标和证据示例
• Evidence Collection Guide — 各项控制的证据类型、自动化工具和文档要求
• Type I vs Type II Comparison — 详细对比、时间线、成本分析和升级路径

---

交叉引用

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