关于 soc2-prep
soc2-prep 是面向准备 SOC 2 认证或回应客户合规要求的初创企业的准备技能。它梳理适用标准与现状差距，并制定路线图、控制实施和证据收集计划；内容仅供规划参考，不构成审计或法律意见。
主要功能
- 01界定适用的 Trust Service Criteria
- 02评估现状并生成差距矩阵
- 03规划 SOC 2 认证路线与时间表
- 04制定政策和控制实施计划
- 05提供审计证据收集指引
适用场景
- 01为企业客户要求准备 SOC 2
- 02评估当前安全与合规差距
- 03规划 Type I 到 Type II 的进度
- 04准备审计前的模拟评估
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/soc2-prep确认已加载。
详细介绍
SOC 2 准备
适用场景
当创始人正在准备 SOC 2 认证、客户或潜在客户要求提供 SOC 2 报告、需要在董事会或预算讨论中量化安全风险、希望制定按业务价值排序的合规路线图，或需要评估整体安全状况时启用。用户提到“SOC 2”“合规审计”“信任服务准则”“安全预算”“我们需要 SOC 2 才能拿下这笔交易”或“CISO”时，也应启用。
所需背景信息
- **来自 startup-context：**产品类型、技术栈、云基础设施提供商、团队规模、当前安全实践、商业模式、客户群体（企业客户通常要求 SOC 2）。
- **来自用户：**哪些信任服务准则在范围内、当前文档和政策的状态、现有安全工具（SSO、MDM、监控）、目标是 Type I 还是 Type II、期望时间线、预算限制、是否已选定审计师，以及排名前 3 的潜在客户的合规要求。
工作流
- 量化业务案例 — 使用 ALE（年度预期损失 = 单次损失预期 × 年发生率）以金额衡量安全投资。转化为董事会语言：“这项风险的年度预期损失为 $X。缓解风险的成本为 $Y。”安全是销售助力，而不是打勾了事。
- 定义范围 — 确定哪些信任服务准则在范围内。安全（通用准则）始终是必需项。可用性、处理完整性、保密性和隐私是可选项。根据客户要求和产品类型确定范围。
- 评估当前状态 — 梳理现有政策、控制措施和工具。明确哪些已经具备、哪些部分具备、哪些完全缺失。检查下方的危险信号列表。
- 差距分析 — 将当前状态与每项适用的 TSC 准则进行对照。生成差距矩阵，标明合规、部分合规和不合规的领域。
- 制定合规路线图 — 按业务价值排序：SOC 2 Type I（3-6 个月），然后是 SOC 2 Type II（从启动起 12 个月），再根据客户需求考虑 ISO 27001 或 HIPAA。基本安全卫生措施到位之前，不要追求认证。
- 编写政策 — 根据公司规模起草所需政策。早期初创公司需要实用的 2-5 页政策，而不是 50 页的企业级文档。
- 制定控制措施实施计划 — 针对每项差距，定义控制措施、负责人、工具和时间线。
- 提供证据收集指导 — 明确审计师会针对每项控制措施要求哪些材料，以及如何系统地收集这些材料。
- 准备情况审查 — 在联系审计师之前进行模拟评估。
输出格式
# Security & Compliance Assessment: [Company Name]
## Risk Quantification — top risks with ALE, mitigation cost, expected value
## Gap Analysis Matrix — TSC criterion, requirement, current state, gap, priority, remediation
## Compliance Roadmap — sequenced timeline: SOC 2 Type I > Type II > ISO 27001/HIPAA
## Policy Documents — generated as needed, each with purpose/scope/roles/statements/procedures
## Implementation Timeline — phased checklist with milestones
## Evidence Collection Checklist — per-control artifacts, storage location, refresh cadence
## Security Metrics Dashboard — table of key metrics with current values and targets
框架与最佳实践
风险量化（CISO 方法）
将技术风险转化为业务影响：收入损失、监管罚款、声誉损害。使用 ALE 确定优先级。
公式： ALE = SLE x ARO（单次损失预期 × 年发生率）
董事会语言：“一个 200K 美元的安全计划可以防范一次发生概率为 40% 的 2M 美元数据泄露，预期价值为 800K 美元。该计划的回报是成本的 4 倍。”
将安全支出定位为风险转移成本，而非管理费用。
安全指标
| 类别 | 指标 | 目标 |
|---|---|---|
| 风险 | ALE 覆盖率（已缓解 / 总计） | > 80% |
| 检测 | 平均检测时间（MTTD） | < 24 小时 |
| 响应 | 平均响应时间（MTTR） | < 4 小时 |
| 合规 | 通过审计的控制措施 | > 95% |
| 安全卫生 | SLA 内完成的关键补丁 | > 99% |
| 访问 | 每季度审查的特权账户 | 100% |
| 供应商 | 每年评估的 Tier 1 供应商 | 100% |
| 培训 | 钓鱼模拟点击率 | < 5% |
信任服务标准概览
**安全性（通用标准——始终适用）：**CC1-CC2（控制环境、沟通）、CC3（风险评估）、CC4-CC5（监控、控制活动）、CC6（逻辑/物理访问、加密）、CC7-CC8（系统运维、漏洞管理、事件响应、变更管理）、CC9（供应商管理、业务连续性）。
**可选：**可用性（A1）、处理完整性（PI1）、保密性（C1）、隐私（P1-P8）。
必备政策（至少 10 项）
信息安全、访问控制（MFA、最小权限、访问审查）、变更管理（代码审查、回滚）、事件响应（从检测到事后复盘）、风险评估（每年一次，并建立风险登记册）、供应商管理、数据分类、业务连续性/灾难恢复（RTO/RPO、备份测试）、可接受使用、HR 安全（背景调查、入职/离职流程）。
供应商安全评估等级
| 等级 | 数据访问权限 | 评估级别 |
|---|---|---|
| Tier 1 | 可访问 PII/PHI | 每年进行全面评估 |
| Tier 2 | 业务数据 | 问卷 + 审查 |
| Tier 3 | 无敏感数据 | 自我声明 |
应主动指出的危险信号
- 安全预算依据基准而非风险分析制定
- 在落实基本安全卫生措施（打补丁、MFA、备份）之前就追求认证
- 没有记录在案的资产清单——不知道拥有哪些资产，就无法保护它们
- 已制定 IR 计划但从未测试；安全团队向 IT 汇报，而非向高管汇报
- 安全问卷积压超过 30 天——企业交易正在悄然流失
- 可访问敏感数据的供应商尚未接受评估
面向初创公司的建议
**Type I 与 Type II：**Type I 在某个时间点检查控制设计（3-6 个月，适合拿下首个企业客户）。Type II 检查控制在 3-12 个月内的运行情况（成熟买家看重此项，总体计划 12 个月）。立即开始 Type I；控制到位后开始 Type II 观察期。
**按发展阶段调整规模：**Seed（5-15 人）：基础控制、以自动化为主、精简政策、由一名兼职负责人负责。Series A（15-50 人）：设立专职合规负责人或兼职 CISO，正式开展访问审查。Series B+（50 人以上）：全职安全团队、内部审计、GRC 平台。
**经济高效的工具：**合规自动化（Vanta、Drata、Secureframe——可大幅减少人工工作）、SSO（Google Workspace 或 Okta）、MDM（Kandji 或 Jamf）、监控（Datadog、PagerDuty）、漏洞扫描（Dependabot、Snyk、Trivy）。
时间线模板
- **激进型 Type I（3 个月）：**第 1 个月确定范围/差距/政策，第 2 个月实施，第 3 个月准备就绪 + 审计。
- **标准型 Type I（6 个月）：**第 1-2 个月确定范围/制定政策，第 3-4 个月实施，第 5 个月收集证据，第 6 个月审计。
- **Type II（12 个月）：**第 1-6 个月完成 Type I，第 6-12 个月观察 + 收集证据，第 12 个月审计。
输出置信度标签
所有发现都必须在提交给决策者之前添加标签：已验证（已根据证据确认）、中等（已报告，但未经独立验证）、假设（根据推断得出，需要验证）。
相关技能
privacy-policy— SOC 2 隐私标准（P1-P8）与隐私政策承诺直接对应。确保两者一致。security-review— security-review 中的技术安全控制对应 SOC 2 通用标准（CC6、CC7、CC8）。使用评估结果开展差距分析。
示例
示例 1：企业交易要求 SOC 2
用户：“一位潜在客户要求我们在签署一份 20 万美元的合同前提供 SOC 2。我们什么都没有。”
良好的输出摘录：
**商业论证：**这笔 20 万美元的交易足以支持 3 万至 5 万美元的合规投入。以你们目前的发展阶段来看，每笔因缺少 SOC 2 而受阻的企业交易都有机会成本。
领域 状态 主要差距 访问控制 部分符合 AWS 根账户未强制启用 MFA、没有 SSO、没有正式审查 变更管理 部分符合 使用 GitHub PR，但没有记录在案的政策 事件响应 缺失 没有记录在案的计划，也没有值班轮班安排 风险评估 缺失 尚未进行正式风险评估 **建议方案：**3 个月内完成 Type I，随后开始 Type II 观察期。 立即行动：（1）注册使用合规自动化服务。（2）在所有地方强制启用 MFA。（3）选择一位具有初创公司经验的审计师。 **向潜在客户的临时回复：**分享安全问卷回复、SOC 2 Type I 承诺时间表，以及附有安全附录的双方保密协议。
示例 2：安全态势评估
用户：“我们已经使用 Okta 实现 SSO，也会进行代码审查。我们距离 SOC 2 还有多远？”
良好的输出摘录：
差距分析摘要：已准备就绪 55%
**符合要求：**CC6.1 使用 Okta SSO 并启用 MFA；CC8.1 通过 PR 进行代码审查。 **部分符合：**CC6.2 没有记录季度访问审查；CC7.2 从未测试 IRP；CC6.3 没有正式的离职清单。 **缺失：**CC3.1 没有年度风险评估；CC2.1 没有安全培训；CC9.2 没有供应商管理；CC4.1 没有控制监控；所有 10 项必需政策都需要起草。
**免责声明：**此技能仅提供 SOC 2 准备指导，供规划之用，不构成法律、审计或专业合规建议。SOC 2 报告只能由持牌 CPA 事务所出具。请聘请合格的审计师，在安排审计前确认准备情况。