7.2 合同与SLA安全条款

7.2 合同与 SLA 安全条款

本节摘要：出了事故，图纸和台账都是内部证据，最终决定权责的是白纸黑字的合同。本节逐条审云服务合同里的关键安全条款——责任划分、审计权、数据返还与删除、泄露通知、可用性承诺——并示范怎么用条款倒推自家的运营时限，让合同从抽屉文件变成运营依据。

合同是安全责任的最后文本

共享责任模型（第一章）在厂商文档里是图，在合同里是字。图是解释性的，字才是约束性的：真正打起交道来，"你们文档里说厂商负责 X"永远说不过"合同里没写厂商承诺 X"。所以合同审查不是法务一个人的事——安全负责人必须在场，因为只有他知道哪些条款出事时真的要用。

审合同的正确姿势不是逐字读，是带着场景读：假设六个月后发生一次数据泄露，这份合同的每一条会怎么被援引？谁能查现场（审计权）、多久内通知（时限）、数据谁负责删（返还与删除）、赔多少怎么算（责任上限）。场景一过，关键条款自动浮出。

关键安全条款逐条审

责任与角色条款：合同必须写清双方各自是法规意义上的什么角色（控制者还是处理者），这决定通知义务与责任归属的方向。委托处理场景下，还应有一份处理约定（数据处理的内容、目的、期限、安全措施、子处理者约束）。缺这份附件的云合同，在严法域下等于把委托方拖进违规。

审计与证明条款：客户对厂商安全措施有验证权，但"上门审计"在多租户环境既不现实也不被接受——通行替代是"认证加报告"：厂商提供年度第三方审计报告与认证证书（8.2 的尽调材料），重大变更时补充说明。谈判要点不是"我要上门"，而是"你的证明材料覆盖范围与我担的数据是否对得上"。

数据返还与删除条款：合同终止时数据怎么办？必须明确：返还的格式与时限、删除的确认方式（是否出具删除证明）、备份中残留数据的处理口径（通常约定"备份按其轮换周期自然清除且继续受保密义务保护"）。这条与第三章的密码学销毁衔接——技术手段（作废密钥）要在合同里被承认为有效删除方式，否则会出现"技术上已不可读、合同上还要求物理擦除"的死结。

泄露通知条款：厂商发现涉及客户数据的安全事件后多久通知客户？行业谈判水平在"无不当迟延、通常七十二小时内"，客户要在此基础上叠加自己的法定通知义务（7.1 的差异变量二）倒推出总时限：厂商通知时限加自评时间必须短于最严法域的监管时限。这条是合同与第六章事件响应的直接接口。

可用性与补偿条款：SLA 的可用性百分比只是表象，实质是三层——测量口径（怎么算宕机：单区域还是全局、计划内维护算不算）、补偿形式（服务积分还是违约金，通常积分）、以及免责情形（不可抗力、客户配置错误的边界）。SLA 条款最深的坑是口径错位：客户以为的"可用"与厂商定义的"可用"不是一回事。

推演：一次条款谈判

背景：一家金融科技公司采购 SaaS 客服系统，厂商标准合同里泄露通知写的是"商业上合理的时限"，数据删除写的是"厂商按惯例处理"。

推演：金融监管对客户信息泄露的通知以小时计，"商业上合理"这种弹性表述等于把通知时限的决定权让给对方——红线。删除条款的"按惯例"则让数据终局状态不可知——红线。谈判目标：通知时限改写为"发现后七十二小时内书面通知，含事件时间、影响数据范围与已采取措施"；删除改为"终止后三十日内完成删除并出具书面确认，备份按轮换周期清除且持续受保密义务约束"；另加一条审计替代——厂商年度提供第三方安全报告，重大安全事件后三十日内提供专项说明。

结果对照：三条修订把三个不可控的弹性表述变成了可验证的义务。这就是合同谈判的安全视角——不追求条款漂亮，追求出事那天每一条都能被援引、被执行、被验证。

条款落地：从合同到运行

签完的合同要"长"进运营里，否则条款只是抽屉文件。三个动作：把厂商的通知时限写进自家事件响应预案的时钟里（第六章的时间线因此多一个外部刻度）；把合同承诺的可用性口径同步给监控团队，按同一口径测、按同一口径报告；把数据删除义务写进 6.3 的合规检查——到期合同清单自动触发"数据终局处置"流程。合同条款的运行态，才是合规域"问责留证"的实体。

条款审读的高频陷阱清单

合同审读的陷阱集中在措辞弹性上，列一张高频陷阱清单，逐条给出危险信号与替换写法。

清单的共性值得点破：所有危险措辞都是"把裁量权让渡给对方"的写法，所有应争取的写法都是"可验证、可援引"的写法。这正好与本册的主线咬合——合同谈判的尽头是证据标准，出事那天你拿得出什么，取决于今天写进了什么。

考试风格的场景判断

合同域的题常给一段条款描述让你挑毛病。练一道：题干说"云服务商承诺每月可用性 99.9%，未达标按服务费 10% 补偿"，问该条款作为业务连续性保障的不足。

分析要点三层：其一，口径未定义——99.9% 按单实例还是按服务整体、计划内维护是否剔除、按分钟还是按请求计，口径不同实际可用性差距巨大；其二，补偿与损失错配——10% 服务费与业务中断的真实损失通常差着量级，SLA 补偿从来不是损失的等价物；其三，它只覆盖可用性一个维度——数据安全与合规义务并不随可用性条款自动兑现。所以正确判断是：该条款可作为服务质量的参考，绝不能当业务连续性与安全的保障，真正的保障要靠架构冗余（4.4）加合同里独立的安全条款。看清"补偿是安慰剂"这层，合同域的选项就不容易被带偏。

本节要点回顾

• 合同是技术承诺的法律化：控制面里配得出的，还要在文本里写得住——出事那天能援引的只有写进合同的字。
• 通知、删除、审计三类条款是安全审的主战场：模糊措辞等于把裁量权让渡给对方，可验证、可援引是争取方向。
• SLA 补偿是安慰剂不是保障：口径未定义、补偿与损失错配、维度单一，三层不足决定它不能替代架构冗余。
• 数据处理协议看三权：谁能处理、为 何目的处理、如何退出——子处理者清单与变更通知是外包场景的命门。
• 谈判的尽头是证据标准：今天写进合同的条款，决定事故当天你拿得出什么。

补一个谈判桌上的现实问题：厂商不给改条款怎么办。云合同多数是格式合同，逐条改写的空间确实有限，但还有三个次优动作。其一，附件补充：正文不让动，安全附件与数据处理附录往往可谈——把泄露通知时限、审计报告清单塞进附件，法律效力与正文相同。其二，留档留证：厂商拒绝的条款要做书面记录（邮件、会议纪要），这份"我们要求过、对方拒绝"的记录在出事后是分散责任的重要证据，也是 7.3 残余风险登记的依据。其三，补偿性控制：改不动条款就在自建侧加控制——备份独立存放、出口侧 DLP，把条款缺口变成 7.3 登记册上"缓解加接受"的组合。谈判的本事不止于说服，也在于谈不动时把风险安放得清清楚楚。

条款审完了，最后一节补上决策工具：把法规要求与技术风险都折算成一个量，让管理层能拍板——风险评估与管理。