3. 数据安全治理组织架构与职责矩阵设计

为什么“责任推诿”本质是矩阵缺位

中型企业常见现象：安全团队发现某张客户表未脱敏，业务说“系统是IT建的”，IT说“数据是业务在用”，运维说“策略是安全定的”。根因不是态度问题，而是同一项数据安全活动上出现了多个“负责”或零个“负责”。治理组织架构解决“谁在场”，RACI矩阵解决“谁对哪件事负什么责”。

本案例以一家约1200人、含电商与线下门店的中型企业为对象，设计三层治理组织，并用RACI矩阵把责任钉死在具体活动上。RACI定义如下，全篇保持一致：

• R（Responsible，执行者）：实际动手完成活动的人，每项活动至少1个，可多个。
• A（Accountable，批准者/最终责任人）：对结果负最终责任、有否决权的人，每项活动有且仅有1个，这是消除推诿的关键约束。
• C（Consulted，被咨询者）：事前提供专业意见，双向沟通。
• I（Informed，被通知者）：事后知悉结果，单向通知。

三层治理组织与职责边界

组织分三层，避免“委员会什么都管、执行组什么都扛”的常见失衡：

• 数据安全治理委员会（决策层）：由CDO任主任，成员含CIO、CISO、法务负责人、各业务线负责人。职责是批准策略与分级标准、裁决跨部门争议、审批高风险数据出境与共享、审议重大安全事件。不介入日常操作。
• 数据Owner（业务责任层）：按数据域设置，如客户数据Owner、交易数据Owner、商品数据Owner，由对应业务负责人担任。职责是确认本域数据分类分级、审批访问授权、决定共享范围、对本域数据安全结果负责。
• 数据安全执行组（执行层）：由安全团队牵头，含安全工程师、数据平台工程师、运维、法务专员。职责是落地技术控制、执行扫描与监控、处理事件、维护矩阵与台账。执行组不替Owner做业务决策。

RACI矩阵设计：把责任钉到活动上

矩阵的行是数据安全活动（不是部门），列是角色。设计时先列活动，再逐行填R/A/C/I，最后校验“每行A唯一”。以下为可直接落地的示例矩阵，覆盖数据生命周期关键活动：

落地校验：三步确认矩阵可用

1. 行校验：逐行检查A的数量，必须恰好为1。若为0，说明该活动无人最终负责；若大于1，说明会出现推诿或冲突。
2. 列校验：检查每个角色是否被过度填充。若某角色在超过70%的行中都是R，说明执行负荷集中，需要拆分或增补人力。
3. 争议回放：拿过去3个月真实发生的2~3次推诿事件，代入矩阵走一遍，看是否能明确落到唯一A。若仍模糊，说明活动颗粒度太粗，需拆细。

可落地的组织职责文档结构

矩阵确定后，输出一份正式文档，建议包含以下字段，便于后续审计与修订：

文档名称：数据安全治理组织与职责矩阵
版本：V1.0    生效日期：____    复审周期：每半年
1. 治理组织架构
   1.1 委员会：主任、成员、议事规则、决策权限
   1.2 数据Owner清单：数据域 / 姓名 / 职务 / 联系方式
   1.3 执行组：组长、成员、支撑范围
2. 职责边界说明
   2.1 委员会职责（批准/裁决/审批）
   2.2 Owner职责（确认分级/审批授权/决定共享）
   2.3 执行组职责（技术落地/扫描监控/事件处置）
3. RACI矩阵（见上表，含活动编号）
4. 争议升级路径
   执行组 → 数据Owner → 委员会（3个工作日内裁决）
5. 修订记录
   版本 / 日期 / 修订人 / 变更内容