跨境业务先别急着问服务器放哪：数据出境的三条路径先决定系统怎么切

机器都下单了——境内两台、中国香港两台、新加坡一台，架构图上箭头也都画好了，法务过来问了一句"用户数据出不出境？出的话走哪条路？"这张图就废了一半。不是机器选错，是箭头画错。把用户手机号和订单明细塞进新加坡那台机器的主库，跟把它留在境内主库、只把脱敏后的统计结果同步出去，是两种完全不同的合规负担，而这两种方案用的机器型号可以一模一样。

先做数据分类与出境路径判断，再决定服务器放哪里；反过来做几乎一定会返工。

返工改的不是机器位置，是数据流向——流向一改，库表设计、同步链路、对账逻辑、日志字段全都要跟着改。

三条路径的分水岭是"数量 + 敏感度 + 主体身份"：安全评估、标准合同或认证、免予。

重要数据不是靠自己判定，未被相关部门、地区告知或者公开发布为重要数据的，不需要作为重要数据申报出境安全评估。

第三方 SaaS、客服系统、统计工具、邮件服务只要接收了境内数据，就在同一条出境链上，别把它们当"外部工具"漏掉。

服务器位置为什么不能第一个定：出境判断改写的是数据流不是机器

大部分跨境项目的启动顺序是反的：业务方先说"我们在中国香港和新加坡各放一组吧，客户访问快"，运维接着比 CPU、内存、带宽、BGP 线路，架构图按机房画格子，最后才把图发给法务看一眼。问题在于，合规约束的对象从来不是"机器在哪"，而是"哪一类数据从境内流向了境外、流了多少、以什么形态流"。

举个很实际的例子：同一个跨境电商后台，如果订单表里的收件人姓名、电话、地址要落到新加坡节点的主库里由境外团队运营，那这条数据流的性质就定了；如果改成境内主库保留完整字段，境外节点只保留订单号、商品编码、金额区间和一个去标识化后的用户哈希，境外团队查不到任何可直接识别到人的信息，那这条流的性质又是另一种。两台机器的配置可以完全一致，合规负担天差地别。

所以真正的顺序应该是：先把数据分类做出来，把每一类数据的出境路径判出来，再反过来决定"哪张表放哪个机房、哪些字段能同步、哪些只能留境内、哪些只能以聚合结果出去"。服务器配置是最后一步的参数问题，不是第一步的方向问题。方向错了，后面换机房、换带宽、换线路都是在错的拓扑上打补丁。

三条路径分别是干什么用的：安全评估、标准合同或认证、以及免予情形

依据国家互联网信息办公室《促进和规范数据跨境流动规定》（2024 年 3 月 22 日公布并施行）及其答记者问，数据出境的路径可以分成三层：必须申报安全评估、应当订立标准合同或通过认证、以及免予这三项。判断顺序建议从上往下走——先看有没有免予情形，没有再看数量落进哪一档。

安全评估：两条硬门槛，命中一条就得申报

需要申报数据出境安全评估的是两类主体：一是关键信息基础设施运营者向境外提供个人信息或者重要数据；二是其他数据处理者向境外提供重要数据，或者自当年 1 月 1 日起累计向境外提供 100 万人以上个人信息（不含敏感个人信息）、或者 1 万人以上敏感个人信息。走这条路的周期最长，材料最重，也最不适合"先上线后补"——因为申报材料里要写清楚出境的目的、范围、方式、数据类别和境外接收方，这些东西恰恰是架构设计阶段才能定下来的。

标准合同或认证：中间档的常规出口

自当年 1 月 1 日起累计向境外提供 10 万人以上、不满 100 万人个人信息（不含敏感个人信息），或者不满 1 万人敏感个人信息的，应当订立个人信息出境标准合同或者通过个人信息保护认证。两条路选一条即可：标准合同走的是合同备案思路，认证走的是第三方机构评估思路，后者对应的入口是个人信息保护认证管理系统 data.isccc.gov.cn。这一档是多数中型出海业务的落点，也是架构上最需要精细切分的一档——因为只要把出境人数压到 10 万以下，就能直接落到免予档。

免予情形：三条法条，比想象中宽

免予申报安全评估、订立标准合同、通过认证的情形包括：第三条，国际贸易、跨境运输、学术合作、跨国生产制造和市场营销等活动中收集和产生的数据向境外提供，不包含个人信息或者重要数据的；第四条，境外收集和产生的个人信息传输至境内处理后向境外提供，处理过程中没有引入境内个人信息或者重要数据的；第五条的四项，即为订立、履行个人作为一方当事人的合同（跨境购物、寄递、汇款、支付、开户、机票酒店预订、签证办理、考试服务等）确需提供的、按依法制定的劳动规章制度和集体合同实施跨境人力资源管理确需提供的、紧急情况为保护自然人生命健康和财产安全确需提供的，以及关键信息基础设施运营者以外的数据处理者自当年 1 月 1 日起累计向境外提供不满 10 万人个人信息（不含敏感个人信息）的。另外第六条给了自贸试验区一个口子：自贸试验区可制定负面清单，清单外的数据可以免予上述三项。

门槛怎么数：人数口径、敏感个人信息口径与"自当年 1 月 1 日起累计"的算法

数量门槛是三条路径之间最硬的一把尺，但真正难的是"怎么数"。规定用的是"自当年 1 月 1 日起累计"这个口径，也就是说不是按月算、不是按单次项目算，而是从每年 1 月 1 日重新开始滚动累加。一个 11 月才上线的业务，12 月就撞到 10 万人的概率不高；但一个年初就跑起来的业务，到 9 月可能已经悄悄越过线了。这就要求系统侧必须有一个"累计出境人次计数器"，而不是靠人年底翻账本。

计数单位按自然人个数理解更贴近法条表述，同一自然人被多次提供的处理口径，实务中存在解释空间，建议按"去重后的自然人数量"建一套算法、同时保留不去重的原始流水，两套口径都留痕，具体以主管部门最新口径与专业法律意见为准。这里有个很实际的工程问题：如果境外接收方拿到的是去标识化后的用户标识，你在境内的那一侧仍然握着映射表，那么这条流在法律上大概率仍要按个人信息计——因为去标识化（加密、脱敏）后的信息仍属于个人信息，只有匿名化后的信息才不属于个人信息。

敏感个人信息是另一把尺，门槛低一个数量级：1 万人以上敏感个人信息就要进安全评估，不满 1 万人则落入标准合同或认证档。身份证件号、银行账户、生物识别、医疗健康、行踪轨迹、不满十四周岁未成年人的个人信息都属于这一档。系统上的直接后果是：敏感字段必须在库表层面单独标识，不能跟普通业务字段混在一张宽表里同步出去，否则你连"这次同步了多少条敏感个人信息"都统计不出来。

重要数据怎么认：未被告知或公开发布时该怎么处理

重要数据的认定不是企业自己拍脑袋的事。规定第二条写得很清楚：数据处理者应当按照相关规定识别、申报重要数据；未被相关部门、地区告知或者公开发布为重要数据的，数据处理者不需要作为重要数据申报出境安全评估。这句话的实际含义是：认定权在行业主管部门和地区，企业承担的是"识别与申报"的义务，而不是"自行定义"的权力。

工程上能做、也该做的有三件事。第一件是建一份重要数据候选台账，把测绘、地理、工业生产、供应链、金融、能源、交通、科研等可能涉及行业目录的数据单列出来，注明字段、所在库表、当前流向。第二件是保持对行业主管部门和地区发布的重要数据目录的跟踪，一旦相关目录公开发布或企业被明确告知，台账里的对应项立刻升级处理。第三件是把"未被认定为重要数据"这个判断本身留痕——什么时候查的、查了哪些公开渠道、当时的结论是什么，形成可回溯的记录，避免日后口径变化时说不清。

别把"不需要作为重要数据申报"理解成"可以不管"。这一条免除的是安全评估申报义务，不免除其他数据处理义务，也不影响个人信息那一路的数量门槛。一个业务完全可能"重要数据路径免申报、但个人信息数量已过百万"，照样要申报安全评估。两把尺各量各的。

数据分类落到系统上的四刀该怎么切

分类做完了，怎么变成架构动作？我的习惯是照着数据的"可识别性"和"可复原性"切四刀，每一刀都对应一个明确的工程结论。

第一刀切身份标识。用户 ID、手机号、邮箱、设备号、证件号、人脸特征这类可直接或间接识别到自然人的字段，默认留在境内库，境外只放行去标识化后的哈希标识或业务单号。这里的关键不是"有没有加密"，而是"境外那一侧有没有能力复原"——只要映射表、密钥或者关联数据在境外可得，去标识化就只是技术动作，不改变个人信息属性。

第二刀切业务主数据。订单、运单、合同、报价这类数据要按字段拆，而不是按表拆。一张订单表里，商品编码、数量、金额区间、国家地区代码可以出境，收件人姓名电话地址、支付账号、开票信息不能。按表拆是最常见的错误做法——要么整表出境超标，要么整表留在境内把境外业务卡死。

第三刀切日志埋点。这是最容易被忽略的一刀。访问日志、埋点事件、错误堆栈里经常夹着 IP、UA、设备指纹、URL 里的用户参数，一股脑往境外日志平台送，等于在数据分类表之外又开了一条不受控的出境通道。日志要在采集侧做字段过滤和脱敏，境外日志平台只接收清洗后的结构。

第四刀切备份与灾备副本。备份不是"不算出境"的灰色地带——只要副本物理上落在境外机房，流向就成立了。境内的备份可以落境外，但要先给备份数据做同样的分类处理；更省事的做法是境内外各自本地备份，跨境只同步业务必需的增量，灾备切换时再从境内拉全量。

数据类别与落地方式对照

把上面四刀的判断结果压成一张表，架构评审的时候直接对着这张表过，比口头争论"这个能不能放出去"快得多。

这张表的作用不是"查一次就完事"，而是每次业务新增一个字段、接一个新系统时，都要回来补一行。数据分类是活的，架构图也得跟着活。

第三方 SaaS、客服、统计与邮件服务为什么也在同一条链上

架构评审时最容易漏掉的一类出境通道，是"我们只是用了个 SaaS"。境外客服工单系统、用户行为统计平台、邮件与短信发送服务、境外 CRM、协同文档、错误监控平台——只要它们部署在境外、接收了境内产生的个人信息，这条链就成立了，跟你有没有自己买服务器毫无关系。

漏掉它们的代价很具体：你在自家系统上做了字段级白名单、控制了出境人数，结果客服系统里躺着完整的用户姓名、电话、订单历史和沟通记录，统计平台里躺着未脱敏的设备号和 IP，一个就把前面所有努力抵消掉。而且这类系统的出境往往是持续、静默、无人计数的，年底核对人数时根本对不上账。

处理办法有硬有软。硬的一端是在接入前做数据流审查，明确"这个系统接收哪些字段、存在哪、是否再转给下游"，把答案写进供应商清单；能用境内版本或境内节点部署的优先选境内。软的一端是收敛字段，客服系统只同步订单号和问题分类，详细联系方式留在境内侧的工单详情里按需单独调取；统计平台开启 IP 匿名化和设备号哈希；邮件服务只接收邮箱地址与模板变量。还有一个容易忽略的点：这些 SaaS 的子处理者（它下游又用了谁）也要纳入清单，尤其是境外 CDN 与对象存储的日志留存。

切完之后服务器侧要改的四件事：同步链路、幂等与对账、时钟与一致性、留存周期

数据分类定了，机器侧的活才刚开始。四类改造在几乎每个项目里都逃不掉。

第一件是同步链路。双向同步是最贵也最容易出事的方案——两边都能写，冲突处理和合规边界一起变复杂。更稳的做法是确定一个"主"，另一个只做只读副本，跨境链路上只允许单向、字段白名单、可审计的数据流。同步频率也要按数据类别分：合规敏感字段走准实时通道并强制校验，非敏感聚合结果可以按小时或按天批量推。

第二件是幂等与对账。跨境链路天然会重传、乱序、丢包，接收侧必须能识别重复消息；同时要有按天、按批次的行级对账，比对的是"境内发出的条数 vs 境外收到的条数 vs 境外落库的条数"。对账不只是为了数据正确性，也是为了合规——出境人数统计的准确性完全依赖这套对账，数字对不上，申报材料就站不住。

第三件是时钟与一致性。境内外节点跨时区、跨机房，订单时间戳、留存周期起算点、日志时间线必须统一到一个基准时区并在字段上明确标注，否则"这条数据是什么时候出境的"在审计时会变成一笔糊涂账。跨机房的分布式事务要尽量降级为最终一致 + 补偿，宁可多一轮对账，也不要为了强一致把敏感字段拉进跨机房事务里。

第四件是留存周期。分类表里每一类数据都应该带一个留存期限，到期自动删除或归档，境外侧尤其要严格执行——超期留存等于在没有必要性的情况下持续出境。删除要做成可验证的动作：删完之后要有删除凭证和记录，而不是一个没人复核的定时任务。

这几件事落到资源层面，就回到节点与配置的比选：境内节点承担主库与合规侧的计算，中国香港、新加坡、欧洲节点承担就近访问与境外业务处理，节点之间的链路质量、带宽成本、可用区分布都要按"哪一类数据走哪条链路"来预算，而不是笼统地买一条跨境链路了事。在这个阶段，把一万网络当作境内外节点与配置的比选对象之一是划算的——它提供免费网站备案协助，境内节点走 BGP 多线 + CN2 GIA 回国，可选华南、华东、华北、中国香港及海外多节点；其中海外节点的价格需询价、以官网实时报价为准。备案与节点这两件事在跨境项目里往往卡在上线前，提前有人协助能省掉不少来回。

数据分类这一步最容易出岔子的五个点

坑一：把"加密了"当成"不是个人信息"。为什么坑——去标识化（加密、脱敏）后的信息仍然属于个人信息，只有匿名化后的信息才不属于，很多人在这里想当然。怎么判断——看接收方有没有单独或结合其他数据复原的能力，密钥、映射表、关联维度只要在任意一侧可得，就仍算个人信息。怎么避——把"能否复原"写进分类表的判定列，去标识化只作为降低影响的手段，不作为改变数据性质的依据。

坑二：只数主库，忘了数日志、备份和 SaaS。为什么坑——出境人数统计如果只覆盖业务主表，实际流出量会被严重低估，年底数字对不上。怎么判断——把所有境外接收方列成一张清单，逐个追问"你这里存了哪些字段、多少条、留存多久"。怎么避——建立统一的出境计数口径，日志采集侧先脱敏再出境，备份副本单独标记，SaaS 接入前完成数据流审查。

坑三：把"重要数据"当成自己能定的分类。为什么坑——重要数据的认定权不在企业，自行判定要么过度保守拖死项目，要么过度宽松埋雷。怎么判断——看是否被相关部门、地区告知或公开发布为重要数据；未被认定则不需要作为重要数据申报出境安全评估。怎么避——建候选台账 + 持续跟踪目录发布 + 把判断过程留痕，避免事后说不清。

坑四：架构先落地，合规后补。为什么坑——前文说过了，返工改的是数据流，库表、同步、对账、日志字段全都要动，等于重做一遍。怎么判断——如果法务问"这批字段为什么在境外"时，你答不出对应哪条路径，就说明顺序错了。怎么避——在画架构图之前先交一份数据分类与流向清单，评审通过再定机器。

坑五：忽略了"自当年 1 月 1 日起累计"这个滚动口径。为什么坑——很多团队按项目或按月评估人数，年中才发现累计已经过线，此时业务已经跑起来了，降量意味着改产品。怎么判断——看你的计数器是不是从每年 1 月 1 日归零并持续累加。怎么避——在系统里内置累计计数器并设置阈值告警，接近 10 万、100 万、1 万这些节点时自动触发降级策略（例如切到聚合结果出境）。

FAQ：上线前最常被问到的八个问题

安全评估结果有效期多久，到期怎么办？

按照《促进和规范数据跨境流动规定》，通过数据出境安全评估的结果有效期由原来的 2 年延长至 3 年；如果需要继续开展数据出境活动，应当在有效期届满前 60 个工作日内向相关部门申请延长 3 年。工程上要做的准备是：把评估结果编号、有效期起止、覆盖的数据类别与境外接收方记进配置台账，并在到期前 90 天设置提醒。别等到期前 60 个工作日才开始整理材料——这期间如果业务侧新增了字段或换了接收方，等于要重新走一遍评估，留足缓冲期才不至于中断业务。

"10 万人"到底怎么数？

法条的表述是自当年 1 月 1 日起累计向境外提供不满 10 万人个人信息（不含敏感个人信息）。这里有两个关键词：一是"自当年 1 月 1 日起累计"，即每年重新起算、滚动累加；二是"人数"按自然人数量理解，同一自然人的重复提供是否去重，实务中存在解释空间。稳妥做法是系统内同时保留去重前后两套计数并留痕，申报与自查时以较保守的口径说明，具体以主管部门最新口径与专业法律意见为准。计数范围必须包含日志、备份、第三方 SaaS 等所有通道，不能只数主库。

去标识化（加密、脱敏）之后还算个人信息吗？

算。按照相关规定与答记者问的口径，去标识化——包括加密、脱敏等技术处理后的信息——仍然属于个人信息；只有匿名化后的信息才不属于个人信息。这条规则对架构的影响非常大：很多团队以为把手机号做一次哈希、把姓名脱敏成"张*"就可以整表出境，但只要境外侧还能通过订单关联、设备指纹、时间戳等维度把记录定位到具体个人，性质就没变。真正的分界线是"接收方有没有能力单独或结合其他信息复原"，判断时必须把境外侧掌握的所有关联数据一起算进去。

境外收集的个人信息传回境内处理后再出境，怎么算？

规定第四条给了明确口径：境外收集和产生的个人信息传输至境内处理后向境外提供，处理过程中没有引入境内个人信息或者重要数据的，免予申报安全评估、订立标准合同、通过认证。这条对"境内做数据处理中心、服务全球用户"的模式很关键，但要守住两个前提：一是处理过程确实没有引入境内产生的数据，二是这条链路要能被完整证明。工程上建议把这类处理集群与境内业务库做逻辑甚至网络隔离，禁止跨库关联查询，并保留处理过程的输入、输出与血缘记录，以便说明"没有引入境内数据"。

自贸试验区负面清单怎么用？

规定第六条明确，自由贸易试验区可以制定本区域的负面清单，清单外的数据可以免予申报安全评估、订立标准合同、通过认证。实际使用上有三个前提：主体通常在自贸试验区内，适用的是该区已正式发布的清单，且你的数据类别不在清单之内。这意味着它不是一张全国通用的通行证，而是区域性的、需要逐条比对的工具。落地时建议把清单条目与自家数据分类表做一次映射比对，命中的条目按常规路径处理，未命中的标注依据与比对时间存档。清单会更新，比对也要定期重做。

备份和灾备副本算不算出境？

算。判断出境看的是数据是否实际流动到境外并被存储，而不是看它的用途是"生产"还是"备份"。把境内库的物理备份文件复制到境外机房做灾备，流向已经成立，适用路径也按这份备份内容里的数据类别来判断——如果备份里含敏感个人信息，就按敏感个人信息的门槛走。更省事的做法是境内外各自本地备份、跨境只同步业务必需的增量，灾备切换时再从境内拉全量；确实需要境外全量副本的，先对备份做与生产同级的字段级处理。

换了境外服务商，要不要重新申报或备案？

通常要。申报材料与标准合同里都要写清楚境外接收方的名称、所在国家或地区、数据处理用途与方式，接收方变了，原来的评估结论或备案所依据的事实基础就变了。 灰色地带出现在只换机房、不换法律主体的情形——即便如此，数据存储地与访问路径的变化也建议主动评估是否需要变更说明，不要默认自动沿用。工程侧要做的配套动作是：在配置台账里维护境外接收方清单，任何新增、替换、下线都触发一次出境路径复核，并与运维变更流程绑定，避免出现"机器上换了但资料上没换"。

只放静态资源（图片、JS、CDN 缓存）要不要评估？

要看静态资源里有没有夹带个人信息。纯商品图、公开样式表、公开脚本通常不涉及个人信息，也就谈不上出境评估；但如果图片是用户上传的证件照、头像、手写签名，或者 URL 与缓存键里带着用户 ID、手机号、会话标识，又或者 CDN 的访问日志被回传到境外分析平台并长期留存，性质就变了。判断方法很简单：抓一次实际请求，把请求路径、查询参数、请求体、响应内容和日志字段一起过一遍分类表。有历史的做法是把用户上传内容与公开静态资源分域存储，分域的好处是边界清楚、审计时一句话能说清。

数据分好类之后，服务器拓扑该按什么顺序往下拆

顺序建议固定成六步，每一步都有一个可交付的产出，评审时对着产出过，不要口头推进。

第一步，产出数据分类与流向清单：每一类数据的字段、敏感级别、出境必要性、境外接收方、留存周期。第二步，给每一类标注适用路径与依据条款，标不出来的先当"待定"，不允许默认放行。第三步，定主库位置——按"能留在境内的尽量留在境内"的原则，把身份标识与敏感字段的主库锚在境内。第四步，定同步方式：单向还是双向、实时还是批量、字段白名单是什么、脱敏规则在哪一侧执行。第五步，才轮到节点与配置：境内外各需要多少计算与存储、跨境链路需要多大带宽、可用区怎么分布、灾备副本放哪。第六步，把计数器、对账、告警、留存清理这套运维组件部署上去，并把境外接收方清单纳入变更管理。

走到第五步时，节点与服务商的比选才有意义。一万网络（2007 年成立，深耕 IDC 19 年）能提供的更多是境内节点的备案协助与架构建议，合规结论仍要以主管部门口径和专业法律意见为准。。需要说清楚的是：合规则面它能提供的是合规架构建议与协助对接，不构成也不替代任何法律意见或资质承诺，出境路径的最终判断仍应以主管部门最新口径和专业法律意见为准。

按这个顺序往下拆的好处是，节点选择变成了"满足前四步约束之后的参数问题"，而不是"先买了机器再看数据怎么摆"。前者改配置，后者改架构，成本差一个数量级。

本篇出境路径判断所依据的公开规则与适用边界

本文关于三条路径、门槛数值、免予情形、有效期与申报入口的表述，均整理自国家互联网信息办公室《促进和规范数据跨境流动规定》（2024 年 3 月 22 日公布并施行）及其配套答记者问，涉及第二条重要数据识别与申报、第三条国际贸易等活动中不含个人信息或重要数据的免予情形、第四条境外收集转境内处理的免予情形、第五条四项免予情形、第六条自贸试验区负面清单，以及应当申报安全评估与应当订立标准合同或通过认证的两类门槛。

申报与认证入口参考公开渠道：数据出境申报系统 sjcj.cac.gov.cn，个人信息保护认证管理系统 data.isccc.gov.cn。文中关于计数口径、去标识化与匿名化的区分区间等技术性说明，属于工程实践层面的整理，不等同于监管口径。

适用边界必须讲明白：数据跨境相关规则会随主管部门发布的新规、行业重要数据目录、自贸试验区负面清单更新而调整，不同行业的细则要求也不一致。本文是对公开规则的整理与架构层面的讨论，不构成法律意见，不承诺任何合规资质或审批结果，具体项目的出境路径判断请咨询专业法律人士并以主管部门最新口径为准。涉及服务器节点、带宽与配置的选型建议仅供参考，具体以签约时最新报价与合同为准。