soc2-compliance-expert

SOC 2 合规专家

SOC 2 Type I 和 Type II 合规管理，涵盖全部信任服务标准（TSC）、基础设施安全验证、证据收集和端到端审计准备。

---

SOC 2 概览

Type I 与 Type II

方面	Type I	Type II
范围	某一时点的控制设计	一段时期内的设计及运行有效性
时长	单个日期（快照）	观察期（3-12 个月，通常为 6-12 个月）
费用	$20K-$60K（首次审计）	$40K-$150K（首次审计）
时间安排	1-3 个月	6-15 个月（包含观察期）
客户偏好	早期阶段可接受	企业客户要求

先从 Type I 开始验证控制设计，然后在 6 个月内过渡到 Type II。

信任服务标准摘要

类别	重点	控制项
CC1-CC5	通用标准（基于 COSO）	控制环境、沟通、风险、监控、控制活动
CC6	逻辑和物理访问	身份验证、授权、物理安全、加密
CC7	系统运营	漏洞管理、监控、事件响应、BCP
CC8	变更管理	授权、测试、部署控制
CC9	风险缓解	供应商管理、业务中断、风险转移
A1	可用性	容量规划、DR、恢复测试
PI1	处理完整性	数据验证、错误处理、对账
C1	保密性	分类、加密、处置
P1	隐私	通知、同意、数据主体权利、保留

有关各类别的详细控制要求，请参阅 REFERENCE.md。

---

先澄清

运行就绪度评估前，请先确定以下输入。如果某项缺失或含糊不清，且会影响评估结果，请询问；如果不会影响，则使用合理的默认值，并说明所用默认值。

• 报告类型： Type I（某一时点的设计）还是 Type II（一段时期内的运行有效性）（决定观察期要求和时间安排）。
• TSC 范围： 除强制要求的 Security 外，纳入哪些标准（Availability、Processing Integrity、Confidentiality、Privacy）（决定所需的控制和证据）。
• 子服务组织： carve-out 还是 inclusive（影响范围和系统描述）。

针对当前请求，只询问最重要的两到三项，而不是列出的全部内容。如果用户希望立即获得结果，请直接生成，并在顶部说明假设。

就绪度评估工作流

Agent 将引导组织完成 SOC 2 就绪流程，从差距分析到审计完成。

工作流：阶段 1 -- 差距分析（第 1-4 周）

1. 定义范围 -- 确定要纳入的 TSC 类别（Security 为强制要求），定义系统边界，识别子服务组织（carve-out 还是 inclusive），记录主要服务承诺。
2. 评估当前状态 -- 清点现有政策和程序，将当前控制映射到 TSC 要求，并访谈流程负责人和控制执行人员。
3. 使用 scripts/soc2_readiness_checker.py 运行自动化差距分析。
4. 记录差距 -- 缺失的控制、缺少证据的控制、运行无效的控制。
5. 按风险级别和整改工作量对差距进行优先级排序。
6. 验证检查点： 差距分析涵盖所有范围内的 TSC 类别；每项差距均已评定严重程度并指定整改负责人。

工作流：第 2 阶段 -- 整改（第 5-16 周）

1. 制定/更新政策 -- 信息安全政策、各控制领域的配套流程、政策审查和审批工作流。
2. 实施技术控制 -- 配置 IdP 以强制执行 SSO/MFA，部署终端安全措施（MDM、EDR、磁盘加密），实施 SIEM 日志记录和监控，配置备份和 DR，加固云基础设施。
3. 建立流程 -- 访问审查流程、变更管理工作流、事件响应流程、供应商管理计划、安全意识培训。
4. 设置证据收集 -- 配置自动收集，建立存储库结构，按 TSC 类别定义刷新频率。
5. 验证检查点： 所有已发现的差距均已整改；通过 scripts/soc2_infrastructure_auditor.py 验证技术控制；证据收集已生成材料。

工作流：第 3 阶段 -- 审计前准备（第 17-20 周）

1. 开展内部准备度评估 -- 针对所有范围内的 TSC 进行模拟审计，验证证据的完整性和质量，运行基础设施审计工具进行技术验证。
2. 整改审计前发现的问题 -- 解决剩余差距，强化证据。
3. 选择并聘请 CPA 公司 -- 协商范围、时间表和费用；安排启动会议；准备系统说明书草案。
4. 验证检查点： 模拟审计通过，且不存在严重差距；系统说明书已审阅；已聘请审计师。

工作流：第 4 阶段 -- 执行审计

1. Type I 审计（如适用）-- 审计师审查控制设计；管理层提供声明；在 Type II 审计前解决审计发现的问题。
2. Type II 观察期（3-12 个月）-- 控制措施持续一致地运行，持续收集证据，每季度进行自我评估，并定期与审计师沟通。
3. 现场工作（2-4 周）-- 审计师抽取样本、测试控制措施、访谈人员；审阅报告草案；发布最终报告。
4. 验证检查点： 已收到无保留意见；任何审计发现均有管理层回应和整改计划。

---

证据收集框架

按 TSC 类别划分的证据

TSC	证据类型	收集方法	刷新频率
CC1	行为准则确认记录	HR 系统导出	每年
CC2	安全意识培训记录	LMS 导出	持续
CC3	风险评估报告、风险登记册	GRC 平台	每年/每季度
CC4	渗透测试报告、漏洞扫描	第三方/扫描器	每年/每月
CC5	带有版本历史记录的政策文件	政策管理	每年审查
CC6	访问审查、MFA 注册、离职处理	IAM/IdP/HRIS	每季度/按事件
CC7	漏洞整改、事件记录	工单/ITSM	持续
CC8	带有审批记录的变更工单、代码审查	ITSM/Git	每次变更
CC9	供应商风险评估、供应商 SOC 2 报告	GRC 平台	每年
A1	正常运行时间报告、DR 测试、备份日志	监控/备份	每月/每半年
PI1	数据验证/对账报告	应用程序日志	每个流程
C1	数据分类清单、加密配置	手动/自动	每年/每季度
P1	PIA、DSR 响应跟踪	隐私工具	按事件

示例：证据收集命令

# Generate evidence checklist for all TSC categories
python scripts/evidence_collector.py --generate-checklist --categories all

# Track evidence status
python scripts/evidence_collector.py --status evidence-tracker.json

# Update specific evidence item
python scripts/evidence_collector.py --update evidence-tracker.json \
  --item CC6.1-MFA --status collected

# Generate readiness dashboard
python scripts/evidence_collector.py --dashboard evidence-tracker.json

# Export for auditor review
python scripts/evidence_collector.py --export evidence-tracker.json --format json

自动化策略

GRC 平台： Vanta、Drata、Secureframe、Laika、AuditBoard——通过 API 集成自动收集证据、持续监控控制措施，并提供审计师协作门户。

基础设施即证据： 云配置快照（AWS Config、Azure Policy、GCP Org Policies）、作为配置证据的 Terraform 状态、作为变更管理证据的 Git 历史记录、作为部署控制证据的 CI/CD 流水线日志。

---

基础设施安全验证

该 Agent 根据 SOC 2 要求验证基础设施配置。

快速参考：基础设施检查

领域	关键检查项	SOC 2 映射
云（AWS/Azure/GCP）	加密、IAM、日志记录、网络、备份、密钥	CC6、CC7、A1、C1
DNS	SPF、DKIM、DMARC、DNSSEC、CAA	CC6.6、CC2.2
TLS/SSL	TLS 1.2+、AEAD 密码套件、HSTS、自动续期	CC6.7
终端	MDM、磁盘加密、EDR、修补、屏幕锁定	CC6.1、CC6.8、CC7.1
网络	分段、WAF、DDoS、VPN/ZTNA、出口流量过滤	CC6.6、A1.1
容器	镜像扫描、精简基础镜像、禁止特权模式、RBAC	CC6.1、CC7.1
CI/CD	签名提交、分支保护、SAST/DAST、SBOM	CC7.1、CC8.1
密钥	Vault 存储、轮换策略、Git 扫描	CC6.1

如需查看各提供商的详细控制映射，请参阅 REFERENCE.md。

示例：基础设施审计命令

# Full infrastructure audit
python scripts/soc2_infrastructure_auditor.py --config infra-config.json

# Audit specific domains only
python scripts/soc2_infrastructure_auditor.py --config infra-config.json \
  --domains dns tls cloud

# JSON output with severity ratings
python scripts/soc2_infrastructure_auditor.py --config infra-config.json --format json

# Generate sample configuration template
python scripts/soc2_infrastructure_auditor.py --generate-template

---

审计时间表

典型时间表（首次 SOC 2）

阶段	时长	活动
界定范围	2-4 周	定义 TSC、系统边界、选择审计师
差距分析	2-4 周	评估当前控制，识别差距
整改	8-16 周	实施缺失的控制、政策和流程
Type I 审计	2-4 周	评估特定时点的控制设计
Type II 观察期	3-12 个月	控制持续运行并持续收集证据
Type II 现场工作	2-4 周	审计师测试、证据审查、访谈
报告出具	2-4 周	审阅草稿、管理层回复、最终报告

年度续审

• 在观察期结束前 3 个月开始规划续审
• 在各审计期间持续保持合规
• 在新的观察期开始前处理上一年度的发现
• 报告之间的间隔可提供衔接函

---

事件响应要求

IRP 结构

1. 准备 -- 确定 IR 团队，建立沟通渠道，为常见事件制定操作手册，聘请法律/公关顾问。
2. 检测与分析 -- 覆盖监控/告警，划分严重级别（SEV1-SEV4），制定分诊流程和升级矩阵。
3. 遏制、根除、恢复 -- 隔离受影响的系统，保全证据，确定根本原因，恢复并验证。
4. 事件后处理 -- 在 5 个工作日内进行无责复盘，总结经验教训，改进控制，评估通知要求（跟踪 MTTD、MTTR、MTTC）。

如需了解严重级别定义和违规通知时限，请参阅 REFERENCE.md。

---

工具

SOC 2 就绪度检查器

# Full readiness assessment
python scripts/soc2_readiness_checker.py --config org-controls.json

# JSON output for programmatic use
python scripts/soc2_readiness_checker.py --config org-controls.json --format json

# Check specific TSC categories
python scripts/soc2_readiness_checker.py --config org-controls.json \
  --categories security availability

# Include cloud provider control mapping
python scripts/soc2_readiness_checker.py --config org-controls.json --cloud-mapping

证据收集器

# Generate checklist and track status
python scripts/evidence_collector.py --generate-checklist --categories all
python scripts/evidence_collector.py --status evidence-tracker.json
python scripts/evidence_collector.py --dashboard evidence-tracker.json

基础设施审计器

# Validate infrastructure against SOC 2 requirements
python scripts/soc2_infrastructure_auditor.py --config infra-config.json
python scripts/soc2_infrastructure_auditor.py --config infra-config.json --format json

---

反模式

在控制措施开始运行前启动观察期

错误： 控制措施仍在建设中时，Type II 观察期就已开始。 原因： 销售交易敲定了审计日期，而启动计时让人感觉是在推进工作。 建议： 所有范围内的控制措施都必须从第一天起运行；观察期内出现差距会成为报告中的一项发现。运行 soc2_readiness_checker.py，并在观察期开始前弥补关键差距。

到现场工作时才收集证据

错误： 在审计师到来前几周才收集截图、工单和日志。 原因： 证据让人觉得只是文书工作，可以等到有人要求时再处理。 建议： 无法证明的控制措施会被视为不存在。从观察期第一天起开始收集，并使用 evidence_collector.py 跟踪每一项证据。

确定每个信任服务准则类别的范围

错误做法： 将安全性、可用性、处理完整性、保密性和隐私全部纳入范围。 原因： 范围更广的报告在买家看来更有说服力。 正确做法： 安全性是必选项；只有在客户提出要求时才添加其他类别。每增加一个类别，都会增加控制措施、证据和审计成本。

更多常见错误见 references/audit-preparation-playbook.md（应避免的常见错误）。

参考资料

文档	描述
REFERENCE.md	详细的 TSC 控制措施、基础设施检查、访问控制规范、供应商管理、培训、IRP、BC/DR
信任服务准则指南	完整的 TSC 参考资料，包含控制目标和审计问题
基础设施安全控制措施	云、DNS、TLS、终端、容器、CI/CD 安全配置
审计准备指南	端到端的审计准备指南，包含时间表、检查清单、成本估算

---

故障排查

问题	可能原因	解决方法
就绪度检查器在所有类别中的得分均为 0%	Controls JSON 缺少 config_key 值，或这些值全部为 false	确认输入 JSON 在正确的 config_key 下，将每项 TSC 控制措施映射为布尔值。运行 --generate-sample > sample-config.json 查看预期结构。
基础设施审计器将所有检查报告为“失败”	基础设施配置 JSON 为空或使用了错误的键名	运行 --generate-template 生成有效模板。使用实际基础设施状态填充 DNS、TLS、云、终端及其他部分。
证据收集器生成的检查清单缺少类别	--categories 标志筛选了输出内容	使用 --categories all 生成完整检查清单。可用类别：security、availability、processing_integrity、confidentiality、privacy。
证据跟踪器状态未更新	跟踪器文件路径不正确或文件不可写	确认传递给 --status 或 --update 的路径指向现有的跟踪器 JSON 文件。检查文件权限。
就绪度报告中未显示云映射	未包含 --cloud-mapping 标志	在就绪度检查器命令中添加 --cloud-mapping，以在输出中包含 AWS/Azure/GCP 控制措施映射。
Type II 观察期对审计师而言过短	观察期不足 3 个月	大多数 CPA 事务所要求 Type II 的观察期至少为 3 个月。6-12 个月的观察期更具说服力。请在确定范围阶段规划观察期。
审计师要求提供跟踪器中没有的证据	证据目录未涵盖所选范围内的所有 TSC 子标准	在自动生成的检查清单中补充审计师特定的证据要求。每家 CPA 事务所可能会在标准 TSC 证据项目之外提出额外要求。

---

成功标准

• 明确定义 SOC 2 范围，选定所有适用的 TSC 类别，记录系统边界，并识别次级服务组织（剔除法或纳入法）
• 完成差距分析，为每项已识别的差距分配严重性评级、整改负责人和目标完成日期
• 在聘请 CPA 事务所前，所有范围内的 TSC 类别就绪度评分达到 80% 以上；在 Type II 现场审计前提升至 95% 以上
• 证据收集框架投入运行，设有集中式存储库、针对每个 TSC 类别定义更新频率，并尽可能实现自动收集
• 基础设施审计通过，DNS、TLS、云、终端或访问控制领域均无严重或高严重性发现
• Type II 观察期至少为 6 个月，期间持续运行控制措施、每季度开展自我评估，且无重大控制失效
• 获得无保留的 SOC 2 Type II 意见，任何发现均由管理层回应并制定有记录的整改计划

---

范围与限制

范围内：

• 针对所有 TSC 类别（CC1-CC9、A1、PI1、C1、P1）开展 SOC 2 Type I 和 Type II 就绪度评估
• 基础设施安全验证（DNS、TLS、云、终端、网络、容器、CI/CD、机密信息）
• 生成并跟踪证据收集框架
• 开展差距分析，提供按严重性评级的发现和整改指导
• 规划审计时间线，并准备聘请 CPA 事务所
• 制定事件响应计划的结构和要求
• 设计持续合规计划

范围外：

• CPA 事务所执行审计（这些工具用于审计准备；实际的 Type I/II 报告需要由独立 CPA 事务所出具）
• SOC 1（ICFR）评估（SOC 1 涵盖财务报告控制，而非安全性、可用性或隐私）
• 生成 SOC 3 报告（SOC 3 是根据 SOC 2 编制的面向公众的摘要；需先完成 SOC 2 审计）
• 执行渗透测试（使用 infrastructure-compliance-auditor 或聘请第三方渗透测试公司）
• 选择或实施 GRC 平台（此技能兼容 Vanta、Drata、Secureframe 等平台，但不负责实施）
• 就 SOC 2 报告的客户合同要求提供法律建议
• 物理安全评估（基础设施审计工具涵盖逻辑控制；物理数据中心审计需要现场评估）

---

集成点

技能	集成
infrastructure-compliance-auditor	提供 Vanta 级别的基础设施检查，涵盖云、DNS、TLS、终端、访问控制和 CI/CD，可直接映射到 SOC 2 TSC 要求
nist-csf-specialist	NIST CSF 功能可映射到 SOC 2 TSC 类别；对于同时推进两项工作的组织，可使用控制映射器构建统一控制矩阵
information-security-manager-iso27001	ISO 27001 附录 A 控制措施构成管理体系骨干，可满足许多 SOC 2 要求；共享证据可减轻审计负担
pci-dss-specialist	PCI DSS 要求与 SOC 2 CC6（访问）、CC7（运营）、CC8（变更管理）存在重叠；适用于支付处理组织的共享控制措施
gdpr-dsgvo-expert	GDPR 要求与 SOC 2 隐私（P1）标准一致；处理欧盟个人数据的组织可利用共享隐私控制措施
nis2-directive-specialist	NIS2 最低安全措施与 SOC 2 安全标准存在重叠；欧盟实体可映射共享的事件响应、访问控制和加密控制措施

---

工具参考

soc2_readiness_checker.py

根据 SOC 2 信任服务准则评估组织控制措施，并按类别评分。

标志	必需	说明
--config	是（或 --generate-sample）	组织控制措施 JSON 文件的路径，文件中每项 TSC 控制措施均使用布尔值
--format	否	输出格式：json 表示结构化输出；省略则输出人类可读文本
--categories	否	要评估的 TSC 类别，以空格分隔（例如 security availability）。省略则评估全部类别。
--cloud-mapping	否	在输出中包含云服务提供商（AWS/Azure/GCP）的控制措施映射
--generate-sample	否	生成示例控制措施 JSON 模板（使用 > sample-config.json 重定向到文件）

evidence_collector.py

生成证据收集清单，并跟踪证据收集状态。

标志	必需	说明
--generate-checklist	否	为指定类别生成证据收集清单
--categories	否	TSC 类别，以空格分隔：security、availability、processing_integrity、confidentiality、privacy 或 all
--status	否	要显示收集状态的证据跟踪器 JSON 文件路径
--update	否	要更新的证据跟踪器 JSON 文件路径（与 --item 和 --status 一起使用）
--item	否	要更新的证据项标识符（例如 CC6.1-MFA）
--dashboard	否	要生成就绪情况仪表板的证据跟踪器 JSON 文件路径
--export	否	要导出的证据跟踪器 JSON 文件路径
--format	否	导出格式：json 表示结构化输出

soc2_infrastructure_auditor.py

审计基础设施配置是否符合 SOC 2 要求，并提供按严重性评级的审计发现。

标志	必需	说明
--config	是（或 --generate-template）	基础设施配置 JSON 文件的路径，文件包含 DNS、TLS、云、终端节点及其他领域的设置
--format	否	输出格式：json 表示包含严重性评级的结构化审计发现；省略则输出人类可读文本
--domains	否	要审计的基础设施领域，以空格分隔（例如 dns tls cloud）。省略则审计所有领域。
--generate-template	否	生成示例基础设施配置模板（使用 > infra-config.json 重定向到文件）