2. 治理框架与数字化映射

网络安全治理数字化平台最容易失败的地方，不是技术选型，而是“政策—标准—平台”三者脱节：制度文件写得完整，平台里却找不到对应功能；平台采集了大量数据，却无法回答某条合规要求是否被满足。治理框架与数字化映射要解决的，正是把“纸面要求”翻译成“平台可执行对象”的问题。

一、映射的本质：三层翻译

治理要求通常以三种形态存在：政策（组织内部的管理意志，如《网络安全管理办法》）、标准（如 GB/T 22239 等级保护要求、ISO/IEC 27001 控制项）、合规要求（如《数据安全法》《个人信息保护法》的具体条款）。它们描述的是“应当做什么”，而平台需要的是“由谁、在什么条件下、对什么对象、执行什么动作、留下什么记录”。因此映射不是简单摘抄，而是一次结构化翻译，可拆为三层：

• 要求层：把政策条款拆成可判定的原子要求，每条要求有唯一编号、来源、适用对象、判定条件。
• 模型层：把原子要求落到平台的数据模型上，明确它作用于哪个资产、账号、数据字段或流程实例。
• 执行层：把模型层对象绑定到功能模块与流程规则，形成“可操作、可采集、可判定”的闭环。

三层之间是逐级收敛的关系：一条政策可能拆成多条原子要求，多条原子要求可能复用同一个数据模型，一个功能模块也可能同时支撑多条要求。这种多对多关系必须在映射表中显式记录，否则后续合规审计时无法追溯。

二、从条款到原子要求：拆解规则

拆解时遵循“一要求一判定”原则。以“重要数据出境应进行安全评估”为例，可拆为：识别重要数据资产、判定是否出境、触发评估流程、留存评估记录、评估未通过时阻断。每条原子要求应包含五个字段：要求编号、来源条款、适用对象、判定条件、证据形式。判定条件必须可被平台数据验证，例如“资产标签包含‘重要数据’且目的地在境外”，而不是“应当加强管理”这类无法判定的表述。

对于无法直接自动判定的要求（如“定期开展安全培训”），应转化为流程规则：由平台生成周期性任务、指定责任人、要求上传培训记录，并以“任务完成率”作为合规证据。这样，定性要求也能进入数字化闭环。

三、数据模型：让要求有“落点”

平台数据模型是映射的承载体。建议围绕治理要求建立四类核心实体：资产（系统、数据、账号、设备）、控制（对应标准控制项或原子要求）、证据（日志、截图、审批单、扫描报告）、责任（部门、角色、人员）。控制与资产之间是“适用”关系，控制与证据之间是“证明”关系，责任与资产之间是“归属”关系。

例如等级保护“身份鉴别”要求，可映射为：控制项 C-IDENT-01，适用资产为“三级系统账号”，证据形式为“登录日志与双因素认证配置快照”，责任角色为“系统管理员”。平台据此自动采集账号登录日志、比对是否启用双因素认证，并生成证据条目。这样，一条标准要求就变成了可查询、可告警的数据对象。

四、流程规则：把要求变成动作

映射的最后一步是流程规则。常见规则类型包括：触发规则（资产打上“重要数据”标签即触发评估任务）、校验规则（账号未启用双因素认证则标记不合规）、时限规则（评估任务 5 个工作日内未完成则升级提醒）、阻断规则（评估未通过时禁止数据导出）。规则应尽量以配置方式表达，而非硬编码，便于政策更新时快速调整。

五、映射关系可视化

下图展示一条政策条款如何逐级映射为平台功能模块、数据模型与流程规则，并最终形成合规证据。图中同时体现“多对多”复用关系：同一数据模型可支撑多条要求，同一功能模块可服务多个控制项。

六、落地要点与常见偏差

实践中常见三类偏差。第一类是“只映射不验证”：映射表建得很全，但没有把判定条件接入平台数据，导致合规状态仍靠人工填报。第二类是“颗粒度失衡”：把整份制度直接挂到一个功能模块上，无法定位具体缺口；或拆得过细，产生数百条无人维护的原子要求。建议单条原子要求对应 1～3 个平台对象，超出则继续拆分。第三类是“责任悬空”：要求映射到了模块，却没有绑定责任角色，流程触发后无人处理。

为控制偏差，可建立映射评审机制：由治理、业务、平台三方共同确认每条原子要求的判定条件是否可采集、证据是否可留存、责任是否可落实。评审通过后，映射表版本化入库，政策修订时以“变更影响分析”方式定位受影响的平台对象与流程规则，避免全量返工。