跳到正文
返回交付模板库
治理记录美国(联邦)全球中国大陆通用企业软件 SaaS大模型 / 生成式 AIAI 智能体

SOC 2 Type II 就绪清单(信托服务准则)

把"拿到一份客户愿意接收的 SOC 2 Type II 报告"拆成可排期的准备工作:范围与准则类别怎么定、体系说明书怎么写、控制矩阵怎么建、覆盖期间内的证据怎么持续产生、事务所怎么选、例外事项怎么处理、报告拿到后怎么维护。适用于把北美企业客户作为主要市场、被合同要求每年提供覆盖过去十二个月的 Type II 报告的中国厂商。

阅读对象:内部:安全、工程、人力、法务与财务;外部:出具报告的会计师事务所、客户的第三方风险团队与采购审批人

已对照官方来源核实 · 2026-09-12部分依据二手来源,建议复核
下载 Markdown 骨架

这份文件回应的法规义务

章节结构(8)

  1. 1. 范围界定与信托服务准则类别选择

    先决定两件事,它们决定全部后续成本。第一,报告覆盖谁:整个实体、某个子公司或分部、还是某一特定系统/服务。中国厂商常见做法是只覆盖售卖给海外客户的那条服务线,但范围划得太窄会被客户质疑"报告没覆盖我买的东西",必须与销售侧主张的服务边界一致。第二,选哪些准则类别:安全性是共同准则、几乎所有报告都包含;可用性、处理完整性、保密性、隐私性按客户合同承诺与业务性质加选。建议逐条对照已签客户合同中的安全附件承诺来定类别 —— 合同里承诺了可用率就应考虑纳入可用性,承诺了数据保密与销毁就应考虑纳入保密性。另需明确系统边界与子服务机构(如公有云)的处理方式(纳入法还是剔除法),该选择会直接影响客户对残余风险的判断。

    需要附的证据

    • · 范围声明(实体/系统边界、覆盖的产品与部署形态、地理范围)
    • · 准则类别选择依据(与客户合同承诺的对照表)
    • · 子服务机构清单与纳入/剔除方法的选择说明
    • · 范围决策的管理层批准记录

    常见失分点

    • · 范围只覆盖研发环境不覆盖生产运营,报告对客户没有说服力
    • · 合同承诺了可用率却未纳入可用性类别,客户据此要求补做
    • · 采用剔除法却未说明对云厂商控制的依赖与补充监控,客户认为残余风险不明
  2. 2. 体系说明书(System Description)的编写

    体系说明书是报告中客户真正会读的部分,它描述服务的性质、系统组件(基础设施、软件、人员、流程、数据)、服务承诺与系统要求、以及所依赖的子服务机构与互补性用户实体控制。写作要点:用客户能理解的语言描述数据在系统中的完整流转;明确列出对客户方的控制假设(互补性用户实体控制,例如客户须自行管理其管理员账号与配置);如实描述报告期间内发生的重大变更(架构迁移、并购、重大事件)。中国厂商还要特别写清人员与地理维度:哪些团队在中国境内、他们能接触哪些数据、以及相应的访问控制 —— 隐去这部分会让客户在阅读时自行推测,结果通常更糟。

    需要附的证据

    • · 体系说明书草稿与内部评审意见
    • · 系统组件清单与架构图、数据流图
    • · 服务承诺与系统要求清单(对应合同与 SLA)
    • · 互补性用户实体控制清单
    • · 报告期间重大变更记录

    常见失分点

    • · 体系说明书由事务所代写、公司无人复核,与实际运营不符
    • · 未列互补性用户实体控制,客户误以为所有责任都在供应商侧
    • · 刻意隐去境内团队的访问能力,后续被客户审计发现
  3. 3. 控制矩阵:准则到控制到证据的三级映射

    建立一张三列映射:准则条款 → 我方控制描述 → 证据类型与产生频率。每条控制要写明:控制目标、执行者、执行频率(每次变更/每日/每季)、自动还是人工、以及证据的系统来源。经验法则:能自动产生证据的控制优先设计成自动控制(工单系统、CI/CD 流水线、云审计日志),因为 Type II 检查的是覆盖期间内每一次执行,人工控制在抽样时最容易暴露缺失。同时把矩阵与 ISO/IEC 27001 附录 A、云控制矩阵(CCM)做交叉映射,一套控制多处复用 —— 这是同时面向北美与欧洲/亚洲客户时成本最低的做法。

    需要附的证据

    • · 控制矩阵(准则条款、控制描述、执行者、频率、自动/人工、证据来源)
    • · 与 ISO/IEC 27001 附录 A 及 CCM 的交叉映射表
    • · 控制设计评审记录与差距分析结论
    • · 自动化证据采集的系统配置说明

    常见失分点

    • · 控制描述抄自模板,与公司实际流程不符,测试阶段大面积失败
    • · 控制过多过细,覆盖期间内根本无法持续执行
    • · 关键控制依赖单个人手工执行,此人休假期间出现证据断档
  4. 4. 就绪评估与整改(覆盖期间开始前完成)

    在正式覆盖期间开始之前做一次就绪评估(可由事务所的咨询团队或独立第三方执行,注意出具报告的事务所对咨询业务有独立性限制),逐条测试控制设计与运行,输出缺口清单与整改计划。整改要在覆盖期间开始前完成 —— 期间开始后才补的控制,在报告里会体现为该控制仅覆盖部分期间,客户看到这一点通常会要求下一期再看。这一阶段也是确定覆盖期间长度的时点:首年常见的做法是先做较短期间的 Type II 以尽快取得可交付报告,再在次年延长至完整年度,但具体期间长度须与事务所和主要客户合同要求一并确认,不要按传闻惯例假设。

    需要附的证据

    • · 就绪评估报告与缺口清单
    • · 整改计划(事项、责任人、完成期限)与完成证据
    • · 覆盖期间起止日期的决策记录(含与客户合同要求的对照)
    • · 独立性确认(就绪评估方与出具报告方的关系)

    常见失分点

    • · 整改与覆盖期间并行推进,报告中出现大量"控制自期间中段起实施"的表述
    • · 覆盖期间长度按传闻设定,与主要客户合同要求(如覆盖过去十二个月)不匹配
    • · 为省成本跳过就绪评估,直接进入正式审计,期末才发现系统性缺口
  5. 5. 覆盖期间内的证据运营

    Type II 检查的是控制在一段期间内的运行有效性,因此这一节的本质是"让证据自然沉淀"。建立三件事:(1) 证据日历 —— 每项周期性控制(权限复核、备份恢复演练、供应商评估、安全意识培训、风险评估)的执行月份、责任人与提醒;(2) 证据存放规范 —— 统一目录、命名、留存位置与访问控制,禁止散落在个人聊天记录与邮箱;(3) 月度自查 —— 每月核对上月应产生的证据是否齐全,缺失立即补救而不是等到审计。中国团队常见的坑是证据以中文产生但报告为英文,应在证据规范中明确关键字段的双语要求或统一翻译流程,避免审计期临时大批量翻译。

    需要附的证据

    • · 证据日历(控制、频率、责任人、执行月份、状态)
    • · 证据存放规范与目录结构说明
    • · 月度自查记录与缺失补救台账
    • · 证据双语化/翻译流程说明

    常见失分点

    • · 季度控制在一个季度漏做,整个覆盖期间的该项控制被判定失效
    • · 证据截图无时间戳与操作者信息,无法证明执行时点
    • · 人员离职带走了唯一的证据存放位置
  6. 6. 事务所选择与业务约定

    SOC 2 报告须由持证会计师事务所出具。选择时至少确认四点:事务所的执业资质与同业复核状态;其出具的报告是否被你的目标客户实际接受(可在签约前向重点客户确认);团队是否有同类技术栈与跨境业务经验;以及业务约定中的时间表、抽样方式、例外事项处理与出报告时限。要警惕以极低价格、极短周期承诺出证的"合规工具 + 合作审计方"打包方案 —— 美国注册会计师协会已就此类做法公开提示风险,选错事务所会导致报告被客户拒收,成本远高于节省的审计费。约定中还应明确谁承担体系说明书的编写责任、以及后续年度的续作安排。

    需要附的证据

    • · 事务所资质与同业复核状态核查记录
    • · 重点客户对拟选事务所报告接受度的确认
    • · 业务约定书(时间表、抽样、例外处理、出报告时限、续作安排)
    • · 费用与内部准备成本预算(含行业估算区间的参考来源)

    常见失分点

    • · 选了报价最低的事务所,报告出具后被主要客户以事务所资质为由拒收
    • · 业务约定未写出报告时限,期末拖延数月导致合同违约
    • · 预算只算审计费,忽略内部准备的人力成本,项目中途资源不足
  7. 7. 例外事项与管理层回应

    几乎没有首年报告是零例外的,关键是例外怎么写。对每一项例外准备:事实描述(发生了什么、涉及多少样本)、根因分析、影响评估(是否影响服务承诺与客户数据)、已采取的补救措施与完成时间、以及防止再发生的机制。管理层回应要具体、有时间表、不辩解 —— 客户的第三方风险团队读例外时看的是"这家公司发现问题后怎么处理",一段坦率且有闭环的回应往往比零例外更能建立信任。同时准备一份面向客户的例外说明摘要,供销售在解释报告时统一口径,避免不同销售给出不同解释。

    需要附的证据

    • · 例外事项清单(事实、样本数、根因、影响、补救、完成时间)
    • · 管理层回应文本与批准记录
    • · 再发防止机制的设计与验证记录
    • · 面向客户的例外说明摘要(统一口径)

    常见失分点

    • · 管理层回应写成"该例外影响轻微"而无根因与时间表,客户视为治理能力不足
    • · 销售在客户会议上淡化例外,与报告文本不一致
    • · 同一例外连续两年出现且回应文字一字未改
  8. 8. 报告交付、桥接函与年度续作

    报告是有覆盖期间的文档,期间结束到出具有滞后,客户会要求提供覆盖这段空档的桥接函(由管理层出具,声明期间结束后控制未发生重大变化)。因此签约前就要确认自己能否按期提供桥接函,并把桥接函的出具流程、签署人与模板预置好。交付侧还要建立:报告分发登记(谁在什么时候拿到了哪一版,通常需在保密协议下提供)、客户问询的统一答复口径、以及下一年度覆盖期间的排期(与本年度衔接、避免出现覆盖空档)。把续作排期录入合规日历,并在年度预算中预留费用。

    需要附的证据

    • · 报告分发登记表(接收方、版本、日期、保密协议状态)
    • · 桥接函模板、签署人授权与历史桥接函
    • · 下一年度覆盖期间排期与预算
    • · 客户问询答复口径文档

    常见失分点

    • · 合同承诺每年提供覆盖过去十二个月的报告,实际排期出现覆盖空档
    • · 桥接函由销售自行起草并签署,缺乏管理层授权
    • · 报告被客户转发给第三方且未受保密约束,敏感架构信息外流

对应标准

  • SOC 2(服务机构控制报告)与 AICPA 信托服务准则 · 2017 年信托服务准则(含 2022 年修订关注点)
  • ISO/IEC 27001:2022 信息安全管理体系(ISMS)要求 · ISO/IEC 27001:2022(第 3 版,2022-10);欧洲采标 EN ISO/IEC 27001:2023 并含 A1:2024 修改单
  • CSA STAR 与 STAR for AI(含 CCM / CAIQ / AICM / AI-CAIQ) · STAR 项目(CCM/CAIQ v4.1 合并版);AI 控制矩阵 AICM v1(2025-07-09 发布,2025-10-30 更新,另有 v1.1)

来源(5)

内容截至 2026-09-12 · 语料版本 2026.09|本内容基于公开官方来源整理,标注了来源链接与复核日期,供合规决策参考;监管要求可能变化,正式对外披露、监管申报或合同承诺前请由持证专业人士复核。

GDPR · PIPL · CCPA 控制映射
AI 决策可追溯 · 有来源即标注
ISO 27001 对标推进中
WCAG 2.1 AA 可访问性目标
SOC 2 Type II 就绪清单(信托服务准则) · 交付模板 | 海问 HQ