6.2 合规与法律法规
6.2 合规与法律法规
本节摘要：合规（Compliance）指组织的实践满足适用法律法规与行业标准的强制要求；在网络安全语境下，主要框架包括等级保护制度、数据安全法与个人信息保护法体系、欧盟 GDPR、以及行业性规范。本节鉴定合规与安全的真实关系（底线与上限）、主要框架的管辖逻辑与落地要点。承接 6.1 节的自愿风险管理，本节处理法定底线，通往 6.3 节的运营响应。
合规不等于安全，但安全绕不开合规
先立一个鉴定所的标准判词：合规是及格线，安全是实际水平。一家组织可以通过检查（合规）却依然会被打穿（不安全）；也完全可能做得比检查表要求的好得多（安全）却因某项手续缺失被处罚（不合规）。两者相关但不等价——检查表永远是昨天的威胁写成的，而攻击者研究的是明天的漏洞。
那为什么还要单独鉴定合规术语？因为三条现实理由：其一，违规本身有直接代价（罚款、停业、责任人追责），这条底线不由技术团队裁量；其二，合规框架把行业最佳实践翻译成了可检查的条款，顺着做能兜住常见错误的下限；其三，越来越多业务的准入资格（招投标、行业许可）直接挂钩合规证明——它是商业问题，不只是法律问题。
验明正身：主要框架的管辖逻辑
各框架的适用范围与考察重心不同，放一张对照表：
| 框架 | 性质 | 管什么 | 典型义务 |
|---|---|---|---|
| 等级保护 2.0 | 国家强制制度 | 境内网络运营者的信息系统 | 定级备案、按级建设整改、测评 |
| 数据安全法 | 国家法律 | 境内数据处理活动 | 数据分类分级、重要数据保护、风险评估 |
| 个人信息保护法 | 国家法律 | 个人信息处理活动 | 告知同意、最小必要、跨境传输规则 |
| GDPR | 欧盟法规 | 处理欧盟居民数据的组织（域外效力） | 合法依据、数据主体权利、72 小时泄露通报 |
| 行业规范（支付、医疗等） | 行业强制或契约 | 特定行业的系统与数据 | 行业特定的控制项与审计 |
域外效力值得专门一句：GDPR 与我国个保法的管辖都不止于"境内机构"——只要处理了受保护主体的数据，无论机构在哪，都可能落入管辖。跨国业务的数据流拓扑因此成了法务与安全共同审查的对象。
验明正身：落地的一般方法论
框架虽多，落地方法论高度趋同，抽出四步通用流程：
合规落地四步法（跨框架通用）: 1. 适用性判定: 梳理业务涉及的数据类型、地域、行业, 列出适用框架清单 2. 差距分析: 对照条款逐项盘点现状, 产出差距清单与整改优先级 3. 制度与控制项落地: 把条款翻译成组织自己的制度与技术控制 (这里与第 1 章 1.3 节的安全基线合流) 4. 持续证据运营: 合规要求"能证明", 日志、审批记录、测评报告要持续留存
第四步最容易被低估。多数合规条款的检查逻辑是"举证倒置"——组织要能拿出证据证明控制项在持续运转，而不是出事时口头承诺"我们一直有做"。这也解释了 3.3 节 SIEM 的另一个身份：它不仅是检测中枢，还是合规证据的集中产地（日志留存期限是多个框架共同的硬性要求）。
以个人信息处理的"最小必要"原则为例，看条款怎么翻译成工程约束：
条款: 收集个人信息应当限于实现处理目的的最小范围 工程翻译: 表单字段 → 与注册会计师逐字段核对必要性, 砍掉"先存着以后用" 接口返回 → 按调用方角色裁剪字段, 不整行返回用户表 内部权限 → 能看脱敏视图的岗位不给明文查询权 日志内容 → 日志里不打手机号全量, 打掩码 共同点: 每条都是 4.2 节最小权限思想在数据字段层的复刻
工程实践要点
把合规控制项映射到现有技术资产。 高效的做法是建立一张"条款 → 控制项 → 责任系统"的映射表：日志留存对应 SIEM 配置、访问控制对应 IAM 策略、漏洞管理对应 6.4 节的 SLA。一次技术建设支撑多条合规要求，避免每个框架各建一套——映射表做不出来，说明技术底座本身有缺口。
通报时限要进应急演练。 多个框架对数据泄露设有刚性通报时限（GDPR 的 72 小时最有名）。从"发现事件"到"完成对监管的通报"中间隔着确认、定级、取证、法务审核一整条链，没有演练过的组织几乎必然超时。把通报演练并进 6.3 节的事件响应演习。
⚠️ 常见坑：把合规外包等于把安全外包。请服务机构代写制度、代做测评，出事时法律责任主体仍是组织自己。外部服务能补人手，替代不了归属在组织内的理解与执行。
💡 关键直觉：读任何合规条款时先问"它防御的是哪种历史事故"——条款都是事故写的。理解了背后的事故，条款就从背诵负担变成了设计输入。
鉴定结论
- 合规是及格线不是安全水平，但它是不可裁量的法定底线与商业准入条件；
- 各框架管辖逻辑不同（地域、数据类型、行业），跨境业务必须做适用性判定；
- 落地四步法通用，证据运营（能持续证明）是被低估的重头；
- 条款的最优读法是还原它背后的历史事故；
- 底线立住了。下一节回到运营现场：事件真正爆发时，SOC 与事件响应的每个阶段该做什么。
附卷：条款到控制项的翻译练习
合规落地最难的一步是"翻译"：把法律语言翻成工程语言。练五个例子：
| 条款大意 | 翻译成控制项 | 责任系统 |
|---|---|---|
| 日志留存不少于法定期限 | 留存策略配置加到期归档审计 | SIEM 与日志平台 |
| 处理敏感个人信息需单独告知 | 产品流程埋点：敏感操作前弹独立告知页 | 业务前端与法务文案库 |
| 出境数据需安全评估 | 数据流拓扑盘点加出境通道清单化 | 数据目录与网关策略 |
| 发生泄露及时通知 | 通报预案进应急演练，模板预签 | 事件响应流程（6.3 节） |
| 委托处理需签订协议 | 供应商清单加合同条款核查表 | 采购与法务流程 |
翻译练习的价值在第三列——每条控制项都要挂到一个"责任系统"上，翻译不出来就说明现状缺基础设施，缺什么补什么，这就是差距分析的真实含义。第二列的另一个 hidden 好处：控制项是跨框架复用的（"日志留存"同时服务多个框架），一次建设多处合规，映射表让复用显性化。
证据运营的"三个容器"也值得固化成制度：工单容器（一切审批与操作留痕在系统里，口头承诺不算证据）、日志容器（技术控制项的自动运行记录）、报告容器（周期性自查与外部测评的书面结论）。检查来了按容器取证据，平时按容器做自查——合规从"运动式迎检"变成"日常式留痕"，靠的就是这三个容器常年不空。
附卷二：常见违规场景与第一反应
把执法通报里反复出现的场景收成一张表，逐条给出第一反应：
| 场景 | 违规点 | 第一反应 |
|---|---|---|
| 新系统收集了告知范围之外的数据 | 最小必要与告知义务 | 立即停止收集，评估已收数据的处置 |
| 旧系统仍在使用已离职承包商账号 | 账号治理缺位 | 当日禁用，倒查全部外部账号 |
| 出境传输走了未评估的通道 | 出境合规缺口 | 暂停通道，补评估或改道 |
| 泄露事件超过通报时限才上报 | 通报义务违约 | 先上报再完善，时限是刚性的 |
| 客户索要删除其数据，无响应流程 | 数据主体权利未落地 | 建删除受理流程，先个案后机制 |
表里"先上报再完善"一行值得加粗记忆：通报时限是所有合规义务里最刚性的一个，宁可先报初步情况再补细节，也不要等"查清楚再说"——查清楚的代价常常是逾期。五个场景的共同点也值得注意：没有一个源于高级攻击，全部源于日常管理失守。合规风险的样子通常是"懒"而不是"险"，这也是它最容易被低估的原因。
给本章收一个务实的尾：中小团队没有专职合规岗时，最经济的做法是指定一名工程师兼任"条款翻译"，每季度花半天把新法规速览一遍，只回答两个问题——"管不管我们""影响哪条控制项"。翻译件进 6.2 节的映射表，重大变化升级给法务。合规不是一次考试，是一年四次的简答，这套轻量机制足够让绝大多数团队不掉队。