面向监控工具的 SOC 2 审计日志：审计师关注什么
监控工具在 SOC 2 审计中会在两个方面被提及。审计师希望看到您对可用性和性能进行了监控（AV 信任服务标准），并且记录了谁在更改监控配置（CC 信任服务标准）。前者很简单：任何正常运行时间监控工具都能产生足够的证据。后者则是大多数团队准备不足的地方。本指南将介绍 SOC 2 审计师真正关注的内容、您的监控工具应该记录哪些内容，以及如何在审计期间展示这些控制措施。
SOC 2 对监控的关注点
SOC 2 是基于原则的，而非规定性的。审计师不会核查您是否购买了某款特定工具，而是核查您是否制定了相应的控制措施，以支持您所承诺的信任服务标准。
通常有两项标准与监控工具相关。可用性（AV）：您对服务进行中断监控并及时响应。通用标准（CC），特别是 CC7.2（系统运行监控）和 CC8.1（变更管理）：您对谁能更改监控配置以及这些变更如何被记录有相应的控制措施。前者较为直接，后者则是大多数团队难以达标的门槛。
审计师期望在日志中看到的内容
在 SOC 2 审计期间，会被要求提供四类日志条目。确保您的监控工具能够产生这四类日志，并且您能在审计周期内将其完整提交。
- 用户访问：谁登录、何时登录、来自哪个 IP。需关联到具名个人，而非共享账户。
- 配置变更：每一次对监控的变更（创建、更新、删除）、每一次对通知规则的变更、每一次对 API 密钥的变更。包括变更人和变更内容。
- 事件记录：每一次检测到的中断，包含时间戳、持续时间以及已发送的通知。
- 管理操作：套餐变更、用户邀请、角色变更、密码重置。审计师希望看到完整的管理活动追踪。
满足审计师要求的保留期限
SOC 2 并未规定保留期限；审计师通常期望至少 12 个月的日志，对于覆盖多个季度运行期的 Type 2 审计有时还会更长。
实务建议：审计日志至少保留 13 个月，以覆盖完整的 Type 2 运行期并留有缓冲。事件记录和检查日志至少保留 90 天以满足 AV 标准。许多监控工具在 Business 或更高级别套餐中提供此项功能；在选定供应商前请先核实。
审计师将测试的控制措施
审计将测试您控制措施的运行有效性，而不仅仅是其是否存在。有四项常见测试涉及监控。
- 访问变更抽样：审计师从审计日志中抽取 5 至 10 条记录，并要求您出示对应的工单或变更请求。请确保您的变更管理流程在监控工具之外得到记录。
- 事件抽样：审计师从该周期中抽取 3 至 5 起事件，要求提供响应过程的记录。请预先准备好运行手册和事后回顾模板。
- API 密钥清单：审计师会询问谁持有 API 密钥、最近一次使用时间，以及权限范围是否合适。请每季度进行一次密钥审查并形成文档。
- 监控覆盖范围：审计师会询问您如何决定监控哪些内容。请准备一份书面政策，列出相应标准；如果回答是含糊的「我们知道哪些是重要的」，则无法通过测试。
需要核实的供应商方控制措施
您的监控供应商自身的 SOC 2 报告也是您审计的一部分。审计师会要求查看该报告。
签约前请核实：供应商是否拥有 SOC 2 Type 2 报告？报告于何时签发，运行期为多久？是否覆盖相关标准（AV、CC）？是否包含 User Entity Considerations 章节，列明您需要在供应商的基础上自行实施的控制措施？请认真对待此事；没有最新 SOC 2 报告的供应商可能会影响您的审计结果。
通过监控相关 SOC 2 审计所需的最小控制集
使用一款能产生用户访问日志、配置变更日志、事件日志和管理操作日志，且保留期至少为 13 个月的监控工具。维护一份书面的监控政策，列明您覆盖的服务以及添加新服务的标准。通过工单系统或 git PR 跟踪配置变更，使每次变更都有书面理由。每季度审查 API 密钥。每年进行一次事件响应桌面演练。将所有事项形成文档。具备这五项控制措施后，监控将在您的 SOC 2 审计中成为一项亮绿灯的项目，而非绊脚石。
