4、SOC2审计范围：确定审计边界、系统描述、基础设施、软件、人员、数据、流程

好，咱们进入第四讲。这一章很关键，说白了就是回答一个问题：审计到底审什么？

很多团队第一次做SOC2，上来就问「我们要准备多少文档？」「要过几个控制点？」。我通常会反问一句：你的审计边界画清楚了吗？

边界没定，后面全是糊涂账。我在项目中遇到过一家SaaS公司，自认为只审「核心交易系统」，结果审计师进场后发现他们连内部HR系统都挂在同一套基础设施上。嗯，那场面，挺尴尬的。

4.1 审计边界：你的「领地」在哪儿？

审计边界，就是你要向审计师证明「这些地方我管好了」的范围。它不是拍脑袋定的，而是基于你的服务承诺和实际运营情况。

我个人习惯用三个维度来切分边界：

• 组织边界：哪些部门、哪些子公司纳入审计？
• 系统边界：哪些系统是「受信系统」，哪些是外部依赖？
• 时间边界：审计覆盖哪段时间？通常是过去12个月。

4.2 系统描述：让审计师一眼看懂你

系统描述是审计范围的「说明书」。它要回答五个W：

• What：你提供什么服务？
• Who：谁在用？
• Where：数据存在哪儿？
• When：服务时间？
• How：怎么运作的？

我建议用一张表格来呈现，清晰明了：

维度	描述内容	示例
服务名称	你对外提供的核心服务	云文档协作平台
用户群体	谁在使用你的服务	企业客户（B2B）
数据处理	你处理什么类型的数据	用户文档、元数据、日志
部署方式	SaaS / 私有化 / 混合	多租户SaaS
关键依赖	你依赖哪些第三方服务	AWS、Stripe、SendGrid

4.3 基础设施：你的「地基」稳不稳？

基础设施包括服务器、网络设备、机房、云资源等。SOC2审计里，基础设施主要看三点：

• 物理安全：机房有门禁吗？监控覆盖了吗？
• 网络安全：防火墙规则合理吗？有没有入侵检测？
• 环境控制：温湿度、UPS、消防，这些有没有保障？

如果你用的是云服务（比如AWS、Azure），别慌。审计师通常接受云厂商的合规报告（比如SOC2 Type II、ISO 27001）。但注意——你仍然需要证明你正确配置了云资源。我记得有个客户，AWS的物理安全没问题，但S3存储桶配成了公开可读，那就不行。

4.4 软件：代码质量与安全

软件范围包括你自研的应用、第三方组件、以及运维工具。审计师会关注：

• 开发流程：有没有代码审查？有没有安全测试？
• 变更管理：上线前有没有审批？有没有回滚方案？
• 漏洞管理：有没有定期扫描？修复周期多长？

我个人的经验是，别试图隐藏你用了开源组件。审计师不介意你用开源，但介意你不知道自己用了哪些开源组件。一份完整的SBOM（软件物料清单）能省去很多麻烦。

4.5 人员：谁在碰你的系统？

人员范围不是「全公司所有人」，而是那些能接触到客户数据或影响系统运行的人。包括：

• 开发工程师
• 运维工程师
• 客服人员（可能查看客户数据）
• 第三方供应商人员（比如外包运维）

这里有个容易忽略的点：离职人员。我曾经审计一家公司，发现一个离职半年的工程师账号还在生产环境有权限。嗯，那是个不小的发现项。

4.6 数据：你的核心资产

数据范围是审计的重中之重。你要明确：

• 数据类型：客户数据、配置数据、日志数据、备份数据
• 数据生命周期：创建、存储、使用、归档、销毁
• 数据分类：哪些是敏感数据？哪些是公开数据？

我建议做一张数据流图，把数据从「用户输入」到「最终存储或删除」的路径画出来。审计师特别喜欢看这个。你想想看，一张图就能讲清楚数据去了哪里、谁碰过、怎么保护的，多省事。

4.7 流程：制度不是摆设

流程范围包括你所有的管理制度和操作流程。比如：

• 信息安全策略
• 事件响应流程
• 变更管理流程
• 供应商管理流程

这里有个常见误区：流程写得很漂亮，但实际没执行。审计师会通过访谈和抽样来验证。比如你写了「所有代码变更必须经过Code Review」，审计师会随机抽几个PR记录，看看是不是真的有人Review了。

我记得有一次，客户说他们有完善的变更管理流程，结果审计师一查，发现过去三个月有40%的变更没有审批记录。那场面，真是「嘴上说一套，做起来另一套」。

小结

确定审计范围，不是一蹴而就的事。它需要你反复问自己：哪些东西真正影响客户信任？把精力花在刀刃上，别为了凑数而扩大边界。

下一章，我们会聊到具体的控制点设计。到时候你会发现，范围定好了，控制点自然就清晰了。嗯，咱们下节课见。