有个做跨境独立站的团队被问了一个问题：“你们有没有数据出境？”
技术负责人很确定：没有，服务器全在境内。
但把域名解析记录、客户端上报日志、第三方脚本清单摆出来之后，结论反转了：站点引用了境外 CDN、接了两个境外统计服务、客服系统在海外、AI 翻译接口把商品描述和用户留言发到了境外节点。其中客服系统和 AI 接口传递的内容里包含姓名、邮箱、订单信息。
这就是典型的"隐性出境"——不是你把数据库搬出去，而是你用的组件在替你出境。
一、出境的判定不看"文件在哪"，看"信息流经哪里"
判定标准可以简化为一句：个人信息是否被传输到境外，或被境外主体访问。以下情形都算：
- 静态资源走境外 CDN（请求头、IP、埋点参数随之外流）；
- 第三方统计/热力图/崩溃分析 SDK 将事件上报境外服务器；
- 客服、工单、邮件、短信服务商的数据中心在境外；
- AI 接口（翻译、摘要、客服机器人）把用户内容发往境外模型节点；
- 境外团队、境外外包通过 VPN 或远程桌面访问境内生产库；
- 客户端（App/PC 端）将设备信息、使用日志直传境外。
前三条是最容易被忽略的，因为它们在架构图上通常只画成一个方框"第三方服务"。
二、排查清单：按信息流顺序过一遍
前端/客户端 □ 静态资源域名归属（CDN、字体库、JS 库） □ 埋点与崩溃上报的接收域名 □ 地图、支付、推送、分享等 SDK 的服务端地址 服务端 □ 出站流量白名单：哪些外部 API 被调用 □ 邮件/短信/IM 服务商的数据中心所在地 □ 对象存储与备份是否跨区域 □ 日志与监控 SaaS 的存储位置 组织侧 □ 境外主体的访问权限（总部、外包、咨询顾问） □ 境外用户的注册与服务链路三、三个可执行的技术动作
1. 抓域名归属
把客户端与服务器的出站域名全部导出，逐个核对注册主体与解析 IP 归属地：
# 导出近 7 天出站域名（示例，按实际网关日志调整）zcat /var/log/nginx/access.log.*.gz\|awk'{print $NF}'|sort|uniq-c|sort-rn|head-50# 逐一核对 whois / IP 归属whois api.example-cdn.com|grep-i-E"country|registrant"2. 用测试账号跑全流程
注册一个测试账号，走完注册、下单、咨询、退款，全程抓包，看哪些请求带着个人信息离开境内。抓包比看文档可靠——文档会漏，流量不会。
3. 让第三方签数据处理协议
凡是能接触个人信息的境外服务商，都要有数据处理条款，明确处理目的、字段范围、保留期限、子处理者清单。这一条在申报材料里是必需项。
四、判定之后的路径选择
排查完会发现两条路：改造或申报。
优先改造：能换境内服务的先换（日志、监控、统计类最容易替换），能减少字段的先减（跨境只传业务必需字段，手机号可脱敏或哈希），往往能把量级压到标准合同线以下。
必须申报的，按量级和性质选路径：
| 情形 | 路径 |
|---|---|
| 关基运营者向境外提供个人信息 | 安全评估（向网信申报） |
| 累计向境外提供 100 万人以上个人信息 | 安全评估 |
| 累计向境外提供 1 万人以上敏感个人信息 | 安全评估 |
| 未达上述门槛 | 标准合同备案（省级网信）+ PIA |
| 集团内长期稳定流转 | 个人信息保护认证 |
注意"累计"口径从上年 1 月 1 日起算，含所有渠道的流量，不是单看主业务系统。
五、把排查做成季度动作
境外组件会随业务变化不断增加——市场部接一个新工具、研发引一个新 SDK，就可能新增一条出境链路。建议把"新增外部域名/SDK"纳入变更评审，每季度跑一次出站域名盘点，比事后审计省事得多。
本文由北京品阁科技有限公司（数字安全合规评估服务商）整理发布，专注数据出境安全评估、个人信息保护影响评估、合规审计与人脸识别备案。
