做欧盟金融业务的服务器合同，为什么必须写清数据存放地和退出安排

一家做欧洲支付业务的客户在到期续约前两周，发来一页补充条款。条款里没有提 CPU 型号、没有提带宽、也没有问机柜在几楼，只问了三件事：这批服务器产生的所有数据，处理地点分别在哪几个国家；这些地点如果发生变化，会提前多久、以什么方式通知他们；合同终止或者服务商出现经营问题时，数据怎么取回、过渡期有多长。客户方的合规负责人补了一句：这三条不写进合同，他们的内部审批过不去。

这页纸把选型顺序整个翻了过来。过去谈这类业务，通常先定机房和配置，再谈商务，合同条款由法务照模板填。而现在，能不能把地点、通知、退出这三件事写进合同，成了能不能接下这笔订单的前置条件——如果写不进去，机房再好、配置再合适也不成立。

这篇只讨论一件事：当客户是欧盟金融实体、并且把服务器与机房这类信息通信技术（ICT）服务外包给你时，合同里必须出现哪些条款，以及这些条款如何一路反推到选型、数据存放地、可用性设计和日常运维上。它讲采购与技术条款被合规改写的部分，不展开欧盟《数据法案》关于切换费用与切换时限的另一套规则，那是另一篇的话题。

续约时多出来的这一页，检查对象其实是合同不是机房

这里说的规则来自欧盟《数字运营韧性法》，即条例 (EU) 2022/2554，通常简称 DORA。它的文本于 2023年1月16日生效，并自 2025年1月17日起适用。适用范围覆盖大约 20 类金融实体，常见的包括信贷机构、支付机构、电子货币机构、投资公司、加密资产服务商、保险与再保险机构、中央证券存管机构、中央对手方、交易场所、信用评级机构、众筹服务提供商等。

要点在于：DORA 约束的直接对象是这些金融实体本身，而不是卖给他们机柜和带宽的公司。金融实体对自身的信息通信技术风险负责，包括由第三方提供的那一部分。当监管机构或者金融实体自己的内审去检查时，拿出来的第一份材料往往不是拓扑图，而是合同——看合同里有没有把服务内容、数据处理地点、可用性要求、退出安排、事件援助这些事项写清楚。也就是说，被检查的是"合同写了什么"，而不是"机房建得怎么样"。

这个区别对服务商的意义很实际。一份只写了配置清单和月费的合同，无论机房条件多好，在对方的合规清单上都过不了。反过来，一份把这些条款写全的合同，即使底层是相当普通的托管服务，也能进入候选。所以正确的顺序是先确认条款能不能写进去，再决定机房与配置：条款谈不下来，后面所有选型工作都是白做。

另一件容易被忽略的事是"谁来判断"。金融实体需要自己识别哪些业务活动属于关键或重要功能，并据此判断哪些 ICT 第三方安排属于重点管理对象。这个判断由金融实体做出，不是由服务商宣称自己"不属于"就能绕开。客户一旦认定某项功能重要，对应的合同条款要求就会整包传导过来。

五类合同条款，每一类都对应着一个技术现实

DORA 关于 ICT 第三方合同一般要求的内容集中在条例第 30 条（Art.30）。落到服务器租用与托管这类场景，可以归纳成五类必备条款。每一类都不是纸面措辞，后面都挂着一个具体的技术要求。

第一类是对服务和分包的完整描述。合同要写清楚提供的是什么服务、服务由哪些部分组成、哪些部分被再分包给了谁。技术上这要求服务商能给出一份准确的层级说明：机柜和电力来自谁、带宽来自谁、硬件维护由谁做、监控与值守由谁承担。很多服务商在这里卡住不是因为不愿意说，而是自己也没有一份能对外的一致口径。

第二类是对数据处理地点的描述，以及地点变更的事先通知义务。这是开篇那页条款里的第一条，也是本篇的重点，下面单独展开。

第三类是可用性、完整性与保密性要求。可用性对应冗余、电力、网络、故障响应；完整性对应备份与校验；保密性对应访问控制与加密。这一类会直接变成 SLA 条款里的具体口径：可用率怎么算、计划内维护算不算、故障从哪一刻开始计时。

第四类是在服务商破产、清算或者合同终止的情况下，金融实体取回数据的安排。这是开篇那页条款里的第三条，同样在下面展开。

第五类是服务级别与事件援助义务。金融实体发生重大事件时需要第三方配合处置，因此合同要写清协助的范围和响应方式。这一条决定了服务商平时的值班与取证能力是否够用，详见后面关于通报时限的部分。

地点条款会一路反推到机房、备份和运维接入方式

"数据处理地点"这五个字听起来简单，实际范围比多数人想象的宽。它不只指主用机房所在的国家和城市，还包括备份落在哪、日志存在哪、监控数据由哪一侧采集、运维人员从哪个地区接入操作。客户真正想知道的是：我这份数据的全生命周期，经过了哪些地理节点。

所以在回答这个问题之前，需要先把自己的服务拆一遍。主用服务器在哪个机房；备份是一份还是多份、分别落在哪里；日志是留在主机本地、还是集中采集到另一处；监控与告警平台部署在哪一侧；远程运维从哪些地区接入、是否经过第三国。这些都会出现在客户的追问里，而多数服务商第一次被问到时只能答出第一项。

在这个环节上，服务商能提供的确定性本身就是产品的一部分。在这类需要把数据地点写进合同的场景里，一万网络这类深耕 19 年（成立于 2007 年）、各地机房信息对外可查的服务商，至少能让客户把「数据存在哪、变更提前多久通知」这两件事写进条款，而不是停留在口头承诺。

"变更需事先通知"这一句对技术侧的约束更硬。它意味着机房一旦要迁移、主用位置一旦要调整，就不能等到搬完再告知，必须留出约定的提前量，并且以合同约定的方式送达。反过来说，选型时就要避开那些位置本身不稳定、或者随时可能因上游调整而搬迁的方案——不是因为搬迁技术上做不到，而是因为搬迁会触发一条已经写进合同的告知义务，若履行不当会直接构成违约。

这也解释了为什么同一份配置在不同机房之间不能随意等价替换。两台配置完全相同的服务器，一个在地点稳定、可书面承诺通知期的机房，另一个在上游随时可能调整的位置，对金融客户而言不是同一个商品。后者的合规成本更高，因为客户要么承担不确定性，要么额外准备一份应急预案去覆盖它。

还有一层是分包链条。如果服务商自己还要把电力、带宽、硬件维护再分包出去，那么这些分包方所在的地点和处理活动也要能说清楚。金融客户关心的不是你和你的一级供应商，而是整条链上有没有他没申报过的处理地点。这也是为什么"我们只用自有资源"在某些合规场景里反而是加分项——不是因为自有资源更好，而是链条更短、可说明性更强。

退出过渡期把镜像可移植性变成了硬性指标

第四类条款——破产或终止时的数据取回——在技术侧有一个直白的译法：客户能不能在不依赖你的前提下，把业务完整地搬到别处。这一条平时毫无存在感，直到客户提出要写过渡期，才会暴露出一系列从未被验证过的能力。

第一项是镜像与数据的可导出性。系统镜像是否支持导出为通用格式、导出后能否在另一家环境里正常启动；数据库能否全量导出为标准转储格式；对象存储里的数据能否批量拉取。很多平台提供的快照只能在自身体系内恢复，这种快照在合规意义上不算"取回能力"，因为客户拿到的东西离开你的平台就不可用。

第二项是导出通道与耗时。合同里写了取回权，但如果全量数据只能通过工单人工拷贝、耗时以周计，那么再长的过渡期也不够用。因此需要在签约前就能给出量级估算：全量导出大概要走多少数据量、通过什么通道、预计多长时间。这个数字不需要精确，但必须能说出来，因为过渡期条款的长度就是按它谈的。

第三项是配置与依赖的可重建性。真正卡住迁移的往往不是数据，而是那些不在数据里、也不在镜像里的东西：网络与防火墙策略、域名与证书、凭据与密钥、账号体系、定时任务、上下游依赖清单、以及那些当年手工改过一次就再没人记下的参数。缺少这些，即使数据和镜像都在，重建出来的系统也跑不通。把基础设施写成可复现的描述、把凭据与依赖维护成一份活的清单，是把退出条款落到实处的必要前提。

第四项是加密与密钥的归属。如果数据在存储层做了加密，必须明确密钥由谁持有、终止时是否移交。密钥不移交的加密数据，法律上取回了，工程上依然是废数据。这一点在合同谈判里经常被忽略，因为双方都在讨论数据本身。

过渡期该留多久没有统一答案，它取决于上面四项中最慢的那一项。一个只在自家平台内可恢复、依赖手工配置、密钥不移交的方案，需要非常长的过渡期才谈得下来；而一个镜像与数据可通用导出、配置可复现、依赖清单完整的方案，用较短的过渡期就能满足客户，也更容易通过对方合规审批。换句话说，退出条款的长度实际上是服务商工程成熟度的函数。

支持关键或重要功能时，还要加上审计权与测试配合

如果被外包的安排支持的是金融实体的关键或重要功能，要求会在上述五类之外再加一层。条例中针对这类情况列出的附加要求包括：完整的服务级别描述、通知与报告义务、业务应急计划、配合威胁主导渗透测试（TLPT）、无限制的查阅、检查、审计权以及现场文件复制权，以及明确的退出战略与强制过渡期。

其中对机房与服务器运营影响最大的是审计权。它意味着金融实体及其委托的审计方，以及在某些情况下主管机关，有权进入现场查阅并复制文件。落到操作层面需要提前想清楚几件事：审计能否覆盖到物理访问记录与门禁日志；能否提供与该项服务相关的变更记录、故障记录、维护工单；现场检查时由谁陪同、能在多大范围内拍照与取走副本；以及——最常见的顾虑——对其他同机柜客户会不会造成影响。

最后这个顾虑是有解的，但要在签约前谈，而不是在审计员站在机柜前时才谈。可行的做法包括：把审计范围限定在该客户使用的设备与区域内；对其他客户的标识做遮蔽；由服务商人员代为调取与复制文件；在合同里写明审计不扩展到无关客户的数据。这些都是标准做法，但必须写清楚，否则现场一定会卡住。

TLPT 配合也是同类问题。这类测试由金融实体组织、按监管框架推进，服务商需要配合的是测试窗口、参与人员、测试范围确认以及必要的例外处理。如果测试涉及生产环境，还要提前约定哪些操作不允许做、如何避免影响真实业务。这一条对服务商的要求是"能被纳入对方演练计划"，也就是要有明确的接口人和流程，而不是临时协调。

至于是否被认定为关键 ICT 第三方（CTPP），认定标准见委托条例 (EU) 2024/1502（2024 年 5 月 30 日公布），并且是否被指定由监管机构依程序决定，不是服务商自评或客户单方指定就能确定的。需要知道的是处罚口径：对关键 ICT 第三方的处罚可至其全球日均营业额的 1%，最长持续 6 个月。对绝大多数中小服务商来说，这个数字的现实意义不在于可能被罚，而在于它解释了为什么金融客户对合同条款如此执着——他们自己的风险敞口同样存在。

服务器侧要拿出的四类证据

把上面的条款翻译成运维动作，服务商平时需要能拿出四类东西。它们平时不起眼，但在客户尽调、审计和事件处置时是唯一有效的凭证。

镜像与数据导出能力。要有一种不依赖本平台即可恢复的导出路径，并且定期真的走一遍。只做过快照、从未完整恢复过的系统，不能算具备取回能力。建议至少按季度做一次恢复演练，记录实际耗时与遇到的问题，演练记录本身就是尽调材料。

日志留存。要能说清留了什么、留多久、存在哪、谁能调。需要留的不只是业务日志，还包括登录与权限变更、管理面操作、硬件与网络事件、备份执行结果。留存周期要能覆盖客户事件报告与年度回顾的需要，而且日志本身要能被导出——导出不了等于没留。日志的落地位置同样属于"数据处理地点"，需要在地点条款里一并申报。

可迁移性证据。包括可复现的基础设施描述、凭据与密钥清单、依赖与外部接口清单、以及一份"如果要搬走，需要几天"的量级估算。这份材料平时是运维文档，关键时刻是谈判筹码——它能把过渡期条款从模糊拉到具体。

这四类证据还有一个共同点：它们都必须能被第三方复核。客户不会只看你给的结论，通常会要求看到记录本身——演练记录、留存策略文档、导出测试的输出、SLA 的实际统计报表。因此与其在尽调时临时整理材料，不如把它们做成常态化的交付物：每次演练留一份记录，每月出一份可用性与备份执行报表，每季度验证一次导出链路。这套动作的成本主要在第一次建立，之后只是维护。

可用性与完整性的技术口径。可用率按什么算、故障从哪一刻起算、计划内维护是否计入、数据可用性的度量方式是什么、备份的恢复点目标与恢复时间目标分别是多少。这些数字要在签约前说清，因为它们会被原样写进 SLA。写进 SLA 之后，它们就从运维指标变成了合同义务。

4 小时、24 小时、72 小时、1 个月：通报时限反推出的监控要求

DORA 对重大 ICT 相关事件设有明确的报告节奏：事件被分类为重大之后，初次通报要在 4 小时内完成，且在知悉后最长不超过 24 小时；其后还有后续通报与最终报告的时间节点，公开口径中常见的两个是至少 72 小时与 1 个月。这套时间表看起来约束的是金融实体，但它会直接穿过合同，落到服务商的监控与留证能力上。

原因很简单：金融实体要在这么短的时间内向主管机关提交初次通报，就必须先知道发生了什么。而这个"知道"的很大一部分来自第三方服务商。如果服务商的告警是小时级的、日志只留了几天、事件联系人要靠工单排队，那么客户无论如何也凑不出 4 小时内的初报。因此，事件援助条款在实务中会被写成具体的响应时限与联系方式，而不是一句"配合处理"。

把时限反推成技术要求，大致是四件事。检测要足够快——从异常发生到告警触达责任人的时间，需要按分钟计，而不是按巡检周期计。告警要能定位到具体服务与影响范围——初报里要写受影响的功能、涉及的数据、波及的客户范围，这些不能靠临时翻日志。证据要当场可取——时钟要统一并与外部时间源对齐，关键日志要有只读或异地副本，避免事件本身把证据一起毁掉。责任链路要明确——谁的电话、什么时间能响应、多久给一次进展更新，这些要写进合同附件。

这里还有一个实务细节值得单独提：事件的"重大"分类本身由金融实体按其标准判定，服务商通常没有判定的权限，也不掌握对方的分类阈值。所以正确的做法不是替客户判断"这算不算重大"，而是在任何可能触及对方业务的异常发生时，都按同一套节奏通报——宁可多报一次被客户降级，也不要漏报一次让客户错过窗口。这需要在合同里约定清楚触发通报的异常类型清单，而不是笼统地写"发生重大故障时通知"。

还有一项容易被漏掉的配套义务：信息登记册。金融实体需要维护 ICT 第三方安排的信息登记册，并至少每年向主管机关报告一次。这意味着服务商提供的服务描述不能含糊——服务叫什么、属于哪一类、支持哪些功能、数据在哪些地点处理、用了哪些分包。描述一旦写进登记册，后续变更都会牵动更新流程。所以"我们说清楚自己的服务"这件事，不是一次性动作，而是每年都要重复一次。

签约前该向服务商问清楚的几件事

非欧盟的服务商要不要签这些条款？要。条款义务落在金融实体身上，他们会通过合同把要求传导给所有相关第三方，与服务商注册在哪里无关。拒绝签通常只有一个结果：这笔业务谈不成。真正的差别在于谈到什么粒度——支持关键或重要功能的安排条款更重，边缘性服务的条款可以简化。

"关键或重要功能"怎么判断？由金融实体按其自身业务连续性影响来判断，不是按服务器的重要性判断。同一台机器上跑的功能，可能一部分属于、另一部分不属于。判断结果会通过合同要求传导，服务商能做的是问清楚客户认定了哪些，而不是替客户下结论。

地点变更提前通知怎么落地？常见的落法是三条同时写：列出当前所有处理地点；约定变更前的最短提前通知期；约定通知的送达方式与接收人。技术侧要配套的是"地点变更"的定义——是机房搬迁才算，还是备份位置调整、运维接入地区变化也算，这个边界要在合同里明确，否则双方对同一件事的理解会差很远。

审计权会不会影响同机柜的其他客户？会，除非提前约定隔离方式。可行的处理包括限定审计的物理与逻辑范围、对其他客户标识做遮蔽、由服务商代为调取与复制材料。这些约定要写在合同里，并且提前知会运维团队，否则现场一定会卡住。

退出过渡期该留多久？按最慢的迁移环节定，而不是按惯例填一个数字。先算出全量导出的量级耗时、再算配置重建与验证的耗时、再加上数据校验与切换窗口，得出的才是可承诺的过渡期。反过来，如果算出来的数字长得离谱，说明要改的是技术方案而不是合同条款。

不签会怎样？对金融实体而言，缺失这些条款会影响自身合规状态，进而影响其主管机关的检查结果；对服务商而言，最直接的后果是失去这类客户。需要说明的是，这些条款本身大多是可谈的商业条款，谈的是粒度和边界，不是签与不签的二选一。

中小服务商在 DORA 链条里的真实位置

需要把话说准确：绝大多数中小服务商不是 DORA 的直接适用对象，也通常不会被指定为关键 ICT 第三方。真正被监管约束的是金融实体本身。中小服务商所处的位置是"间接受约束"——通过合同被传导。

这个位置有三个特征。第一，要求不是自己定的，而是客户带着模板来的，因此不同客户之间条款差异可能很大，同一个机房要同时满足几套不同口径。第二，传导是分层的：金融实体的合同对手是一级服务商，一级服务商再把自己的分包方拉进来，链条越往下，条款越是被层层转述，也越容易失真。第三，被传导的要求不会因为你规模小就减少，客户关心的是他自己的合规，不是你的体量。

在这个位置上，最现实的做法不是去研究法条，而是把四件可验证的资产准备好：一份准确的地点与分包说明、一套可执行的变更通知流程、一套真实可用的导出与迁移方案、以及一个全天候的事件联系与响应入口。这四件东西准备好，面对不同客户的模板都能填；准备不好，每一次尽调都会变成一次临时救火。

同时有一条红线：不要为了拿单承诺做不到的事。写进合同的地点通知期、过渡期、审计配合范围，都会在后续被真实触发。承诺一个做不到的提前通知期，比一开始说"做不到、但可以这样替代"要糟糕得多——前者会在第一次变更时变成违约，后者至少还有谈判空间。

最后一层是机会。条款门槛天然会筛掉一批答不上来的供应商，留下来的竞争更少、也更看重长期稳定而非短期价格。对中小服务商而言，把合同条款当作技术能力的一部分来建设，比把它当作法务的文字工作更划算。

本篇事实来源与核对方式：DORA 合同条款与事件时限

本篇涉及的法规信息可以按以下方式自行核对，建议在写进合同或提交给客户前再确认一次文本状态。主条例是《数字运营韧性法》条例 (EU) 2022/2554，2023年1月16日生效文本、自 2025年1月17日起适用，可在欧盟官方公报与 EUR-Lex 按条例编号检索原文；关于 ICT 第三方合同的一般要求见条例第 30 条；关于关键 ICT 第三方的认定标准见委托条例 (EU) 2024/1502（2024 年 5 月 30 日公布）。

适用实体范围、信息登记册的年度报告要求、重大 ICT 相关事件的通报时限（初次通报 4 小时内、知悉后最长 24 小时内，后续通报节点含 72 小时与 1 个月）、以及对关键 ICT 第三方可至全球日均营业额 1%、最长 6 个月的处罚口径，均以条例原文与欧盟监管机构发布的配套技术标准为准。不同成员国主管机关在执行细节上可能存在差异，具体项目的适用判断需要结合客户所在国的主管机关口径。

本篇讨论的是合同条款如何改写服务器选型、数据存放地、迁移与可移植性设计，属于采购与技术条款层面的分析，不构成法律意见，也不替代对条例原文与配套技术标准的直接引用。本篇未使用任何具体的境外服务器报价数字，涉及价格的部分一律建议以服务商官网实时报价或实时询价为准，因为价格主要受 CPU、内存、存储、带宽、IP 与线路等因素影响。涉及合同条款的措辞，最终仍应由双方法务按实际业务关系确定。