信息安全技术数据出境安全评估指南

安全与风控

把数据出境安全评估的技术标准拆成可执行动作:先判断触发、再准备材料、最后留证应对,附自查清单与常见误区。

团队要往境外发数据,翻到一份《信息安全技术 数据出境安全评估指南》,条款能读懂,但不知道第一步该做啥、材料该谁写、评估过了之后还能不能改。这篇按实际操作顺序走一遍:先确认你的场景到底触不触发、再按清单准备、最后说清有效期内的变更与留证。

团队要往境外发数据,翻到一份《信息安全技术 数据出境安全评估指南》,条款能读懂,但落到自己身上就卡住:第一步该做啥、材料该谁写、评估过了之后还能不能改。这篇不逐条翻译标准,按实际操作顺序走一遍,先确认你的场景到底触不触发,再按清单准备,最后说清有效期内的变更与留证。

阅读前先明确一点:本文只给判断标准和可执行动作,不给绝对化承诺。因为触发口径、材料格式、有效期这些会随监管要求和行业实践变化,具体数字和当期要求,到站内 /safety 分区对应页面核对,别抄任何文章里的旧结论。

第一步先判断:你的场景到底触不触发

别一上来就写材料。先做初筛,用三个维度交叉看:数据性质、数据数量规模、境外接收方所在地区。任一维度踩线,就往评估这条路上靠。三个维度都明显不沾边,也别直接关掉,先做内部登记留痕,说明为什么判断不触发,谁做的判断。

维度看什么容易漏的点
数据性质是否含个人信息、敏感个人信息、重要数据把「看起来不敏感」的字段直接放过
数量规模累计数量、涉及自然人数量、是否持续出境只算单次,不算按年累计
接收方地区接收方所在国家或地区、后续是否再转移忽略接收方下游再转移
业务形态是长期通道还是单次传输临时项目不做登记
  • 纯境外收集再回传的场景,要单独判断,不能简单当成不触发
  • 员工跨境办公邮件、境外客服系统这类边界场景,按实际数据内容和规模判,不要一刀切
  • 判断口径要和法务、数据安全负责人对齐后再定,不要业务方自己拍
  • 不确定时先登记留痕,不要等业务上线才回头补
  • 初筛结论写一页纸,注明判断人、时间、依据,归到证据包里

谁牵头、谁配合:把责任和时间线排出来

牵头方通常是数据安全或合规岗,业务方提供数据流向图,技术方出安全措施说明,三方缺一环材料大概率被退回。最容易卡的是业务方说不清数据到底流向哪,建议先固定一张流向模板再开会,会上只填模板,不空谈。

  1. 梳理数据资产业务方列出涉及的系统、表、字段,标出敏感级,产出资产清单
  2. 画数据流向图标注起点、传输链路、境外接收方、是否再转移、存储位置
  3. 写风险自评估合规牵头,业务和技术补充,写清目的、必要性、风险与应对
  4. 内部预审后再提交至少一轮内部交叉评审,重点看流向图和自评估是否对得上

时间线按「资产梳理 → 流向 → 自评估 → 提交」排,每段留返工余量。别把时间压成一条直线,实际执行中流向图和自评估几乎一定会来回改两三轮。跨部门协作里,先固定模板比先开会更省时间。

材料清单:按这一份逐条打勾

四类材料是主干:申报书、数据出境风险自评估报告、与境外接收方的法律文件、安全措施说明。缺一项都要补。建议做一张打勾表,每项注明负责人和版本号,避免提交时才发现有人交的是旧版。

材料核心写什么谁主笔
申报书出境场景、数据范围、接收方基本信息合规岗
风险自评估报告数据种类规模、出境目的与必要性、接收方保障能力、风险与应对合规牵头,业务与技术补
法律文件用途限制、再转移约束、安全事件通知、终止后数据处置法务
安全措施说明加密、访问控制、日志、脱敏的具体实现技术方
  • 法律文件里要能看到用途限制、再转移约束、安全事件通知、终止后数据处置这几个条款,缺一条就补
  • 自评估报告别写成制度摘抄,要落到本次出境的具体场景和具体字段
  • 所有材料版本统一,避免提交的是上一版
  • 接收方名称、地区、联系方式前后一致,别一处写法一处简称

技术侧要准备什么:别只写制度不写实现

技术侧最常被退回的原因是只写制度不写实现。评审看的不是你「有加密要求」,而是这条链路里到底怎么加密、密钥谁管、什么时候轮换。写不清楚,就等于没写。

加密传输
说清算法类别、链路范围、终端到服务端是否全程覆盖
加密存储
说清密钥谁管、轮换周期怎么定、密钥和密文是否分离
访问控制
能对上岗位,导出、批量查询、外发要有单独审批或审计记录
日志留存
留存范围、留存位置、谁能查、查到什么粒度
脱敏策略
链路里敏感字段怎么处理,敏感级怎么标记

术语叫法建议统一,别自评估报告一个说法、安全措施说明另一个说法。可以直接对照站内 /safety 的安全与合规术语页统一叫法,减少评审来回问「这两个是不是一回事」。具体技术指标数字,到站内 /tools/speed-test 或对应页面看当期口径,别抄旧数。

和 API Key 安全的分工:原则归原则,操作归操作

哪些字段能发、哪些一律不发的判断原则,交给 key-safety 那篇,这里不重复。这篇只讲出境场景下的动作:发之前怎么标记字段敏感级、走哪条审批、出事后怎么定位是哪条链路漏的。两篇配合看,一篇定边界,这篇定流程和留证方式。

  • 发之前:按字段标敏感级,敏感级决定走不走出境审批
  • 发之中:走审批记录,记录里写清字段范围、接收方、传输方式
  • 发之后:日志能对上审批记录,能回放到具体某次外发
  • 出事后:先按审批记录缩小范围,再看日志定位链路,不要全量排查

评估通过之后:有效期内的变更怎么处理

评估通过不等于一劳永逸。有效期、续评时间点这类会变的数字,到站内 /safety 分区对应页面核对当下口径,别抄别人文章里的旧数。更重要的是变更判断:不是所有变化都要重评,但有三类变化通常需要重新评估或补充说明。

变化类型举例通常怎么处理
新增数据种类原来只发订单,现在加发身份信息重新评估或补充说明
更换接收方换成另一家境外供应商重新评估
扩大规模从单次变成长期通道,数量上升重新评估或补充说明

建议做一张变更登记表,任何影响出境范围的动作先登记,再评估要不要走流程。表格列上变化描述、影响范围、判断结论、判断人、时间。别默认原评估能覆盖,很多问题就是「以为能覆盖」拖出来的。

留证与自查:出事时手里得拿得出东西

留证不是把文件堆一个文件夹,而是按时间归档,能还原每次决策的来龙去脉。留存对象包括申报材料版本、审批记录、数据流向图、与接收方的往来确认。归档时按时间线放,不是按文件类型放。

  • 新业务上线前必查:流向图和实际链路是否一致
  • 存量业务按季度抽查流向图与实际是否一致
  • 发现不符,先停掉相关外发动作再补材料,顺序别反
  • 每次变更登记单独归档,和原评估材料放一起
  • 自查结论留判断人签字或记录,别只留一句「已检查」

自查频率跟着业务节奏走,业务变化快就查得勤。发现流向图和实际不符,先停外发再补材料,顺序反了会让后续说明很难自洽。自查不是为了交差,是为了出事时能自证当时的判断和动作。

评估不是一次性动作,是一条从初筛到留证的流水线;每一步留下痕迹,比最后补材料省事得多。
下一步把你的出境场景对照初筛表过一遍,再到站内核对当前的有效期与提交口径,顺手把变更登记表建起来。

常见问题

我们数据量不大,是不是就不用做安全评估?

规模只是判断维度之一,数据性质和接收方所在地同样重要。涉及敏感个人信息、重要数据,或者接收方所在地区有特殊监管要求的,量小也可能触发。建议先按三个维度做一次初筛并留档,判断不确定时优先按需要准备,而不是先默认不用。

自评估报告能不能直接套模板?

可以借鉴结构,但内容必须对得上自己的数据流向。审核看的是数据种类与规模、出境必要性、接收方能力、风险应对这几块是否自洽。直接套模板最常出问题的地方是业务描述和数据流向图对不上,一被问细节就答不上来。

评估通过后多久要复查一次?

有效期和复查节点属于会调整的口径,别直接引用别处的旧数字,到站内 /safety 分区的对应页面看当前说明。更实用的做法是内部再设一条触发线:业务新增数据种类、更换接收方、规模明显扩大时,先登记再判断是否需要重新评估。

技术措施要写到什么颗粒度?

写到能落地的程度:加密说清算法类别和密钥管理方式,访问控制说清岗位对应权限,日志说清留存范围和敏感字段处理方式。只写「已采取加密措施」这种句子,在补充说明阶段基本都要返工重写。

和标准合同、认证这几条路径怎么选?

路径选择取决于你的场景属于哪一类,不是所有情况都走评估。先做完场景初筛再选路径,选错了材料白准备。路径之间的对比判断,建议结合站内安全与合规分区的相关页面一起看,别只看单一篇。

本文依据各平台公开文档与官方公告整理,只做中文归纳;具体做法、参数与限制以官方文档为准。