内容摘要：去年夏天，一家做跨境电商的朋友找我帮忙看合同。他们和一家东南亚物流公司签了数据交换协议，全文不到三页，没提加密标准，没写违约责任，连数据保留期限都是空白。结果对方系统被撞库，三万条客户手机号泄露，他们

去年夏天，安全一家做跨境电商的协议朋友找我帮忙看合同。他们和一家东南亚物流公司签了数据交换协议，范本全文不到三页，安全没提加密标准，协议没写违约责任，范本连数据保留期限都是安全空白。结果对方系统被撞库，协议三万条客户手机号泄露，范本他们才发现协议里连“通知义务”四个字都找不到。安全这事之后我整理了一份安全协议的协议基本框架，不是范本法律范本，而是安全技术层面必须落地的条款清单。

安全协议的协议第一段，得把“谁管什么”写死。范本很多协议喜欢用“双方应共同保障数据安全”这种话，等于什么都没说。具体到操作层面，得明确：甲方负责应用层加密，乙方负责传输通道加密；甲方持有密钥管理权限，乙方不得留存任何明文副本。去年某支付公司和云服务商的纠纷就出在这——协议写的是“服务商应确保数据安全”，结果云盘配置错误导致公开可读，法院判下来双方各担一半责任。谁配置、谁审计、谁备份，这些动作必须落到具体角色上。

加密算法别写“采用国际标准算法”这种虚词。直接写AES-256-GCM用于静态数据，TLS 1.3用于传输，密钥轮换周期不超过90天。我见过一份协议写“使用强加密”，结果对方用Base64编码当加密，还振振有词说“编码也是保护”。更隐蔽的坑是密钥托管——如果协议允许一方在紧急情况下绕过加密访问数据，那加密形同虚设。必须写明：任何密钥恢复操作需双人授权且全程审计。

数据分类分级不是合规摆设。协议里要有一张表，把“个人身份信息”“支付记录”“设备指纹”分开列，每类对应的存储位置、访问权限、脱敏规则都不同。比如手机号在日志里必须哈希后存储，但客服系统需要明文回拨——这种矛盾要在协议里提前解决，而不是等开发时拍脑袋。一家出行公司曾把乘客行程和司机身份混在同一张表，结果一个低权限账号能拉出全部历史订单。分类没做，权限控制就是空谈。

事件响应条款最容易被糊弄。“及时通知”是多久？两小时还是两天？我坚持写“确认泄露后4小时内书面通知，24小时内提供影响范围评估”。同时要约定取证配合义务：日志保留至少180天，且双方不得单方面删除。有个案例是乙方发现入侵后直接重装了系统，日志全丢，甲方连攻击入口都查不到。协议里得加一句：安全事件相关的原始数据在调查结束前冻结。

最后是审计权。不是“每年一次”这种频率问题，而是“甲方有权在提前7天通知后，对乙方安全控制措施进行现场或远程审计，乙方需提供最近90天的访问日志和配置变更记录”。没有审计权的安全协议就是一张纸。我见过最离谱的协议写“双方可委托第三方审计”，但没约定谁出钱、标准是什么、发现问题怎么整改。审计条款要具体到能执行：查什么系统、看什么日志、不合格的整改期限。

这些条款写进去，协议可能从三页变成十页。但省下的每一页，未来都可能变成事故报告里的一行“未定义”。安全协议不是法律文书，是技术操作的说明书。写不清楚，就别怪系统出事时没人认账。