团队要往境外发数据,翻到一份《信息安全技术 数据出境安全评估指南》,条款能读懂,但不知道第一步该做啥、材料该谁写、评估过了之后还能不能改。这篇按实际操作顺序走一遍:先确认你的场景到底触不触发、再按清单准备、最后说清有效期内的变更与留证。
团队要往境外发数据,翻到一份《信息安全技术 数据出境安全评估指南》,条款能读懂,但落到自己身上就卡住:第一步该做啥、材料该谁写、评估过了之后还能不能改。这篇不逐条翻译标准,按实际操作顺序走一遍,先确认你的场景到底触不触发,再按清单准备,最后说清有效期内的变更与留证。
阅读前先明确一点:本文只给判断标准和可执行动作,不给绝对化承诺。因为触发口径、材料格式、有效期这些会随监管要求和行业实践变化,具体数字和当期要求,到站内 /safety 分区对应页面核对,别抄任何文章里的旧结论。
第一步先判断:你的场景到底触不触发
别一上来就写材料。先做初筛,用三个维度交叉看:数据性质、数据数量规模、境外接收方所在地区。任一维度踩线,就往评估这条路上靠。三个维度都明显不沾边,也别直接关掉,先做内部登记留痕,说明为什么判断不触发,谁做的判断。
| 维度 | 看什么 | 容易漏的点 |
|---|---|---|
| 数据性质 | 是否含个人信息、敏感个人信息、重要数据 | 把「看起来不敏感」的字段直接放过 |
| 数量规模 | 累计数量、涉及自然人数量、是否持续出境 | 只算单次,不算按年累计 |
| 接收方地区 | 接收方所在国家或地区、后续是否再转移 | 忽略接收方下游再转移 |
| 业务形态 | 是长期通道还是单次传输 | 临时项目不做登记 |
- 纯境外收集再回传的场景,要单独判断,不能简单当成不触发
- 员工跨境办公邮件、境外客服系统这类边界场景,按实际数据内容和规模判,不要一刀切
- 判断口径要和法务、数据安全负责人对齐后再定,不要业务方自己拍
- 不确定时先登记留痕,不要等业务上线才回头补
- 初筛结论写一页纸,注明判断人、时间、依据,归到证据包里
谁牵头、谁配合:把责任和时间线排出来
牵头方通常是数据安全或合规岗,业务方提供数据流向图,技术方出安全措施说明,三方缺一环材料大概率被退回。最容易卡的是业务方说不清数据到底流向哪,建议先固定一张流向模板再开会,会上只填模板,不空谈。
- 梳理数据资产业务方列出涉及的系统、表、字段,标出敏感级,产出资产清单
- 画数据流向图标注起点、传输链路、境外接收方、是否再转移、存储位置
- 写风险自评估合规牵头,业务和技术补充,写清目的、必要性、风险与应对
- 内部预审后再提交至少一轮内部交叉评审,重点看流向图和自评估是否对得上
时间线按「资产梳理 → 流向 → 自评估 → 提交」排,每段留返工余量。别把时间压成一条直线,实际执行中流向图和自评估几乎一定会来回改两三轮。跨部门协作里,先固定模板比先开会更省时间。
材料清单:按这一份逐条打勾
四类材料是主干:申报书、数据出境风险自评估报告、与境外接收方的法律文件、安全措施说明。缺一项都要补。建议做一张打勾表,每项注明负责人和版本号,避免提交时才发现有人交的是旧版。
| 材料 | 核心写什么 | 谁主笔 |
|---|---|---|
| 申报书 | 出境场景、数据范围、接收方基本信息 | 合规岗 |
| 风险自评估报告 | 数据种类规模、出境目的与必要性、接收方保障能力、风险与应对 | 合规牵头,业务与技术补 |
| 法律文件 | 用途限制、再转移约束、安全事件通知、终止后数据处置 | 法务 |
| 安全措施说明 | 加密、访问控制、日志、脱敏的具体实现 | 技术方 |
- 法律文件里要能看到用途限制、再转移约束、安全事件通知、终止后数据处置这几个条款,缺一条就补
- 自评估报告别写成制度摘抄,要落到本次出境的具体场景和具体字段
- 所有材料版本统一,避免提交的是上一版
- 接收方名称、地区、联系方式前后一致,别一处写法一处简称
技术侧要准备什么:别只写制度不写实现
技术侧最常被退回的原因是只写制度不写实现。评审看的不是你「有加密要求」,而是这条链路里到底怎么加密、密钥谁管、什么时候轮换。写不清楚,就等于没写。
- 加密传输
- 说清算法类别、链路范围、终端到服务端是否全程覆盖
- 加密存储
- 说清密钥谁管、轮换周期怎么定、密钥和密文是否分离
- 访问控制
- 能对上岗位,导出、批量查询、外发要有单独审批或审计记录
- 日志留存
- 留存范围、留存位置、谁能查、查到什么粒度
- 脱敏策略
- 链路里敏感字段怎么处理,敏感级怎么标记
术语叫法建议统一,别自评估报告一个说法、安全措施说明另一个说法。可以直接对照站内 /safety 的安全与合规术语页统一叫法,减少评审来回问「这两个是不是一回事」。具体技术指标数字,到站内 /tools/speed-test 或对应页面看当期口径,别抄旧数。
和 API Key 安全的分工:原则归原则,操作归操作
哪些字段能发、哪些一律不发的判断原则,交给 key-safety 那篇,这里不重复。这篇只讲出境场景下的动作:发之前怎么标记字段敏感级、走哪条审批、出事后怎么定位是哪条链路漏的。两篇配合看,一篇定边界,这篇定流程和留证方式。
- 发之前:按字段标敏感级,敏感级决定走不走出境审批
- 发之中:走审批记录,记录里写清字段范围、接收方、传输方式
- 发之后:日志能对上审批记录,能回放到具体某次外发
- 出事后:先按审批记录缩小范围,再看日志定位链路,不要全量排查
评估通过之后:有效期内的变更怎么处理
评估通过不等于一劳永逸。有效期、续评时间点这类会变的数字,到站内 /safety 分区对应页面核对当下口径,别抄别人文章里的旧数。更重要的是变更判断:不是所有变化都要重评,但有三类变化通常需要重新评估或补充说明。
| 变化类型 | 举例 | 通常怎么处理 |
|---|---|---|
| 新增数据种类 | 原来只发订单,现在加发身份信息 | 重新评估或补充说明 |
| 更换接收方 | 换成另一家境外供应商 | 重新评估 |
| 扩大规模 | 从单次变成长期通道,数量上升 | 重新评估或补充说明 |
建议做一张变更登记表,任何影响出境范围的动作先登记,再评估要不要走流程。表格列上变化描述、影响范围、判断结论、判断人、时间。别默认原评估能覆盖,很多问题就是「以为能覆盖」拖出来的。
留证与自查:出事时手里得拿得出东西
留证不是把文件堆一个文件夹,而是按时间归档,能还原每次决策的来龙去脉。留存对象包括申报材料版本、审批记录、数据流向图、与接收方的往来确认。归档时按时间线放,不是按文件类型放。
- 新业务上线前必查:流向图和实际链路是否一致
- 存量业务按季度抽查流向图与实际是否一致
- 发现不符,先停掉相关外发动作再补材料,顺序别反
- 每次变更登记单独归档,和原评估材料放一起
- 自查结论留判断人签字或记录,别只留一句「已检查」
自查频率跟着业务节奏走,业务变化快就查得勤。发现流向图和实际不符,先停外发再补材料,顺序反了会让后续说明很难自洽。自查不是为了交差,是为了出事时能自证当时的判断和动作。
评估不是一次性动作,是一条从初筛到留证的流水线;每一步留下痕迹,比最后补材料省事得多。下一步把你的出境场景对照初筛表过一遍,再到站内核对当前的有效期与提交口径,顺手把变更登记表建起来。→
常见问题
我们数据量不大,是不是就不用做安全评估?
规模只是判断维度之一,数据性质和接收方所在地同样重要。涉及敏感个人信息、重要数据,或者接收方所在地区有特殊监管要求的,量小也可能触发。建议先按三个维度做一次初筛并留档,判断不确定时优先按需要准备,而不是先默认不用。
自评估报告能不能直接套模板?
可以借鉴结构,但内容必须对得上自己的数据流向。审核看的是数据种类与规模、出境必要性、接收方能力、风险应对这几块是否自洽。直接套模板最常出问题的地方是业务描述和数据流向图对不上,一被问细节就答不上来。
评估通过后多久要复查一次?
有效期和复查节点属于会调整的口径,别直接引用别处的旧数字,到站内 /safety 分区的对应页面看当前说明。更实用的做法是内部再设一条触发线:业务新增数据种类、更换接收方、规模明显扩大时,先登记再判断是否需要重新评估。
技术措施要写到什么颗粒度?
写到能落地的程度:加密说清算法类别和密钥管理方式,访问控制说清岗位对应权限,日志说清留存范围和敏感字段处理方式。只写「已采取加密措施」这种句子,在补充说明阶段基本都要返工重写。
和标准合同、认证这几条路径怎么选?
路径选择取决于你的场景属于哪一类,不是所有情况都走评估。先做完场景初筛再选路径,选错了材料白准备。路径之间的对比判断,建议结合站内安全与合规分区的相关页面一起看,别只看单一篇。