---
name: "soc2-compliance"
description: "当用户要求准备 SOC 2 审计、映射信任服务准则、构建控制矩阵、收集审计证据、执行差距分析或评估 SOC 2 Type I 与 Type II 就绪度时使用。"
---

# SOC 2 合规

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

## 目录

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

---

## 概述

### 什么是 SOC 2？

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

### Type I 与 Type II 对比

| 方面 | Type I | Type II |
|--------|--------|---------|
| **范围** | 某一时点的控制设计 | 一段时间内的设计 AND 运行有效性 |
| **持续时间** | 快照（单一日） | 观察窗口（3-12 个月，通常为 6 个月） |
| **证据** | 控制描述、策略 | 控制描述 + 运行证据（日志、工单、截图） |
| **成本** | $20K-$50K（审计费用） | $30K-$100K+（审计费用） |
| **时间线** | 1-2 个月（审计阶段） | 6-12 个月（观察 + 审计） |
| **最适合** | 首次合规、快速满足市场需求 | 成熟组织、企业客户 |

### 谁需要 SOC 2？

- **SaaS 公司**——向企业客户销售产品
- **云基础设施提供商**——处理客户工作负载
- **数据处理者**——管理 PII、PHI 或财务数据
- **托管服务提供商**——可访问客户系统
- **任何供应商**——其客户要求第三方保障

### 典型路径

```
差距评估 → 整改 → Type I 审计 → 观察期 → Type II 审计 → 年度续审
 (4-8 周)   (8-16 周)  (4-6 周)   (6-12 月)    (4-6 周)    （持续）
```

---

## 信任服务准则

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** | 监控与执行 | 隐私项目监控、投诉处理 |

**选择时机：** 您处理 PII 且客户期望隐私保障（补充 GDPR 合规）。

---

## 控制矩阵生成

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

### 矩阵结构

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

### 控制命名规范

```
{类别}-{编号}
SEC-001 至 SEC-NNN  → 安全性
AVL-001 至 AVL-NNN  → 可用性
CON-001 至 CON-NNN  → 机密性
PRI-001 至 PRI-NNN  → 处理完整性
PRV-001 至 PRV-NNN  → 隐私
```

### 工作流

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

---

## 差距分析工作流

### 阶段 1：现状评估

1. **记录现有控制**——盘点所有安全策略、流程和技术控制
2. **映射至 TSC**——将现有控制与信任服务准则对齐
3. **收集证据样本**——收集控制存在且正在运行的证明
4. **访谈控制负责人**——验证理解程度和执行情况

### 阶段 2：差距识别

对当前控制运行 `gap_analyzer.py` 以识别：

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

### 阶段 3：整改计划

针对每个差距，定义：

| 字段 | 描述 |
|-------|-------------|
| 差距 ID | 引用标识符 |
| TSC 准则 | 受影响的准则 |
| 差距描述 | 缺失或不足的内容 |
| 整改措施 | 弥补差距的具体步骤 |
| 负责人 | 负责整改的人员 |
| 优先级 | 严重 / 高 / 中 / 低 |
| 目标日期 | 完成期限 |
| 依赖项 | 必须先完成的其他差距或项目 |

### 阶段 4：时间线规划

| 优先级 | 目标整改时间 |
|----------|--------------------|
| 严重 | 2-4 周 |
| 高 | 4-8 周 |
| 中 | 8-12 周 |
| 低 | 12-16 周 |

---

## 证据收集

### 按控制类别的证据类型

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

### 自动化机会

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

### 持续监控

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

1. **自动化证据收集**——按计划自动拉取证据的脚本
2. **控制仪表板**——实时查看控制状态
3. **基于告警的监控**——当控制偏离合规状态时发出通知
4. **证据仓库**——集中式、带时间戳的证据存储

---

## 审计就绪检查清单

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

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

### 就绪度评分

| 得分 | 评级 | 含义 |
|-------|--------|---------|
| 90-100% | 审计就绪 | 放心推进 |
| 75-89% | 少量差距 | 在安排审计前解决 |
| 50-74% | 显著差距 | 需要整改 |
| < 50% | 未就绪 | 需要大规模项目构建 |

### 常见审计发现

| 发现项 | 根本原因 | 预防措施 |
|---------|-----------|-----------|
| 不完整的访问审查 | 手动流程、无提醒 | 自动化季度审查触发器 |
| 缺少变更审批 | 紧急变更绕过流程 | 定义紧急变更流程并辅以事后审批 |
| 过期的漏洞扫描 | 扫描器配置错误 | 自动化每周扫描并设置告警 |
| 策略未被确认 | 无跟踪机制 | 年度电子签名工作流 |
| 缺少供应商评估 | 无供应商清单 | 维护供应商登记册并设定审查计划 |

---

## 供应商管理

### 第三方风险评估

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

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. **自动化证据收集**——cron 作业、API 集成、IaC 快照
2. **构建控制仪表板**——将控制状态汇总到单一视图
3. **配置漂移告警**——当控制偏离合规时发出通知
4. **建立审查节奏**——每周控制负责人检查、每月指导会议
5. **维护证据仓库**——集中式、带时间戳、审计师可访问

### 年度复评周期

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

---

## 反模式

| 反模式 | 失败原因 | 更好的方法 |
|--------------|-------------|----------------|
| 时间点合规 | 控制项在审计间退化；审计时发现差距 | 实施持续监控和自动化证据收集 |
| 手动证据收集 | 耗时、不一致、易出错 | 通过脚本、IaC 和合规平台自动化 |
| 缺少供应商评估 | 审计师指出供应商尽职调查不完整 | 维护供应商登记册并制定基于风险等级的评估计划 |
| 复制粘贴策略 | 通用策略与实际运行不符 | 根据实际环境和技术栈定制策略 |
| 安全表演 | 控制只在纸面上存在但未被执行 | 验证运行有效性；将控制融入工作流 |
| 跳过 Type I | 在基础就绪前直接进入 Type II | 从 Type I 开始，在观察前验证控制设计 |
| TSC 范围过广 | 包含全部 5 个类别而实际只需安全性 | 根据实际客户/业务需求选择类别 |
| 将审计视为项目 | 报告发布后合规水平下降 | 将合规融入日常运营和工程文化 |

---

## 工具

### 控制矩阵生成器

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

```bash
# 生成完整的安全性矩阵，输出为 Markdown
python scripts/control_matrix_builder.py --categories security --format md

# 为多个类别生成 JSON 格式的矩阵
python scripts/control_matrix_builder.py --categories security,availability,confidentiality --format json

# 所有类别，CSV 输出
python scripts/control_matrix_builder.py --categories security,availability,confidentiality,processing-integrity,privacy --format csv
```

### 证据跟踪器

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

```bash
# 从控制矩阵检查证据状态
python scripts/evidence_tracker.py --matrix controls.json --status

# JSON 输出用于集成
python scripts/evidence_tracker.py --matrix controls.json --status --json
```

### 差距分析器

分析当前控制与 SOC 2 要求的差距。

```bash
# Type I 差距分析
python scripts/gap_analyzer.py --controls current_controls.json --type type1

# Type II 差距分析（含运行有效性）
python scripts/gap_analyzer.py --controls current_controls.json --type type2 --json
```

---

## 参考资料

- [信任服务准则参考](references/trust_service_criteria.md)——所有 5 个 TSC 类别及其子准则、控制目标和证据示例
- [证据收集指南](references/evidence_collection_guide.md)——每个控制的证据类型、自动化工具、文档要求
- [Type I 与 Type II 对比](references/type1_vs_type2.md)——详细对比、时间线、成本分析和升级路径

---

## 交叉引用

- **[gdpr-dsgvo-expert](../gdpr-dsgvo-expert/SKILL.md)**——SOC 2 隐私准则与 GDPR 要求有显著重叠；处理欧盟个人数据时结合使用
- **[information-security-manager-iso27001](../information-security-manager-iso27001/SKILL.md)**——ISO 27001 附录 A 控制与 SOC 2 安全性准则紧密对应；同时追求两者的组织可以共享证据
- **[isms-audit-expert](../isms-audit-expert/SKILL.md)**——审计方法论和发现项管理模式可直接迁移至 SOC 2 审计准备