数据出境不是只有「把数据库复制到国外服务器」这一种

很多企业经营者的第一反应是「我的数据都在国内的服务器上，不存在数据出境」。这个认知问题比合规本身的问题还要严重。

在法律定义上，数据出境的场景远比你想象的要广。你把员工邮箱系统托管在海外的邮件服务商那里，境外的技术人员在维护时可以访问到你的通讯录和邮件内容——这就是数据出境。你的CRM系统用的是国外的SaaS服务，客户信息存储在境外的服务器上——这也是数据出境。你把自己的电商网站部署在海外的云服务上，消费者的收货地址和联系方式存在了境外——这同样是数据出境。

国家网信办在2022年发布的数据出境安全评估办法中明确了几种需要申报安全评估的情形：处理一百万人以上个人信息的数据处理者向境外提供个人信息；自上年1月1日起累计向境外提供十万人以上个人信息或一万人以上敏感个人信息；以及其他网信办规定的需要申报的情形。达到这些门槛就必须走安全评估，不是「自行判断风险不大就可以不走」。

第一道坎：数据出境的必要性论证

安全评估不是让你证明数据出境的行为在技术上安全——技术安全只是评估内容的一部分。评估的第一个核心问题是：你这个数据出境到底是必须的，还是你自己为了方便才这么做的。

很多申请在这个环节被反复退回来修改，因为申请材料写成了一份「我为什么要用这个境外服务」的商业理由说明书，而不是在法律框架下论证「为什么用这个境外服务是不可替代的」。两者之间的区别很重要。论证必要性的标准是：有没有不涉及数据出境的替代方案可以达到同等的业务效果。如果有，你需要在申报材料中解释为什么替代方案不可行。

对中小企业来说，在准备申报材料之前先把这个问题想清楚是最值得花时间的一步。如果真的能找到国内的可替代服务从而完全避免数据出境，那比走安全评估流程要快得多。如果确实没有可替代方案——比如说你要合作的境外客户要求使用他们指定的内部系统——那么把这个原因写清楚，比写一堆「国际化战略需要」要有说服力得多。

第二道坎：境外接收方的数据保护能力评估

第二个卡点是对境外接收方的评估。安全评估要求申报企业对数据接收方——比如你的境外云服务商、SaaS平台、母公司或合作伙伴——的数据保护能力做详细评估。

这就产生了一个实际操作上的困难：很多中小企业不掌握境外接收方的内部安全管理制度和技术架构细节。你要求AWS或者Google Cloud把他们的内部安全审计报告给你看，对方大概率不会配合一个中小客户的需求。但没有这些材料，你的评估报告又缺乏必要的支撑。

解决这个问题的实际路径通常不是硬要从服务商那里要材料，而是换个角度组织你的评估论证：第一，引用服务商对外公开的安全认证——比如ISO 27001信息安全管理体系认证、SOC 2审计报告——作为主要的技术能力证明材料；第二，引用你和该服务商签订的数据处理协议中的安全条款和违约责任条款；第三，说明你在自己的控制范围内采取了哪些额外的安全措施来降低整体风险。这三类材料组合在一起，可以从法律文件、第三方认证、自身控制能力三个角度证明你做了该做的尽职调查。

第三道坎：个人信息主体权益保护方案

第三个经常被忽略的关键要求是：你需要向监管部门证明，数据出境不会削弱中国法律赋予个人信息主体的各项权利——查询权、更正权、删除权、投诉权等。换句话说，数据到了境外，你想查自己的数据、想删自己的数据、想投诉数据被滥用，这些权利不能被削弱。

这个问题在实操中的难点在于，境外的法律体系不一定提供和中国《个人信息保护法》同等标准的权利保护。比如中国法律规定的「个人信息主体有权要求数据处理者删除其个人信息」，在有些国家的法律框架下可能对应的是一个更窄的删除权范围——比如说只适用于非法处理的情形，而不是用户随时可以要求删除。

申报材料中对这一点的处理，通常需要在你和境外接收方的数据处理协议中明确约定：境外接收方同意在数据处理活动中遵守不低于中国法律保护标准的个人信息保护要求。这个条款需要在合同中以明确的语言写出来，而不是靠「双方应遵守适用法律」这类通用条款一笔带过。

不是所有数据出境都需要走安全评估

最后澄清一个重要但经常被误解的点：不是所有涉及数据出境的场景都必须要走安全评估。如果涉及的数据量没有达到申报门槛，可以选择走标准合同备案或个人信息保护认证这两条更低门槛的路径。这三条路径适用于不同的数据出境规模和个人信息类型，企业应该根据自己的实际情况选择最合适的一条——网信办的文件中对每条路径的适用条件有明确的界定。

但不管走哪条路径，本文讨论的三个核心问题——必要性论证、接收方评估、主体权益保障——都是绕不开的。区别只在于提交的材料精细程度不同。因此，在决定走哪条路径之前，先坐下来把这三个问题理清楚，可以节省后续大量的返工时间。