GDPR下把用户数据跨境传到亚洲服务器，SCC到底怎么签

把欧盟用户数据放到亚洲服务器，很多团队第一反应是“签个SCC就行”。实际使用中发现，SCC不是一份随便盖章的模板，它更像是跨境传输的合同骨架：谁把数据传给谁、传什么数据、为什么传、服务器在哪、谁能访问、出了事谁通知、目的地国家法律会不会影响数据主体权利，这些都要写进去。

这里说的SCC，一般指欧盟委员会2021年发布的新版Standard Contractual Clauses，也就是Commission Implementing Decision (EU) 2021/914。老版SCC在新项目里基本不要再用了，合规审查时很容易被打回来。

先判断这次传输到底是不是GDPR意义上的跨境传输

GDPR里的跨境传输，不是看服务器品牌是哪国，也不是看付款主体在哪，而是看个人数据是否从EEA范围内，被传到没有充分性认定的第三国，或者被第三国主体远程访问。

举个很常见的场景：德国用户注册了一个SaaS，业务系统部署在新加坡机房，数据库里有邮箱、IP、订单、登录日志。即使运营团队在欧洲，只要数据落到新加坡服务器，通常就属于GDPR Chapter V下的跨境传输，需要传输机制。新加坡目前没有欧盟充分性认定，所以SCC基本是主路径。

再看另一个场景：生产数据库在法兰克福，但亚洲运维团队可以通过堡垒机远程查日志，日志里有用户ID、IP、设备信息。这也可能构成跨境访问，不是“数据没出欧洲就没事”。远程访问在合规审计里经常被问到，尤其是日志、客服后台、BI系统。

亚洲国家里要特别分开看。日本和韩国有欧盟充分性认定，传输压力会小很多，但也不是完全不用管，仍要看具体接收方、数据用途、后续再转移。中国大陆、中国香港、新加坡、印度、越南、泰国、马来西亚等地区，一般要走SCC、BCR或其他合法传输工具，企业项目里最常见还是SCC。

SCC签之前，角色要先掰清楚

SCC新版不是一份所有场景通吃的合同，它分模块。模块选错，后面的条款看起来都能填，但法律关系是错的。

EU业务方把数据放到亚洲云服务器

这是最常见的情况。EU业务方决定收集哪些用户数据、用来做什么，亚洲云服务商只提供云服务器、存储、网络、安全防护，不决定数据用途。这时EU业务方通常是Controller，云服务商是Processor，对应SCC Module 2，也就是Controller to Processor。

比如电商平台在欧洲卖货，把会员系统部署到新加坡云服务器。云厂商只负责IaaS资源，不分析会员画像，不拿数据做自己的营销，这就是典型Module 2。

EU处理商再把数据交给亚洲子处理商

很多外包研发、MSP、SaaS厂商会遇到这个。欧洲客户是Controller，欧洲SaaS厂商是Processor，SaaS厂商再采购亚洲服务器或亚洲运维团队处理数据。这时欧洲SaaS厂商和亚洲服务商之间一般用Module 3，Processor to Processor。

这里容易漏的是sub-processor授权。GDPR Article 28要求Processor不能私自找子处理商，必须取得Controller的授权。SCC签了还不够，主合同或DPA里也要把子处理商授权机制写清楚。

两个独立公司之间共享用户数据

如果EU公司把用户数据传给亚洲合作方，亚洲合作方会自己决定用途，比如联合营销、独立风控、广告投放，那可能是Controller to Controller，对应Module 1。

这个场景不能硬说对方是Processor。监管看的是实际控制权，不是合同标题。对方如果能自己决定处理目的和方式，写成Processor也会留下风险。

亚洲总部把数据传回欧洲处理商

Module 4是Processor to Controller，实际项目里相对少见。比如非欧盟Controller把数据交给欧盟Processor处理，欧盟Processor再把数据返回非欧盟Controller。这个模块不要随手套，除非角色链路确实符合。

SCC文本不能乱改，能填的是附件和可选项

新版SCC的正文条款不能实质性修改。可以选择模块、填写附件、补充商业条款，但补充内容不能和SCC冲突。实际合同里常见做法是：主服务协议MSA管价格、SLA、付款、资源规格；DPA管数据处理责任；SCC作为DPA附件或单独附件签署。

不要把SCC正文删来删去，也不要为了“看起来短一点”把Clause 8、Clause 14、Clause 15删掉。合规审查时，这类改动很扎眼。

Annex I要写到能看懂数据链路

Annex I不是形式字段，它是审计人员判断传输范围的入口。这里要写清楚数据出口方Data Exporter、数据进口方Data Importer、双方角色、联系方式、DPO或隐私联系人、处理活动描述、数据主体类别、个人数据类别、敏感数据类别、处理频率、保留期限、目的地国家。

实际填写时，别只写“user data”。这太粗了。可以写成：账号数据包括姓名、邮箱、手机号；技术日志包括IP地址、User-Agent、登录时间、请求路径；交易数据包括订单号、支付状态、账单地址；客服数据包括工单内容和附件。

敏感数据要单独判断。GDPR里的special categories包括健康数据、宗教、政治观点、生物识别、种族、性生活等。很多业务以为自己没有敏感数据，但客服工单附件里用户上传了身份证、医疗证明、银行卡截图，这种就不能按普通账号数据处理。

传输频率也要具体一点。比如“continuous transfer through application API and database replication”，比“regularly”更靠谱。保留期限也别写“as needed”，可以写“account data retained during contract term and deleted or anonymised within 30 days after termination unless legal retention applies”。

Annex II是重点，安全措施要写得像真实系统

Annex II写Technical and Organisational Measures，也就是TOMs。很多合同模板会写一堆泛泛的安全词，比如“industry standard security measures”。这在内部法务初审可能能过，但到了客户安全评估、DPIA、ISO审计，通常会被要求展开。

云服务器场景里，Annex II至少要覆盖传输加密、静态加密、访问控制、权限审批、日志审计、备份恢复、漏洞管理、隔离机制、事件响应、数据删除、人员保密、子处理商管理。

传输加密可以写TLS 1.2或TLS 1.3，管理面访问走VPN、Zero Trust或堡垒机，SSH禁用密码登录，只允许Key或短期证书。数据库不要裸露公网，至少放到私网、安全组、ACL后面。这里不是为了写得漂亮，而是后续真的要按这个执行。

静态加密要看实际能力。云盘加密、对象存储SSE、数据库TDE都算常见手段。如果业务方自己控制KMS密钥，尤其是密钥保留在EU区域，风险会比服务商完全控制密钥更低。Schrems II之后，监管很关注第三国公共机构访问风险，密钥控制权会被反复问。

访问控制要写到人和流程。比如生产环境仅限授权SRE访问，采用MFA，权限按最小权限授予，紧急访问需要工单审批并自动记录，离职或岗位变更后24小时内回收权限。实际使用中发现，很多项目出问题不是加密算法不够强，而是共享账号、长期Root权限、日志没人看。

备份也要写。备份数据同样是个人数据，不是“备份不算”。备份存放区域、保留周期、恢复演练、删除机制，都要和主数据一致。比如生产数据在新加坡，备份复制到香港或东京，这也是再传输，要写进Annex I和Annex III相关材料里。

Annex III别漏，云服务商的子处理商也算

Module 2和Module 3会涉及sub-processors。云服务商可能还会使用机房运营商、DDoS清洗服务、工单系统、监控告警、邮件通知、CDN、对象存储、备份服务。这些不一定都能接触明文个人数据，但要做识别。

Annex III里通常写子处理商名称、地址、处理活动、所在国家。也可以在DPA里约定维护一个在线sub-processor list，并在新增子处理商前提前通知客户，比如提前30天通知，客户有合理反对权。

这里补充一点，IaaS场景里，机房方是否构成sub-processor要看它是否可能处理个人数据。只提供物理托管、无逻辑访问权限，有的合同会把它归为基础设施供应方；但如果机房人员有机会接触硬盘、故障设备、备份介质，合规团队通常会要求披露。

Clause 14的TIA不能省，特别是传到亚洲非充分性认定地区

SCC签完不代表万事结束。Schrems II之后，数据出口方还要评估目的地国家法律和实践是否会影响SCC的执行，这就是Transfer Impact Assessment，常叫TIA。

TIA一般会看这些内容：目的地国家是否有政府访问数据的法律机制；访问是否有必要性和比例性限制；企业是否能挑战不合法请求；数据类型是否敏感；传输规模是否大；接收方有没有收到过政府访问请求；技术措施是否能让第三方无法理解数据。

传到新加坡、香港、印度、中国大陆等地时，客户经常会要求TIA文件。不是所有项目都要写成几十页，但至少要能说明判断过程。比如用户数据只是低敏账号数据，业务做了字段级加密，密钥在EU KMS，亚洲服务器只处理密文或假名化ID，这比把完整用户资料明文放在亚洲数据库里好解释很多。

如果是中国大陆服务器，还要额外关注中国本地的数据安全法、个人信息保护法、网络安全法要求。GDPR解决的是从EU往外传的问题，中国PIPL解决的是在中国境内处理个人信息以及向境外提供个人信息的问题，两边不是互相替代。

服务器选型时，合同材料和网络质量要一起看

合规不是只看PDF，业务也不是只跑合同。把欧洲用户数据放到亚洲服务器，网络延迟、DDoS防护、带宽计费、日志保留、快照备份、工单响应都会影响后续可用性。

实际采购时可以把供应商问卷和技术参数一起拉出来看。比如是否能提供DPA、SCC签署支持、sub-processor list、安全白皮书、ISO 27001或SOC 2材料；服务器侧是否支持私网隔离、安全组、快照、备份、DDoS清洗、带宽峰值说明；工单里是否能配合删除证明、事故通知、访问日志导出。

如果你也在找海外云服务器、高防服务器或者跨境业务节点，可以看看129云。它们主要做高性能云服务器、G口大带宽服务器、高防服务器租用和海外云计算解决方案，适合游戏、企业、高防这类对稳定性和网络质量比较敏感的场景。采购前可以直接把DPA、SCC、日志留存、DDoS防护边界这些问题列出来问清楚，客服热线400-9177118。

多说一句，DDoS防护和GDPR安全措施不是一回事。DDoS防护解决可用性，能算安全措施的一部分，但不能替代访问控制、加密、删除、审计。比如美国高防-D型这类200G防御、150Mbps峰值、三网精品线路，适合被攻击风险高的业务入口；但如果里面承载EU个人数据，SCC、DPA、TIA仍然要照常做。

签署文件通常怎么放

比较常见的合同结构是MSA加DPA加SCC。MSA写服务内容、费用、SLA、违约责任；DPA写GDPR Article 28要求，包括处理目的、处理类型、数据主体类别、保密、协助数据主体请求、删除返还、审计权、子处理商；SCC作为DPA附件，选定对应Module并填Annex。

如果客户来自英国，还要额外处理UK GDPR。英国不直接使用EU SCC新版作为唯一工具，通常用UK IDTA，或者在EU SCC后面加UK Addendum。很多跨国客户会要求同时签EU SCC和UK Addendum，因为用户既有EEA也有UK。

瑞士用户数据还要看FADP。实务里常见做法是在SCC里加瑞士补充说明，把瑞士FDPIC、瑞士数据主体、瑞士法律引用补进去。这个细节在跨境SaaS项目里经常被欧洲客户法务问到。

Clause 9子处理商授权别写得太死

SCC Clause 9里，子处理商可以选择specific prior authorisation，也可以选择general written authorisation。云服务实际运营中，完全逐个特定授权会比较难，因为监控、告警、邮件、机房、网络供应商可能会调整。

更常用的是general authorisation，加一个提前通知机制。比如新增或替换sub-processor前提前30天通知Data Exporter，Data Exporter可以基于合理数据保护理由提出反对。如果无法解决，双方按合同约定终止受影响服务。

这个写法对云服务商和客户都比较现实。客户有知情权和反对权，服务商也不至于每换一个告警平台都重新签一轮合同。

Clause 13监管机构和Clause 17法律适用要填对

SCC里要指定主管监管机构。一般跟Data Exporter在EEA的建立地有关。如果Data Exporter在德国，可能就是对应德国州监管机构；在爱尔兰，就是DPC；在法国，就是CNIL。如果Data Exporter不在EEA，但受GDPR Article 3(2)约束，通常看其欧盟代表所在成员国。

法律适用也不能随便写香港法、新加坡法或中国法。SCC Clause 17要求选择允许第三方受益人权利的EU成员国法律。很多合同会选爱尔兰法、德国法、荷兰法、法国法，具体看公司主体、客户要求和律师意见。

Clause 18管法院管辖，也要选EU成员国法院。商业主合同可以另有争议解决条款，但不能削弱SCC里数据主体的权利。

不要把SCC当成安全豁免

SCC是传输工具，不是安全认证。签了SCC但数据库公网开放、Root密码多人共享、备份长期不删、日志包含明文Token，这些问题一样会构成GDPR风险。

工程侧经常要配合做这些动作：生产数据最小化，只同步亚洲业务真正需要的字段；能假名化就不要直接用邮箱手机号做主键；敏感字段做应用层加密；密钥放在EU KMS或独立HSM；亚洲运维访问走MFA和堡垒机；导出数据自动脱敏；日志里过滤Authorization、Cookie、身份证号、银行卡号。

还有一个容易忽略的点：开发测试环境。很多团队生产环境管得很严，测试环境直接从生产库dump一份到亚洲开发机。GDPR下这同样是个人数据处理。测试数据最好脱敏或合成，必须用真实数据时，要写明目的、权限、保留期限和删除流程。

数据删除和返还要能执行，不只是合同里写

SCC和DPA通常都会要求服务结束后删除或返还个人数据。云服务器场景里，删除不只是rm一个目录。要考虑云盘、快照、镜像、对象存储、备份、副本、日志、监控数据、工单附件。

比较稳的做法是维护数据位置清单。用户数据在哪些系统里存在，主库、从库、缓存、队列、搜索索引、对象存储、日志平台、备份仓库都列出来。到删除时按清单执行，能自动化就自动化，不能自动化至少有工单记录。

备份删除通常有延迟，这是可以接受的，但要写清楚。比如主数据在30天内删除，滚动备份在90天自然覆盖，期间备份被隔离保护，不用于生产恢复以外目的。如果客户要求删除证明，供应商要能出具合理说明。

事故通知时间要和GDPR 72小时对齐

GDPR要求Controller在知道个人数据泄露后，必要时72小时内通知监管机构。Processor发现事件后要without undue delay通知Controller。SCC和DPA里要把这个链路写清楚。

云服务商不一定能判断某个事件是否达到监管通知门槛，因为它未必知道业务数据含义。但它至少要及时通知客户：发生时间、影响资源、已知数据范围、已采取措施、建议客户采取的动作、后续更新频率。

技术侧要准备日志。没有日志，事故调查只能靠猜。管理面登录、API调用、快照创建、磁盘挂载、安全组变更、数据库登录、导出任务，都建议保留可审计记录。日志保留期限要和合同一致，常见是90天、180天或一年，取决于客户行业和成本。

跨境链路变更时，SCC也要跟着更新

服务器从新加坡迁到香港，备份从东京改到孟买，新增印度客服团队访问后台，CDN日志从EU写到亚洲对象存储，这些都可能改变传输事实。SCC Annex和TIA不能永远停留在项目上线那天。

实战里建议把跨境数据变更放进变更流程。不是让法务卡每一次发布，而是让涉及数据区域、访问主体、子处理商、数据类别、保留期限的变更能被识别出来。变更单里加几个字段就能解决很多后续扯皮：是否涉及个人数据，是否离开EEA，是否新增第三国访问，是否新增sub-processor，是否改变数据保留。

一份SCC材料包通常应该包含什么

客户真正审的时候，通常不会只要SCC签字页。更常见的是要一组材料：签署版DPA、签署版SCC、Annex I/II/III、sub-processor list、TIA、安全措施说明、数据删除流程、事故响应流程、访问控制说明、相关认证或渗透测试摘要。

如果业务涉及游戏、金融、医疗、未成年人，材料会更细。游戏业务还会问DDoS防护、Anti-Cheat日志、玩家行为日志、语音聊天数据；金融会问PCI DSS、账单数据、风控模型；医疗会问special categories和加密密钥控制。不同业务别用同一份“通用SCC附件”硬套。

常见坑位直接写清楚

把亚洲云厂商写成Controller，但实际上它只是IaaS Processor，这会导致责任分配混乱。云厂商通常不决定客户数据用途，不应承担Controller义务。

只签SCC不签DPA。SCC解决跨境传输，DPA解决Processor处理义务。EU Controller把数据交给Processor，Article 28 DPA基本绕不开。

Annex II写得过于抽象。客户问“是否支持MFA、密钥谁控制、日志保留多久、删除怎么做”时答不上来，说明附件没落到真实系统配置。

忽略远程访问。数据存在欧洲，但亚洲团队能查库、看日志、导出报表，也要纳入跨境访问评估。

生产和测试混在一起。测试库拿真实EU用户数据，又没有SCC范围说明、没有脱敏、没有删除周期，这是审计里很常见的红灯。

供应商换了机房或备份区域，没通知客户。只要目的地国家、sub-processor或数据访问路径变了，原来的TIA结论可能就不够用了。

签之前可以直接问供应商这些问题

能否签署EU SCC 2021/914，支持哪些Module；是否提供DPA；是否有sub-processor list；数据中心具体国家和城市在哪里；备份和快照会存到哪些区域；运维人员在哪些国家；是否支持MFA、堡垒机、访问日志导出；云盘和对象存储是否支持加密；客户能否自管密钥；删除后是否能提供证明；发生安全事件多久通知；是否支持UK Addendum或IDTA；是否有ISO 27001、SOC 2、PCI DSS等材料。

这些问题不需要等合同快签完才问。越早问，越容易判断供应商是否适合承载EU个人数据。尤其是亚洲服务器项目，一旦业务上线后再补SCC、补TIA、补子处理商清单，改网络架构和数据流会很麻烦。

一个贴近真实项目的签署写法

Data Exporter：一家注册在荷兰的SaaS公司，向EEA客户提供在线工单系统，是Controller。

Data Importer：一家位于新加坡的云服务器供应商，为该SaaS提供计算、存储、网络和基础安全防护，是Processor。

SCC Module：Module 2 Controller to Processor。

传输内容：账号信息、工单内容、附件、IP地址、登录日志、操作日志、账单状态。若附件可能包含敏感数据，在Annex I单独说明，并在产品侧限制上传类型或增加脱敏提示。

处理目的：托管SaaS生产环境、提供存储、备份、网络访问、故障排查和安全监控。

目的地：Singapore。若备份复制到Japan，也要写Japan。若监控日志写入Hong Kong，也要写Hong Kong。

保留期限：合同期间保留；合同终止后30天内删除主数据；备份在90天滚动覆盖；法律另有要求除外。

TOMs：TLS 1.2+传输加密，数据库不开放公网，管理访问启用MFA和堡垒机，生产权限最小化，访问日志保留180天，云盘加密，敏感字段应用层加密，密钥由客户控制并存放于EU KMS，季度权限复核，漏洞按严重级别修复，安全事件发现后without undue delay通知客户。

子处理商：列出机房运营商、DDoS防护服务、监控告警平台、工单系统，并说明处理活动和所在国家。新增子处理商提前30天通知。

TIA结论：基于数据类别、加密措施、密钥控制、访问限制、目的地法律评估和接收方历史请求情况，当前补充措施可降低传输风险；若新增敏感数据、大规模数据分析或政府访问请求，重新评估。