在不过度承诺的前提下确定首份 SOC 2 报告的范围

SOC 2 报告涵盖一个系统：即客户所购买的服务及其背后的全部组成部分。如果边界划得过宽，你将花费数月时间去证明那些客户根本没有询问的控制措施；如果划得过窄，报告又无法回答客户的问题。大多数代价高昂的初次 SOC 2 错误，都发生在界定范围的那一周。

决策 1：涵盖哪个系统

从客户购买并依赖的内容入手。对大多数软件公司而言，这通常是生产平台，包括应用程序、其基础设施和数据存储、负责开发与运维的人员，以及他们遵循的流程。通常排除在外的包括：从未接触客户数据的内部企业 IT、其他产品线以及销售系统。

尽早将边界书面记录下来，因为它将成为报告中的系统描述，并且在整个观察期内的每一天，边界内的每一项控制都必须在所有范围内正常运行。

决策 2：适用哪些标准

安全性（即通用标准 CC1 至 CC9）是必选项。只有在客户确实需要时，才增加其他标准：

• 可用性：如果客户依赖正常运行时间承诺。
• 保密性：如果你持有被指定为保密的客户数据（大多数 B2B 服务均属此类）。
• 处理完整性：如果客户依赖你正确处理其数据，例如支付、薪资或计费。
• 隐私：如果你出于自身目的处理个人信息，且客户提出此类要求。正如我们对 SOC 2 与 ISO 27001 的分析所示，其大部分标准在安全框架中并无对应内容。

决策 3：分包服务机构

你的云服务提供商、支付处理商或托管数据库提供商运行着你所依赖的控制措施。你可以在以下两种方式之间进行选择：

• 剥离法（最常见）：排除其控制措施；说明你依赖其提供的具体内容，并证明你会审查其自身的 SOC 2 报告。
• 包含法：在你的报告中对其控制措施进行测试。这需要对方的配合，对于大型提供商而言较为少见。

决策 4：用户实体互补控制

列出客户为使你的服务正常运作而必须执行的控制措施，例如管理其自身用户账户、保护其 API 密钥、配置其 SSO。请保持内容切合实际且数量精简，因为客户会仔细阅读，其安全团队也会质疑不合理的清单。

决策 5：Type I 或 Type II 以及观察期

Type I 出具速度较快；而大多数客户想要的是 Type II。对于首次 Type II，通常采用三至六个月的观察期。只有在控制措施已运行数周之后再开始观察期，以免观察期前段充斥例外情况。

范围界定检查清单

在与你的 CPA 事务所启动项目之前，请先明确以下问题的答案：

• 报告针对的是哪款产品或服务？客户依赖它完成哪些工作？
• 哪些环境纳入范围（仅生产环境，还是包括预发布环境）？
• 涉及哪些云账户、区域和数据存储？
• 哪些团队和角色负责运营该系统？
• 该系统依赖哪些分包服务机构？你是否持有它们的报告？
• 适用哪些信任服务标准类别，原因是什么？
• 客户需要运行哪些用户实体互补控制措施？
• 先做 Type I 还是直接做 Type II？观察期为多久？
• 有哪些现有框架或审计的证据可以复用？

书面答案将成为系统描述的初稿，可节省数周的反复沟通。如果你已持有 ISO 27001，ISO 27001 → SOC 2 差距报告可回答最后一个问题。

代价最高的范围错误

• 为“保险起见”而纳入企业 IT：这会使需要证明的系统数量翻倍。
• 因为听起来不错就增加隐私或处理完整性：每一项都会在整个观察期内增加控制措施和证据要求。
• 系统描述与实际情况不符：审计师测试的是你所书写的内容。
• 在控制措施运行之前就开始观察期：第一个月的例外情况会保留在报告中。

SOC 2 指南涵盖完整流程；SOC 2 框架页面列出了每项标准及其对照映射；如果你已持有其他框架，差距分析可显示其对你的帮助程度。

常见问题

SOC 2 报告的最低范围是什么？

针对已界定系统的安全类别（即通用标准 CC1 至 CC9）。可用性、保密性、处理完整性和隐私均为可选项。

SOC 2 中的剥离项是什么？

从你的报告中排除分包服务机构的控制措施（例如云服务提供商的数据中心控制措施），同时说明你依赖其提供的内容以及你如何对其进行监控。